Subject: Re: Requirements for Service Discovery

From: Erik Nordmark <[email-masked]>(by way of Stuart Cheshire, <[email-masked]>)
Date: Fri, 2 Aug 2002 11:10:34 -0700

> Host names can be organized into domains and subdomains
> (e.g. host.sales.apple.com., host.eng.apple.com., etc.,
> or host.building1.apple.com., host.building2.apple.com., etc.,
> as the organization chooses).

This brings up an interesting issue.
Today we have one DNS search list for host names.

But as a user, if I use DNS for discovering services, it isn't
clear that I want the same search list for each service. 
For instance, when looking for a printer I probably want a searchlist
based on physical location e.g.
	floor1.building2.example.com floor2.building2.example.com

but when looking for a file server I might only care about 
organizational aspects i.e. have a searchlist of
	myorg.eng.example.com

Doesn't this imply a different search list per service?

One could of course say that such complexity indicates that the network is
"large" hence administered hence a different mechanism (web pages listing
printers etc) should be used. But I think assuming such a discountinuity 
as architecturally desired is a bad idea; even large companies with 
administrators want to minimize the cost of administering the network. 
Forcing
a large discountinuity when going from a "small" to a "large" network
seems counter to this. Compare this with the SLP approach where a "large" 
network implies introducing DAs but not doing service discovery in a 
completely
different fashion - that discontinuity is much much smaller.

The discontinuity issue is IMHO an indication that we don't yet agree
on the constraints for the problem we are trying to solve for service
discovery.

   Erik

---

From: Stuart Cheshire <[email-masked]>
Date: Thu, 8 Aug 2002 15:08:37 -0700

>I think I agree in principle, but disagree with choice of implementation:
>
>NIAS promotes abuse of the TXT RR, which has been accepted
>(abused?) by many as having no semantic definition

I agree that an explicit "attribute list" RR type would be good, but 
there is such opposition to creating any new DNS RR types that if you 
want to ship a product this decade, the only way to do it is with an 
existing type.

I am willing to be proved wrong on this. If NIAS were to be adopted as an 
IETF document, and DNSEXT were to prove willing to create a new RR type 
to better support it, then Apple would find a way to do a 
backwards-compatible migration over to the new standard.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org