If folks agree that this [RFC6355] adequately serves the registry
function for the
_service, second-level underscore name for SRV and URI, that's fine.
As of Berlin, I thought I heard that there was (still) deviations.
I can believe it, but as I suggested, if that's the case, register the
rogue names in the service name registry. It's FCFS, not a big deal.
says that it already has updated the SRV RFC. This provide yet-another
example why we should aggressively deprecate use of RFC access via
https://www.ietf.org/rfc/
Use the rfc-index.txt that comes along with the rsync'ed RFCs. It has
what is supposed to be a complete list of what updates and obsoletes what.
For URI records RFC 7553 says they're either named the same as SRV
records, or they use enumservice names from the Enumservice
Declaring a namespace as the union of two, independently-maintained
registries is a very efficient way to encourage -- actually in theoretical
terms, it guarantees -- collisions.
I suppose, but since the two registries exist and the URI RFC says to use
both of them as _name, that horse has left the barn. In any particular
context a URI record will either be used to look up a regular service or
an enumservice but not both so if there were a collision, it wouldn't
matter since the context would tell you which one is intended. The RFC's
authors are Patrik and Olaf, so we could ask them if that's what they had
in mind. At this point there are only four live proto names and two dozen
enumservice names, so by my eyeball inspection, there's currently no
collisions.
This line of concern, I think, reduces to the view that the recent versions
of the _underscore draft espoused, which is that the primary concern needs to
be the top-level underscore name, since it draws from a 'global' namespace.
So far, so good.
For any interesting top-level underscore name -- _proto set for SRV are /not/
sufficiently interesting (distinctive) which is why we need to worry about
their associated _service string -- any underscore names at a lower level are
only of interest to the specification defining them. That is, the global
effort can ignore them.
Is there an extra /not/ in there? Service names only appear as child
names of _proto so the _proto are the only ones that can have collision
problems.
Regards,
John Levine, jo...@taugh.com, Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
