Subject: RFC 2782: The format of SRV names

From: Stuart Cheshire <[email-masked]>
Date: Sat, 13 May 2000 18:27:29 -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 contain dots? 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)?

Is there a strong reason why the name of an SRV record is restricted to the
specific syntax of "_firstpart._secondpart.name"?

Stuart Cheshire <[email-masked]>

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

---

From: Paul A Vixie <[email-masked]>
Date: Sat, 13 May 2000 18:52:36 -0700

> "_smtp._http._tcp.example.com" (Mail tunnelled over http which runs over

those cases weren't considered when SRV was first specified.  they are
perfectly natural extensions, assuming an RFC is written about them.

> redundant and unnecessary to specify that in the SRV)?

redundant or not, the existing naming specification requires the _tcp there.

> 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.

---

From: Greg Hudson <[email-masked]>
Date: Sat, 13 May 2000 21:57:32 -0400

>> _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?

My reading would be "any name in
ftp://ftp.isi.edu/in-notes/iana/assignments/protocol-numbers",
although it could be clearer.

> 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)?

By my reading, no, none of these are allowed, except for the first one
on a local basis.

> 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.)

> Is there a strong reason why the name of an SRV record is restricted
> to the specific syntax of "_firstpart._secondpart.name"?

I don't know if there's a strong reason.  The authors were probably
not envisioning tunneling and other forms of multilayered transports;
I suspect the second part is only there for the sake of protocols like
SIP (RFC 2543) which can run over both TCP and UDP.