Subject: Re: RFC 2782: The format of SRV names

From: Jeffrey Altman <[email-masked]>
Date: Sun, 14 May 2000 9:42:28 EDT

> > How about "_smtp._http.example.com"? (Mail tunnelled over http)
> > Along those lines, can the protocol or service contain dots? What about
> > "_smtp._http._tcp.example.com" (Mail tunnelled over http which runs over
> > tcp)?
> 
> those cases weren't considered when SRV was first specified.  they are
> perfectly natural extensions, assuming an RFC is written about them.
> 
> > Is there a strong reason why the name of an SRV record is restricted to the
> > specific syntax of "_firstpart._secondpart.name"?
> 
> that's all we envisioned or needed at the time of the specification.  we
> did not intend to limit future extensive specifications.

In the case of the Kerberos DNS SRV spec we needed to specify
subclasses.  Our conclusion was that it would in appropriate to
increase the number of segments due to the fact that eventually
someone will extend the resolv library to include a function to return
the SRV data which takes the "service" and the "protocol" as the only
parameters (without the underscore prefixes).  It would be unclear how
a multisegment service name would be passed to the function.

Our conclusion was that service names with multiple parts should be
separated with dashes.  

  _smtp-http._tcp.example.com

for instance.  

    Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
                 The Kermit Project * Columbia University
              612 West 115th St #716 * New York, NY * 10025
  http://www.kermit-project.org/k95.html * [email-masked]

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: Sun, 14 May 2000 9:44:02 EDT

> > What about "_telnet.example.com" (telnet only runs over tcp, so it
> > is redundant and unnecessary to specify that in the SRV)?
> 
> Again, bad.  If half the world decides the _tcp is "redundant and
> unnecessary" and half doesn't, we have an interoperability problem.
> (And it would be the fault of the first half, since they would be
> violating the RFC.)

Besides, there may eventually be a version of telnet that runs on top
of some protocol other than TCP.