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

[Julian Reschke <[e-mail]>]

On 2016-05-04 18:26, Sean Leonard wrote:
> 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?

Sorry.

I *believe* it is too vague to be helpful.

Best regards, Julian