draft-ietf-urnbis-semantics-clarif-00.txt   draft-ietf-urnbis-semantics-clarif-01.txt 
Uniform Resource Names (urnbis) J. Klensin Uniform Resource Names (urnbis) J. Klensin
Internet-Draft Internet-Draft
Updates: 3986 (if approved) August 25, 2014 Updates: 3986 (if approved) February 14, 2015
Intended status: Standards Track Intended status: Standards Track
Expires: February 26, 2015 Expires: August 18, 2015
URN Semantics Clarification URN Semantics Clarification
draft-ietf-urnbis-semantics-clarif-00.txt draft-ietf-urnbis-semantics-clarif-01.txt
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 Informational Sciences the Library, Museum, Publisher, and Information Science communities
communities and other users, this specification separates URNs from and other users, this specification separates URNs from the semantic
the semantic constraints that many people believe are part of the constraints that many people believe are part of the specification
specification for Uniform Resource Identifiers (URIs) specified in for Uniform Resource Identifiers (URIs) in RFC 3986, updating that
RFC 3986, updating that document accordingly. The syntax of URNs is document accordingly. The syntax of URNs is still constrained to
still constrained to that of RFC 3986, so generic URI parsers are that of RFC 3986, so generic URI parsers are unaffected by this
unaffected by this change. change.
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 February 26, 2015. This Internet-Draft will expire on August 18, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Pragmatic Goals . . . . . . . . . . . . . . . . . . . . . . . 3 2. Pragmatic Goals . . . . . . . . . . . . . . . . . . . . . . . 4
3. The role of queries and fragments in URNs . . . . . . . . . . 4 3. The role of queries and fragments in URNs . . . . . . . . . . 4
4. Changes to RFC 3986 . . . . . . . . . . . . . . . . . . . . . 5 4. Changes to RFC 3986 . . . . . . . . . . . . . . . . . . . . . 5
5. Other Required Actions . . . . . . . . . . . . . . . . . . . 5 5. Actions Occurring in Parallel with this Specification . . . . 5
6. Alternatives and comparison . . . . . . . . . . . . . . . . . 5 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5
6.1. Terminology and Information Location. . . . . . . . . . . 5 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6
6.2. Comparison and "Part of the URN" . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6.3. Applicability of components. . . . . . . . . . . . . . . 6 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6.4. Internal syntax. . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.5. Extended, embedded, base, and derived URNs . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 7
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . 7
8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 8 Appendix A. Background on the URN - URI relationship . . . . . . 8
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 8
10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 B.1. Changes from draft-ietf-urnbis-urns-are-not-uris-00
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 (2014-04-07) to -01 (2014-07-03) . . . . . . . . . . . . 9
11.1. Normative References . . . . . . . . . . . . . . . . . . 8 B.2. Changes from draft-ietf-urnbis-urns-are-not-uris-01
11.2. Informative References . . . . . . . . . . . . . . . . . 9 to draft-ietf-urnbis-semantics-clarif-00 (2014-08-25) . . 9
Appendix A. Background on the URN - URI relationship . . . . . . 10 B.3. Changes from draft-ietf-urnbis-semantics-clarif-00
Appendix B. Three views of locator-identifier separation . . . . 10 (2014-08-25) to -01 . . . . . . . . . . . . . . . . . . . 10
B.1. A Perspective on Locations and Names . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10
B.2. A More Pragmatic Perspective . . . . . . . . . . . . . . 13
B.3. A more radical (or most conservative) view of URNs and
their role . . . . . . . . . . . . . . . . . . . . . . . 15
Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 16
C.1. Changes from draft-ietf-urnbis-urns-are-not-uris-00 to
-01 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
C.2. Changes from draft-ietf-urnbis-urns-are-not-uris-01
to draft-ietf-urnbis-semantics-clarif-00 . . . . . . . . 17
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17
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] (i.e., about URNs of the variety described in RFC 2141 [RFC2141] and its
those that use the "urn" scheme). URLs, other types of names, and successors [RFC2141bis] (i.e., those that use the "urn" scheme).
any URI types that may not fall into one of the above categories are URLs, other types of names, and any URI types that may not fall into
out of its scope and unaffected by it. one of the above categories are out of its scope and unaffected by
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 its scope has hampered several ways in which their inclusion under its scope has hampered
understanding, adoption, and especially extension in ways that were understanding, adoption, and especially extension (specifically
anticipated in RFC 2141. The need for extensions to the URN concept extensions of types that were anticipated in RFC 2141). The need for
is now being felt in some communities, especially those that include extensions to the URN concept is now being felt in some communities,
libraries, museums, publishers, and other information scientists. especially those that include 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. This specification especially the "query" and "fragment" ones and the various syntax
excludes URNs from those definitions of meaning and interpretation so forms and interpretations it allows for <hier-part>. This
that RFC 3986 applies to their syntax only. The meaning --and any specification excludes URNs from those definitions of meaning and
more specific syntax rules-- for those fields for URNs are now interpretation so that RFC 3986 applies to their syntax only. The
defined in a URN-specific document [RFC2141bis]. meaning --and any more specific syntax rules-- for those fields for
[[CREF1: Note forward pointer to a future version of 2141bis.]] URNs are now defined in a URN-specific document [RFC2141bis]. URNs
URNs remain members of the URI family and parsers for generic URI remain members of the URI family and parsers for generic URI syntax
syntax are not affected by this specification. are not affected by this specification although parsers that make
assumptions based on other URI schemes obviously might be.
Portions of this document were inspired by discussions at the meeting This specification does not discuss DDDS [RFC3401] resolution or
of the WG during IETF 90 [IETF90-URNBISWG] and subsequent comments conversion to (and interpretation of) URCs [RFC2483] or URN
and clarifications on the mailing list [URNBIS-MailingList]. In its "resolution" more generally. Any of those topics that do need to be
present form, it is intended primarily to focus WG discussions. addressed should be covered in other documents. The document also
does not discuss alternatives to URNs, either those that might use a
different scheme name within the RFC 3986 URI framework or those that
might use a different framework entirely. In particular, some
externally-defined content or object identification systems could be
represented either by a URN namespace or through separate URI
schemes. This 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 that would be confusing).
This draft does not discuss issues about DDDS resolution or This document updates RFC 3986 to make the distinction between syntax
conversion to (and interpretation of) URCs or URN "resolution" more and semantics clear for URNs and to isolate URNs from presumed URI
generally. If any of those topics need to be addressed, it should be semantic requiremnts. It is important to note that some readers of
in other documents. Because URCs (as specified in RFC 2483 [RFC2483] RFC 3986 are convinced that the separation is clear in that
or elsewhere) have not been significantly implemented or deployed, specification and therefore that no changes to that document are
discussion of them is probably out of scope for the WG at this point. needed. For them, this specification is only a confirming
The document also does not discuss alternatives to URNs, either those clarification.
that might use a different scheme name within the RFC 3986 URI
framework or those that might use a different framework entirely. In the long term, as the expanded syntax and uses of URNs become
commonplace and RFC 3986 is updated, this specification is likely to
become of historical interest only, providing an extended rationale
for decisions made and adjustment of the boundary between URN
specifications and generic URI ones.
2. Pragmatic Goals 2. Pragmatic Goals
Despite the important background and rationale in the sections that Despite the important background and rationale in the sections that
follow, the change made by this specification is driven by a desire follow, the change made (or clarification provided) by this
to avoid philosophical debates about terminology or ultimate truths. specification is driven by a desire to avoid philosophical debates
Instead, it is motivated by three very pragmatic principles: about terminology or ultimate truths. Instead, it is motivated by
three very pragmatic principles and goals:
1. Try to accommodate all of those who think URNs are necessary, 1. Accommodate all of those who think URNs are necessary, i.e., that
i.e., that they can and should be usefully distinguished in they can and should be usefully distinguished from other URIs, at
certain respects from other URIs, at least those that have been least location-oriented ones including URI schemes defined prior
defined prior to this document. In particular, provide a to the time work started on this document in August 2014. In
foundation for extensions to the URN syntax allowed by and particular, provide a foundation for extensions to the URN syntax
defined in RFC 2141 to support requirements encountered by some (as allowed by and defined in RFC 2141) to support requirements
of those communities. encountered by some of those communities.
2. Try to avoid getting bogged down in declarative statements about 2. Provide a path to avoid getting bogged down in declarative
definitions and debates about what is and is not correct in the statements about definitions and debates about what is and is not
abstract. correct in the abstract.
3. Avoid a fork in the standard that leads to multiple, conflicting, 3. Avoid a fork in the standard that would be likely to lead to
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.
The assumption here is that parsing into the components identified in It establishes a principle that, for the "urn" scheme, parsing into
RFC 3986 will be performed but that any meanings or interpretation the components identified in RFC 3986 will be performed but that any
assigned to those components (including that applicability of the meanings or interpretation assigned to those components (including
normal English meanings of such terms as "query" or "fragment" are a that applicability of the normal English meanings of such terms as
matter for URN-specific specifications. "query" or "fragment" are a matter for URN-specific specifications.
It helps lay the foundarion for the distinguishing terms
"p-component", "q-component", and "f-component" 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
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. For many cases, the analogy fragment components of generalized URNs but that might have different
cannot be exact. For example, RFC 3986 ties the interpretation of properties. For many cases, the analogy cannot be exact. For
fragments to media types. Since media type is a function of specific example, RFC 3986 ties the interpretation of fragments to media
content, URNs that are never resolved to particular content cannot types. Since media type is a function of specific content, URNs that
have an associated media type. Similarly, while the syntax for are never resolved cannot have an associated media type, nor can URNs
queries (and fragments) may be entirely appropriate for URN use, that resolve to, for example, other URIs that may then not be
terminology like "Service Request" (see Appendix B to the "URNs are resolved further. Similarly, while the RFC 3986 syntax for queries
(and fragments) may be entirely appropriate for URN use, terminology
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 query more suitable to the URN context than "query" (if, indeed, the
portion of the URN is where those requests belong). portion of the URN that is syntactically equivalent to a URI query is
where those requests belong).
These issues are discussed as questions facing the WG in Section 6
below.
4. Changes to RFC 3986 4. Changes to RFC 3986
This specification removes URN semantics from the scope of RFC 3896. This specification removes URN semantics from the scope of RFC 3896.
It makes no changes to the generic URI syntax. That syntax still It makes no changes to the generic URI syntax. That syntax still
applies to URNs as well as to other URI types. Even as regard to 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 semantics, it has no practical effect for URNs defined in strict
conformance to the prior URN specification [RFC2141] or the conformance to the prior URN specification [RFC2141] or the
associated registration specification [RFC3406]. associated registration specification [RFC3406].
In particular, the generic URI syntax for "queries" (strings starting In particular, the generic URI syntax for path segments that appear
with "?" and continuing to the end of the URI or to a "#") and after the NID and NSS of a URN, i.e., after an initial "/", for
"fragments" (strings starting with "#" and continuing to the end of "queries" (strings starting with "?" and continuing to the end of the
the URI) is unchanged, but the terms "query" and "fragment" become, URI or to a "#"), and for "fragments" (strings starting with "#" and
for URNs, terms of convenience that are defined in URN-specific ways. continuing to the end of the URI) is unchanged, but the terms for
those path segments, "query" and "fragment" become, for URNs, terms
of convenience that are defined in URN-specific ways as p-components,
q-components, and f-components [RFC2141bis].
5. Other Required Actions 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. Successors to before RFC 3986 and therefore does not depend on it. The successor
that specification will need to fully spell out, or reference 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, using great care about generic or implicit reference syntax of URNs. It uses great care about generic or implicit
to any URI specification. reference to any URI specification and delegates further details to
specific namespaces.
6. Alternatives and comparison
[[Note in draft: temporary section to facilitate WG discussion]]
If this draft is approved, the WG will then have a number of other
choices to make. They include:
6.1. Terminology and Information Location.
RFC 3986 syntax appears to allow three components of a URI in which
we could put information for extending URNs past the "urn:nid:nss"
syntas of RFC 2141. The syntax that introduces each of these is
reserved for future use by RFC 2141 (Section 2.3.2). They are as
follows:
path segment(s). The NSS string could be extended to allow one or
more "path segments", introduced by "/" and terminating with the
next "/", a "?", a "#", or the end of the URI. These path segment
elements have been referred to as "facets" on the mailing list.
If they are to be used, the WG will need to settle on what they
should be called.
query. The URN syntax could be extended by use of what 3986 refers
to as a "query", represented as a string that starts with "?" and
extends to the first "#" or the end of the URI.
fragment. The URN syntax could be extended by use of what 3986
refers to as a "fragment", represented as a string that starts
with "#" and extends to the end of the URI.
The WG will need to determine which of these fields to use (it could
allow or require more than one of them, see below) and what to call
them. The terms "path segment", "query", and "fragment" have the
advantage of being traditional and associated in many people's minds
with the corresponding delimiter. On the other hand, the normal
conception of what those terms mean (including any semantics
associated with them in 3986) may not be a good match for the needs
of URNs. In particular, if a string starting in "?" were going to be
treated as a collection of "Service Requests", calling that a "query"
may strike some people as odd.
Allowing more than one of these components will probably require that
the WG understand and document the semantic relationship among them
(see below).
6.2. Comparison and "Part of the URN"
There has been fairly extensive discussion of what is compared when
one compares URNs for equality. There has been a separate, but
possibly equivalent, discussion about what elements associated with a
URN identify things. The discussions have particularly emphasized,
whether any of path segments, queries, or identifiers that are
allowed participate in such comparisons or identification. As with
other topics, some WG participants believe the answers are obvious,
but don't agree on what they are. Others make a distinction about
terminology (e.g., what is "part of the NSS") and assume that it
answers the questions. The WG will need to figure out whether these
discussions are the same and how to resolve the questions they imply.
6.3. Applicability of components.
The WG will need to decide whether whatever components are allowed
are allowed on a per-NID basis or, at least syntactically, across the
entire collection of URNs, remembering that, as far as 3986 is
concerned, some things have traditionally been associated with
schemes and all URNs are formally part of the same scheme. As noted
above, RFC 3986 ties the interpretation of fragments to media types,
but that is probably not meaningful for URNs, especially URNs that
are never resolves to objects. Part of this requires deciding what
should happen when a component is specified that is not applicable to
the particular NID-identified namespace. At least part of the web
tradition has been to simply ignore such fields but that may not be
the right answer for URNs, especially if one or more of them
participates in comparisons (see above).
6.4. Internal syntax.
As long as the conditions for terminating substrings were not
violated, the WG could decide on syntax within the components that
are to be allowed, possibly including defining syntax for identifying
keywords and defining or reserving some or all such keywords. Put
differently, it may be important to decide whether "a query" is a
series of related terms or components, possibly to be applied
serially or whether it has components that are assumed to be
independent and unordered. The latter choice may or may not interact
with considering query components (or some of them) as "Service
Requests".
6.5. Extended, embedded, base, and derived URNs
There has been discussion on the mailing list of different types of
URNs or near-URNs using at least the above terms. It is not clear
whether, once the issues above are resolved, those terminology
distinctions will be trivial or whether they represent additional
issues that the WG will need to resolve.
Note that this may interact with a discussion on the mailing list [[CREF1: Note in Draft: Perhaps this section can be dropped
(off-topic for this document) about embedding URNs in HTTP or other entirely.]]
URLs that locate a particular resolution or information-obtaining
system. It may also interact with potential revised registration
templates for ISSNs, ISBNs, and other existing URN namespaces and
hence with the transition discussion [URN-transition].
7. 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
other alternatives that would both satisfy the needs of persistent an approach that would both satisfy the needs of persistent name-type
name-type identifiers and still fully conform to the specifications identifiers and still fully conform to the specifications and intent
and intent of RFC 3986. That search lasted several years and of RFC 3986. That search lasted several years and considered many
considered many alternatives. Discussions with Leslie Daigle, Juha alternatives. Discussions with Leslie Daigle, Juha Hakala, Barry
Hakala, Barry Leiba, Keith Moore, Andrew Newton, and Peter Saint- Leiba, Keith Moore, Andrew Newton, and Peter Saint-Andre during the
Andre during the last quarter of 2013 and the first quarter of 2014 last quarter of 2013 and the first quarter of 2014 were particularly
were particularly helpful in getting to the conclusion that a helpful in arriving at the conclusion that a conceptual separation of
conceptual separation of notions of location-based identifiers (e.g., notions of location-based identifiers (e.g., URLs) and the types of
URLs) and the types of persistent identifiers represented by URNs was persistent identifiers represented by URNs was necessary. Juha
necessary. As noted below, Juha Hakala provided much of the text on Hakala provided useful explanations and significant working text
which Appendix B.1 was based. Peter Saint-Andre provided significant about the needs of the library community and their perception of
text in a pre-publication review. The author also appreciates the identifiers and consequent implications for URN structure. Peter
efforts of several people, notably Tim Berners-Lee, Larry Masinter, Saint-Andre provided significant text in a pre-publication review.
Keith Moore, Juha Hakala, Julian Reschke, Lars Svensson, Henry S. The author also appreciates the efforts of several people, notably
Thompson, and Dale Worely, to challenge text and ideas and demand Tim Berners-Lee, Leslie Daigle, Larry Masinter, Keith Moore, Juha
answers to hard questions. Whether they agree with the results or Hakala, Julian Reschke, Lars Svensson, Henry S. Thompson, and Dale
not, their insights have contributed significantly to whatever Worely, to challenge text and ideas and demand answers to hard
clarity and precision appears in the text. questions. Whether they agree with the results or not, their
insights have contributed significantly to whatever clarity and
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. 2014 [IETF90-URNBISWG] and subsequent comments and clarifications on
the mailing list [URNBIS-MailingList]. The contributions of all of
the participants in those discussions, only some of whose names
appear above, are gratefully acknowledged.
8. Contributors 7. Contributors
Juha Hakala contributed most of the text of Appendix B.1. Juha Hakala contributed considerable text, some of which was removed
from later versions of the document to streamline it.
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
9. IANA Considerations 8. IANA Considerations
[[CREF2: RFC Editor: Please remove this section before publication.]] [[CREF2: RFC Editor: Please remove this section before publication.]]
This memo is not believed to require any action on IANA's part. In This memo is not believed to require any action on IANA's part. In
particular, we note that there are a collection of "Uniform Resource particular, we note that there is a collection of "Uniform Resource
Identifier (URI) Schemes" that does not include URNs and a series of Identifier (URI) Schemes" that does not include URNs and a series of
URN-specific registries that do not rely on the URI specificstions. URN-specific registries that do not rely on the URI specificstions.
10. Security Considerations 9. Security Considerations
This specification changes the semantics of URNs to make them self- This specification changes the semantics of URNs to make them self-
contained (as specified in other documents), relying on the generic contained (as specified in other documents), relying on the generic
URI syntax specification for syntax only. It should have no effect URI syntax specification for syntax only. It should have no effect
on Internet security unless the use of a definition, syntax, and on Internet security unless the use of a definition, syntax, and
semantics that are more clear reduces the potential for confusion and semantics that are more clear reduces the potential for confusion and
consequent vulnerabilities. consequent vulnerabilities.
11. References 10. References
11.1. Normative References 10.1. Normative References
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005. 3986, January 2005.
11.2. Informative References 10.2. Informative References
[DeterministicURI] [DeterministicURI]
Mazahir, O., Thaler, D., and G. Montenegro, "Deterministic Mazahir, O., Thaler, D., and G. Montenegro, "Deterministic
URI Encoding", February 2014, <http://www.ietf.org/id/ URI Encoding", February 2014, <http://www.ietf.org/id/
draft-montenegro-httpbis-uri-encoding-00.txt>. draft-montenegro-httpbis-uri-encoding-00.txt>.
[IETF90-URNBISWG] [IETF90-URNBISWG]
IETF, "URN BIS Working Group Minutes", July 2014, IETF, "URN BIS Working Group Minutes", July 2014,
<http://www.ietf.org/proceedings/90/minutes/ <http://www.ietf.org/proceedings/90/minutes/
minutes-90-urnbis>. minutes-90-urnbis>.
skipping to change at page 9, line 32 skipping to change at page 7, line 41
Resource Locators (URL)", RFC 1738, December 1994. Resource Locators (URL)", RFC 1738, December 1994.
[RFC2141bis] [RFC2141bis]
Saint-Andre, P., "Uniform Resource Name (URN) Syntax", Saint-Andre, P., "Uniform Resource Name (URN) Syntax",
January 2014, <https://datatracker.ietf.org/doc/draft- January 2014, <https://datatracker.ietf.org/doc/draft-
ietf-urnbis-rfc2141bis-urn/>. ietf-urnbis-rfc2141bis-urn/>.
[RFC2483] Mealling, M. and R. Daniel, "URI Resolution Services [RFC2483] Mealling, M. and R. Daniel, "URI Resolution Services
Necessary for URN Resolution", RFC 2483, January 1999. Necessary for URN Resolution", RFC 2483, January 1999.
[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
"Uniform Resource Names (URN) Namespace Definition "Uniform Resource Names (URN) Namespace Definition
Mechanisms", BCP 66, RFC 3406, October 2002. Mechanisms", BCP 66, RFC 3406, October 2002.
[ServiceRequests] [ServiceRequests]
Klensin, J., "Names are Not Locators and URNs are Not Klensin, J., "Names are Not Locators and URNs are Not
URIs, Appendix B", July 2014, <http://www.ietf.org/id/ URIs, Appendix B", July 2014, <http://www.ietf.org/id/
draft-ietf-urnbis-urns-are-not-uris-01.txt>. draft-ietf-urnbis-urns-are-not-uris-01.txt>.
[URN-transition] [URN-transition]
Klensin, J. and J. Hakala, "Uniform Resource Name (URN) Klensin, J. and J. Hakala, "Uniform Resource Name (URN)
Namespace Registration Transition", August 2014, Namespace Registration Transition", February 2015,
<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
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" -- see for those who are sensitive to the term "identifier" such as many
Appendix B.1). The primary examples of these two categories are members of the library and information science communities.. The
Uniform Resource Names (URNs [RFC2141] [RFC2141bis]) and Uniform primary examples of these two categories are Uniform Resource Names
Resource Locators (URLs) [RFC1738]). That experience leads to the (URNs [RFC2141] [RFC2141bis]) and Uniform Resource Locators (URLs)
conclusion that it is impractical to constrain URNs to the high-level [RFC1738]). That experience leads to the conclusion that it is
semantics of URLs. The generic syntax for URIs [RFC3986] is impractical to constrain URNs to the high-level semantics of URLs.
adequately flexible to accommodate the perceived needs of URNs, but The generic syntax for URIs [RFC3986] is adequately flexible to
the specific semantics associated with the URI syntax definition -- accommodate the perceived needs of URNs, but the specific semantics
what particular constructions "mean" and how and where they are associated with the URI syntax definition -- what particular
interpreted -- appear to not be. Generalization from URLs to generic constructions "mean" and how and where they are interpreted -- appear
Uniform Resource Identifiers (URIs) [RFC3986], especially to name- to not be. Generalization from URLs to generic Uniform Resource
based, high-stability, long-persistence, identifiers such as many Identifiers (URIs) [RFC3986], especially to name-based, high-
URNs, has failed because the assumed similarities do not adequately stability, long-persistence, identifiers such as many URNs, has
extend to all forms of URNs. Ultimately, locators, which typically failed because the assumed similarities do not adequately extend to
depend on particular accessing protocols and a specification relative all forms of URNs. Ultimately, locators, which typically depend on
to some physical space or network topology, are simply different particular accessing protocols and a specification relative to some
creatures from long-persistence, location-independent, object physical space or network topology, are simply different creatures
identifiers. The syntax and semantic constraints that are from long-persistence, location-independent, object identifiers. The
appropriate for locators are either irrelevant to or interfere with syntax and semantic constraints that are appropriate for locators are
the needs of resource names as a class. That was tolerable as long either irrelevant to or interfere with the needs of resource names as
as the URN system didn't need additional capabilities (over those a class. That was tolerable as long as the URN system didn't need
specified in RFC 2141) but experience since RFC 2141 was published additional capabilities (over those specified in RFC 2141) but
has shown that they are, in fact, needed. experience since RFC 2141 was published has shown that they are, in
fact, needed.
Appendix B. Three views of locator-identifier separation
Beginning in the 1990s with the first discussions of generalizing
HTTP-style URLs to more general, "URI" forms with more or less
different properties, there have been controversies between people
and communities with strongly-held views about whether the
differences between "locators" and "identifiers" are real, whether
the categories are actually disjoint (RFC 3986 says that they are
not), and, if real differences exist, how they are manifested and
what their interests are. The subsections below are intended to at
least partially capture different views of those issues. They are
included here in the hope that they will assist with focusing
discussion and reduce the frequency with which arguments are
repeated. It is almost certain that the community does not have
consensus on all of the points made below and that these blocks of
text should be moved into other documents if they should be retained
at all.
B.1. A Perspective on Locations and Names
Content industries (e.g., publishers) and memory organizations (e.g.,
libraries, archives, and museums) invest a lot of resources on naming
things and the topics of naming and classification are important
information science issues. Tens, if not hundreds, of millions of
persistent identifiers have been assigned during the last decade.
Several identifier systems have been developed for persistent and
unique identification of resources. When there is a real need to
preserve something important (such as scientific publications,
research data, government publications, etc.) for the long term, URNs
or other persistent identifiers are used; URLs (or other generic
URIs) are not being used for identification or even linking purposes.
Naming and locating, e.g., for library resources, are both complex
activities which have different aims. Traditionally, naming and
locating resources have been separate activities, and the rules for
the former are much more stringent than for the latter. The same
principles are being applied to digital materials as well as more
traditional ones. In a library, any book, be it printed or digital,
has both unique and persistent International Standard Book Number
(ISBN) and non-unique (each copy has its own location information)
and short-lived location information which cannot be trusted in the
long run. ISBN never changes, but both shelf locations and Web
addresses usually do, many times during the book's life span.
Giving location information a role in identification would not only
force libraries to adopt different policies for printed and digital
content, it would also undermine the value of existing identifier
systems. Let us assume that ten people independently upload a copy
of an electronic book into different locations in the Web. Are all
these ten URLs valid identifiers of the book? And what is their
relation to the ISBN or other identification information of the book
such as its title?
From the perspective of the communities who depend on persistent
identifiers, critical issues include:
1. Resource identification has to be a managed process. Assigning
URIs generally is not. Although it may be possible to introduce
some level of control to URI assignment, a user cannot determine
whether some URI is reliable or not.
2. Anyone may assign new URIs to resources even if these resources
already have proper identifiers assigned to them. Claiming that
these URIs actually identify something undermines the value of
proper identifiers.
3. There is no 1:1 relation between the resource identified and
URIs. An e-book in the Web may be represented as 1-n files
(URIs), and a single file may contain several books. And books
are simple, we need to name very complex objects such as research
data sets, or some component parts within these complex data
sets.
4. One resource such as a scientific article is typically available
from multiple locations, including (for instance) the publisher's
document supply service, a university's open repositories and
other cooperative repository systems, legal deposit collections
and the Internet archive. A resource should have one and only
one identifier of a given type; URIs do not meet this
requirement.
5. URIs relate to instances (copies) of resources, whereas
traditionally identification has much broader scope. Identifiers
may be assigned to, e.g., an immaterial work (such as Hamlet),
its expressions (e.g. Finnish translation of Hamlet), and
manifestations of works and expressions (e.g. PDF version of
Finnish translation of Hamlet).
6. Over time, different resources (or different versions of the same
resource) may be found from the same non-URN URI. A user has no
way of knowing whether the resource has changed. One of the
basic principles for proper identifier systems is that the same
identifier is never assigned to another resource. In general,
URIs do not meet this requirement.
7. Persistent identification must be available for resources which
are available only in databases and other environments that are
often identified today as "deep web". URIs for these resources
tend to be very complicated and it will be difficult to keep them
alive even with the help of DNS redirection when e.g. the
underlying database management system changes.
8. The role URI fragment and query could or should have in
identification is unclear and the statements in RFC 3986 are
definitely problematic from the points of view of existing
identifier systems and management of naming.
Does "fragment" identify a location or a certain section of a
resource? In the evolving set of URN Internet standards,
fragment will not be a part of the Namespace Specific String.
Then fragment only indicates a place / segment within the
identified resource, but does not identify it. If fragment
had a role in identification, fragments would extend the scope
of existing standard identifiers to component parts of
resources. For instance, anyone could use URN based on ISBN +
fragment to identify chapters of electronic books.
Things get even more complicated with "query" since what the
combination of an identifier and a query resolves to may not
have anything to do with the original resource. For instance,
a URN based in ISBN + query may resolve to the metadata record
describing the book. These records have their own identifiers
which are not based on ISBNs.
9. For many organizations, persistence means decades or centuries.
Anything that is protocol dependent will eventually fail. URLs
do not change by themselves, but in the long run it is very
difficult for people to not change them or the objects to which
they point.
The mention of centuries is intentional. Content industries,
memory organizations (such as national and repository
libraries and national archives) and universities and other
research organizations, need identifiers that will persist for
hundreds of years. Such identifiers might even need to
outlast the institutions themselves, and definitely should be
usable even if current technologies such as the Web and the
Internet cease to exist or are supplanted by something new (as
unlikely as that might seem today).
In addition, operations on, or additional specifications
about, names and the associated objects must be possible, as
stable as the names themselves, and reasonably efficient. For
example, if a URN were assigned to an encyclopedia that
consisted of many volumes, it should be feasible to identify
(and locate and retrieve if that were desired) a particular
volume or even a particular article without accessing or
retrieving the entire set.
B.2. A More Pragmatic Perspective
The subsection above provides an explanation of the reasons for this
change and actually for a more radical separation of URNs from
generic URIs. That explanation is not without controversy,
especially from those who make different assumptions about the
future, or even interpretations of the present, than many members of
the community (and especially members of the communities described in
that section). Some of those who do not accept the explanation above
simply do not recognize and accept the distinctions on which it, and
URNs more generally, are based, including the name-locator
distinction. In some cases, opposition to that explanation is quite
pronounced, involving fundamental differences in philosophy that move
beyond mere differences of opinion.
Like most controversies in which one group does not accept the
definitions, facts, or logic of another, the differences are unlikely
to be resolved by further discussion, no matter how sensible and
patient. The material in this appendix is provided for the benefit
of those who cannot accept Appendix B.1 or consider the discussion
there to be meaningless.
Put differently, the issue is ultimately not whether the perspective
that Appendix B.1 reflects is, in some universal epistemology,
correct or incorrect or even whether the consequences and
implications of the introduction of the web and/or digital media
renders it hopelessly obsolete. If only in their manifestation
through national repository libraries and archives and setters of
standards for them -- activities that have far more formal authority
than the IETF or even W3C -- The community involved is relevant and
legitimate. If the IETF wishes to maintain authority over things
that are called URNs, then those perceived needs probably need to be
accommodated in some reasonable way... where "reasonable" is defined
as much or more by those communities as by the IETF one.
Independent of the details of the discussion above, in the case of
URNs, the IETF is faced with a pair of problems that are ultimately
faced sooner or later by all voluntary standards bodies: nothing
except quality and broad community consensus prevents a standard from
being ignored in the marketplace and nothing prevents another body
from creating a competing standard. The effort required to create a
competing standard can be increased and its potential for confusion
can be reduced somewhat by various measures -- measures the IETF has
rarely tried to actually use -- but those measures are rarely
effective when the other body is convinced that they have legitimate
and significant needs that differ from the original atandard.
Because of those problems, the key question for the URN effort is
ultimately not whether a clear enough distinction exists between
names and locator or location-based information, nor whether
"persistent" can be defined clearly enough, nor even whether the
communities and requirements described in Appendix B.1 are valid or
will be judged valid in retrospect in a few decades or centuries.
Instead, the question is whether the IETF is willing to evolve and
adapt the URN definition to accommodate those perceived needs or
whether if prefers to have that work done elsewhere, either by
adoption in the broader community and marketplace of a different
approach or, potentially, even a competing URN standard. If, in the
long run, those other communities and perspectives turn out to be
wrong, the additional features will atrophy. But that would be true
whether they are specified and standardized in the IETF or elsewhere.
B.3. A more radical (or most conservative) view of URNs and their role
[[CREF3: The text in this subsection was derived from an on-list
discussion. I believe it represents an even stronger position than
RFC 3986 takes although I think similar positions have come up in
other discussions. Because of its origins, the writing style is
somewhat different from the rest of this document. Again, this text
is provided for convenience and is not expected to survive into RFC
publication--JcK ]]
The essence of this position is that URNs are "just" names and that,
insofar as one can talk about location or resolution services of
various types, they are data associated with the URN (or underlying
name) and are not only not part of the URN but they are useful only
for constructing locator-type URIs to which the URN (name) is an
argument.
Suppose we have a URN that looks like
urn:isbn:1-4012-9876-1
It is really just a name. Associations with objects are someone
else's problem. There is actually no requirement that an object
exist, only that the publisher/registrant have sufficient intention
to create an object to assign the code. Now a query about metadata
associated with that name makes perfect sense although there are
questions about how far it should go (see below). For example, one
could invoke
urn:isbn:1-4012-9876-1?publisher
and, modulo some issues about queries being defined by the resource,
have a more than reasonable expectation of getting back "DC Comics".
But, since that is a name and not an object or the location of an
object, I don't know what a fragment is. One could certainly write
urn:isbn:1-4012-9876-1#publisher
or
urn:isbn:1-4012-9876-1#1
but, assuming one knows how ISBNs are constructed, the result would
presumably be
1-4012
and not anything useful, since there is no object to retrieve and
evaluate with regard to either media type or content.
If we are going to maintain a strong name - object distinction, this
approach makes a certain amount of sense.
An extreme version of the argument that we can't have fragments on
URNs because they are just names, not objects, might lead to the
claim that the only way one gets "Section 2" of that book is with
something like
http://school-
library.ps1234.k12.ma.example/?urn="isbn:1-4012-9876-1"&Section=2
or, in two more general cases:
myFavoriteLibraryRetrievalScheme://library-
domain.example/?urn="isbn:1-4012-9876-1"&Section=2
or maybe
http://www.generic-
bookseller.example/?urn="isbn:1-4012-9876-1"#Section=2
In all three of those cases and some other variations we can thinks
of, the URN is, itself, stable and persistent. Neither the two
schemes nor the domain parts associated with them need be.If the
fragment that refers to a section is valid, it is too (that doesn't
make it part of the name -- that is a separate question). The
retrieval/ resolution system is not a property of the URN. Instead,
the URN is a name-type argument --an object identifier-- used as
input to the retrieval system.
Appendix C. Change Log Appendix B. Change Log
[[CREF4: RFC Editor: Please remove this appendix before [[CREF3: RFC Editor: Please remove this appendix before
publication.]] publication.]]
C.1. Changes from draft-ietf-urnbis-urns-are-not-uris-00 to -01 B.1. Changes from draft-ietf-urnbis-urns-are-not-uris-00 (2014-04-07)
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.
o Added a Security Considerations section, replacing the placeholder o Added a Security Considerations section, replacing the placeholder
in the previous version. in the previous version.
o Added Appendix B.2 and inserted a note in the material titled "A o Added later-deleted Appendix B and inserted a note in the material
Perspective on Locations and Names" pointing to it (that material titled "A Perspective on Locations and Names" pointing to it (that
is in Appendix B.1 in the current version, but was Section 2 and material was removed from draft-ietf-urnbis-semantics-clarif-01,
then Section 3 in earlier versions). but was Section 2 and then Section 3 in earlier versions).
o Added temporary Appendix B for this version only. o Added temporary Appendix B for this version only.
o Enhanced and updated the Acknowledgments section. o Enhanced and updated the Acknowledgments section.
o The usual small clarifications and editorial changes. o The usual small clarifications and editorial changes.
C.2. Changes from draft-ietf-urnbis-urns-are-not-uris-01 to draft-ietf- B.2. Changes from draft-ietf-urnbis-urns-are-not-uris-01 to draft-ietf-
urnbis-semantics-clarif-00 urnbis-semantics-clarif-00 (2014-08-25)
o Changed title and file name to better reflect changes summarized o Changed title and file name to better reflect changes summarized
below. Note that the predecessor of this document was draft-ietf- below. Note that the predecessor of this document was draft-ietf-
urnbis-urns-are-not-uris-01. urnbis-urns-are-not-uris-01.
o Revised considerably as discussed on the mailing list and at IETF o Revised considerably as discussed on the mailing list and at IETF
90. In particular, the document has been narrowed to change 90. In particular, the document has been narrowed to change
semantics only without affecting the relationship to URI syntax semantics only without affecting the relationship to URI syntax
and the document title and other details changed to match. and the document title and other details changed to match.
o Dropped much of the original Introduction (moving it temporarily o Dropped much of the original Introduction (moving it temporarily
to an appendix) and trimmed the abstract to be consistent with the to an appendix) and trimmed the abstract to be consistent with the
new, more limited. scope. new, more limited. scope.
o Revised Appendix B.2 to make "perceived requirement" more clear. o Revised an earlier version of Appendix B to make "perceived
requirement" more clear.
o Removed the former Appendix B, as promised in the previous draft, o Removed the former Appendix B, as promised in the previous draft,
moved considerably more text into appendices, and added some new moved considerably more text into appendices, and added some new
appendix text. Note that the earlier text is temporarily appendix text.
referenced in Appendix B.3 above. If we intend to keep that
appendix material, we will have to drag at least part of the text
back in from the earlier draft.
o Added new Section 6 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. are approved. That material was removed from draft-ietf-urnbis-
semantics-clarif-01.
B.3. Changes from draft-ietf-urnbis-semantics-clarif-00 (2014-08-25) to
-01
o Removed some appendices and the topic discussion material, as
discused in the previous draft.
o Aligned the document and its terminology somewhat better with
draft-ietf-urnbis-rfc2141bis-urn-09 including providing for
p-components and using the p-/q-/f-component terminology.
o Made several clarifying changes to reflect mailing list
discussions (mostly of 2141bis) since the earlier version was
posted.
o Revised earlier portions of this change tracking appendix to
remove referenced to deleted material. It is not possible to
reconstruct what earlier versions of this document contained by
examining these change summaries.
o Moved specific comments about the IETF 90 discussions to
Acknowledgments and removed or edited some material that was only
appropriate for a discussion piece.
o Made several small editorial changes as usual.
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. 51 change blocks. 
573 lines changed or deleted 232 lines changed or added

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