On Fri, Mar 30, 2018 at 1:23 AM, Stuart Cheshire <chesh...@apple.com> wrote:
> 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? > > ... > > > 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:al...@example.com 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 <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). > 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
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
