On 29 Feb 2016, at 14:27, John R Levine <jo...@taugh.com> 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 <ph...@hallambaker.com> 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 _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
