draft-ietf-urnbis-semantics-clarif-03.txt   draft-ietf-urnbis-semantics-clarif-04.txt 
Uniform Resource Names (urnbis) J. Klensin Uniform Resource Names (urnbis) J. Klensin
Internet-Draft February 5, 2016 Internet-Draft June 8, 2016
Updates: 3986 (if approved) Updates: 3986 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: August 8, 2016 Expires: December 10, 2016
URN Semantics Clarification URN Semantics Clarification
draft-ietf-urnbis-semantics-clarif-03.txt draft-ietf-urnbis-semantics-clarif-04
Abstract Abstract
Experience has shown that identifiers associated with persistent Experience has shown that identifiers associated with persistent
names have properties and requirements that may be somewhat different names have properties and requirements that may be somewhat different
from identifiers associated with the locations of objects. This is from identifiers associated with the locations of objects. This is
especially true when such names are expected to be stable for a very especially true when such names are expected to be stable for a very
long time or when they identify large and complex entities. In order long time or when they identify large and complex entities. In order
to allow Uniform Resource Names (URNs) to evolve to meet the needs of to allow Uniform Resource Names (URNs) to evolve to meet the needs of
the Library, Museum, Publisher, and Information Science communities the Library, Museum, Publisher, and Information Science communities
and other users, this specification separates URNs from the semantic and other users, this specification separates URNs from the semantic
constraints that many people believe are part of the specification constraints that many people believe are part of the specification
for Uniform Resource Identifiers (URIs) in RFC 3986, updating that for Uniform Resource Identifiers (URIs) in RFC 3986, updating that
document accordingly. The syntax of URNs is still constrained to document accordingly. The syntax of URNs is still constrained to
that of RFC 3986, so generic URI parsers are unaffected by this that of RFC 3986, so generic URI parsers are unaffected by this
change. change.
Advice to RFC Editor and WG
Note to RFC Editor: Various comments in drafts of this documents were
written to describe the situation in, and perspective of, the WG.
They will need careful checking for tense if the document is queued
for publication as an RFC.
WG participants: please do not spend time reporting or discussing
that type of obvious editorial issues or, e.g., the amount of white
space after periods -- the RFC Production Center are really very good
at their jobs.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 8, 2016. This Internet-Draft will expire on December 10, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Pragmatic Goals . . . . . . . . . . . . . . . . . . . . . . . 4 2. Pragmatic Goals . . . . . . . . . . . . . . . . . . . . . . . 4
3. The role of queries and fragments in URNs . . . . . . . . . . 4 3. The role of queries and fragments in URNs . . . . . . . . . . 5
4. Changes to RFC 3986 . . . . . . . . . . . . . . . . . . . . . 5 4. Changes to RFC 3986 . . . . . . . . . . . . . . . . . . . . . 6
5. Actions Occurring in Parallel with this Specification . . . . 5 5. Actions Occurring in Parallel with this Specification . . . . 7
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 9
10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 9
10.2. Informative References . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . 9
Appendix A. Background on the URN - URI relationship . . . . . . 9 Appendix A. Background on the URN - URI relationship . . . . . . 10
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 9 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 11
B.1. Changes from draft-ietf-urnbis-urns-are-not-uris-00 B.1. Changes from draft-ietf-urnbis-urns-are-not-uris-00
(2014-04-07) to -01 (2014-07-03) . . . . . . . . . . . . 9 (2014-04-07) to -01 (2014-07-03) . . . . . . . . . . . . 11
B.2. Changes from draft-ietf-urnbis-urns-are-not-uris-01 B.2. Changes from draft-ietf-urnbis-urns-are-not-uris-01
to draft-ietf-urnbis-semantics-clarif-00 (2014-08-25) . . 10 to draft-ietf-urnbis-semantics-clarif-00 (2014-08-25) . . 12
B.3. Changes from draft-ietf-urnbis-semantics-clarif-00 B.3. Changes from draft-ietf-urnbis-semantics-clarif-00
(2014-08-25) to -01 . . . . . . . . . . . . . . . . . . . 10 (2014-08-25) to -01 . . . . . . . . . . . . . . . . . . . 12
B.4. Changes from draft-ietf-urnbis-semantics-clarif-01 B.4. Changes from draft-ietf-urnbis-semantics-clarif-01
(2015-02-14) to -02 . . . . . . . . . . . . . . . . . . . 11 (2015-02-14) to -02 . . . . . . . . . . . . . . . . . . . 13
B.5. Changes from draft-ietf-urnbis-semantics-clarif-02 B.5. Changes from draft-ietf-urnbis-semantics-clarif-02
(2015-08-10) to -03 . . . . . . . . . . . . . . . . . . . 11 (2015-08-10) to -03 . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
B.6. Changes from draft-ietf-urnbis-semantics-clarif-03
(2016-02-07) to -04 . . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
The Generic URI Syntax specification [RFC3986] covers both locators The Generic URI Syntax specification [RFC3986] covers both locators
and names and mixtures of the two (See its Section 1.1.3) and and names and mixtures of the two (See its Section 1.1.3) and
describes Uniform Resource Locators (URLs) -- first documented in the describes Uniform Resource Locators (URLs) -- first documented in the
IETF in RFC 1738 [RFC1738] -- as an embodiment of the locator concept IETF in RFC 1738 [RFC1738] -- as an embodiment of the locator concept
and Uniform Resource Names (URNs), specifically those using the "urn" and Uniform Resource Names (URNs), specifically those using the "urn"
scheme [RFC2141], as an embodiment of the names that do not directly scheme [RFC2141], as an embodiment of the names that do not directly
provide for resource location. This specification is concerned only provide for resource location. This specification is concerned only
about URNs of the variety described in RFC 2141 [RFC2141] and its about URNs of the variety described in RFC 2141 [RFC2141] and its
successors [RFC2141bis] (i.e., those that use the "urn" scheme). successors [RFC2141bis] (i.e., those that use the "urn" scheme).
URLs, other types of names, and any URI types that may not fall into URLs, other types of names, and any URI types that may not fall into
one of the above categories are out of its scope and unaffected by one of the above categories are out of its scope and unaffected by
it. it.
Experience with URNs since the publication of RFC 3986 has identified Experience with URNs since the publication of RFC 3986 has identified
several ways in which their inclusion under the 3986 scope has several ways in which their inclusion under the 3986 scope has
hampered understanding, adoption, and especially extension hampered understanding, adoption, and especially extension
(specifically extensions of types that were anticipated, but not (specifically types of extensions that were anticipated, but not
defined, in RFC 2141). The need for extensions to the URN concept is defined, in RFC 2141). The need for extensions to the URN concept is
now being felt in some communities, especially those that include now being felt in some communities, especially those that include
libraries, museums, publishers, and other information scientists. libraries, museums, publishers, and other information scientists.
In particular, the Generic URI Syntax specification goes beyond In particular, the Generic URI Syntax specification goes beyond
syntax to specify the meaning and interpretation of various fields, syntax to specify the meaning and interpretation of various fields,
especially the "query" and "fragment" ones and the various syntax especially the "query" and "fragment" ones and the various syntax
forms and interpretations it allows for <hier-part>. This forms and interpretations it allows for <hier-part>. There is
specification excludes URNs from those definitions of meaning and disagreement in the community about whether some of the statements in
interpretation so that RFC 3986 applies to their syntax only. The RFC 3986 are normative requirements or discussion of possible options
meaning --and any more specific syntax rules-- for those fields for and, if the latter, whether the options given are an exclusive list.
URNs are now defined in a URN-specific document [RFC2141bis]. URNs Sequences of statements in that document that can be read in
remain members of the URI family and parsers for generic URI syntax different ways reinforce those disagreements. As one example, the
are not affected by this specification although parsers that make 3986 discussion of fragments (see Section 3.5, especially the first
assumptions based on other URI schemes obviously might be. two paragraphs) has been read as leaving the interpretation of
strings in fragment syntax that are not associated with retrievable
objects and media types as undefined and unconstrained and hence
available for other uses. Others have read the second paragraph as
prohibiting any interpretation or use of fragments on a per-scheme
basis, essentially prohibiting them when the URI does not resolve to
an object with a media type.
This document does not attempt to resolve those disagreements. Doing
so does not seem to be necessary and would be far out of scope for
the WG that produced it, and would mire URN work in controversies
that might never be resolved. Instead, it provides what might best
be thought of as an interpretation rule: if someone reads a statement
about the meaning or interpretation of a particular field, or non-
syntactic restrictions on it, as inconsistent between RFC 3986 and
this document and/or [RFC2141bis], these URN-specific documents
prevail (again, only for the "urn:" scheme; any extension to other
types of names would be the subject of other work).
In other words, this specification excludes URNs from the RFC 3986
definitions of meaning and interpretation so that RFC 3986 applies,
for URNs, to their syntax only. The meaning --and any more specific
syntax rules-- for those fields for URNs are now defined in a URN-
specific document [RFC2141bis]. URNs remain members of the URI
family and parsers for generic URI syntax are not affected by this
specification although parsers that make assumptions based on other
URI schemes obviously might be.
Neither this specification nor the successor to RFC 2141 [RFC2141bis] Neither this specification nor the successor to RFC 2141 [RFC2141bis]
discusses DDDS [RFC3401] resolution or conversion to (and discusses DDDS [RFC3401] resolution or conversion to (and
interpretation of) URCs [RFC2483] or, with the exception of providing interpretation of) URCs [RFC2483] or, with the exception of providing
some syntax to cover some specific cases, URN "resolution" more some syntax to cover some specific cases, URN "resolution" more
generally. Any of those topics that do need to be addressed should generally. Any of those topics that do need to be addressed should
be covered in other documents. The document also does not discuss be covered in other documents. The document also does not discuss
alternatives to URNs, either those that might use a different scheme alternatives to URNs, either those that might use a different scheme
name within the RFC 3986 URI framework or those that might use a name within the RFC 3986 URI framework or those that might use a
different framework entirely. In particular, some externally-defined different framework entirely. In particular, some externally-defined
content or object identification systems could be represented either content or object identification systems could be represented either
by a URN namespace or through separate URI schemes. This by a URN namespace or through separate URI schemes. This
specification does not offer advice on that choice other than to specification does not offer advice on that choice other than to
suggest that the two options not be confused (or both used in a way suggest that the two options not be confused (or both used in a way
that would be confusing). that would be confusing).
This document updates RFC 3986 to make the distinction between syntax
and semantics clear for URNs and to isolate URNs from presumed URI
semantic requiremnts. It is important to note that some readers of
RFC 3986 are convinced that the separation is clear in that
specification and therefore that no changes to that document are
needed. For them, this specification is only a confirming
clarification.
In the long term, as the expanded syntax and uses of URNs become In the long term, as the expanded syntax and uses of URNs become
commonplace and RFC 3986 is updated, this specification is likely to commonplace and RFC 3986 is updated, this specification is likely to
become of historical interest only, providing an extended rationale become of historical interest only, providing an extended rationale
for decisions made and adjustment of the boundary between URN for decisions made and adjustment of the boundary between URN
specifications and generic URI ones. specifications and generic URI ones, especially those that are used
as locators rather than names.
2. Pragmatic Goals 2. Pragmatic Goals
Despite the important background and rationale in the sections that Despite the important background and rationale in other sections of
follow, the change made (or clarification provided) by this this document, the change made (or clarification provided) by this
specification is driven by a desire to avoid philosophical debates specification is driven by a desire to avoid philosophical debates
about terminology or ultimate truths. Instead, it is motivated by about terminology, ultimate truths, or even different interpretations
three very pragmatic principles and goals: of RFC 3986. Instead, it is motivated by three very pragmatic
principles and goals:
1. Accommodate all of those who think URNs are necessary, i.e., that 1. Accommodate the communities who think URNs are necessary, i.e.,
they can and should be usefully distinguished from other URIs, at that they can and should be usefully distinguished from other
least location-oriented ones including URI schemes defined prior URIs, at least location-oriented ones (including URI schemes
to the time work started on this document in August 2014. In defined prior to the time work started on this document in August
particular, provide a foundation for extensions to the URN syntax 2014). In particular, provide a foundation for extensions to the
(as allowed by and partially defined in RFC 2141) to support URN syntax (as allowed by and partially defined in RFC 2141) to
requirements encountered by some of those communities. support requirements encountered by some of those communities.
2. Provide a path to avoid getting bogged down in declarative 2. Provide a path to avoid getting bogged down in declarative
statements about definitions and debates about what is and is not statements about definitions and debates about what is and is not
correct in the abstract. abstractly correct.
3. Avoid a fork in the standard that would be likely to lead to 3. Avoid a fork in the standard that would be likely to lead to
multiple, conflicting, definitions or criteria for URNs. multiple, conflicting, definitions or criteria for URNs.
In addition, this document is intended to move past debates about In addition, this document is intended to move past debates about
whether or not URNs are intended to be parsed at all (i.e., whether a whether or not URNs are intended to be parsed at all (i.e., whether a
"urn"-scheme URI is simply opaque to a URI parser once the scheme "urn"-scheme URI is simply opaque to a URI parser once the scheme
name is identified) and, if not, how much of it is actually expected name is identified) and, if not, how much of it is actually expected
to be understood and broken into identifiable parts by such a parser. to be understood and broken into identifiable parts by such a parser.
It establishes a principle that, for the "urn" scheme, parsing into It establishes a principle that, for the "urn" scheme, parsing into
the components identified in RFC 3986 will be performed but that any the components identified in RFC 3986 may be performed but that any
meanings or interpretation assigned to those components (including meanings or interpretation assigned to those components (including
that applicability of the normal English meanings of such terms as application of the normal English meanings of such terms as "query"
"query" or "fragment" are a matter for URN-specific specifications. or "fragment") are a matter for URN-specific specifications. That
It helps lay the foundation for the distinguishing terms principle and its application provides a foundation for the
"q-component", "r-component", and "f-component" in the accompanying distinguishing terms "q-component", "r-component", and "f-component"
URN definition specification [RFC2141bis]. that are developed in the accompanying URN definition specification
[RFC2141bis].
3. The role of queries and fragments in URNs 3. The role of queries and fragments in URNs
[[CREF1: Note in Draft to WG: Given what is now above and material in
2141bis, I suggest removing this section entirely (if needed,
transposing it into 2141bis). If we do retain it, it almost
certainly needs more work. Comments, specifically about whether it
should be removed and, if so, what changes (if any) are needed to
2141bis, would be appreciated. --JcK (-04) ]]
Part of the concern that led to this document was a desire to Part of the concern that led to this document was a desire to
accommodate URN components that would be analogous to the query and accommodate URN components that would be analogous to the query and
fragment components of generalized URNs but that might have different fragment components of generalized URNs but that might have different
properties. For many cases, the analogy cannot be exact. For properties. For many cases, the analogy cannot be exact. For
example, RFC 3986 ties the interpretation of fragments to media example, RFC 3986 ties the interpretation of fragments to media
types. Since media type is a function of specific content, URNs that types. Since media type is a function of specific content, URNs that
are never resolved cannot have an associated media type, nor can URNs are never resolved cannot have an associated media type, nor can URNs
that resolve to, for example, other URIs that may then not be that resolve to, for example, other URIs that may then not be
resolved further. Similarly, while the RFC 3986 syntax for queries resolved further. Similarly, while the RFC 3986 syntax for queries
(and fragments) may be entirely appropriate for URN use, terminology (and fragments) may be entirely appropriate for URN use, terminology
like "Service Request" (see Appendix B of the predecessor "URNs are like "Service Request" (see Appendix B of the predecessor "URNs are
not..." draft [ServiceRequests] for additional discussion) may be not..." draft [ServiceRequests] for additional discussion) may be
more suitable to the URN context than "query" (if, indeed, the more suitable to the URN context than "query" (if, indeed, the
portion of the URN that is syntactically equivalent to a URI query is portion of the URN that is syntactically equivalent to a URI query is
where those requests belong). where those requests belong).
4. Changes to RFC 3986 4. Changes to RFC 3986
This specification removes URN semantics from the scope of RFC 3896. The interpretation rule discussed in Section 1 notwithstanding, this
It makes no changes to the generic URI syntax. That syntax still document alters ("updates") RFC 3986 itself only by specifying that
applies to URNs as well as to other URI types. Even as regard to the interpretation of URNs of the "urn:" scheme, may vary from that
semantics, it has no practical effect for URNs defined in strict for other types of URIs. That might be implemented by, for example,
conformance to the prior URN specification [RFC2141] or the inserting text at the end of Section 1.1.3 (of RFC 3986) similar to:
associated registration specification [RFC3406].
Nonetheless, URIs classified as names, particularly those of the
"urn:" scheme, may require different interpretations of, or even
deviations from, the interpretations of various fields or rules of
this document that are more obviously applicable to locators.
Those differences are motivated by differences in the
relationships to retrievable objects and other resources between
locators and more abstract names. For the "urn:" scheme, the
issues are discussed in [ThisRFC] and specific definitions are
supplied in [RFC2141bis].
[[CREF2: Note in Draft: The above example suggested text opens the
door to unbinding _all_ name-type URIs from the semantics of 3986
despite assertions elsewhere in this document that anything other
then the "urn:" scheme is out of scope. In reviewing 3986, the
example location and text seemed the best and most consistent way to
modify the relevant section. That section definitely does not talk
about individual schemes. WG participants, in reviewing this section
and text, should note that IETF procedures have never required that a
specification that "updates" a document provide modifying text nor
that an author or WG working on a revision to the document thereby
updated use that text. I've included it here because of discussion
on the mailing list to the effect that this document was unclear
about just how it updated 3986 -- the above is intended to make that
crystal-clear. Alternate text that would not have those issues would
be welcome. --JcK (-04)]]
The effect of the above is to remove URN semantics from the scope of
RFC 3986. It makes no changes to the generic URI syntax, nor to the
semantics of any other URI scheme. The 3986 syntax still applies to
URNs as well as to other URI types. Even as regard to semantics, it
has no practical effect for URNs defined in strict conformance to the
prior URN specification [RFC2141] or the associated registration
specification [RFC3406].
[[CREF3: I think the paragraph that follows can safely be dropped and
will do so in future versions (if any) unless there are comments to
the contrary that explain what purpose it serves and any needed
changes. --JcK (-04)]]
In particular (but without altering RFC 3986 in any way), the generic In particular (but without altering RFC 3986 in any way), the generic
URI syntax for "queries" (strings starting with "?" and continuing to URI syntax for "queries" (strings starting with "?" and continuing to
the end of the URI or to a "#"), and for "fragments" (strings the end of the URI or to a "#"), and for "fragments" (strings
starting with "#" and continuing to the end of the URI) is unchanged. starting with "#" and continuing to the end of the URI) is unchanged.
For URNs, additional syntax is introduced to divide the URI "query" For URNs, additional syntax is introduced to divide the URI "query"
into two parts, referred to as "q-components" and "r-components". into two parts, referred to as "q-components" and "r-components".
The syntax and general semantics of "fragments" (specified in RFC The syntax and general semantics of "fragments" (specified in RFC
3986 as scheme-independent) are unchanged, but a somewhat liberal 3986 as scheme-independent) are unchanged, but a somewhat liberal
interpretation may be needed in the context of URNs, so a fragment is interpretation may be needed in the context of URNs, so a fragment is
referred to as an "f-component" as a term of convenience to highlight referred to as an "f-component" as a term of convenience to highlight
that distinction. [RFC2141bis]. that distinction [RFC2141bis].
5. Actions Occurring in Parallel with this Specification 5. Actions Occurring in Parallel with this Specification
The basic URN syntax specification [RFC2141] was published well The basic URN syntax specification [RFC2141] was published well
before RFC 3986 and therefore does not depend on it. The successor before RFC 3986 and therefore does not depend on it. The successor
to that specification [RFC2141bis], fully spells out, or references to that specification [RFC2141bis], fully spells out, or references
documents that spell out, the semantics and any required within-field documents that spell out, the semantics and any required within-field
syntax of URNs. It uses great care about generic or implicit syntax of URNs. It uses great care about generic or implicit
reference to any URI specification and delegates further details to reference to any URI specification and delegates further details to
specific namespaces. specific namespaces.
[[CREF1: Note in Draft: Perhaps this section can be dropped [[CREF4: Note in Draft: Perhaps this section can be dropped entirely.
entirely.]] --JcK (04)]]
6. Acknowledgments 6. Acknowledgments
This specification was inspired by a search in the IETF URNBIS WG for This specification was inspired by a search in the IETF URNBIS WG for
an approach that would both satisfy the needs of persistent name-type an approach that would both satisfy the needs of persistent name-type
identifiers and still fully conform to the specifications and intent identifiers and still fully conform to various readings and
of RFC 3986. That search lasted several years and considered many understandings of the specifications and intent of RFC 3986. That
alternatives. Discussions with Leslie Daigle, Juha Hakala, Barry search lasted several years and considered many alternatives.
Leiba, Keith Moore, Andrew Newton, and Peter Saint-Andre during the Discussions with Leslie Daigle, Juha Hakala, Barry Leiba, Keith
last quarter of 2013 and the first quarter of 2014 were particularly Moore, Andrew Newton, and Peter Saint-Andre during the last quarter
helpful in arriving at the conclusion that a conceptual separation of of 2013 and the first quarter of 2014 were particularly helpful in
notions of location-based identifiers (e.g., URLs) and the types of arriving at the conclusion that a conceptual separation of notions of
persistent identifiers represented by URNs was necessary. Juha location-based identifiers (e.g., URLs) and the types of persistent
Hakala provided useful explanations and significant working text identifiers represented by URNs was necessary. Juha Hakala provided
about the needs of the library community and their perception of useful explanations and significant working text about the needs of
identifiers and consequent implications for URN structure. Peter the library community and their perception of identifiers and
Saint-Andre provided significant text in a pre-publication review. consequent implications for URN structure. Peter Saint-Andre
The author also appreciates the efforts of several people, notably provided significant text in a pre-publication review. The author
Tim Berners-Lee, Leslie Daigle, Larry Masinter, Keith Moore, Juha also appreciates the efforts of several people, notably Tim Berners-
Hakala, Julian Reschke, Lars Svensson, Henry S. Thompson, and Dale Lee, Leslie Daigle, Juha Hakala, Sean Leonard, Larry Masinter, Keith
Moore, Julian Reschke, Lars Svensson, Henry S. Thompson, and Dale
Worely, to challenge text and ideas and demand answers to hard Worely, to challenge text and ideas and demand answers to hard
questions. Whether they agree with the results or not, their questions. Whether they agree with the results or not, their
insights have contributed significantly to whatever clarity and insights have contributed significantly to whatever clarity and
precision appears in the present document. precision appears in the present document.
The specification was changed considerably and its focus narrowed The specification was changed considerably and its focus narrowed
after an extended discussion at the WG meeting during IETF 90 in July after an extended discussion at the WG meeting during IETF 90 in July
2014 [IETF90-URNBISWG] and subsequent comments and clarifications on 2014 [IETF90-URNBISWG] and subsequent comments and clarifications on
the mailing list [URNBIS-MailingList]. The contributions of all of the mailing list [URNBIS-MailingList]. The contributions of all of
the participants in those discussions, only some of whose names the participants in those discussions, only some of whose names
skipping to change at page 7, line 7 skipping to change at page 8, line 33
Contact Information: Contact Information:
Juha Hakala Juha Hakala
The National Library of Finland The National Library of Finland
P.O. Box 15, Helsinki University P.O. Box 15, Helsinki University
Helsinki, MA FIN-00014 Helsinki, MA FIN-00014
Finland Finland
Email: juha.hakala@helsinki.fi Email: juha.hakala@helsinki.fi
8. IANA Considerations 8. IANA Considerations
[[CREF2: RFC Editor: Please remove the first paragraph below before [[CREF5: RFC Editor: Please remove the first paragraph below before
publication.]] publication.]]
This memo is not believed to require any action on IANA's part. This memo is not believed to require any action on IANA's part.
There is an existing (i.e. prior to the publication of this document) There is an existing (i.e. prior to the publication of this document)
registry for "Uniform Resource Identifier (URI) Schemes" that already registry for "Uniform Resource Identifier (URI) Schemes" that already
includes the "urn" scheme itself and a separate existing URN includes the "urn" scheme itself and a separate existing URN
Namespace registry. None of those registrations have any specific Namespace registry. None of the registrations that predate this
dependencies on generic URI specifications. specification have any specific dependencies on generic URI
specifications. More information on this subject appears in
[RFC2141bis] and documents referenced from it.
9. Security Considerations 9. Security Considerations
This specification changes the semantics of URNs to make them self- As discussed in Section 1 above, this document is largely
contained (as specified in other documents), relying on the generic precautionary, providing an interpretation rule for the URI
URI syntax specification for syntax only. It should have no effect definition [RFC3986] when URNs are concerned. Some members of the
on Internet security unless the use of a definition, syntax, and community believe that rule (and hence this document) are
semantics that are more clear reduces the potential for confusion and unnecessary, at most reinforcing provisions already in that
consequent vulnerabilities. definition. Others believe that it restores the original URN
definition [RFC2141], produced before RFC 3986 was adopted and not
updated by it. Still others see this specification as making a
necessary change to allow the semantics of URNs to be self-contained
(as specified in other documents), relying on the generic URI syntax
specification for syntax only.
Independent of which of those models is applicable, the specification
should have no effect on Internet security unless the use of a
definition, syntax, and semantics that are more clear reduces the
potential for confusion and consequent vulnerabilities.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141, [RFC2141] Moats, R., "URN Syntax", RFC 2141, DOI 10.17487/RFC2141,
May 1997, <http://www.rfc-editor.org/info/rfc2141>. May 1997, <http://www.rfc-editor.org/info/rfc2141>.
[RFC2141bis] [RFC2141bis]
Saint-Andre, P. and J. Klensin, "Uniform Resource Name Saint-Andre, P. and J. Klensin, "Uniform Resource Name
skipping to change at page 9, line 7 skipping to change at page 10, line 44
Namespace Registration Transition", Feburary 2016, Namespace Registration Transition", Feburary 2016,
<https://datatracker.ietf.org/doc/draft-ietf-urnbis-ns- <https://datatracker.ietf.org/doc/draft-ietf-urnbis-ns-
reg-transition/>. reg-transition/>.
[URNBIS-MailingList] [URNBIS-MailingList]
IETF, "IETF URN Mailing list", 2014, IETF, "IETF URN Mailing list", 2014,
<https://www.ietf.org/mailman/listinfo/urn>. <https://www.ietf.org/mailman/listinfo/urn>.
Appendix A. Background on the URN - URI relationship Appendix A. Background on the URN - URI relationship
[[CREF6: Note in Draft: I've slightly rewritten this Appendix, but
suspect it may still be controversial. If it is, the WG should
discuss whether the advantages of having the explanation justify the
energy to figure out exactly what it should say or whether those
advantages are few enough that it should just be dropped. --JcK
(-04).]]
The Internet community now has many years of experience with both The Internet community now has many years of experience with both
name-type identifiers and location-based identifiers (or "references" name-type identifiers and location-based identifiers (or "references"
for those who are sensitive to the term "identifier" such as many for those who are sensitive to the term "identifier" (a group that
members of the library and information science communities.. The includes many members of the library and information science
primary examples of these two categories are Uniform Resource Names communities. The primary examples of these two categories are
(URNs [RFC2141] [RFC2141bis]) and Uniform Resource Locators (URLs) Uniform Resource Names (URNs [RFC2141] [RFC2141bis]) and Uniform
[RFC1738]). That experience leads to the conclusion that it is Resource Locators (URLs) [RFC1738]). That experience leads to the
impractical to constrain URNs to the high-level semantics of URLs. conclusion that it is impractical to constrain URNs to the high-level
The generic syntax for URIs [RFC3986] is adequately flexible to semantics of URLs. The generic syntax for URIs [RFC3986] is
accommodate the perceived needs of URNs, but the specific semantics adequately flexible to accommodate the perceived needs of URNs, but
associated with the URI syntax definition -- what particular the specific semantics associated with the URI syntax definition --
constructions "mean" and how and where they are interpreted -- appear what particular constructions "mean" and how and where they are
to not be. Generalization from URLs to generic Uniform Resource constrained or interpreted -- appear to not be. Generalization from
Identifiers (URIs) [RFC3986], especially to name-based, high- URLs to generic Uniform Resource Identifiers (URIs) [RFC3986],
stability, long-persistence, identifiers such as many URNs, has especially to name-based, high-stability, long-persistence,
failed because the assumed similarities do not adequately extend to identifiers such as many URN namespaces, has failed because the
all forms of URNs. Ultimately, locators, which typically depend on assumed similarities do not adequately extend to all forms of, and
particular accessing protocols and a specification relative to some requirements for, URNs.
physical space or network topology, are simply different creatures
from long-persistence, location-independent, object identifiers. The Ultimately, locators, which typically depend on particular accessing
syntax and semantic constraints that are appropriate for locators are protocols (protocols that are typically linked to the particular URI
either irrelevant to or interfere with the needs of resource names as scheme) and a specification relative to some physical space or
a class. That was tolerable as long as the URN system didn't need network topology, are simply different creatures from long-
persistence, location-independent, object identifiers or abstract
designators. Many of the constraints and interpretation rules that
are appropriate for locators are either irrelevant to or interfere
with the needs of resource names (at least of the "urn:" scheme) as a
class. That was tolerable as long as the URN system didn't need
additional capabilities (over those specified in RFC 2141) but additional capabilities (over those specified in RFC 2141) but
experience since RFC 2141 was published has shown that they are, in experience since RFC 2141 was published has shown that they are, in
fact, needed. fact, needed.
Appendix B. Change Log Appendix B. Change Log
[[CREF3: RFC Editor: Please remove this appendix before [[CREF7: RFC Editor: Please remove this appendix before
publication.]] publication.]]
B.1. Changes from draft-ietf-urnbis-urns-are-not-uris-00 (2014-04-07) B.1. Changes from draft-ietf-urnbis-urns-are-not-uris-00 (2014-04-07)
to -01 (2014-07-03) to -01 (2014-07-03)
o Revised Section 1 slightly and added some new material to try to o Revised Section 1 slightly and added some new material to try to
address questions raised on the mailing list. address questions raised on the mailing list.
o Added Section 2, reflecting an email exchange. o Added Section 2, reflecting an email exchange.
skipping to change at page 10, line 45 skipping to change at page 12, line 45
o Added new material to discuss the next round of decisions the WG o Added new material to discuss the next round of decisions the WG
will have to make, assuming this provisions of this specification will have to make, assuming this provisions of this specification
are approved. That material was removed from draft-ietf-urnbis- are approved. That material was removed from draft-ietf-urnbis-
semantics-clarif-01. semantics-clarif-01.
B.3. Changes from draft-ietf-urnbis-semantics-clarif-00 (2014-08-25) to B.3. Changes from draft-ietf-urnbis-semantics-clarif-00 (2014-08-25) to
-01 -01
o Removed some appendices and the topic discussion material, as o Removed some appendices and the topic discussion material, as
discused in the previous draft. discussed in the previous draft.
o Aligned the document and its terminology somewhat better with o Aligned the document and its terminology somewhat better with
draft-ietf-urnbis-rfc2141bis-urn-09 including providing for draft-ietf-urnbis-rfc2141bis-urn-09 including providing for
p-components and using the p-/q-/f-component terminology. p-components and using the p-/q-/f-component terminology.
o Made several clarifying changes to reflect mailing list o Made several clarifying changes to reflect mailing list
discussions (mostly of 2141bis) since the earlier version was discussions (mostly of 2141bis) since the earlier version was
posted. posted.
o Revised earlier portions of this change tracking appendix to o Revised earlier portions of this change tracking appendix to
skipping to change at page 11, line 33 skipping to change at page 13, line 33
o Reissued to keep draft alive; no substantive changes. o Reissued to keep draft alive; no substantive changes.
o Updated references, including some that were already outdated in o Updated references, including some that were already outdated in
-01. -01.
B.5. Changes from draft-ietf-urnbis-semantics-clarif-02 (2015-08-10) to B.5. Changes from draft-ietf-urnbis-semantics-clarif-02 (2015-08-10) to
-03 -03
o Made a few substantive updates to reflect evolution in 2141bis, o Made a few substantive updates to reflect evolution in 2141bis,
particularly the elimination of p-component as a separate category particularly the elimination of p-component as a separate category
and the added distinction between q-component and r-component.. and the added distinction between q-component and r-component.
o Updated references and made several minor editorial changes to o Updated references and made several minor editorial changes to
improve clarity. improve clarity.
B.6. Changes from draft-ietf-urnbis-semantics-clarif-03 (2016-02-07) to
-04
o Rewrote parts of Sections 1, 2, 9, and Appendix A to try to
clarify the intentions of this document and its relationship to
others, including better specifying and providing example location
and text for the "updates" relationship to RFC 3986.
o Added temporary editor's notes, marked "[[CREF ... -JcK (-04)",
the latter denoting the version, about issues the WG should
consider.
o Updated the Acknowledgments.
o Many small editorial corrections
Author's Address Author's Address
John C Klensin John C Klensin
1770 Massachusetts Ave, Ste 322 1770 Massachusetts Ave, Ste 322
Cambridge, MA 02140 Cambridge, MA 02140
USA USA
Phone: +1 617 245 1457 Phone: +1 617 245 1457
Email: john-ietf@jck.com Email: john-ietf@jck.com
 End of changes. 36 change blocks. 
116 lines changed or deleted 236 lines changed or added

This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/