[Ietf-not43] contact lookups: the elephant in my room

Andrew Newton anewton at ecotroph.net
Tue Apr 1 13:39:14 EST 2003


If we were working on a global white pages project, I'd be all for this. 
  But in the scope of domain registries/registrars, this would add 
complexity that does not yield adequate returns.

-andy

Peter Gietz wrote:
> Yes, index servers are a solution to the problem. Althought there had 
> been an attempt to define a standard directory indexing protocol (CIP, 
> RFC2651-2653) it never came beyond proposed standard and it would need 
> some twinkling for that. Anyway CIP would also specify things like 
> update times etc. and it can be implemented in a mesh, e.g. a 
> hierarchical structure of index servers that provide better privacy 
> handling but adds additional referrals before the client reaches the 
> data searched for. That would be a compromise between "ask one central 
> index service" and "ask all data servers you know of".
> 
> 3.1.7 BTW only forbids requirement of one central service where all data 
> agregation takes place. A mesh of indexes without a central superindex, 
> or index of indexes would not contradict 3.1.7. But beware the less 
> hierarchical the greater the number of referrals to chase.
> 
> One could even think of an LDAP implementation of such meshes without 
> using CIP, which might need specification of referral configuration, 
> special referral handling via controls and the like...
> 
> Instead of referencing CIP (which should be revised anyway) in the crisp 
> protocol docs or building meshes without CIP, you could reword the 
> requirements on distributed search to something like:
> 
> "Contact lookup given a fully-qualified domain name or IP address"
> 
> where the server with the appropriate contact data of that domain could 
> be looked up via DNS SRV. That seems better to me than getting rid of a 
> MUST on contact lookup.
> 
> Or would this be too easy and am I not seing the proper use cases? This 
> is not the first discussion of these issues on this list, but I am not 
> aware of a lot of uses case discussion on this. Sorry if I missed 
> something.
> 
> Cheers,
> 
> Peter
> 
> 
> 
> 
> Eric A. Hall wrote:
> 
>> on 4/1/2003 5:01 AM william at elan.net wrote:
>>
>>
>>> On this topic, the only easy way to do distributed search is to have 
>>> unified index server.
>>
>>
>>
>> I agree that this is feasible, and its an approach I've advocated too. 
>> But
>> it's really an ad-hoc solution to the problem, and is not viable as the
>> standards-track solution to the problem. For example, if this were the
>> standards-track solution, there would have to be a universally available
>> catalog server, there would have to be specs on cache times, there would
>> have to be mandates for replication, and so forth. All of this is likely
>> to happen through ad-hoc free-market development, but its not 
>> practical to
>> force this as "the one true way".
>>
>> There's a couple of other secondary factors here. One factor is that 
>> using
>> a catalog server may not even require any protocol specification; in the
>> case of the LDAP-WHOIS approach, you could use existing LDAP search
>> mechanisms to search *any* attribute in the cache (not just email 
>> address,
>> but city, phone number, whatever). Describing how to do searches of any
>> given attribute (or all of them) would be redundant and possibly even
>> harmful (if we don't specify "begins with" queries, are they legal?).
>>
>> Anyway, I agree with you that this is likely to be the practical solution
>> in the long-term, but I don't think its something we should try to
>> standardize at this point.
>>
> 




More information about the Ietf-not43 mailing list