On Sep 11, 2011, at 6:23 PM, Joe Touch wrote:
On Sep 11, 2011, at 2:09 PM, Keith Moore wrote:
On Sep 11, 2011, at 4:46 PM, Joe Touch wrote:
We've been discussing this in the Transport area lately.
DNS SRVs are defined in RFC 2782 as I have described. Additional info is
passed in TXT records for current DNS SRVs.
I.e. what I have proposed is what is both current spec and current
widespread practice.
Before proposing a change (which would need to happen before we would use
it in a new spec anyway), is there something the current syntax (and use of
TXTs for additional info) cannot do that you want?
Why use SRV records at all if you also need TXT records to convey part of
the information needed by apps (and thus, have to do multiple queries for
the same level of information)? Why not just encode all of the information
in TXT records?
The SRV records provide a standard way of mapping a service (as per the IANA
ports and service names registry) on a specific transport to a hostname and
port number.
The TXT records are linked to the SRV records, and provide additional
bootstrap info that the service does not provide in-band.
You did not answer the question.
If you're looking for a more generic database query system, you might
consider using LDAP rather than the DNS.
I'm not looking for anything in particular. I just don't see any
justification for insisting that SRV records always be used with RFC 2782 style
labels. Nor do I immediately see any justification for using SRV at all if the
application also needs to look up TXT records to get the service's profile.
Of course, one of the problems with using SRV more widely (in addition to
backward compatibility issues) is that in many cases what's desired is not
merely to map a service name (as defined in the IANA registry and equated with
a default port) onto an address and port, but rather, to provide instructions
as to how a service may be accessed - a service profile, if you will. So I can
certainly see why SRV alone would not do the job. What I don't immediately see
is why it's worth the trouble of using SRV at all for those cases when it won't
do the job.
(LDAP by itself wouldn't solve this problem either - you'd still need to define
a way to represent an application service profile in LDAP. And if the name of
the service is reasonably represented by a DNS name, then arguably, the profile
belongs in DNS. Or at least, a pointer to the profile belongs in DNS. The
last thing we need is to have LDAP and DNS providing conflicting information
about what a DNS name means.)
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf