On 2/6/2004 11:20 AM, John C Klensin wrote:
On a devil's advocate basis, let me respond to your DHCP comment
above by saying "it all depends on how DHCP is used and in which
environments... and that it may be lots more appropriate for
some than for others". Specifically,
<snip>
The real problem with Submit (and many other potential SRV and
DHCP targets/values), it seems to me, is that someone has to
make a policy decision about the semantics of the server or
service that is being searched for.
That's exactly correct. That's also precisely why there are so many
configuration services available, and why they all have different favored
deployment scenarios. The market HAS spoken -- they want ALL of the
different configuration services! Therefore, application services which
want to provide autoconfiguration that works in every scenario need to
support the whole array. Of course, in the usual case, the application
services support none of them explicitly.
The SRV draft essentially aims for the specific usage scenario which I
personally believe to be the most common: the user has an email address,
and they want to fetch and send email associated with that address. That
scenario reflects people on ISP accounts, people in typical job/work
environments, and so forth. It does not consider all of the other
scenarios. For the covered usages, keying off the domain part is the
appropriate mechanism, but also implicies that the user can obtain this
data while roaming on different subnets within an organization or remote
networks (assuming that the infrastructure allows it, which isn't the
concern of the draft).
If anybody wants to define algorthims and whatnot for other mechanisms
(DHCP, LDAP, ServLoc, whatever), feel free to define them.
--
Eric A. Hall http://www.ehsco.com/
Internet Core Protocols http://www.oreilly.com/catalog/coreprot/