Subject: Re: [DNSOP] SRV-related _underscore registry (was Re: Call for Adoption: draft-crocker-dns-attrleaf)

From: Stuart Cheshire <[email-masked]>
Date: Thu, 29 Mar 2018 22:23:22 -0700

On 29 Feb 2016, at 14:27, John R Levine <[email-masked]> wrote:

> The existing port and service registry already has all of the _service names, and is updated as people invent new services. What's the benefit of duplicating it rather than just pointing to it?

I agree. Where possible, it’s better to add to an existing registry, rather than creating an entirely new (but mostly overlapping) one.

When we wrote RFC 6335 we made a conscious choice that 15 ASCII characters is short enough to be efficient over the air and not burdensome to implement in constrained devices, yet long enough for the set of available identifiers to be effectively unlimited, and long enough to allow for reasonably mnemonic identifiers where that is desired (at least in English, which we deemed acceptable since these are protocol identifiers, not generally seen by end users).

A consequence of this abundant namespace is that it’s okay to have some identifiers in it that are not applicable in all contexts, and that’s preferable to having separate per-context namespaces, which risks having some identifier string appear in more than of those namespaces, with unrelated meanings. When RFC 6335 unified the two separate identifier namespaces there were four such unintended overlaps (esp, hydra, recipe, xmp), which fortunately were resolved amicably: <https://tools.ietf.org/html/rfc6335#section-10.1>.

On 1 Mar 2016, at 09:55, Phillip Hallam-Baker <[email-masked]> wrote:

> The _service._protocol approach in SRV is rather obviously a mistake. Given the function of SRV, the protocol tag should have been on the RIGHT hand side of the RR type, not the left. The choice of UDP or TCP should be an OUTPUT from the service discovery process, not an input.

We thought about this too, and concluded that few application protocols offer the luxury of running over both TCP and UDP (NFS and DNS being two examples that come to mind).

In reality, most application protocols are defined as a bundle, such as application-protocol-over-UDP-over-IP, or application-protocol-over-TCP-over-IP, or application-protocol-over-TLS-over-TCP-over-IP. The application protocol name implicitly encodes the transport it expects. In an iPhone looking for AirPrint (i.e., IPP) printers were to be told that it had found an AirPrint printer that supported IPP, but only over SCTP, or DCCP, or whatever, the iPhone would simply fail to print on it, because the iPhone doesn’t implement IPP-over-foo.

In retrospect, I wish we had defined all SRV service type identifiers to be simply “_app-proto._srv”, and let the specification of the “_app-proto” application protocol state what transport layer stack it requires. In practice what happens is that TCP-based protocols use “_tcp” and everything else uses “_udp” as the catch-all for all non-TCP protocols. RFC 6763 talks about this: <https://tools.ietf.org/html/rfc6763#section-7>.

A common convention that seems to be emerging is that application protocols that run over TLS are given SRV service type identifiers ending in “-tls”, such as, “_dns-update-tls._tcp” and “_dns-push-tls._tcp”. This is just a convention for mnemonic convenience though, and not every service uses it. For example, IPP over TLS uses service type “_ipps._tcp”. When looking for AirPrint (i.e., IPP) printers a modern iPhone will browse for both “_ipp._tcp” and “_ipps._tcp”, and show a unified list to the user. In some ways this is not ideal, but engineering is often a pragmatic choice between imperfect solutions and picking the less bad one. Moving forward we expect that most application protocols that need security will only run over TLS, making this “dual personality” behavior rare.

Stuart Cheshire

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 30 Mar 2018 11:18:00 -0400

On Fri, Mar 30, 2018 at 1:23 AM, Stuart Cheshire <[email-masked]> wrote:

> > The existing port and service registry already has all of the _service
> names, and is updated as people invent new services. What's the benefit of
> duplicating it rather than just pointing to it?
>
> ​...
>
>
> A consequence of this abundant namespace is that it’s okay to have some
> identifiers in it that are not applicable in all contexts, and that’s
> preferable to having separate per-context namespaces, which risks having
> some identifier string appear in more than of those namespaces, with
> unrelated meanings. When RFC 6335 unified the two separate identifier
> namespaces there were four such unintended overlaps (esp, hydra, recipe,
> xmp), which fortunately were resolved amicably: <
> https://tools.ietf.org/html/rfc6335#section-10.1>.

​This is key. The IANA registries have two different functions:

1) To stop anyone else taking 'my' name and using it. for a different
purpose.
2) To tell people where to find the authoritative specification for the use
of my name.

​So for example, I have a protocol assignment mmm. Which means that
interpretation of _mmm._tcp.example.com is unambiguous.

What about mmm://example.com/ ?
​
​Right now I am not using that identifier and I am not sure that I will
ever use it or what the syntax would be if I do. It might well be that
mmm:[email-masked] would be better. Right now, I just do not know.​

But what I do know is that nobody else should be allowed to register mmm:
URIs.

On 1 Mar 2016, at 09:55, Phillip Hallam-Baker <[email-masked]> wrote:
>
> > The _service._protocol approach in SRV is rather obviously a mistake.
> Given the function of SRV, the protocol tag should have been on the RIGHT
> hand side of the RR type, not the left. The choice of UDP or TCP should be
> an OUTPUT from the service discovery process, not an input.
>
> We thought about this too, and concluded that few application protocols
> offer the luxury of running over both TCP and UDP (NFS and DNS being two
> examples that come to mind).
>

​Well, I said it was a mistake but not one that you could have fixed. By
the time DNS Discover was written, oceans had flowed under that bridge.​
Might as well fix the spelling of the referer field.

​But what is being proposed now does look like it might well create a use
for the sub-field.

draft-ietf-uta-smtp-tlsrpt-17 ​

​What they are looking to do is to specify a mechanism that allows people
to report when a mail server has its TLS misconfigured. It is clearly a
purpose for which a prefixed field is correct. It is also clearly a purpose
which should be encouraged as best practice.

* Why limit reporting of SMTP server misconfiguration to TLS?
* Surely every protocol should allow for service specific feedback?​

​I do not want to roll this in to the specification of my Web Services
because that makes it impossible to report 'your service is down'.

So it is a separate something and hence a separate protocol field is
appropriate:

_smtp._report.example.com​