Subject: RFC 2782: SRV naming convention

From: Stuart Cheshire <[email-masked]>
Date: Fri, 15 Jun 2001 18:33:13 -0700

>   Proto
>     The symbolic name of the desired protocol, with an underscore
>     (_) prepended to prevent collisions with DNS labels that occur
>     in nature.  _TCP and _UDP are at present the most useful values
>     for this field, though any name defined by Assigned Numbers or
>     locally may be used (as for Service).  The Proto is case
>     insensitive.

Does this really mean ANY name?

How about "_smtp._http.example.com"? (Mail tunnelled over http) Along 
those lines, can the protocol or service be further decomposed into 
layers? What about "_smtp._http._tcp.example.com" (Mail tunnelled over 
http which runs over tcp)?

What about "_telnet.example.com" (telnet only runs over tcp, so it is 
redundant and unnecessary to specify that in the SRV)?

Paul Vixie pointed out to me in private conversation over lunch one day 
that I was putting far too much importance on this naming convention. 
(Though I'm not the only one to make that mistake). Paul pointed out to 
me that this naming convention is merely that -- a convention. It is not 
a strict requirement of the SRV record type. In fact it's not a 
requirement of the SRV record type at all, merely an associated 
recommendation. This RFC recommends that future standards using SRV 
records follow this naming convention, and that's a good recommendation, 
but not an absolute rule.

It is certainly wise to follow this convention, because if there is 
ambiguity about what name a client of a particular service should be 
looking for, then things aren't going to interoperate very well.

However, if some future standard clearly defines how to name an SRV 
record for some specific use, then that future standard is not bound to 
follow this specific naming convention.

I suggest adding the following text:

>This naming convention is not a strict requirement of the SRV
>record type. It is strongly recommended, but not required, that
>future standards using SRV records follow this naming convention
>where appropriate, because interoperability is improved when there
>is no ambiguity about what name a client should be looking up.
>However, if some future standard clearly defines how to name an SRV
>record for some specific use, then that future standard is not
>bound to follow this specific naming convention.

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

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Jeffrey Altman <[email-masked]>
Date: Mon, 18 Jun 2001 14:11:16 EDT

> Something like that might limitations of the SRV format perceived by
> several WG -- notably SIP and IMPP. The problem occurs when a service
> can run on several protocols. For example, SIP can run over UDP, TCP and
> possibly SCTP or TLS; IMPP services can be provided through SIMPLE,
> APEX, PRIM and possibly others. How can we discover not just a server
> name and a port, but also a transport protocol and possibly an
> application protocol? If a given client only supports some of the
> options, how do we restrict the discovery to the server that support
> common options?
> 
> Another extension that has been suggested is to take account some form
> of locality, as in "I am in subnet number X, in domain example.com, and
> I want to find an LDAP server; which is the most appropriate one?"

Use a TXT record to query the protocol types and then use a SRV query
to determine where that service/protocol is located.

 Jeffrey Altman * Sr.Software Designer      C-Kermit 7.1 Alpha available
 The Kermit Project @ Columbia University   includes Secure Telnet and FTP
 http://www.kermit-project.org/             using Kerberos, SRP, and 
 [email-masked]          OpenSSL.  SSH soon to follow.