draft-ietf-urnbis-semantics-clarif-02.txt   draft-ietf-urnbis-semantics-clarif-03.txt 
Uniform Resource Names (urnbis) J. Klensin Uniform Resource Names (urnbis) J. Klensin
Internet-Draft August 10, 2015 Internet-Draft February 5, 2016
Updates: 3986 (if approved) Updates: 3986 (if approved)
Intended status: Standards Track Intended status: Standards Track
Expires: February 11, 2016 Expires: August 8, 2016
URN Semantics Clarification URN Semantics Clarification
draft-ietf-urnbis-semantics-clarif-02.txt draft-ietf-urnbis-semantics-clarif-03.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 Information Science communities the Library, Museum, Publisher, and Information Science communities
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 11, 2016. This Internet-Draft will expire on August 8, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
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 . . . . . . . . . . 4
4. Changes to RFC 3986 . . . . . . . . . . . . . . . . . . . . . 5 4. Changes to RFC 3986 . . . . . . . . . . . . . . . . . . . . . 5
5. Actions Occurring in Parallel with this Specification . . . . 5 5. Actions Occurring in Parallel with this Specification . . . . 5
6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 6
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
10.1. Normative References . . . . . . . . . . . . . . . . . . 7 10.1. Normative References . . . . . . . . . . . . . . . . . . 7
10.2. Informative References . . . . . . . . . . . . . . . . . 7 10.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Background on the URN - URI relationship . . . . . . 8 Appendix A. Background on the URN - URI relationship . . . . . . 9
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 9 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 9
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) . . . . . . . . . . . . 9
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) . . 9 to draft-ietf-urnbis-semantics-clarif-00 (2014-08-25) . . 10
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 . . . . . . . . . . . . . . . . . . . 10
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 . . . . . . . . . . . . . . . . . . . 10 (2015-02-14) to -02 . . . . . . . . . . . . . . . . . . . 11
B.5. Changes from draft-ietf-urnbis-semantics-clarif-02
(2015-08-10) to -03 . . . . . . . . . . . . . . . . . . . 11
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 11
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 its scope has hampered several ways in which their inclusion under the 3986 scope has
understanding, adoption, and especially extension (specifically hampered understanding, adoption, and especially extension
extensions of types that were anticipated in RFC 2141). The need for (specifically extensions of types that were anticipated, but not
extensions to the URN concept is now being felt in some communities, defined, in RFC 2141). The need for extensions to the URN concept is
especially those that include libraries, museums, publishers, and now being felt in some communities, especially those that include
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>. This
specification excludes URNs from those definitions of meaning and specification excludes URNs from those definitions of meaning and
interpretation so that RFC 3986 applies to their syntax only. The interpretation so that RFC 3986 applies to their syntax only. The
meaning --and any more specific syntax rules-- for those fields for meaning --and any more specific syntax rules-- for those fields for
URNs are now defined in a URN-specific document [RFC2141bis]. URNs URNs are now defined in a URN-specific document [RFC2141bis]. URNs
remain members of the URI family and parsers for generic URI syntax remain members of the URI family and parsers for generic URI syntax
are not affected by this specification although parsers that make are not affected by this specification although parsers that make
assumptions based on other URI schemes obviously might be. assumptions based on other URI schemes obviously might be.
This specification does not discuss DDDS [RFC3401] resolution or Neither this specification nor the successor to RFC 2141 [RFC2141bis]
conversion to (and interpretation of) URCs [RFC2483] or URN discusses DDDS [RFC3401] resolution or conversion to (and
"resolution" more generally. Any of those topics that do need to be interpretation of) URCs [RFC2483] or, with the exception of providing
addressed should be covered in other documents. The document also some syntax to cover some specific cases, URN "resolution" more
does not discuss alternatives to URNs, either those that might use a generally. Any of those topics that do need to be addressed should
different scheme name within the RFC 3986 URI framework or those that be covered in other documents. The document also does not discuss
might use a different framework entirely. In particular, some alternatives to URNs, either those that might use a different scheme
externally-defined content or object identification systems could be name within the RFC 3986 URI framework or those that might use a
represented either by a URN namespace or through separate URI different framework entirely. In particular, some externally-defined
schemes. This specification does not offer advice on that choice content or object identification systems could be represented either
other than to suggest that the two options not be confused (or both by a URN namespace or through separate URI schemes. This
used in a way that would be confusing). 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 document updates RFC 3986 to make the distinction between syntax This document updates RFC 3986 to make the distinction between syntax
and semantics clear for URNs and to isolate URNs from presumed URI and semantics clear for URNs and to isolate URNs from presumed URI
semantic requiremnts. It is important to note that some readers of semantic requiremnts. It is important to note that some readers of
RFC 3986 are convinced that the separation is clear in that RFC 3986 are convinced that the separation is clear in that
specification and therefore that no changes to that document are specification and therefore that no changes to that document are
needed. For them, this specification is only a confirming needed. For them, this specification is only a confirming
clarification. 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
skipping to change at page 4, line 20 skipping to change at page 4, line 24
follow, the change made (or clarification provided) by this follow, 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 or ultimate truths. Instead, it is motivated by
three very pragmatic principles and goals: three very pragmatic principles and goals:
1. Accommodate all of those who think URNs are necessary, i.e., that 1. Accommodate all of those who think URNs are necessary, i.e., that
they can and should be usefully distinguished from other URIs, at they can and should be usefully distinguished from other URIs, at
least location-oriented ones including URI schemes defined prior least location-oriented ones including URI schemes defined prior
to the time work started on this document in August 2014. In to the time work started on this document in August 2014. In
particular, provide a foundation for extensions to the URN syntax particular, provide a foundation for extensions to the URN syntax
(as allowed by and defined in RFC 2141) to support requirements (as allowed by and partially defined in RFC 2141) to support
encountered by some of those communities. 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. correct in the abstract.
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 will 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 that applicability of the normal English meanings of such terms as
"query" or "fragment" are a matter for URN-specific specifications. "query" or "fragment" are a matter for URN-specific specifications.
It helps lay the foundarion for the distinguishing terms It helps lay the foundation for the distinguishing terms
"p-component", "q-component", and "f-component" in the accompanying "q-component", "r-component", and "f-component" in the accompanying
URN definition specification [RFC2141bis]. 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 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
skipping to change at page 5, line 23 skipping to change at page 5, line 26
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 path segments that appear In particular (but without altering RFC 3986 in any way), the generic
after the NID and NSS of a URN, i.e., after an initial "/", for URI syntax for "queries" (strings starting with "?" and continuing to
"queries" (strings starting with "?" and continuing to the end of the the end of the URI or to a "#"), and for "fragments" (strings
URI or to a "#"), and for "fragments" (strings starting with "#" and starting with "#" and continuing to the end of the URI) is unchanged.
continuing to the end of the URI) is unchanged, but the terms for For URNs, additional syntax is introduced to divide the URI "query"
those path segments, "query" and "fragment" become, for URNs, terms into two parts, referred to as "q-components" and "r-components".
of convenience that are defined in URN-specific ways as p-components, The syntax and general semantics of "fragments" (specified in RFC
q-components, and f-components [RFC2141bis]. 3986 as scheme-independent) are unchanged, but a somewhat liberal
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
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.
skipping to change at page 6, line 43 skipping to change at page 7, line 7
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 this section before publication.]] [[CREF2: RFC Editor: Please remove the first paragraph below 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.
particular, we note that there is a collection of "Uniform Resource
Identifier (URI) Schemes" that does not include URNs and a series of There is an existing (i.e. prior to the publication of this document)
URN-specific registries that do not rely on the URI specificstions. registry for "Uniform Resource Identifier (URI) Schemes" that already
includes the "urn" scheme itself and a separate existing URN
Namespace registry. None of those registrations have any specific
dependencies on generic URI specifications.
9. 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.
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
(URN) Syntax", June 2015, (URN) Syntax", February 2016,
<https://datatracker.ietf.org/doc/draft-ietf-urnbis- <https://datatracker.ietf.org/doc/draft-ietf-urnbis-
rfc2141bis-urn/>. rfc2141bis-urn/>.
[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, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<http://www.rfc-editor.org/info/rfc3986>. <http://www.rfc-editor.org/info/rfc3986>.
10.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>.
This is an expired document, cited for historical context
only.
[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>.
[RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform [RFC1738] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738, Resource Locators (URL)", RFC 1738, DOI 10.17487/RFC1738,
December 1994, <http://www.rfc-editor.org/info/rfc1738>. December 1994, <http://www.rfc-editor.org/info/rfc1738>.
[RFC2483] Mealling, M. and R. Daniel, "URI Resolution Services [RFC2483] Mealling, M. and R. Daniel, "URI Resolution Services
skipping to change at page 8, line 20 skipping to change at page 8, line 37
[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, DOI 10.17487/RFC3406, Mechanisms", BCP 66, RFC 3406, DOI 10.17487/RFC3406,
October 2002, <http://www.rfc-editor.org/info/rfc3406>. October 2002, <http://www.rfc-editor.org/info/rfc3406>.
[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>.
This is an expired document, cited for historical context
only.
[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 2015, 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
The Internet community now has many years of experience with both The Internet community now has many years of experience with both
skipping to change at page 11, line 5 skipping to change at page 11, line 28
o Made several small editorial changes as usual. o Made several small editorial changes as usual.
B.4. Changes from draft-ietf-urnbis-semantics-clarif-01 (2015-02-14) to B.4. Changes from draft-ietf-urnbis-semantics-clarif-01 (2015-02-14) to
-02 -02
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
-03
o Made a few substantive updates to reflect evolution in 2141bis,
particularly the elimination of p-component as a separate category
and the added distinction between q-component and r-component..
o Updated references and made several minor editorial changes to
improve clarity.
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. 22 change blocks. 
47 lines changed or deleted 74 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/