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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf