--On Tuesday, January 7, 2020 17:31 -0700 Peter Saint-Andre <stpeter@xxxxxxxxxxx> wrote: >... >> 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. I was trying to avoid getting dragged down into details, both in the hope of keeping the message as short as possible and to avoid a distracting side-discussion, but, yes r-components and the issues associated with pass-through information for those URN namespaces that resolve to one or more URLs were examples that crossed my mind. >> 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. If we don't want both the discussion and the document to drag out, I believe so. best, john
