Finally catching up. >For any use of an underscore first-level name, that also uses a >second-level name, the authority over that second-level belongs entirely >and solely to that first-level name. > > ..._my-second._firsta.example > >and > > ..._my-second._firstb.example > >have no conflict.
Aha. That's somewhat different from what I gathered you were saying before. >In the case of SRV, for example, that means that for the core SRV >template specification document: > > 1. The first-level, _Proto name assignment text has to be updated >to use the new, Attrleaf global table. > > 2. The second-level _Service name assignment text can remain >unchanged, per RFC 6335. Seems right. If we want to deal with URI names it needs a similar update to RFC 6117 to put the enumservice type names into the attrleaf table with a pointer back to the enumservice registry for the second level subtypes. >As for the proposed 'common, second-level' table... > >Given that this seems to reduce the Attrleaf 'common second-level' table >to only _adsp, I think it best to remove that table entirely from the >main attrleaf document, and instead have the separate fixup document >contain some text specific to the DKIM document's domain naming scheme, >to indicate how future second-level names should be assigned. Since >ADSP is historic, specifying modification to it doesn't make sense to >modify it. Agree, no need to set up a registry for one dusty name. R's, John _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
