Re: [urn] Feedback on draft-ietf-urnbis-semantics-clarif-03

[Sean Leonard <[e-mail]>]

Quick question on this feedback:

> On Apr 27, 2016, at 8:02 AM, Julian Reschke <[e-mail]> wrote:
> 
> Hi there,
> 
> I was asked off-list to review the current drafts, given my interest in RFC 3986 in the past.
> 
[...]

> Appendix A.  Background on the URN - URI relationship
> 
>   The Internet community now has many years of experience with both
>   name-type identifiers and location-based identifiers (or "references"
>   for those who are sensitive to the term "identifier" such as many
>   members of the library and information science communities..  The
> 
> s/.././
> 
>   primary examples of these two categories are Uniform Resource Names
>   (URNs [RFC2141] [RFC2141bis]) and Uniform Resource Locators (URLs)
>   [RFC1738]).  That experience leads to the conclusion that it is
>   impractical to constrain URNs to the high-level semantics of URLs.
>   The generic syntax for URIs [RFC3986] is adequately flexible to
>   accommodate the perceived needs of URNs, but the specific semantics
>   associated with the URI syntax definition -- what particular
>   constructions "mean" and how and where they are interpreted -- appear
>   to not be.  Generalization from URLs to generic Uniform Resource
>   Identifiers (URIs) [RFC3986], especially to name-based, high-
>   stability, long-persistence, identifiers such as many URNs, has
>   failed because the assumed similarities do not adequately extend to
>   all forms of URNs.  Ultimately, locators, which typically depend on
>   particular accessing protocols and a specification relative to some
>   physical space or network topology, are simply different creatures
>   from long-persistence, location-independent, object identifiers.  The
>   syntax and semantic constraints that are appropriate for locators are
>   either irrelevant to or interfere with the needs of resource names as
>   a class.  That was tolerable as long as the URN system didn't need
>   additional capabilities (over those specified in RFC 2141) but
>   experience since RFC 2141 was published has shown that they are, in
>   fact, needed.
> 
> I don't believe this appendix is way too vague to be helpful.


I am confused by this sentence. Is that a typo? Are you saying that this Appendix is too vague to be helpful, and therefore should be removed? Or are you saying it is not too vague; it is helpful; therefore, keep it in the draft?

Sean