On 1/7/20 12:11 PM, John C Klensin wrote: > Instead, I was trying to raise a far more narrow question: Given > that RFC 3986 separates names and locators and that we have > already had confusion about what is appropriate in URNs based on > the language there, does this document make things worse? I > think it may. Even a statement fragment (from the first > paragraph of Section 3 and inherited from 7320) like "...as > links that are exchanged as part of the protocol, rather than > statically specified syntax" are inconsistent with the use of > keyword values in some URN namespaces as static indicators. Indeed, it's not immediately obvious what a "protocol" would be in the case of many URN namespaces, precisely because the URN is a name rather than a locator. > If > you want to ask the slightly different question of whether, if > RFC 7320 made things worse, does this I-D make things even worse > than that, I don't have an easy answer except to note at least > one example: The last paragraph of Section 2.3, which appears to > be new, says > >> Extensions MUST NOT define a structure within individual URI >> components (e.g., a prefix or suffix), again to avoid >> collisions and erroneous client assumptions. > > But, as I understand that rule, it is precisely what some rules, > and provisions for namespace-specific rules, in RFC 8141, do. It's not clear to me whether a URN namespace counts as a 7320bis protocol extension (which can "offer new capabilities that could apply to any identifier, or to a large subset of possible identifiers"); however a definition of, say, URN r-components would probably fit the bill, and such a definition might well define structures that would violate the aforementioned MUST NOT. > Again, the solution at this point appears to be either to be > much more careful about binding the statements in the I-D to the > concept of ownership or to indication that this specification > does not apply to URNs (or, if preferred, to what 3986 describes > as "name" URIs) at all. That might be the best approach. Peter
