On 11/14/2015 12:28 PM, John Levine wrote: > RFC 6335 came out five years after the > first version of your draft and would have been a fine opportunity to > de-mess.
Given what it was trying to do, I don't think they could reasonably have tackled this topic. However I suppose it's nice that they sought to enfoce a "no underscores" rule for their table, since it facilitates the re-use of the names under SRV. The more serious problem, IMO, is that the SRV spec has such a fuzzy spec for the alternative names that might be used besides _udp and _tcp. I tried to accommodate this actively in the earliest versions of the draft -- even to the point of having the registry be hierarchical -- but seem to have fallen back to something as fuzzy as the SRV spec itself. I finally decided flat organization suffices but didn't care the requirement for explicit registration forward. Yuck. At this point, after looking at the relevant SRV spec text again, I believe the only respectable solution is to change that part of the SRV spec and dictate that the service names must be registered in this IANA table. I do not see a "inherited from the IANA service names table" model as being viable, since it almost encourages name collisions. > Assuming the places in the draft where you refer to the left-most name > you mean the right-most name for what gets registered, it needs to > make clear what names enable what sub-names. oh my. ummm. yes. i only wish i could attribute this to alcohol or dyslexia. > For example, if a name is _tcp or _udp, all of the names in the RFC > 6335 service name registry are eligible. This includes _soap-beep and > _xmlrpc-beep which are in that registry, and _certificates and _crls > which should be but aren't. But RFC 2782 is pretty casual about what > protocols other than _tcp and _udp correspond to SRV names. IANA has > a protocol registry at > http://www.iana.org/assignments/protocol-numbers/protocol-numbers.xhtml > but a lot of the entries are not obvious candidates for SRV. On the > other hand, RFC 5509 makes _sip a SRV protocol name even though it's > also a service. > > DKIM currently allows _adsp as a subtag, probably not worth making a > registry, since there don't seem to be any other likely DKIM subtags. > Similarly there's _report._dmarc which seems to be a one-off. For got that. Thought it was indepedent. ADSP is now removed from the draft. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
