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

[Phillip Hallam-Baker <[e-mail]>]

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

> On 29 Feb 2016, at 14:27, John R Levine <[e-mail]> 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:[e-mail] 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 <[e-mail]> 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​