2466 lines
No EOL
144 KiB
HTML
2466 lines
No EOL
144 KiB
HTML
<!DOCTYPE html>
|
|
<!-- saved from url=(0045)https://datatracker.ietf.org/doc/html/rfc8141 -->
|
|
<html lang="en"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
|
|
|
|
<meta http-equiv="X-UA-Compatible" content="IE=edge">
|
|
<title>
|
|
|
|
rfc8141
|
|
|
|
</title>
|
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|
<style>
|
|
|
|
@media only screen
|
|
and (min-width: 992px)
|
|
and (max-width: 1199px) {
|
|
body { font-size: 14pt; }
|
|
div.content { width: 96ex; margin: 0 auto; }
|
|
}
|
|
@media only screen
|
|
and (min-width: 768px)
|
|
and (max-width: 991px) {
|
|
body { font-size: 14pt; }
|
|
div.content { width: 96ex; margin: 0 auto; }
|
|
}
|
|
@media only screen
|
|
and (min-width: 480px)
|
|
and (max-width: 767px) {
|
|
body { font-size: 11pt; }
|
|
div.content { width: 96ex; margin: 0 auto; }
|
|
}
|
|
@media only screen
|
|
and (max-width: 479px) {
|
|
body { font-size: 8pt; }
|
|
div.content { width: 96ex; margin: 0 auto; }
|
|
}
|
|
@media only screen
|
|
and (min-device-width : 375px)
|
|
and (max-device-width : 667px) {
|
|
body { font-size: 9.5pt; }
|
|
div.content { width: 96ex; margin: 0; }
|
|
}
|
|
@media only screen
|
|
and (min-device-width: 1200px) {
|
|
body { font-size: 10pt; margin: 0 4em; }
|
|
div.content { width: 96ex; margin: 0; }
|
|
}
|
|
h1, h2, h3, h4, h5, h6, .h1, .h2, .h3, .h4, .h5, .h6 {
|
|
font-weight: bold;
|
|
/* line-height: 0pt; */
|
|
display: inline;
|
|
white-space: pre;
|
|
font-family: monospace;
|
|
font-size: 1em;
|
|
font-weight: bold;
|
|
}
|
|
pre {
|
|
font-size: 1em;
|
|
margin-top: 0px;
|
|
margin-bottom: 0px;
|
|
}
|
|
.pre {
|
|
white-space: pre;
|
|
font-family: monospace;
|
|
}
|
|
.header{
|
|
font-weight: bold;
|
|
}
|
|
.newpage {
|
|
page-break-before: always;
|
|
}
|
|
.invisible {
|
|
text-decoration: none;
|
|
color: white;
|
|
}
|
|
@media print {
|
|
body {
|
|
margin-top: 5em;
|
|
font-family: monospace;
|
|
font-size: 10.5pt;
|
|
}
|
|
h1, h2, h3, h4, h5, h6 {
|
|
font-size: 1em;
|
|
}
|
|
|
|
a:link, a:visited {
|
|
color: inherit;
|
|
text-decoration: none;
|
|
}
|
|
.noprint {
|
|
display: none;
|
|
}
|
|
}
|
|
@media screen {
|
|
.grey, .grey a:link, .grey a:visited {
|
|
color: #777;
|
|
}
|
|
.meta-info {
|
|
background-color: #EEE;
|
|
}
|
|
.top {
|
|
border-top: 7px solid #EEE;
|
|
}
|
|
.pad {
|
|
padding-top: 7px;
|
|
line-height: 24px;
|
|
padding-bottom: 4px;
|
|
}
|
|
.bgwhite { background-color: white; }
|
|
.bgred { background-color: #F44; }
|
|
.bggrey { background-color: #666; }
|
|
.bgbrown { background-color: #840; }
|
|
.bgorange { background-color: #FA0; }
|
|
.bgyellow { background-color: #EE0; }
|
|
.bgmagenta{ background-color: #F4F; }
|
|
.bgblue { background-color: #66F; }
|
|
.bgcyan { background-color: #4DD; }
|
|
.bggreen { background-color: #4F4; }
|
|
|
|
.legend { font-size: 90%; }
|
|
.cplate { font-size: 70%; border: solid grey 1px; }
|
|
}
|
|
|
|
|
|
|
|
.bgwhite { background-color: white; }
|
|
.bgred { background-color: #F44; }
|
|
.bggrey { background-color: #666; }
|
|
.bgbrown { background-color: #840; }
|
|
.bgorange { background-color: #FA0; }
|
|
.bgyellow { background-color: #EE0; }
|
|
.bgmagenta{ background-color: #F4F; }
|
|
.bgblue { background-color: #66F; }
|
|
.bgcyan { background-color: #4DD; }
|
|
.bggreen { background-color: #4F4; }
|
|
|
|
.draftcontent { margin-top:0px !important;}
|
|
|
|
|
|
</style>
|
|
|
|
<!--[if lt IE 9]>
|
|
<script src="https://www.ietf.org/lib/dt/7.36.0/html5shiv/html5shiv.min.js"></script>
|
|
<script src="https://www.ietf.org/lib/dt/7.36.0/respond/dest/respond.min.js"></script>
|
|
<![endif]-->
|
|
|
|
<link rel="alternate" type="application/atom+xml" title="Document changes" href="https://datatracker.ietf.org/feed/document-changes/draft-ietf-urnbis-rfc2141bis-urn/">
|
|
<meta name="description" content="Uniform Resource Names (URNs) (RFC )">
|
|
<script src="./rfc8141_files/d3.min.js.download"></script>
|
|
<script src="./rfc8141_files/jquery.min.js.download"></script>
|
|
|
|
|
|
|
|
<link rel="shortcut icon" href="https://www.ietf.org/lib/dt/7.36.0/ietf/images/ietf-icon-blue3.png">
|
|
|
|
<link rel="apple-touch-icon" href="https://www.ietf.org/lib/dt/7.36.0/ietf/images/apple-touch-icon.png">
|
|
</head>
|
|
|
|
<body style="padding-top: 0;">
|
|
|
|
<div class="content" id="content">
|
|
|
|
<!-- template: /a/www/ietf-datatracker/web/ietf/templates/doc/document_html.html -->
|
|
|
|
<div class="rfcmarkup">
|
|
<div class="noprint" style="height: 6px;">
|
|
<div onmouseover="this.style.cursor='pointer';" onclick="showLegend();" onmouseout="hideLegend()" style="height: 6px; min-height: 6px; width: 96ex; position: absolute; margin-top:0; " class="meta-info bgblue" title="Click for colour legend."> </div>
|
|
<div id="legend" class="meta-info noprint pre legend" style="position:absolute; top: 4px; left: 4ex; visibility:hidden; background-color: white; padding: 4px 9px 5px 7px; border: solid #345 1px; " onmouseover="showLegend();" onmouseout="hideLegend();">
|
|
</div>
|
|
</div>
|
|
|
|
|
|
<div class="noprint">
|
|
<pre class="pre meta-info">[<a href="https://datatracker.ietf.org/" title="Document search and retrieval page">Search</a>] [<a href="https://www.rfc-editor.org/rfc/rfc8141.txt" title="Plaintext version of this document">txt</a>|<a href="https://www.rfc-editor.org/rfc/rfc8141.html" title="HTML version of this document, from XML2RFC">html</a>|<a href="https://www.rfc-editor.org/rfc/pdfrfc/rfc8141.txt.pdf" title="PDF version of this document">pdf</a>|<a href="https://datatracker.ietf.org/doc/rfc8141/bibtex" title="BibTex entry for this document">bibtex</a>] [<a href="https://datatracker.ietf.org/doc/rfc8141/" title="Datatracker information for this document">Tracker</a>] [<a href="https://datatracker.ietf.org/group/urnbis/" title="The working group handling this document">WG</a>] [<a href="mailto:draft-ietf-urnbis-rfc2141bis-urn@ietf.org?subject=draft-ietf-urnbis-rfc2141bis-urn" title="Send email to the document authors">Email</a>] [<a href="https://www.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-urnbis-rfc2141bis-urn-22.txt" title="Inline diff (wdiff)">Diff1</a>] [<a href="https://www.ietf.org/rfcdiff?url2=draft-ietf-urnbis-rfc2141bis-urn-22.txt" title="Side-by-side diff">Diff2</a>] [<a href="https://www.ietf.org/tools/idnits?url=https://www.ietf.org/archive/id/draft-ietf-urnbis-rfc2141bis-urn-22.txt" title="Run an idnits check of this document">Nits</a>]
|
|
|
|
From: <a href="https://datatracker.ietf.org/doc/html/draft-ietf-urnbis-rfc2141bis-urn-22">draft-ietf-urnbis-rfc2141bis-urn-22</a> Proposed Standard</pre>
|
|
</div>
|
|
|
|
|
|
<div class="draftcontent">
|
|
<pre>Internet Engineering Task Force (IETF) P. Saint-Andre
|
|
Request for Comments: 8141 Filament
|
|
Obsoletes: <a href="https://datatracker.ietf.org/doc/html/rfc2141">2141</a>, <a href="https://datatracker.ietf.org/doc/html/rfc3406">3406</a> J. Klensin
|
|
Category: Standards Track April 2017
|
|
ISSN: 2070-1721
|
|
|
|
|
|
<span class="h1">Uniform Resource Names (URNs)</span>
|
|
|
|
Abstract
|
|
|
|
A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI)
|
|
that is assigned under the "urn" URI scheme and a particular URN
|
|
namespace, with the intent that the URN will be a persistent,
|
|
location-independent resource identifier. With regard to URN syntax,
|
|
this document defines the canonical syntax for URNs (in a way that is
|
|
consistent with URI syntax), specifies methods for determining URN-
|
|
equivalence, and discusses URI conformance. With regard to URN
|
|
namespaces, this document specifies a method for defining a URN
|
|
namespace and associating it with a namespace identifier, and it
|
|
describes procedures for registering namespace identifiers with the
|
|
Internet Assigned Numbers Authority (IANA). This document obsoletes
|
|
both RFCs 2141 and 3406.
|
|
|
|
Status of This Memo
|
|
|
|
This is an Internet Standards Track document.
|
|
|
|
This document is a product of the Internet Engineering Task Force
|
|
(IETF). It represents the consensus of the IETF community. It has
|
|
received public review and has been approved for publication by the
|
|
Internet Engineering Steering Group (IESG). Further information on
|
|
Internet Standards is available in <a href="https://datatracker.ietf.org/doc/html/rfc7841#section-2">Section 2 of RFC 7841</a>.
|
|
|
|
Information about the current status of this document, any errata,
|
|
and how to provide feedback on it may be obtained at
|
|
<a href="http://www.rfc-editor.org/info/rfc8141">http://www.rfc-editor.org/info/rfc8141</a>.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 1]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-2"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
Copyright Notice
|
|
|
|
Copyright (c) 2017 IETF Trust and the persons identified as the
|
|
document authors. All rights reserved.
|
|
|
|
This document is subject to <a href="https://datatracker.ietf.org/doc/html/bcp78">BCP 78</a> and the IETF Trust's Legal
|
|
Provisions Relating to IETF Documents
|
|
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) in effect on the date of
|
|
publication of this document. Please review these documents
|
|
carefully, as they describe your rights and restrictions with respect
|
|
to this document. Code Components extracted from this document must
|
|
include Simplified BSD License text as described in Section 4.e of
|
|
the Trust Legal Provisions and are provided without warranty as
|
|
described in the Simplified BSD License.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 2]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-3"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
Table of Contents
|
|
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-4">4</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-1.1">1.1</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-5">5</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-1.2">1.2</a>. Design Trade-offs . . . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-6">6</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-1.2.1">1.2.1</a>. Resolution . . . . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-8">8</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-1.2.2">1.2.2</a>. Character Sets and Encodings . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-9">9</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-2">2</a>. URN Syntax . . . . . . . . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-9">9</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-2.1">2.1</a>. Namespace Identifier (NID) . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-10">10</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-2.2">2.2</a>. Namespace Specific String (NSS) . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-10">10</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-2.3">2.3</a>. Optional Components . . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-12">12</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-2.3.1">2.3.1</a>. r-component . . . . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-12">12</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-2.3.2">2.3.2</a>. q-component . . . . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-13">13</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-2.3.3">2.3.3</a>. f-component . . . . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-15">15</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-3">3</a>. URN-Equivalence . . . . . . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-16">16</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-3.1">3.1</a>. Procedure . . . . . . . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-16">16</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-3.2">3.2</a>. Examples . . . . . . . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-17">17</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-4">4</a>. URI Conformance . . . . . . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-18">18</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-4.1">4.1</a>. Use in URI Protocol Slots . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-18">18</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-4.2">4.2</a>. Parsing . . . . . . . . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-19">19</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-4.3">4.3</a>. URNs and Relative References . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-19">19</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-4.4">4.4</a>. Transport and Display . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-19">19</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-4.5">4.5</a>. URI Design and Ownership . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-20">20</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-5">5</a>. URN Namespaces . . . . . . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-20">20</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-5.1">5.1</a>. Formal URN Namespaces . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-22">22</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-5.2">5.2</a>. Informal URN Namespaces . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-23">23</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-6">6</a>. Defining and Registering a URN Namespace . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-24">24</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.1">6.1</a>. Overview . . . . . . . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-24">24</a>
|
|
6.2. Registration Policy and Process: Community Registrations 25
|
|
6.3. Registration Policy and Process: Fast Track for Standards
|
|
Development Organizations, Scientific Societies, and
|
|
Similar Bodies . . . . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-26">26</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.4">6.4</a>. Completing the Template . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-27">27</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.4.1">6.4.1</a>. Purpose . . . . . . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-27">27</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.4.2">6.4.2</a>. Syntax . . . . . . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-28">28</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.4.3">6.4.3</a>. Assignment . . . . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-29">29</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.4.4">6.4.4</a>. Security and Privacy . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-29">29</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.4.5">6.4.5</a>. Interoperability . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-30">30</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.4.6">6.4.6</a>. Resolution . . . . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-30">30</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.4.7">6.4.7</a>. Additional Information . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-30">30</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-7">7</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-31">31</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-7.1">7.1</a>. URI Scheme . . . . . . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-31">31</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-7.2">7.2</a>. Registration of URN Namespaces . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-31">31</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-7.3">7.3</a>. Discussion List for New and Updated NID Registrations . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-31">31</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-8">8</a>. Security and Privacy Considerations . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-32">32</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-9">9</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-32">32</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-9.1">9.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-32">32</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-9.2">9.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-32">32</a>
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 3]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-4"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#appendix-A">Appendix A</a>. Registration Template . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-37">37</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#appendix-B">Appendix B</a>. Changes from <a href="https://datatracker.ietf.org/doc/html/rfc2141">RFC 2141</a> . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-38">38</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#appendix-B.1">B.1</a>. Syntax Changes from <a href="https://datatracker.ietf.org/doc/html/rfc2141">RFC 2141</a> . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-38">38</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#appendix-B.2">B.2</a>. Other Changes from <a href="https://datatracker.ietf.org/doc/html/rfc2141">RFC 2141</a> . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-39">39</a>
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#appendix-C">Appendix C</a>. Changes from <a href="https://datatracker.ietf.org/doc/html/rfc3406">RFC 3406</a> . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-39">39</a>
|
|
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-40">40</a>
|
|
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-40">40</a>
|
|
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . <a href="https://datatracker.ietf.org/doc/html/rfc8141#page-40">40</a>
|
|
|
|
<span class="h2"><a class="selflink" id="section-1" href="https://datatracker.ietf.org/doc/html/rfc8141#section-1">1</a>. Introduction</span>
|
|
|
|
A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI)
|
|
[<a href="https://datatracker.ietf.org/doc/html/rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>] that is assigned under the "urn" URI scheme and a
|
|
particular URN namespace, with the intent that the URN will be a
|
|
persistent, location-independent resource identifier. A URN
|
|
namespace is a collection of such URNs, each of which is (1) unique,
|
|
(2) assigned in a consistent and managed way, and (3) assigned
|
|
according to a common definition. (Some URN namespaces create names
|
|
that exist only as URNs, whereas others assign URNs based on names
|
|
that were already created in non-URN identifier systems, such as
|
|
ISBNs [<a href="https://datatracker.ietf.org/doc/html/rfc3187" title=""Using International Standard Book Numbers as Uniform Resource Names"">RFC3187</a>], ISSNs [<a href="https://datatracker.ietf.org/doc/html/rfc3044" title=""Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace"">RFC3044</a>], or RFCs [<a href="https://datatracker.ietf.org/doc/html/rfc2648" title=""A URN Namespace for IETF Documents"">RFC2648</a>].)
|
|
|
|
The assignment of URNs is done by an organization (or, in some cases,
|
|
according to an algorithm or other automated process) that has been
|
|
formally delegated a URN namespace within the "urn" scheme (e.g., a
|
|
URN in the "example" URN namespace [<a href="https://datatracker.ietf.org/doc/html/rfc6963" title=""A Uniform Resource Name (URN) Namespace for Examples"">RFC6963</a>] might be of the form
|
|
"urn:example:foo").
|
|
|
|
This document rests on two key assumptions:
|
|
|
|
1. Assignment of a URN is a managed process.
|
|
|
|
2. The space of URN namespaces is itself managed.
|
|
|
|
While other URI schemes may allow resource identifiers to be freely
|
|
chosen and assigned, such is not the case for URNs. The syntactical
|
|
correctness of a name starting with "urn:" is not sufficient to make
|
|
it a URN. In order for the name to be a valid URN, the namespace
|
|
identifier (NID) needs to be registered in accordance with the rules
|
|
defined here, and the remaining parts of the assigned-name portion of
|
|
the URN need to be generated in accordance with the rules for the
|
|
registered URN namespace.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 4]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-5"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
So that information about both URN syntax and URN namespaces is
|
|
available in one place, this document does the following:
|
|
|
|
1. Defines the canonical syntax for URNs in general (in a way that
|
|
is consistent with URI syntax), specifies methods for determining
|
|
URN-equivalence, and discusses URI conformance.
|
|
|
|
2. Specifies a method for defining a URN namespace and associating
|
|
it with a particular NID, and describes procedures for
|
|
registering URN NIDs with the Internet Assigned Numbers Authority
|
|
(IANA).
|
|
|
|
For URN syntax and URN namespaces, this document modernizes and
|
|
replaces the original specifications for URN syntax [<a href="https://datatracker.ietf.org/doc/html/rfc2141" title=""URN Syntax"">RFC2141</a>] and for
|
|
the definition and registration of URN namespaces [<a href="https://datatracker.ietf.org/doc/html/rfc3406" title=""Uniform Resource Names (URN) Namespace Definition Mechanisms"">RFC3406</a>]. These
|
|
modifications build on the key requirements provided in the original
|
|
functional description for URNs [<a href="https://datatracker.ietf.org/doc/html/rfc1737" title=""Functional Requirements for Uniform Resource Names"">RFC1737</a>] and on the lessons of many
|
|
years of experience. In those original documents and in the present
|
|
one, the intent is to define URNs in a consistent manner so that,
|
|
wherever practical, the parsing, handling, and resolution of URNs can
|
|
be independent of the URN namespace within which a given URN is
|
|
assigned.
|
|
|
|
Together with input from several key user communities, the history
|
|
and experiences with URNs dictated expansion of the URN definition to
|
|
support new functionality, including the use of syntax explicitly
|
|
reserved for future standardization in <a href="https://datatracker.ietf.org/doc/html/rfc2141">RFC 2141</a>. All URN namespaces
|
|
and URNs that were valid under the earlier specifications remain
|
|
valid, even though it may be useful to update the definitions of some
|
|
URN namespaces to take advantage of new features.
|
|
|
|
The foregoing considerations, together with various differences
|
|
between URNs and URIs that are locators (specifically URLs) as well
|
|
as the greater focus on URLs in <a href="https://datatracker.ietf.org/doc/html/rfc3986">RFC 3986</a> as the ultimate successor to
|
|
[<a href="https://datatracker.ietf.org/doc/html/rfc1738" title=""Uniform Resource Locators (URL)"">RFC1738</a>] and [<a href="https://datatracker.ietf.org/doc/html/rfc1808" title=""Relative Uniform Resource Locators"">RFC1808</a>], may lead to some interpretations of <a href="https://datatracker.ietf.org/doc/html/rfc3986">RFC 3986</a>
|
|
and this specification that appear (or perhaps actually are) not
|
|
completely consistent, especially with regard to actions or semantics
|
|
other than the basic syntax itself. If such situations arise,
|
|
discussions of URNs and URN namespaces should be interpreted
|
|
according to this document and not by extrapolation from <a href="https://datatracker.ietf.org/doc/html/rfc3986">RFC 3986</a>.
|
|
|
|
Summaries of changes from RFCs 2141 and 3406 appear in Appendices B
|
|
and C, respectively. This document obsoletes both [<a href="https://datatracker.ietf.org/doc/html/rfc2141" title=""URN Syntax"">RFC2141</a>] and
|
|
[<a href="https://datatracker.ietf.org/doc/html/rfc3406" title=""Uniform Resource Names (URN) Namespace Definition Mechanisms"">RFC3406</a>]. While it does not explicitly update or replace [<a href="https://datatracker.ietf.org/doc/html/rfc1737" title=""Functional Requirements for Uniform Resource Names"">RFC1737</a>]
|
|
or [<a href="https://datatracker.ietf.org/doc/html/rfc2276" title=""Architectural Principles of Uniform Resource Name Resolution"">RFC2276</a>], the reader who references those documents should be
|
|
aware that the conceptual model of URNs in this document is slightly
|
|
different from those older specifications.
|
|
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 5]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-6"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
<span class="h3"><a class="selflink" id="section-1.1" href="https://datatracker.ietf.org/doc/html/rfc8141#section-1.1">1.1</a>. Terminology</span>
|
|
|
|
The following terms are distinguished from each other as described
|
|
below:
|
|
|
|
URN: A URI (as defined in <a href="https://datatracker.ietf.org/doc/html/rfc3986">RFC 3986</a>) using the "urn" scheme and with
|
|
the properties of a "name" as described in that document as well
|
|
as the properties described in this one. The term applies to the
|
|
entire URI including its optional components. Note to the reader:
|
|
the term "URN" has been used in other contexts to refer to a URN
|
|
namespace, the namespace identifier, the assigned-name, and URIs
|
|
that do not use the "urn" scheme. All but the last of these is
|
|
described using more specific terminology elsewhere in this
|
|
document, but, because of those other uses, the term should be
|
|
used and interpreted with care.
|
|
|
|
Locator: An identifier that provides a means of accessing a
|
|
resource.
|
|
|
|
Identifier system: A managed collection of names. This document
|
|
refers to identifier systems outside the context of URNs as
|
|
"non-URN identifier systems".
|
|
|
|
URN namespace: An identifier system that is associated with a URN
|
|
NID.
|
|
|
|
NID: The identifier associated with a URN namespace.
|
|
|
|
NSS: The URN-namespace-specific part of a URN.
|
|
|
|
Assigned-name: The combination of the "urn:" scheme, the NID, and
|
|
the namespace specific string (NSS). An "assigned-name" is
|
|
consequently a substring of a URN (as defined above) if that URN
|
|
contains any additional components (see <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-2">Section 2</a>).
|
|
|
|
The term "name" is deliberately not defined here and should be (and,
|
|
in practice, is) used only very informally. <a href="https://datatracker.ietf.org/doc/html/rfc3986">RFC 3986</a> uses the term
|
|
as a category of URI distinguished from "locator" (<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-1.1.3">Section 1.1.3</a>) but
|
|
also uses it in other contexts. If those uses are treated as
|
|
definitional, they would conflict with, e.g., the idea of URN
|
|
namespace names (i.e., NIDs) and with terms associated with non-URN
|
|
identifier systems.
|
|
|
|
This document uses the terms "resource", "identifier", "identify",
|
|
"dereference", "representation", and "metadata" roughly as defined in
|
|
the URI specification [<a href="https://datatracker.ietf.org/doc/html/rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>].
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 6]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-7"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
This document uses the terms "resolution" and "resolver" in roughly
|
|
the sense in which they were used in the original discussion of
|
|
architectural principles for URNs [<a href="https://datatracker.ietf.org/doc/html/rfc2276" title=""Architectural Principles of Uniform Resource Name Resolution"">RFC2276</a>], i.e., "resolution" is
|
|
the act of supplying services related to the identified resource,
|
|
such as translating the persistent URN into one or more current
|
|
locators for the resource, delivering metadata about the resource in
|
|
an appropriate format, or even delivering a representation of the
|
|
resource (e.g., a document) without requiring further intermediaries.
|
|
At the time of this writing, resolution services are described in
|
|
[<a href="https://datatracker.ietf.org/doc/html/rfc2483" title=""URI Resolution Services Necessary for URN Resolution"">RFC2483</a>].
|
|
|
|
On the distinction between representations and metadata, see
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc3986#section-1.2.2">Section 1.2.2 of [RFC3986]</a>.
|
|
|
|
Several other terms related to "normalization" operations that are
|
|
not part of the Unicode Standard [<a href="https://datatracker.ietf.org/doc/html/rfc8141#ref-UNICODE" title=""The Unicode Standard"">UNICODE</a>] are also used here as they
|
|
are in <a href="https://datatracker.ietf.org/doc/html/rfc3986">RFC 3986</a>.
|
|
|
|
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
|
|
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
|
|
"OPTIONAL" in this document are to be interpreted as described in
|
|
[<a href="https://datatracker.ietf.org/doc/html/rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
|
|
|
|
<span class="h3"><a class="selflink" id="section-1.2" href="https://datatracker.ietf.org/doc/html/rfc8141#section-1.2">1.2</a>. Design Trade-offs</span>
|
|
|
|
To a degree much greater than when URNs were first considered and
|
|
their uses outlined (see [<a href="https://datatracker.ietf.org/doc/html/rfc1737" title=""Functional Requirements for Uniform Resource Names"">RFC1737</a>]), issues of persistent identifiers
|
|
on the Internet involve fundamental design trade-offs that are much
|
|
broader than URNs or the URN approach and even touch on open research
|
|
questions within the information sciences community. Ideal and
|
|
comprehensive specifications about what should be done or required
|
|
across the entire universe of URNs would require general agreement
|
|
about, and solutions to, a wide range of such issues. Although some
|
|
of those issues were introduced by the Internet or computer-age
|
|
approaches to character encodings and data abstraction, others
|
|
predate the Internet and computer systems by centuries; there is
|
|
unlikely to be agreement about comprehensive solutions in the near
|
|
future.
|
|
|
|
Although this specification consequently contains some requirements
|
|
and flexibility that would not be present in a more perfect world,
|
|
this has been necessary in order to produce a consensus specification
|
|
that provides a modernized definition of URNs (the unattractive
|
|
alternative would have been to not modernize the definition in spite
|
|
of widespread deployment).
|
|
|
|
The following sub-sections describe two of the relevant issues in
|
|
greater detail.
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 7]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-8"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
<span class="h4"><a class="selflink" id="section-1.2.1" href="https://datatracker.ietf.org/doc/html/rfc8141#section-1.2.1">1.2.1</a>. Resolution</span>
|
|
|
|
One issue that is specific to URNs (as opposed to naming systems in
|
|
general) is the fairly difficult topic of "resolution", discussed in
|
|
Sections <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-1.1">1.1</a>, <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-2.3.1">2.3.1</a>, <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.4.6">6.4.6</a>, and elsewhere below.
|
|
|
|
With traditional Uniform Resource Locators (URLs), i.e., with most
|
|
URIs that are locators, resolution is relatively straightforward
|
|
because it is used to determine an access mechanism that in turn is
|
|
used to dereference the locator by (typically) retrieving a
|
|
representation of the associated resource, such as a document (see
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc3986#section-1.2.2">Section 1.2.2 of [RFC3986]</a>).
|
|
|
|
By contrast, resolution for URNs is more flexible and varied.
|
|
|
|
One important case involves the mapping of a URN to one or more
|
|
locators. In this case, the end result is still a matter of
|
|
dereferencing the mapped locator(s) to one or more representations.
|
|
The primary difference here is persistence: even if a mapped locator
|
|
has changed (e.g., a DNS domain name has changed hands and a URL has
|
|
not been modified to point to a new location or, in a more extreme
|
|
and hypothetical case, the DNS is replaced entirely), a URN user will
|
|
be able to obtain the correct representation (e.g., a document) as
|
|
long as the resolver has kept its URN-to-locator mappings up to date.
|
|
Consequently, the relevant relationships can be defined quite
|
|
precisely for URNs that resolve to locators that in turn are
|
|
dereferenced to a representation.
|
|
|
|
However, this specification permits several other cases of URN
|
|
resolution as well as URNs for resources that do not involve
|
|
information retrieval systems. This is true either individually for
|
|
particular URNs or (as defined below) collectively for entire URN
|
|
namespaces.
|
|
|
|
Consider a namespace of URNs that resolve to locators that in turn
|
|
are dereferenced only to metadata about resources because the
|
|
underlying systems contain no representations of those resources; an
|
|
example might be a URN namespace for International Standard Name
|
|
Identifiers (ISNIs) as that identifier system is defined in the
|
|
relevant standard [<a href="https://datatracker.ietf.org/doc/html/rfc8141#ref-ISO.27729.2012">ISO.27729.2012</a>], wherein by default a URN would be
|
|
resolved only to a metadata record describing the public identity
|
|
identified by the ISNI.
|
|
|
|
Consider also URNs that resolve to representations only if the
|
|
requesting entity is authorized to obtain the representation, whereas
|
|
other entities can obtain only metadata about the resource; an
|
|
example might be documents held within the legal depository
|
|
collection of a national library.
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 8]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-9"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
Finally, some URNs might not be intended to resolve to locators at
|
|
all; examples might include URNs identifying XML namespace names
|
|
(e.g., the "dgiwg" URN namespace specified by [<a href="https://datatracker.ietf.org/doc/html/rfc6288" title=""URN Namespace for the Defence Geospatial Information Working Group (DGIWG)"">RFC6288</a>]), URNs
|
|
identifying application features that can be supported within a
|
|
communications protocol (e.g., the "alert" URN namespace specified by
|
|
[<a href="https://datatracker.ietf.org/doc/html/rfc7462" title=""URNs for the Alert-Info Header Field of the Session Initiation Protocol (SIP)"">RFC7462</a>]), and URNs identifying enumerated types such as values in a
|
|
registry (e.g., a URN namespace could be used to individually
|
|
identify the values in all IANA registries, as provisionally proposed
|
|
in [<a href="https://datatracker.ietf.org/doc/html/rfc8141#ref-IANA-URN" title=""A Uniform Resource Name (URN) Namespace for IANA Registries"">IANA-URN</a>]).
|
|
|
|
Various types of URNs and multiple resolution services that may be
|
|
available for them leave the concept of "resolution" more complicated
|
|
but also much richer for URNs than the straightforward case of
|
|
resolution to a locator that is dereferenced to a representation.
|
|
|
|
<span class="h4"><a class="selflink" id="section-1.2.2" href="https://datatracker.ietf.org/doc/html/rfc8141#section-1.2.2">1.2.2</a>. Character Sets and Encodings</span>
|
|
|
|
A similar set of considerations apply to character sets and
|
|
encodings. URNs, especially URNs that will be used as user-facing
|
|
identifiers, should be convenient to use in local languages and
|
|
writing systems, easily specified with a wide range of keyboards and
|
|
local conventions, and unambiguous. There are trade-offs among those
|
|
goals, and it is impossible at present to see how a simple and
|
|
readily understandable set of rules could be developed that would be
|
|
optimal, or even reasonable, for all URNs. The discussion in
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-2.2">Section 2.2</a> defines an overall framework that should make generalized
|
|
parsing and processing possible but also makes recommendations about
|
|
rules for individual URN namespaces.
|
|
|
|
<span class="h2"><a class="selflink" id="section-2" href="https://datatracker.ietf.org/doc/html/rfc8141#section-2">2</a>. URN Syntax</span>
|
|
|
|
As discussed above, the syntax for URNs in this specification allows
|
|
significantly more functionality than was the case in the earlier
|
|
specifications, most recently [<a href="https://datatracker.ietf.org/doc/html/rfc2141" title=""URN Syntax"">RFC2141</a>]. It is also harmonized with
|
|
the general URI syntax [<a href="https://datatracker.ietf.org/doc/html/rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>] (which, it must be noted, was
|
|
completed after the earlier URN specifications).
|
|
|
|
However, this specification does not extend the URN syntax to allow
|
|
direct use of characters outside the ASCII range [<a href="https://datatracker.ietf.org/doc/html/rfc20" title=""ASCII format for network interchange"">RFC20</a>]. That
|
|
restriction implies that any such characters need to be percent-
|
|
encoded as described in <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-2.1">Section 2.1</a> of the URI specification
|
|
[<a href="https://datatracker.ietf.org/doc/html/rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>].
|
|
|
|
The basic syntax for a URN is defined using the Augmented Backus-Naur
|
|
Form (ABNF) as specified in [<a href="https://datatracker.ietf.org/doc/html/rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>]. Rules not defined here
|
|
(specifically: alphanum, fragment, and pchar) are defined as part of
|
|
the URI syntax [<a href="https://datatracker.ietf.org/doc/html/rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>] and used here to point out the syntactic
|
|
relationship with the terms used there. The definitions of some of
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 9]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-10"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
the terms used below are not comprehensive; additional restrictions
|
|
are imposed by the prose that can be found in sections of this
|
|
document that are specific to those terms (especially r-component in
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-2.3.1">Section 2.3.1</a> and q-component in <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-2.3.2">Section 2.3.2</a>).
|
|
|
|
namestring = assigned-name
|
|
[ rq-components ]
|
|
[ "#" f-component ]
|
|
assigned-name = "urn" ":" NID ":" NSS
|
|
NID = (alphanum) 0*30(ldh) (alphanum)
|
|
ldh = alphanum / "-"
|
|
NSS = pchar *(pchar / "/")
|
|
rq-components = [ "?+" r-component ]
|
|
[ "?=" q-component ]
|
|
r-component = pchar *( pchar / "/" / "?" )
|
|
q-component = pchar *( pchar / "/" / "?" )
|
|
f-component = fragment
|
|
|
|
The question mark character "?" can be used without percent-encoding
|
|
inside r-components, q-components, and f-components. Other than
|
|
inside those components, a "?" that is not immediately followed by
|
|
"=" or "+" is not defined for URNs and SHOULD be treated as a syntax
|
|
error by URN-specific parsers and other processors.
|
|
|
|
The following sections provide additional information about the
|
|
syntactic elements of URNs.
|
|
|
|
<span class="h3"><a class="selflink" id="section-2.1" href="https://datatracker.ietf.org/doc/html/rfc8141#section-2.1">2.1</a>. Namespace Identifier (NID)</span>
|
|
|
|
NIDs are case insensitive (e.g., "ISBN" and "isbn" are equivalent).
|
|
|
|
Characters outside the ASCII range [<a href="https://datatracker.ietf.org/doc/html/rfc20" title=""ASCII format for network interchange"">RFC20</a>] are not permitted in NIDs,
|
|
and no encoding mechanism for such characters is supported.
|
|
|
|
Sections <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-5.1">5.1</a> and <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-5.2">5.2</a> impose additional constraints on the strings
|
|
that can be used as NIDs, i.e., the syntax shown above is not
|
|
comprehensive.
|
|
|
|
<span class="h3"><a class="selflink" id="section-2.2" href="https://datatracker.ietf.org/doc/html/rfc8141#section-2.2">2.2</a>. Namespace Specific String (NSS)</span>
|
|
|
|
The NSS is a string, unique within a URN namespace, that is assigned
|
|
and managed in a consistent way and that conforms to the definition
|
|
of the relevant URN namespace. The combination of the NID (unique
|
|
across the entire "urn" scheme) and the NSS (unique within the URN
|
|
namespace) ensures that the resulting URN is globally unique.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 10]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-11"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
The NSS as specified in this document allows several characters not
|
|
permitted by earlier specifications (see <a href="https://datatracker.ietf.org/doc/html/rfc8141#appendix-B">Appendix B</a>). In particular,
|
|
the "/" character, which is now allowed, effectively makes it
|
|
possible to encapsulate hierarchical names from non-URN identifier
|
|
systems. For instance, consider the hypothetical example of a
|
|
hierarchical identifier system in which the names take the form of a
|
|
sequence of numbers separated by the "/" character, such as
|
|
"1/406/47452/2". If the authority for such names were to use URNs,
|
|
it would be natural to place the existing name in the NSS, resulting
|
|
in URNs such as "urn:example:1/406/47452/2".
|
|
|
|
Those changes to the syntax for the NSS do not modify the encoding
|
|
rules for URN namespaces that were defined in accordance with
|
|
[<a href="https://datatracker.ietf.org/doc/html/rfc2141" title=""URN Syntax"">RFC2141</a>]. If any such URN namespace whose names are used outside of
|
|
the URN context (i.e., in a non-URN identifier system) also allows
|
|
the use of "/", "~", or "&" in the native form within that identifier
|
|
system, then the encoding rules for that URN namespace are not
|
|
changed by this specification.
|
|
|
|
Depending on the rules governing a non-URN identifier system and its
|
|
associated URN namespace, names that are valid in that identifier
|
|
system might contain characters that are not allowed by the "pchar"
|
|
production referenced above (e.g., characters outside the ASCII range
|
|
or, consistent with the restrictions in <a href="https://datatracker.ietf.org/doc/html/rfc3986">RFC 3986</a>, the characters "/",
|
|
"?", "#", "[", and "]"). While such a name might be valid within the
|
|
non-URN identifier system, it is not a valid URN until it has been
|
|
translated into an NSS that conforms to the rules of that particular
|
|
URN namespace. In the case of URNs that are formed from names that
|
|
exist separately in a non-URN identifier system, translation of a
|
|
name from its "native" format to a URN format is accomplished by
|
|
using the canonicalization and encoding methods defined for URNs in
|
|
general or specific rules for that URN namespace. Software that is
|
|
not aware of namespace-specific canonicalization and encoding rules
|
|
MUST NOT construct URNs from the name in the non-URN identifier
|
|
system.
|
|
|
|
In particular, with regard to characters outside the ASCII range,
|
|
URNs that appear in protocols or that are passed between systems MUST
|
|
use only Unicode characters encoded in UTF-8 and further encoded as
|
|
required by <a href="https://datatracker.ietf.org/doc/html/rfc3986">RFC 3986</a>. To the extent feasible and consistent with the
|
|
requirements of names defined and standardized elsewhere, as well as
|
|
the principles discussed in <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-1.2">Section 1.2</a>, the characters used to
|
|
represent names SHOULD be restricted to either ASCII letters and
|
|
digits or to the characters and syntax of some widely used models
|
|
such as those of Internationalizing Domain Names in Applications
|
|
(IDNA) [<a href="https://datatracker.ietf.org/doc/html/rfc5890" title=""Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework"">RFC5890</a>], Preparation, Enforcement, and Comparison of
|
|
Internationalized Strings (PRECIS) [<a href="https://datatracker.ietf.org/doc/html/rfc7613" title=""Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and Passwords"">RFC7613</a>], or the Unicode
|
|
Identifier and Pattern Syntax specification [<a href="https://datatracker.ietf.org/doc/html/rfc8141#ref-UAX31" title=""Unicode Standard Annex #31: Unicode Identifier and Pattern Syntax"">UAX31</a>].
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 11]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-12"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
In order to make URNs as stable and persistent as possible when
|
|
protocols evolve and the environment around them changes, URN
|
|
namespaces SHOULD NOT allow characters outside the ASCII range
|
|
[<a href="https://datatracker.ietf.org/doc/html/rfc20" title=""ASCII format for network interchange"">RFC20</a>] unless the nature of the particular URN namespace makes such
|
|
characters necessary.
|
|
|
|
<span class="h3"><a class="selflink" id="section-2.3" href="https://datatracker.ietf.org/doc/html/rfc8141#section-2.3">2.3</a>. Optional Components</span>
|
|
|
|
This specification includes three optional components in the URN
|
|
syntax. They are known as r-component, q-component, and f-component
|
|
and are described in more detail below. Because this specification
|
|
focuses almost exclusively on URN syntax, it does not define detailed
|
|
semantics of these components for URNs in general. However, each of
|
|
these components has a distinct role that is independent of any given
|
|
URN and its URN namespace. It is intended that clients will be able
|
|
to handle these components uniformly for all URNs. These components
|
|
MAY be used with URNs from existing URN namespaces, whether or not a
|
|
URN namespace explicitly supports them. However, consistent with the
|
|
approach taken in <a href="https://datatracker.ietf.org/doc/html/rfc3986">RFC 3986</a>, the behavior of a URN that contains
|
|
components that are undefined or meaningless for a particular URN
|
|
namespace or resource is not defined. The following sections
|
|
describe these optional components and their interpretation in
|
|
greater detail.
|
|
|
|
<span class="h4"><a class="selflink" id="section-2.3.1" href="https://datatracker.ietf.org/doc/html/rfc8141#section-2.3.1">2.3.1</a>. r-component</span>
|
|
|
|
The r-component is intended for passing parameters to URN resolution
|
|
services (taken broadly, see <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-1.2">Section 1.2</a>) and interpreted by those
|
|
services. (By contrast, passing parameters to the resources
|
|
identified by a URN, or to applications that manage such resources,
|
|
is handled by q-components as described in the next section.)
|
|
|
|
The URN r-component has no syntactic counterpart in any other known
|
|
URI scheme.
|
|
|
|
The sequence "?+" introduces the r-component. The r-component ends
|
|
with a "?=" sequence (which begins a q-component) or a "#" character
|
|
(number sign, which begins an f-component). If neither of those
|
|
appear, the r-component continues to the end of the URN. Note that
|
|
characters outside the ASCII range [<a href="https://datatracker.ietf.org/doc/html/rfc20" title=""ASCII format for network interchange"">RFC20</a>] MUST be percent-encoded
|
|
using the method defined in <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-2.1">Section 2.1</a> of the generic URI
|
|
specification [<a href="https://datatracker.ietf.org/doc/html/rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>].
|
|
|
|
As described in <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-3">Section 3</a>, the r-component SHALL NOT be taken into
|
|
account when determining URN-equivalence. However, the r-component
|
|
SHALL be supplied along with the URN when presenting a request to a
|
|
URN resolution service.
|
|
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 12]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-13"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
This document defines only the syntax of the r-component and reserves
|
|
it for future use. The exact semantics of the r-component and its
|
|
use in URN resolution protocols are a matter for potential
|
|
standardization in separate specifications, presumably including
|
|
specifications that define conventions and a registry for resolution
|
|
service identifiers.
|
|
|
|
Consider the hypothetical example of passing parameters to a
|
|
resolution service (say, an ISO alpha-2 country code [<a href="https://datatracker.ietf.org/doc/html/rfc8141#ref-ISO.3166-1">ISO.3166-1</a>] in
|
|
order to select the preferred country in which to search for a
|
|
physical copy of a book). This could perhaps be accomplished by
|
|
specifying the country code in the r-component, resulting in URNs
|
|
such as:
|
|
|
|
urn:example:foo-bar-baz-qux?+CCResolve:cc=uk
|
|
|
|
While the above should serve as a general explanation and
|
|
illustration of the intent for r-components, there are many open
|
|
issues with them, including their relationship to resolution
|
|
mechanisms associated with the particular URN namespace at
|
|
registration time. Thus, r-components SHOULD NOT be used for URNs
|
|
before their semantics have been standardized.
|
|
|
|
<span class="h4"><a class="selflink" id="section-2.3.2" href="https://datatracker.ietf.org/doc/html/rfc8141#section-2.3.2">2.3.2</a>. q-component</span>
|
|
|
|
The q-component is intended for passing parameters to either the
|
|
named resource or a system that can supply the requested service, for
|
|
interpretation by that resource or system. (By contrast, passing
|
|
parameters to URN resolution services is handled by r-components as
|
|
described in the previous section.)
|
|
|
|
The URN q-component has the same syntax as the URI query component
|
|
but is introduced by "?=", not "?" alone. For a URN that may be
|
|
resolved to a URI that is a locator, the semantics of the q-component
|
|
are identical to those for the query component of that URI. Thus,
|
|
URN resolvers returning a URI that is a locator for a URN with a
|
|
q-component do this by copying the q-component from the URN to the
|
|
query component of the URI. An example of the copying operation
|
|
appears below.
|
|
|
|
This specification does not specify a required behavior in the case
|
|
of URN resolution to a URI that is a locator when the original URN
|
|
has a q-component and the URI has a query string. Different
|
|
circumstances may require different approaches. Resolvers SHOULD
|
|
document their strategy in such cases.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 13]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-14"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
If the URN does not resolve to a URI that is a locator, the
|
|
interpretation of the q-component is undefined by this specification.
|
|
For URNs that may be resolved to a URI that is a locator, the
|
|
semantics of the q-component are identical to those for queries to
|
|
the resource located via that URI.
|
|
|
|
For the sake of consistency with <a href="https://datatracker.ietf.org/doc/html/rfc3986">RFC 3986</a>, the general syntax and the
|
|
semantics of q-components are not defined by, or dependent on, the
|
|
URN namespace of the URN. In parallel with <a href="https://datatracker.ietf.org/doc/html/rfc3986">RFC 3986</a>, specifics of
|
|
syntax and semantics, e.g., which keywords or terms are meaningful,
|
|
of course may depend on a particular URN namespace or even a
|
|
particular resource.
|
|
|
|
The sequence "?=" introduces the q-component. The q-component ends
|
|
with a "#" character (number sign, which begins an f-component). If
|
|
that character does not appear, the q-component continues to the end
|
|
of the URN. The characters slash ("/") and question mark ("?") may
|
|
represent data within the q-component. Note that characters outside
|
|
the ASCII range [<a href="https://datatracker.ietf.org/doc/html/rfc20" title=""ASCII format for network interchange"">RFC20</a>] MUST be percent-encoded using the method
|
|
defined in <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-2.1">Section 2.1</a> of the generic URI specification [<a href="https://datatracker.ietf.org/doc/html/rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>].
|
|
|
|
As described in <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-3">Section 3</a>, the q-component SHALL NOT be taken into
|
|
account when determining URN-equivalence.
|
|
|
|
URN namespaces and associated information placement in syntax SHOULD
|
|
be designed to avoid any need for a resolution service to consider
|
|
the q-component. Namespace-specific and more generic resolution
|
|
systems MUST NOT require that q-component information be passed to
|
|
them for processing.
|
|
|
|
Consider the hypothetical example of passing parameters to an
|
|
application that returns weather reports from different regions or
|
|
for different time periods. This could perhaps be accomplished by
|
|
specifying latitude and longitude coordinates and datetimes in the
|
|
URN's q-component, resulting in URNs such as the following.
|
|
|
|
urn:example:weather?=op=map&lat=39.56
|
|
&lon=-104.85&datetime=1969-07-21T02:56:15Z
|
|
|
|
If this example resolved to an HTTP URI, the result might look like:
|
|
|
|
<a href="https://weatherapp/">https://weatherapp</a>.example?op=map&lat=39.56
|
|
&lon=-104.85&datetime=1969-07-21T02:56:15Z
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 14]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-15"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
<span class="h4"><a class="selflink" id="section-2.3.3" href="https://datatracker.ietf.org/doc/html/rfc8141#section-2.3.3">2.3.3</a>. f-component</span>
|
|
|
|
The f-component is intended to be interpreted by the client as a
|
|
specification for a location within, or region of, the named
|
|
resource. It distinguishes the constituent parts of a resource named
|
|
by a URN. For a URN that resolves to one or more locators that can
|
|
be dereferenced to a representation, or where the URN resolver
|
|
directly returns a representation of the resource, the semantics of
|
|
an f-component are defined by the media type of the representation.
|
|
|
|
The URN f-component has the same syntax as the URI fragment
|
|
component. If a URN containing an f-component resolves to a single
|
|
URI that is a locator associated with the named resource, the
|
|
f-component from the URN can be applied (usually by the client) as
|
|
the fragment of that URI. If the URN does not resolve to a URI that
|
|
is a locator, the interpretation of the f-component is undefined by
|
|
this specification. Thus, for URNs that may be resolved to a URI
|
|
that is a locator, the semantics of f-components are identical to
|
|
those of fragments for that resource.
|
|
|
|
For the sake of consistency with <a href="https://datatracker.ietf.org/doc/html/rfc3986">RFC 3986</a>, neither the general syntax
|
|
nor the semantics of f-components are defined by, or dependent on,
|
|
the URN namespace of the URN. In parallel with <a href="https://datatracker.ietf.org/doc/html/rfc3986">RFC 3986</a>, specifics
|
|
of syntax and semantics, e.g., which keywords or terms are
|
|
meaningful, of course may depend on a particular URN namespace or
|
|
even a particular resource.
|
|
|
|
The f-component is introduced by the number sign ("#") character and
|
|
terminated by the end of the URI. Any characters outside the ASCII
|
|
range [<a href="https://datatracker.ietf.org/doc/html/rfc20" title=""ASCII format for network interchange"">RFC20</a>] that appear in the f-component MUST be percent-encoded
|
|
using the method defined in <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-2.1">Section 2.1</a> of the generic URI
|
|
specification [<a href="https://datatracker.ietf.org/doc/html/rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>].
|
|
|
|
As described in <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-3">Section 3</a>, the f-component SHALL NOT be taken into
|
|
account when determining URN-equivalence.
|
|
|
|
Clients SHOULD NOT pass f-components to resolution services unless
|
|
those services also perform object retrieval and interpretation
|
|
functions.
|
|
|
|
Consider the hypothetical example of obtaining resources that are
|
|
part of a larger entity (say, the chapters of a book). Each part
|
|
could be specified in the f-component, resulting in URNs such as:
|
|
|
|
urn:example:foo-bar-baz-qux#somepart
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 15]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-16"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
<span class="h2"><a class="selflink" id="section-3" href="https://datatracker.ietf.org/doc/html/rfc8141#section-3">3</a>. URN-Equivalence</span>
|
|
|
|
<span class="h3"><a class="selflink" id="section-3.1" href="https://datatracker.ietf.org/doc/html/rfc8141#section-3.1">3.1</a>. Procedure</span>
|
|
|
|
For various purposes such as caching, it is often desirable to
|
|
determine if two URNs are "the same". This is done most generally
|
|
(i.e., independent of the scheme) by testing for equivalence (see
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc3986#section-6.1">Section 6.1 of [RFC3986]</a>).
|
|
|
|
The generic URI specification [<a href="https://datatracker.ietf.org/doc/html/rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>] is very flexible about
|
|
equality comparisons, putting the focus on allowing false negatives
|
|
and avoiding false positives. If comparisons are made in a scheme-
|
|
independent way, i.e., as URI comparisons only, many URNs that this
|
|
specification considers equal would be rejected. The discussion
|
|
below applies when the URIs involved are known to be URNs and thus
|
|
uses the terms "URN-equivalent" and "URN-equivalence" to refer to
|
|
equivalence as specified in this document.
|
|
|
|
Two URNs are URN-equivalent if their assigned-name portions are
|
|
octet-by-octet equal after applying case normalization (as specified
|
|
in <a href="https://datatracker.ietf.org/doc/html/rfc3986#section-6.2.2.1">Section 6.2.2.1 of [RFC3986]</a>) to the following constructs:
|
|
|
|
1. the URI scheme "urn", by conversion to lower case
|
|
|
|
2. the NID, by conversion to lower case
|
|
|
|
3. any percent-encoded characters in the NSS (that is, all character
|
|
triplets that match the <pct-encoding> production found in
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-2.1">Section 2.1</a> of the base URI specification [<a href="https://datatracker.ietf.org/doc/html/rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>]), by
|
|
conversion to upper case for the digits A-F.
|
|
|
|
Percent-encoded characters MUST NOT be decoded, i.e., percent-
|
|
encoding normalization (as specified in <a href="https://datatracker.ietf.org/doc/html/rfc3986#section-6.2.2.2">Section 6.2.2.2 of [RFC3986]</a>)
|
|
MUST NOT be applied as part of the comparison process.
|
|
|
|
If an r-component, q-component, or f-component (or any combination
|
|
thereof) is included in a URN, it MUST be ignored for purposes of
|
|
determining URN-equivalence.
|
|
|
|
URN namespace definitions MAY include additional rules for
|
|
URN-equivalence, such as case insensitivity of the NSS (or parts
|
|
thereof). Such rules MUST always have the effect of eliminating some
|
|
of the false negatives obtained by the procedure above and MUST NOT
|
|
result in treating two URNs as not "the same" if the procedure here
|
|
says they are URN-equivalent. For related considerations with regard
|
|
to NID registration, see below.
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 16]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-17"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
<span class="h3"><a class="selflink" id="section-3.2" href="https://datatracker.ietf.org/doc/html/rfc8141#section-3.2">3.2</a>. Examples</span>
|
|
|
|
This section shows a variety of URNs (using the "example" NID defined
|
|
in [<a href="https://datatracker.ietf.org/doc/html/rfc6963" title=""A Uniform Resource Name (URN) Namespace for Examples"">RFC6963</a>]) that highlight the URN-equivalence rules.
|
|
|
|
First, because the scheme and NID are case insensitive, the following
|
|
three URNs are URN-equivalent to each other:
|
|
|
|
o urn:example:a123,z456
|
|
|
|
o URN:example:a123,z456
|
|
|
|
o urn:EXAMPLE:a123,z456
|
|
|
|
Second, because the r-component, q-component, and f-component are not
|
|
taken into account for purposes of testing URN-equivalence, the
|
|
following three URNs are URN-equivalent to the first three examples
|
|
above:
|
|
|
|
o urn:example:a123,z456?+abc
|
|
|
|
o urn:example:a123,z456?=xyz
|
|
|
|
o urn:example:a123,z456#789
|
|
|
|
Third, because the "/" character (and anything that follows it) in
|
|
the NSS is taken into account for purposes of URN-equivalence, the
|
|
following URNs are not URN-equivalent to each other or to the six
|
|
preceding URNs:
|
|
|
|
o urn:example:a123,z456/foo
|
|
|
|
o urn:example:a123,z456/bar
|
|
|
|
o urn:example:a123,z456/baz
|
|
|
|
Fourth, because of percent-encoding, the following URNs are
|
|
URN-equivalent only to each other and not to any of those above (note
|
|
that, although %2C is the percent-encoded transformation of "," from
|
|
the previous examples, such sequences are not decoded for purposes of
|
|
testing URN-equivalence):
|
|
|
|
o urn:example:a123%2Cz456
|
|
|
|
o URN:EXAMPLE:a123%2cz456
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 17]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-18"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
Fifth, because characters in the NSS other than percent-encoded
|
|
sequences are treated in a case-sensitive manner (unless otherwise
|
|
specified for the URN namespace in question), the following URNs are
|
|
not URN-equivalent to the first three URNs:
|
|
|
|
o urn:example:A123,z456
|
|
|
|
o urn:example:a123,Z456
|
|
|
|
Sixth, on casual visual inspection of a URN presented in a human-
|
|
oriented interface, the following URN might appear the same as the
|
|
first three URNs (because U+0430 CYRILLIC SMALL LETTER A can be
|
|
confused with U+0061 LATIN SMALL LETTER A), but it is not
|
|
URN-equivalent to the first three URNs:
|
|
|
|
o urn:example:%D0%B0123,z456
|
|
|
|
<span class="h2"><a class="selflink" id="section-4" href="https://datatracker.ietf.org/doc/html/rfc8141#section-4">4</a>. URI Conformance</span>
|
|
|
|
<span class="h3"><a class="selflink" id="section-4.1" href="https://datatracker.ietf.org/doc/html/rfc8141#section-4.1">4.1</a>. Use in URI Protocol Slots</span>
|
|
|
|
Because a URN is, syntactically, a URI under the "urn" scheme, in
|
|
theory a URN can be placed in any protocol slot that allows for a URI
|
|
(to name just a few, the "href" and "src" attributes in HTML, the
|
|
base element in HTML, the "xml:base" attribute in XML [<a href="https://datatracker.ietf.org/doc/html/rfc8141#ref-XML-BASE" title=""XML Base (Second Edition)"">XML-BASE</a>], and
|
|
the "xmlns" attribute in XML for XML namespace names [<a href="https://datatracker.ietf.org/doc/html/rfc8141#ref-XML-NAMES">XML-NAMES</a>]).
|
|
|
|
However, this does not imply that, semantically, it always makes
|
|
sense in practice to place a URN in a given URI protocol slot; in
|
|
particular, because a URN might not specify the location of a
|
|
resource or even point indirectly to one, it might not be appropriate
|
|
to place a URN in a URI protocol slot that points to a resource
|
|
(e.g., the aforementioned "href" and "src" attributes).
|
|
|
|
Ultimately, guidelines regarding when it is appropriate to use URIs
|
|
under the "urn" scheme (or any other scheme) are the responsibility
|
|
of specifications for individual URI protocol slots (e.g., the
|
|
specification for the "xml:base" attribute in XML might recommend
|
|
that it is inappropriate to use URNs in that protocol slot). This
|
|
specification cannot possibly anticipate all of the relevant cases,
|
|
and it is not the place of this specification to require or restrict
|
|
usage for individual protocol slots.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 18]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-19"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
<span class="h3"><a class="selflink" id="section-4.2" href="https://datatracker.ietf.org/doc/html/rfc8141#section-4.2">4.2</a>. Parsing</span>
|
|
|
|
In part because of the separation of URN semantics from more general
|
|
URI syntax, generic URI processors need to pay special attention to
|
|
the parsing and analysis rules of <a href="https://datatracker.ietf.org/doc/html/rfc3986">RFC 3986</a> and, in particular, must
|
|
treat the URI as opaque unless the scheme and its requirements are
|
|
recognized. In the latter case, such processors may be in a position
|
|
to invoke scheme-appropriate processing, e.g., by a URN resolver. A
|
|
URN resolver can either be an external resolver that the URI resolver
|
|
knows of or be functionality built into the URI resolver. Note that
|
|
this requirement might impose constraints on the contexts in which
|
|
URNs are appropriately used; see <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-4.1">Section 4.1</a>.
|
|
|
|
<span class="h3"><a class="selflink" id="section-4.3" href="https://datatracker.ietf.org/doc/html/rfc8141#section-4.3">4.3</a>. URNs and Relative References</span>
|
|
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc3986#section-5.2">Section 5.2 of [RFC3986]</a> describes an algorithm for converting a URI
|
|
reference that might be relative to a given base URI into "parsed
|
|
components" of the target of that reference, which can then be
|
|
recomposed per <a href="https://datatracker.ietf.org/doc/html/rfc3986#section-5.3">RFC 3986, Section 5.3</a> into a target URI. This
|
|
algorithm is problematic for URNs because their syntax does not
|
|
support the necessary path components. However, if the algorithm is
|
|
applied independent of a particular scheme, it should work
|
|
predictably for URNs as well, with the following understandings
|
|
(syntax production terminology taken from <a href="https://datatracker.ietf.org/doc/html/rfc3986">RFC 3986</a>):
|
|
|
|
1. A system that encounters a <URI-reference> that obeys the syntax
|
|
for <relative-ref>, whether it explicitly has the scheme "urn" or
|
|
not, will convert it into a target URI as specified in <a href="https://datatracker.ietf.org/doc/html/rfc3986">RFC 3986</a>.
|
|
|
|
2. Because of the persistence and stability expectations of URNs,
|
|
authors of documents, etc., that utilize URNs should generally
|
|
avoid the use of the "urn" scheme in any <URI-reference> that is
|
|
not strictly a <URI> as specified in <a href="https://datatracker.ietf.org/doc/html/rfc3986">RFC 3986</a>, specifically
|
|
including those that would require processing of <relative-ref>.
|
|
|
|
<span class="h3"><a class="selflink" id="section-4.4" href="https://datatracker.ietf.org/doc/html/rfc8141#section-4.4">4.4</a>. Transport and Display</span>
|
|
|
|
When URNs are transported and exchanged, they MUST be represented in
|
|
the format defined herein. Further, URN-aware applications are
|
|
strongly encouraged to offer the option of displaying URNs in this
|
|
canonical form to allow for direct transcription (for example by
|
|
copy-and-paste techniques). Such applications might support the
|
|
display of URNs in a more human-friendly form and might use a
|
|
character set that includes characters that are not permitted in URN
|
|
syntax as defined in this specification (e.g., when displaying URNs
|
|
to humans, such applications might replace percent-encoded strings
|
|
with characters from an extended character repertoire such as Unicode
|
|
[<a href="https://datatracker.ietf.org/doc/html/rfc8141#ref-UNICODE" title=""The Unicode Standard"">UNICODE</a>]).
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 19]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-20"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
To minimize user confusion, any application displaying URIs SHOULD
|
|
display the complete URI (including, for URNs, the "urn" scheme and
|
|
any components) to ensure that there is no confusion between URN NIDs
|
|
and URI scheme identifiers. For example, a URI beginning with
|
|
"urn:xmpp:" [<a href="https://datatracker.ietf.org/doc/html/rfc4854" title=""A Uniform Resource Name (URN) Namespace for Extensions to the Extensible Messaging and Presence Protocol (XMPP)"">RFC4854</a>] is very different from a URI beginning with
|
|
"xmpp:" [<a href="https://datatracker.ietf.org/doc/html/rfc5122" title=""Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)"">RFC5122</a>]. Similarly, a potential Digital Object Identifier
|
|
(DOI) URI scheme [<a href="https://datatracker.ietf.org/doc/html/rfc8141#ref-DOI-URI" title=""The "">DOI-URI</a>] is different from, and possibly completely
|
|
unrelated to, a possible DOI URN namespace.
|
|
|
|
<span class="h3"><a class="selflink" id="section-4.5" href="https://datatracker.ietf.org/doc/html/rfc8141#section-4.5">4.5</a>. URI Design and Ownership</span>
|
|
|
|
As mentioned, the assignment of URNs within a URN namespace is a
|
|
managed process, as is the assignment of URN namespaces themselves.
|
|
Although design of the URNs to be assigned within a given URN
|
|
namespace is ceded by this specification to the URN namespace
|
|
manager, doing so in a managed way avoids the problems inherent in
|
|
unmanaged generation of URIs as described in the recommendations
|
|
regarding URI design and ownership [<a href="https://datatracker.ietf.org/doc/html/rfc7320" title=""URI Design and Ownership"">RFC7320</a>].
|
|
|
|
<span class="h2"><a class="selflink" id="section-5" href="https://datatracker.ietf.org/doc/html/rfc8141#section-5">5</a>. URN Namespaces</span>
|
|
|
|
A URN namespace is a collection of names that obey three constraints:
|
|
each name is (1) unique, (2) assigned in a consistent way, and (3)
|
|
assigned according to a common definition.
|
|
|
|
1. The "uniqueness" constraint means that a name within the URN
|
|
namespace is never assigned to more than one resource and never
|
|
reassigned to a different resource (for the kind of "resource"
|
|
identified by URNs assigned within the URN namespace). This
|
|
holds true even if the name itself is deprecated or becomes
|
|
obsolete.
|
|
|
|
2. The "consistent assignment" constraint means that a name within
|
|
the URN namespace is assigned by an organization or created in
|
|
accordance with a process or algorithm that is always followed.
|
|
|
|
3. The "common definition" constraint means that there are clear
|
|
definitions for the syntax of names within the URN namespace and
|
|
for the process of assigning or creating them.
|
|
|
|
A URN namespace is identified by a particular NID in order to ensure
|
|
the global uniqueness of URNs and, optionally, to provide a cue
|
|
regarding the structure of URNs assigned within a URN namespace.
|
|
|
|
With regard to global uniqueness, using different NIDs for different
|
|
collections of names ensures that no two URNs will be the same for
|
|
different resources, because each collection is required to uniquely
|
|
assign each name. However, a single resource MAY have more than one
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 20]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-21"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
URN assigned to it, either in the same URN namespace (if the URN
|
|
namespace permits it) or in different URN namespaces, and for either
|
|
similar purposes or different purposes. (For example, if a publisher
|
|
assigns an ISBN [<a href="https://datatracker.ietf.org/doc/html/rfc3187" title=""Using International Standard Book Numbers as Uniform Resource Names"">RFC3187</a>] to an electronic publication and that
|
|
publication is later incorporated into a digital long-term archive
|
|
operated by a national library, the library might assign the
|
|
publication a national bibliography number (NBN) [<a href="https://datatracker.ietf.org/doc/html/rfc3188" title=""Using National Bibliography Numbers as Uniform Resource Names"">RFC3188</a>], resulting
|
|
in two URNs referring to the same book.) Subject to other
|
|
constraints, such as those imposed by the URI syntax [<a href="https://datatracker.ietf.org/doc/html/rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>], the
|
|
rules of the URN scheme are intended to allow preserving the normal
|
|
and natural form of names specified in non-URN identifier systems
|
|
when they are treated as URNs.
|
|
|
|
With regard to the structure of names assigned within a URN
|
|
namespace, the development of a naming structure (and thereby a
|
|
collection of names) depends on the requirements of the community
|
|
defining the names, how the names will be assigned and used, etc.
|
|
These issues are beyond the scope of URN syntax and the general rules
|
|
for URN namespaces, because they are specific to the community
|
|
defining a non-URN identifier system or a particular URN namespace
|
|
(e.g., the bibliographic and publishing communities in the case of
|
|
the "ISBN" URN namespace [<a href="https://datatracker.ietf.org/doc/html/rfc3187" title=""Using International Standard Book Numbers as Uniform Resource Names"">RFC3187</a>] and the "ISSN" URN namespace
|
|
[<a href="https://datatracker.ietf.org/doc/html/rfc3044" title=""Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace"">RFC3044</a>] or the developers of extensions to the Extensible Messaging
|
|
and Presence Protocol [<a href="https://datatracker.ietf.org/doc/html/rfc6120" title=""Extensible Messaging and Presence Protocol (XMPP): Core"">RFC6120</a>] in the case of the "XMPP" URN
|
|
namespace [<a href="https://datatracker.ietf.org/doc/html/rfc4854" title=""A Uniform Resource Name (URN) Namespace for Extensions to the Extensible Messaging and Presence Protocol (XMPP)"">RFC4854</a>]).
|
|
|
|
Because the colon character (":") is used to separate "urn" from the
|
|
NID and the NID from the NSS, it's tempting to think of the entire
|
|
URN as being structured by colon characters and to assume that colons
|
|
create a structure or hierarchy within the NSS portion of the URN.
|
|
Such structure could be specified by a particular NID specification,
|
|
but there is no implicit structure. In a URN such as
|
|
|
|
urn:example:apple:pear:plum:cherry
|
|
|
|
the NSS string is "apple:pear:plum:cherry" as a whole, and there is
|
|
no specific meaning to the colon characters within that NSS string
|
|
unless such meaning is described in the specification of the
|
|
"example" namespace.
|
|
|
|
URN namespaces inherit certain rights and responsibilities by the
|
|
nature of URNs, in particular:
|
|
|
|
1. They uphold the general principles of a well-managed URN
|
|
namespace by providing persistent identification of resources and
|
|
unique assignment of names in accordance with a common
|
|
definition.
|
|
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 21]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-22"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
2. Optionally, they can be registered in global registration
|
|
services such as those described in [<a href="https://datatracker.ietf.org/doc/html/rfc2483" title=""URI Resolution Services Necessary for URN Resolution"">RFC2483</a>].
|
|
|
|
There are two types of URN namespaces: formal and informal. These
|
|
are distinguished by the expected level of service, the information
|
|
needed to define the URN namespace, and the procedures for
|
|
registration. Because the majority of the URN namespaces registered
|
|
so far have been formal, this document concentrates on formal URN
|
|
namespaces.
|
|
|
|
<span class="h3"><a class="selflink" id="section-5.1" href="https://datatracker.ietf.org/doc/html/rfc8141#section-5.1">5.1</a>. Formal URN Namespaces</span>
|
|
|
|
A formal URN namespace provides benefit to some subset of users on
|
|
the Internet. In particular, it would not make sense for a formal
|
|
URN namespace to be used only by a community or network that is not
|
|
connected to the Internet. For example, it would be inappropriate
|
|
for a URN namespace to effectively force someone to use a proprietary
|
|
network or service not open to the general Internet user. The intent
|
|
is that, while the community of those who might actively use the URNs
|
|
assigned within that URN namespace might be small, the potential use
|
|
of names within that URN namespace is open to any user on the
|
|
Internet. Formal URN namespaces might be appropriate even when some
|
|
aspects are not fully open. For example, a URN namespace might make
|
|
use of a fee-based, privately managed, or proprietary registry for
|
|
assignment of URNs in the URN namespace. However, it might still
|
|
benefit some Internet users if the associated services have openly
|
|
published names.
|
|
|
|
An organization that will assign URNs within a formal URN namespace
|
|
SHOULD meet the following criteria:
|
|
|
|
1. Organizational stability and the ability to maintain the URN
|
|
namespace for a long time; absent such evidence, it ought to be
|
|
clear how the URN namespace can remain viable if the organization
|
|
can no longer maintain the URN namespace.
|
|
|
|
2. Competency in URN assignment. This will improve the likelihood
|
|
of persistence (e.g., to minimize the likelihood of conflicts).
|
|
|
|
3. Commitment to not reassigning existing URNs and to allowing old
|
|
URNs to continue to be valid (e.g., if the assignee of a URN is
|
|
no longer a member or customer of the assigning organization, if
|
|
various information about the assignee or named entity happens to
|
|
change, or even if the assignee or the named entity itself is no
|
|
longer in existence; in all these cases, the URN is still valid).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 22]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-23"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
A formal URN namespace establishes a particular NID, subject to the
|
|
following constraints (above and beyond the syntax rules already
|
|
specified):
|
|
|
|
1. It MUST NOT be an already-registered NID.
|
|
|
|
2. It MUST NOT start with "urn-" (which is reserved for informal URN
|
|
namespaces).
|
|
|
|
3. It MUST be more than two characters long, and it MUST NOT start
|
|
with ALPHA ALPHA "-", i.e., any string consisting of two letters
|
|
followed by one hyphen; such strings are reserved for potential
|
|
use as NIDs based on ISO alpha-2 country codes [<a href="https://datatracker.ietf.org/doc/html/rfc8141#ref-ISO.3166-1">ISO.3166-1</a>] for
|
|
eventual national registrations of URN namespaces (however, the
|
|
definition and scoping of rules for allocation of responsibility
|
|
for such country-code-based URN namespaces are beyond the scope
|
|
of this document). As a consequence, it MUST NOT start with the
|
|
string "xn--" or any other string consisting of two letters
|
|
followed by two hyphens; such strings are reserved for potential
|
|
representation of DNS A-labels and similar strings in the future
|
|
[<a href="https://datatracker.ietf.org/doc/html/rfc5890" title=""Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework"">RFC5890</a>].
|
|
|
|
4. It MUST NOT start with the string "X-" so that it will not be
|
|
confused with or conflict with any experimental URN namespace
|
|
previously permitted by [<a href="https://datatracker.ietf.org/doc/html/rfc3406" title=""Uniform Resource Names (URN) Namespace Definition Mechanisms"">RFC3406</a>].
|
|
|
|
Applicants and reviewers considering new NIDs should also be aware
|
|
that they may have semantic implications and hence be a source of
|
|
conflict. Particular attention should be paid to strings that might
|
|
be construed as identifiers for, or registered under the authority
|
|
of, countries (including ISO 3166-1 alpha-3 codes) and to strings
|
|
that might imply association with existing URI schemes, non-URN
|
|
identifier systems, or trademarks. However, in line with traditional
|
|
policies, disputes about "ownership" of particular strings are
|
|
disagreements among the parties involved; neither IANA nor the IETF
|
|
will become involved in such disputes except in response to orders
|
|
from a court of competent jurisdiction.
|
|
|
|
<span class="h3"><a class="selflink" id="section-5.2" href="https://datatracker.ietf.org/doc/html/rfc8141#section-5.2">5.2</a>. Informal URN Namespaces</span>
|
|
|
|
Informal URN namespaces are full-fledged URN namespaces, with all the
|
|
associated rights and responsibilities. Informal URN namespaces
|
|
differ from formal URN namespaces in the process for assigning the
|
|
NID: for an informal URN namespace, the registrant does not designate
|
|
the NID; instead, IANA assigns the NID consisting of the string
|
|
"urn-" followed by one or more digits (e.g., "urn-7") where the
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 23]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-24"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
digits consist of the next available number in the sequence of
|
|
positive integers assigned to informal URN namespaces. Thus, the
|
|
syntax of an informal URN namespace identifier is:
|
|
|
|
InformalNamespaceName = "urn-" Number
|
|
Number = DigitNonZero 0*Digit
|
|
DigitNonZero = "1"/ "2" / "3" / "4"/ "5"
|
|
/ "6" / "7" / "8" / "9"
|
|
Digit = "0" / DigitNonZero
|
|
|
|
The only restrictions on <Number> are that it (1) consist strictly of
|
|
ASCII digits, (2) not have leading zeros, and (3) not cause the NID
|
|
to exceed the length limitations defined for the URN syntax (see
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-2">Section 2</a>).
|
|
|
|
<span class="h2"><a class="selflink" id="section-6" href="https://datatracker.ietf.org/doc/html/rfc8141#section-6">6</a>. Defining and Registering a URN Namespace</span>
|
|
|
|
<span class="h3"><a class="selflink" id="section-6.1" href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.1">6.1</a>. Overview</span>
|
|
|
|
Because the space of URN namespaces is itself managed, the definition
|
|
of a URN namespace SHOULD pay particular attention to:
|
|
|
|
1. The purpose of the URN namespace.
|
|
|
|
2. The syntax of URNs assigned within the URN namespace, including
|
|
the internal syntax and anticipated effects of r-components or
|
|
q-components. (The syntax and interpretation of f-components are
|
|
defined in <a href="https://datatracker.ietf.org/doc/html/rfc3986">RFC 3986</a>.)
|
|
|
|
3. The process for assigning URNs within the URN namespace.
|
|
|
|
4. The security implications of assigning URNs within the URN
|
|
namespace and of using the assigned URNs.
|
|
|
|
5. Any potential interoperability issues with URNs assigned within
|
|
the URN namespace.
|
|
|
|
6. Optionally, the process for resolving URNs assigned within the
|
|
URN namespace.
|
|
|
|
The section on completing the template (<a href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.4">Section 6.4</a>) explains these
|
|
matters in greater detail. Although the registration templates are
|
|
the same in all cases, slightly different procedures are used
|
|
depending on the source of the registration.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 24]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-25"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
<span class="h3"><a class="selflink" id="section-6.2" href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.2">6.2</a>. Registration Policy and Process: Community Registrations</span>
|
|
|
|
The basic registration policy for URN namespaces is Expert Review as
|
|
defined in the IANA Considerations document [<a href="https://datatracker.ietf.org/doc/html/rfc5226" title="">RFC5226</a>]. For URN
|
|
namespaces or their definitions that are intended to become standards
|
|
or constituent parts of standards, the output of the Expert Review
|
|
process is intended to be a report rather than instructions to IANA
|
|
to take action (see below). The key steps are:
|
|
|
|
1. Fill out the URN namespace registration template (see <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.4">Section 6.4</a>
|
|
and <a href="https://datatracker.ietf.org/doc/html/rfc8141#appendix-A">Appendix A</a>). This can be done as part of an Internet-Draft
|
|
or a specification in another series, although that is not a
|
|
requirement.
|
|
|
|
2. Send the completed template to the urn@ietf.org discussion list
|
|
for review.
|
|
|
|
3. If necessary to address comments received, repeat steps 1 and 2.
|
|
|
|
4. If the Designated Experts approve the request and no
|
|
standardization action is involved, the IANA will register the
|
|
requested NID. If standardization is anticipated, the Designated
|
|
Experts will prepare a report and forward it to the appropriate
|
|
standards approval body (the IESG in the case of the IETF); IANA
|
|
will register the requested NID only after receiving directions
|
|
from that body and a copy of the Expert Review report.
|
|
|
|
A URN namespace registration can be revised by updating the
|
|
registration template, following the same steps outlined above for
|
|
new registrations. A revised registration MUST describe differences
|
|
from prior versions and SHOULD make special note of any relevant
|
|
changes in the underlying technologies or URN namespace management
|
|
processes.
|
|
|
|
Experience to date with URN namespace registration requests has shown
|
|
that registrants sometimes do not initially understand some of the
|
|
subtleties of URN namespaces and that defining the URN namespace in
|
|
the form of a specification enables the registrants to clearly
|
|
formulate their "contract" with the intended user community.
|
|
Therefore, although the registration policy for formal URN namespaces
|
|
is Expert Review and a specification (as distinct from the
|
|
registration template) is not strictly required, registrants SHOULD
|
|
provide a stable specification documenting the URN namespace
|
|
definition and expanding upon the issues described herein.
|
|
|
|
Because naming can be difficult and contentious, URN namespace
|
|
registrants and the Designated Experts are strongly encouraged to
|
|
work together in a spirit of good faith and mutual understanding to
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 25]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-26"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
achieve rough consensus (see [<a href="https://datatracker.ietf.org/doc/html/rfc7282" title=""On Consensus and Humming in the IETF"">RFC7282</a>]) on handling registration
|
|
requests. They are also encouraged to bring additional expertise
|
|
into the discussion if that would be helpful in providing perspective
|
|
or otherwise resolving issues.
|
|
|
|
Especially when iterations in the registration process are prolonged,
|
|
Designated Experts are expected to take reasonable precautions to
|
|
avoid "race conditions" on proposed NIDs and, if such situations
|
|
arise, to encourage applicants to work out any conflicts among
|
|
themselves.
|
|
|
|
<span class="h3"><a class="selflink" id="section-6.3" href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.3">6.3</a>. Registration Policy and Process: Fast Track for Standards</span>
|
|
<span class="h3"> Development Organizations, Scientific Societies, and Similar</span>
|
|
Bodies
|
|
|
|
The IETF recognizes that situations will arise in which URN
|
|
namespaces will be created to either embed existing and established
|
|
standards, particularly identifier standards, or reflect knowledge,
|
|
terminology, or methods of organizing information that lie well
|
|
outside the IETF's scope or the likely subject matter knowledge of
|
|
its Designated Experts. In situations in which the registration
|
|
request originates from, or is authorized by, a recognized standards
|
|
development organization, scientific society, or their designees, a
|
|
somewhat different procedure is available at the option of that body:
|
|
|
|
1. The URN namespace registration template is filled out and
|
|
submitted as in steps 1 and 2 of <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.2">Section 6.2</a>.
|
|
|
|
2. A specification is required that reflects or points to the needed
|
|
external standards or specifications. Publication in the RFC
|
|
Series or through an IETF process (e.g., posting as an Internet-
|
|
Draft) is not expected and would be appropriate only under very
|
|
unusual circumstances.
|
|
|
|
3. The reviews on the discussion list and by the Designated Experts
|
|
are strictly advisory, with the decisions about what advice to
|
|
accept and the length of time to allocate to the process strictly
|
|
under the control of the external body.
|
|
|
|
4. When that body concludes that the application is sufficiently
|
|
mature, its representative(s) will request that IANA complete the
|
|
registration for the NID, and IANA will do so.
|
|
|
|
Decisions about whether to recognize the requesting entity as a
|
|
standards development organization or scientific society are the
|
|
responsibility of the IESG.
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 26]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-27"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
A model similar to this has already been defined for recognized
|
|
standards development organizations that wish to register media
|
|
types. The document describing that mechanism [<a href="https://datatracker.ietf.org/doc/html/rfc6838" title=""Media Type Specifications and Registration Procedures"">RFC6838</a>] provides
|
|
somewhat more information about the general approach.
|
|
|
|
<span class="h3"><a class="selflink" id="section-6.4" href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.4">6.4</a>. Completing the Template</span>
|
|
|
|
A template for defining and registering a URN namespace is provided
|
|
in <a href="https://datatracker.ietf.org/doc/html/rfc8141#appendix-A">Appendix A</a>. This section describes considerations for completing
|
|
the template.
|
|
|
|
<span class="h4"><a class="selflink" id="section-6.4.1" href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.4.1">6.4.1</a>. Purpose</span>
|
|
|
|
The "Purpose" section of the template describes matters such as:
|
|
|
|
1. The kinds of resources identified by URNs assigned within the URN
|
|
namespace.
|
|
|
|
2. The scope and applicability of the URNs assigned within the URN
|
|
namespace; this might include information about the community of
|
|
use (e.g., a particular nation, industry, technology, or
|
|
organization), whether the assigned URNs will be used on public
|
|
networks or private networks, etc.
|
|
|
|
3. How the intended community (and the Internet community at large)
|
|
will benefit from using or resolving the assigned URNs.
|
|
|
|
4. How the URN namespace relates to and complements existing URN
|
|
namespaces, URI schemes, and non-URN identifier systems.
|
|
|
|
5. The kinds of software applications that can use or resolve the
|
|
assigned URNs (e.g., by differentiating among disparate URN
|
|
namespaces, identifying resources in a persistent fashion, or
|
|
meaningfully resolving and accessing services associated with the
|
|
URN namespace).
|
|
|
|
6. Whether resolution services are available or will be available
|
|
(and, if so, the nature or identity of the services). Examples
|
|
of q-component and (when they are standardized) r-component
|
|
semantics and syntax are helpful here, even if detailed
|
|
definitions are provided elsewhere or later.
|
|
|
|
7. Whether the URN namespace or its definition is expected to become
|
|
a constituent part of a standard being developed in the IETF or
|
|
some other recognized standards body.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 27]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-28"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
<span class="h4"><a class="selflink" id="section-6.4.2" href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.4.2">6.4.2</a>. Syntax</span>
|
|
|
|
The "Syntax" section of the template contains:
|
|
|
|
1. A description of the structure of URNs within the URN namespace,
|
|
in conformance with the fundamental URN syntax. The structure
|
|
might be described in terms of a formal definition (e.g., using
|
|
ABNF [<a href="https://datatracker.ietf.org/doc/html/rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>]), an algorithm for generating conformant URNs, or
|
|
a regular expression for parsing the name into constituent parts;
|
|
alternatively, the structure might be opaque.
|
|
|
|
2. Any special character encoding rules for assigned URNs (e.g.,
|
|
which character ought to always be used for quotes).
|
|
|
|
3. Rules for determining URN-equivalence between two names in the
|
|
URN namespace. Such rules ought to always have the effect of
|
|
eliminating false negatives that might otherwise result from
|
|
comparison. If it is appropriate and helpful, reference can be
|
|
made to particular equivalence rules defined in the URI
|
|
specification [<a href="https://datatracker.ietf.org/doc/html/rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>] or to <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-3">Section 3</a> of this document.
|
|
Examples of URN-equivalence rules include equivalence between
|
|
uppercase and lowercase characters in the NSS, between hyphenated
|
|
and non-hyphenated groupings in the name, or between single
|
|
quotes and double quotes. There may also be namespace-specific
|
|
special encoding considerations, especially for URNs that contain
|
|
embedded forms of names from non-URN identifier systems. (Note
|
|
that these are not normative statements for any kind of best
|
|
practice related to handling of relationships between characters
|
|
in general; such statements are limited to one particular URN
|
|
namespace only.)
|
|
|
|
4. Any special considerations necessary for conforming with the URN
|
|
syntax. This is particularly applicable in the case of existing,
|
|
non-URN identifier systems that are used in the context of URNs.
|
|
For example, if a non-URN identifier system is used in contexts
|
|
other than URNs, it might make use of characters that are
|
|
reserved in the URN syntax. This section ought to note any such
|
|
characters and outline necessary mappings to conform to URN
|
|
syntax. Normally, this will be handled by percent-encoding the
|
|
character as specified in <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-2.1">Section 2.1</a> of the URI specification
|
|
[<a href="https://datatracker.ietf.org/doc/html/rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>] and as discussed in <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-1.2.2">Section 1.2.2</a> of this
|
|
specification.
|
|
|
|
5. Any special considerations for the meaning of q-components (e.g.,
|
|
keywords) or f-components (e.g., predefined terms) in the context
|
|
of this URN namespace.
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 28]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-29"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
<span class="h4"><a class="selflink" id="section-6.4.3" href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.4.3">6.4.3</a>. Assignment</span>
|
|
|
|
The "Assignment" section of the template describes matters such as:
|
|
|
|
1. Mechanisms or authorities for assigning URNs to resources. It
|
|
ought to make clear whether assignment is completely open (e.g.,
|
|
following a particular procedure such as first-come, first-served
|
|
(FCFS)), completely closed (e.g., for a private organization), or
|
|
limited in various ways (e.g., delegated to authorities
|
|
recognized by a particular organization); if limited, it ought to
|
|
explain how to become an assigner of names or how to request
|
|
assignment of names from existing assignment authorities.
|
|
|
|
2. Methods for ensuring that URNs within the URN namespace are
|
|
unique. For example, names might be assigned sequentially or in
|
|
accordance with some well-defined process by a single authority,
|
|
assignment might be partitioned among delegated authorities that
|
|
are individually responsible for respecting uniqueness rules, or
|
|
URNs might be created independently following an algorithm that
|
|
itself guarantees uniqueness.
|
|
|
|
<span class="h4"><a class="selflink" id="section-6.4.4" href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.4.4">6.4.4</a>. Security and Privacy</span>
|
|
|
|
The "Security and Privacy" section of the template describes any
|
|
potential issues related to security and privacy with regard to
|
|
assignment, use, and resolution of names within the URN namespace.
|
|
Examples of such issues include:
|
|
|
|
o The consequences of producing false negatives and false positives
|
|
during comparison for URN-equivalence (see <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-3.1">Section 3.1</a> of this
|
|
specification and "Issues in Identifier Comparison for Security
|
|
Purposes" [<a href="https://datatracker.ietf.org/doc/html/rfc6943" title=""Issues in Identifier Comparison for Security Purposes"">RFC6943</a>]).
|
|
|
|
o Leakage of private information when names are communicated on the
|
|
public Internet.
|
|
|
|
o The potential for directory harvesting.
|
|
|
|
o Various issues discussed in the guidelines for security
|
|
considerations in RFCs [<a href="https://datatracker.ietf.org/doc/html/rfc3552" title=""Guidelines for Writing RFC Text on Security Considerations"">RFC3552</a>] and the privacy considerations
|
|
for Internet protocols [<a href="https://datatracker.ietf.org/doc/html/rfc6973" title=""Privacy Considerations for Internet Protocols"">RFC6973</a>]. In particular, note the privacy
|
|
considerations text for the Global System for Mobile
|
|
Communications Association (GSMA) / International Mobile station
|
|
Equipment Identity (IMEI) namespace [<a href="https://datatracker.ietf.org/doc/html/rfc7254" title=""A Uniform Resource Name Namespace for the Global System for Mobile Communications Association (GSMA) and the International Mobile station Equipment Identity (IMEI)"">RFC7254</a>], which may provide a
|
|
useful model for such cases.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 29]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-30"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
<span class="h4"><a class="selflink" id="section-6.4.5" href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.4.5">6.4.5</a>. Interoperability</span>
|
|
|
|
The "Interoperability" section MUST specify any known potential
|
|
issues related to interoperability. Examples include possible
|
|
confusion with other URN namespaces, non-URN identifier systems, or
|
|
URI schemes because of syntax (e.g., percent-encoding of certain
|
|
characters) or scope (e.g., overlapping areas of interest). If at
|
|
all possible, concerns that arise during the registration of a URN
|
|
namespace (e.g., due to the syntax or scope of a non-URN identifier
|
|
system) should be resolved as part of or in parallel to the
|
|
registration process.
|
|
|
|
<span class="h4"><a class="selflink" id="section-6.4.6" href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.4.6">6.4.6</a>. Resolution</span>
|
|
|
|
The "Resolution" section MUST specify whether resolution mechanisms
|
|
are intended or anticipated for URNs assigned within the URN
|
|
namespace.
|
|
|
|
If resolution is intended, then this section SHOULD specify whether
|
|
the organization that assigns URNs within the URN namespace intends
|
|
to operate or recommend any resolution services for URNs within that
|
|
URN namespace. In addition, if the assigning organization intends to
|
|
implement registration for publicly advertised resolution services
|
|
(for example, using a system developed in the spirit of the original
|
|
architectural principles and service descriptions for URN resolution
|
|
[<a href="https://datatracker.ietf.org/doc/html/rfc2276" title=""Architectural Principles of Uniform Resource Name Resolution"">RFC2276</a>] [<a href="https://datatracker.ietf.org/doc/html/rfc2483" title=""URI Resolution Services Necessary for URN Resolution"">RFC2483</a>]), then this section SHOULD list or reference the
|
|
requirements for being publicly advertised by the assigning
|
|
organization. In addition, this section SHOULD describe any special
|
|
considerations for the handling of r-components in the context of
|
|
this URN namespace.
|
|
|
|
<span class="h4"><a class="selflink" id="section-6.4.7" href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.4.7">6.4.7</a>. Additional Information</span>
|
|
|
|
The "Additional Information" section includes information that would
|
|
be useful to those trying to understand this registration or its
|
|
relationship to other registrations, such as comparisons to existing
|
|
URN namespaces that might seem to overlap.
|
|
|
|
This section of the template is optional.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 30]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-31"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
<span class="h2"><a class="selflink" id="section-7" href="https://datatracker.ietf.org/doc/html/rfc8141#section-7">7</a>. IANA Considerations</span>
|
|
|
|
<span class="h3"><a class="selflink" id="section-7.1" href="https://datatracker.ietf.org/doc/html/rfc8141#section-7.1">7.1</a>. URI Scheme</span>
|
|
|
|
This section updates the registration of the "urn" URI scheme in the
|
|
Permanent URI Registry [<a href="https://datatracker.ietf.org/doc/html/rfc8141#ref-URI-Registry">URI-Registry</a>].
|
|
|
|
URI Scheme Name: urn
|
|
|
|
Status: permanent
|
|
|
|
URI Scheme Syntax: See <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-2">Section 2 of RFC 8141</a>.
|
|
|
|
URI Scheme Semantics: The "urn" scheme identifies Uniform Resource
|
|
Names, which are persistent, location-independent resource
|
|
identifiers.
|
|
|
|
Encoding Considerations: See <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-2">Section 2 of RFC 8141</a>.
|
|
|
|
Applications/Protocols That Use This URI Scheme Name: Uniform
|
|
Resource Names are used in a wide variety of applications,
|
|
including bibliographic reference systems and as names for
|
|
Extensible Markup Language (XML) namespaces.
|
|
|
|
Interoperability Considerations: See <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-4">Section 4 of RFC 8141</a>.
|
|
|
|
Security Considerations: See Sections <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.4.4">6.4.4</a> and <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-8">8</a> of <a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a>.
|
|
|
|
Contact: URNBIS working group [mailto:urn@ietf.org]
|
|
|
|
Author/Change Controller: This scheme is registered under the IETF
|
|
tree. As such, the IETF maintains change control.
|
|
|
|
References: None.
|
|
|
|
<span class="h3"><a class="selflink" id="section-7.2" href="https://datatracker.ietf.org/doc/html/rfc8141#section-7.2">7.2</a>. Registration of URN Namespaces</span>
|
|
|
|
This document outlines the processes for registering URN namespaces
|
|
and has implications for the IANA in terms of registries to be
|
|
maintained (see especially <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-6">Section 6</a>). In all cases, the IANA ought
|
|
to assign the appropriate NID (formal or informal) once the
|
|
procedures outlined in <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-6">Section 6</a> have been completed.
|
|
|
|
<span class="h3"><a class="selflink" id="section-7.3" href="https://datatracker.ietf.org/doc/html/rfc8141#section-7.3">7.3</a>. Discussion List for New and Updated NID Registrations</span>
|
|
|
|
As discussed elsewhere in this document, the discussion list
|
|
specified in <a href="https://datatracker.ietf.org/doc/html/rfc3406">RFC 3406</a> (urn-nid@apps.ietf.org) is discontinued and
|
|
replaced by the discussion list urn@ietf.org.
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 31]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-32"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
<span class="h2"><a class="selflink" id="section-8" href="https://datatracker.ietf.org/doc/html/rfc8141#section-8">8</a>. Security and Privacy Considerations</span>
|
|
|
|
The definition of a URN namespace needs to account for potential
|
|
security and privacy issues related to assignment, use, and
|
|
resolution of names within the URN namespace (e.g., some URN
|
|
resolvers might assign special meaning to certain characters in the
|
|
NSS); see <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.4.4">Section 6.4.4</a> for further discussion.
|
|
|
|
In most cases, URN namespaces provide a way to declare public
|
|
information. Normally, these declarations will have a relatively low
|
|
security profile; however, there is always the danger of "spoofing"
|
|
and providing misinformation. Information in these declarations
|
|
ought to be taken as advisory.
|
|
|
|
<span class="h2"><a class="selflink" id="section-9" href="https://datatracker.ietf.org/doc/html/rfc8141#section-9">9</a>. References</span>
|
|
|
|
<span class="h3"><a class="selflink" id="section-9.1" href="https://datatracker.ietf.org/doc/html/rfc8141#section-9.1">9.1</a>. Normative References</span>
|
|
|
|
[<a id="ref-RFC20">RFC20</a>] Cerf, V., "ASCII format for network interchange", STD 80,
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc20">RFC 20</a>, DOI 10.17487/RFC0020, October 1969,
|
|
<<a href="http://www.rfc-editor.org/info/rfc20">http://www.rfc-editor.org/info/rfc20</a>>.
|
|
|
|
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
|
|
Requirement Levels", <a href="https://datatracker.ietf.org/doc/html/bcp14">BCP 14</a>, <a href="https://datatracker.ietf.org/doc/html/rfc2119">RFC 2119</a>,
|
|
DOI 10.17487/RFC2119, March 1997,
|
|
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
|
|
|
|
[<a id="ref-RFC3986">RFC3986</a>] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
|
|
Resource Identifier (URI): Generic Syntax", STD 66,
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc3986">RFC 3986</a>, DOI 10.17487/RFC3986, January 2005,
|
|
<<a href="http://www.rfc-editor.org/info/rfc3986">http://www.rfc-editor.org/info/rfc3986</a>>.
|
|
|
|
[<a id="ref-RFC5226">RFC5226</a>] Narten, T. and H. Alvestrand, "Guidelines for Writing an
|
|
IANA Considerations Section in RFCs", <a href="https://datatracker.ietf.org/doc/html/bcp26">BCP 26</a>, <a href="https://datatracker.ietf.org/doc/html/rfc5226">RFC 5226</a>,
|
|
DOI 10.17487/RFC5226, May 2008,
|
|
<<a href="http://www.rfc-editor.org/info/rfc5226">http://www.rfc-editor.org/info/rfc5226</a>>.
|
|
|
|
[<a id="ref-RFC5234">RFC5234</a>] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
|
|
Specifications: ABNF", STD 68, <a href="https://datatracker.ietf.org/doc/html/rfc5234">RFC 5234</a>,
|
|
DOI 10.17487/RFC5234, January 2008,
|
|
<<a href="http://www.rfc-editor.org/info/rfc5234">http://www.rfc-editor.org/info/rfc5234</a>>.
|
|
|
|
<span class="h3"><a class="selflink" id="section-9.2" href="https://datatracker.ietf.org/doc/html/rfc8141#section-9.2">9.2</a>. Informative References</span>
|
|
|
|
[<a id="ref-DOI-URI">DOI-URI</a>] Paskin, N., Neylon, E., Hammond, T., and S. Sun, "The
|
|
"doi" URI Scheme for the Digital Object Identifier (DOI)",
|
|
Work in Progress, <a href="https://datatracker.ietf.org/doc/html/draft-paskin-doi-uri-04">draft-paskin-doi-uri-04</a>, June 2003.
|
|
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 32]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-33"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
[<a id="ref-IANA-URN">IANA-URN</a>] Saint-Andre, P. and M. Cotton, "A Uniform Resource Name
|
|
(URN) Namespace for IANA Registries", Work in Progress,
|
|
<a href="https://datatracker.ietf.org/doc/html/draft-saintandre-iana-urn-01">draft-saintandre-iana-urn-01</a>, February 2013.
|
|
|
|
[<a id="ref-ISO.27729.2012">ISO.27729.2012</a>]
|
|
ISO, "Information and documentation - International
|
|
standard name identifier (ISNI)", ISO 27729:2012,
|
|
Technical Committee ISO/TC 46, Information and
|
|
documentation, Subcommittee SC 9, Identification and
|
|
description, March 2012.
|
|
|
|
[<a id="ref-ISO.3166-1">ISO.3166-1</a>]
|
|
ISO, "Codes for the representation of names of countries
|
|
and their subdivisions -- Part 1: Country codes",
|
|
ISO 3166-1:2013, November 2013.
|
|
|
|
[<a id="ref-RFC1737">RFC1737</a>] Sollins, K. and L. Masinter, "Functional Requirements for
|
|
Uniform Resource Names", <a href="https://datatracker.ietf.org/doc/html/rfc1737">RFC 1737</a>, DOI 10.17487/RFC1737,
|
|
December 1994, <<a href="http://www.rfc-editor.org/info/rfc1737">http://www.rfc-editor.org/info/rfc1737</a>>.
|
|
|
|
[<a id="ref-RFC1738">RFC1738</a>] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
|
|
Resource Locators (URL)", <a href="https://datatracker.ietf.org/doc/html/rfc1738">RFC 1738</a>, DOI 10.17487/RFC1738,
|
|
December 1994, <<a href="http://www.rfc-editor.org/info/rfc1738">http://www.rfc-editor.org/info/rfc1738</a>>.
|
|
|
|
[<a id="ref-RFC1808">RFC1808</a>] Fielding, R., "Relative Uniform Resource Locators",
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc1808">RFC 1808</a>, DOI 10.17487/RFC1808, June 1995,
|
|
<<a href="http://www.rfc-editor.org/info/rfc1808">http://www.rfc-editor.org/info/rfc1808</a>>.
|
|
|
|
[<a id="ref-RFC2141">RFC2141</a>] Moats, R., "URN Syntax", <a href="https://datatracker.ietf.org/doc/html/rfc2141">RFC 2141</a>, DOI 10.17487/RFC2141,
|
|
May 1997, <<a href="http://www.rfc-editor.org/info/rfc2141">http://www.rfc-editor.org/info/rfc2141</a>>.
|
|
|
|
[<a id="ref-RFC2276">RFC2276</a>] Sollins, K., "Architectural Principles of Uniform Resource
|
|
Name Resolution", <a href="https://datatracker.ietf.org/doc/html/rfc2276">RFC 2276</a>, DOI 10.17487/RFC2276, January
|
|
1998, <<a href="http://www.rfc-editor.org/info/rfc2276">http://www.rfc-editor.org/info/rfc2276</a>>.
|
|
|
|
[<a id="ref-RFC2483">RFC2483</a>] Mealling, M. and R. Daniel, "URI Resolution Services
|
|
Necessary for URN Resolution", <a href="https://datatracker.ietf.org/doc/html/rfc2483">RFC 2483</a>,
|
|
DOI 10.17487/RFC2483, January 1999,
|
|
<<a href="http://www.rfc-editor.org/info/rfc2483">http://www.rfc-editor.org/info/rfc2483</a>>.
|
|
|
|
[<a id="ref-RFC2648">RFC2648</a>] Moats, R., "A URN Namespace for IETF Documents", <a href="https://datatracker.ietf.org/doc/html/rfc2648">RFC 2648</a>,
|
|
DOI 10.17487/RFC2648, August 1999,
|
|
<<a href="http://www.rfc-editor.org/info/rfc2648">http://www.rfc-editor.org/info/rfc2648</a>>.
|
|
|
|
[<a id="ref-RFC3044">RFC3044</a>] Rozenfeld, S., "Using The ISSN (International Serial
|
|
Standard Number) as URN (Uniform Resource Names) within an
|
|
ISSN-URN Namespace", <a href="https://datatracker.ietf.org/doc/html/rfc3044">RFC 3044</a>, DOI 10.17487/RFC3044,
|
|
January 2001, <<a href="http://www.rfc-editor.org/info/rfc3044">http://www.rfc-editor.org/info/rfc3044</a>>.
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 33]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-34"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
[<a id="ref-RFC3187">RFC3187</a>] Hakala, J. and H. Walravens, "Using International Standard
|
|
Book Numbers as Uniform Resource Names", <a href="https://datatracker.ietf.org/doc/html/rfc3187">RFC 3187</a>,
|
|
DOI 10.17487/RFC3187, October 2001,
|
|
<<a href="http://www.rfc-editor.org/info/rfc3187">http://www.rfc-editor.org/info/rfc3187</a>>.
|
|
|
|
[<a id="ref-RFC3188">RFC3188</a>] Hakala, J., "Using National Bibliography Numbers as
|
|
Uniform Resource Names", <a href="https://datatracker.ietf.org/doc/html/rfc3188">RFC 3188</a>, DOI 10.17487/RFC3188,
|
|
October 2001, <<a href="http://www.rfc-editor.org/info/rfc3188">http://www.rfc-editor.org/info/rfc3188</a>>.
|
|
|
|
[<a id="ref-RFC3406">RFC3406</a>] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom,
|
|
"Uniform Resource Names (URN) Namespace Definition
|
|
Mechanisms", <a href="https://datatracker.ietf.org/doc/html/bcp66">BCP 66</a>, <a href="https://datatracker.ietf.org/doc/html/rfc3406">RFC 3406</a>, DOI 10.17487/RFC3406,
|
|
October 2002, <<a href="http://www.rfc-editor.org/info/rfc3406">http://www.rfc-editor.org/info/rfc3406</a>>.
|
|
|
|
[<a id="ref-RFC3552">RFC3552</a>] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
|
|
Text on Security Considerations", <a href="https://datatracker.ietf.org/doc/html/bcp72">BCP 72</a>, <a href="https://datatracker.ietf.org/doc/html/rfc3552">RFC 3552</a>,
|
|
DOI 10.17487/RFC3552, July 2003,
|
|
<<a href="http://www.rfc-editor.org/info/rfc3552">http://www.rfc-editor.org/info/rfc3552</a>>.
|
|
|
|
[<a id="ref-RFC4854">RFC4854</a>] Saint-Andre, P., "A Uniform Resource Name (URN) Namespace
|
|
for Extensions to the Extensible Messaging and Presence
|
|
Protocol (XMPP)", <a href="https://datatracker.ietf.org/doc/html/rfc4854">RFC 4854</a>, DOI 10.17487/RFC4854, April
|
|
2007, <<a href="http://www.rfc-editor.org/info/rfc4854">http://www.rfc-editor.org/info/rfc4854</a>>.
|
|
|
|
[<a id="ref-RFC5122">RFC5122</a>] Saint-Andre, P., "Internationalized Resource Identifiers
|
|
(IRIs) and Uniform Resource Identifiers (URIs) for the
|
|
Extensible Messaging and Presence Protocol (XMPP)",
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc5122">RFC 5122</a>, DOI 10.17487/RFC5122, February 2008,
|
|
<<a href="http://www.rfc-editor.org/info/rfc5122">http://www.rfc-editor.org/info/rfc5122</a>>.
|
|
|
|
[<a id="ref-RFC5890">RFC5890</a>] Klensin, J., "Internationalized Domain Names for
|
|
Applications (IDNA): Definitions and Document Framework",
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc5890">RFC 5890</a>, DOI 10.17487/RFC5890, August 2010,
|
|
<<a href="http://www.rfc-editor.org/info/rfc5890">http://www.rfc-editor.org/info/rfc5890</a>>.
|
|
|
|
[<a id="ref-RFC6120">RFC6120</a>] Saint-Andre, P., "Extensible Messaging and Presence
|
|
Protocol (XMPP): Core", <a href="https://datatracker.ietf.org/doc/html/rfc6120">RFC 6120</a>, DOI 10.17487/RFC6120,
|
|
March 2011, <<a href="http://www.rfc-editor.org/info/rfc6120">http://www.rfc-editor.org/info/rfc6120</a>>.
|
|
|
|
[<a id="ref-RFC6288">RFC6288</a>] Reed, C., "URN Namespace for the Defence Geospatial
|
|
Information Working Group (DGIWG)", <a href="https://datatracker.ietf.org/doc/html/rfc6288">RFC 6288</a>,
|
|
DOI 10.17487/RFC6288, August 2011,
|
|
<<a href="http://www.rfc-editor.org/info/rfc6288">http://www.rfc-editor.org/info/rfc6288</a>>.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 34]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-35"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
[<a id="ref-RFC6648">RFC6648</a>] Saint-Andre, P., Crocker, D., and M. Nottingham,
|
|
"Deprecating the "X-" Prefix and Similar Constructs in
|
|
Application Protocols", <a href="https://datatracker.ietf.org/doc/html/bcp178">BCP 178</a>, <a href="https://datatracker.ietf.org/doc/html/rfc6648">RFC 6648</a>,
|
|
DOI 10.17487/RFC6648, June 2012,
|
|
<<a href="http://www.rfc-editor.org/info/rfc6648">http://www.rfc-editor.org/info/rfc6648</a>>.
|
|
|
|
[<a id="ref-RFC6838">RFC6838</a>] Freed, N., Klensin, J., and T. Hansen, "Media Type
|
|
Specifications and Registration Procedures", <a href="https://datatracker.ietf.org/doc/html/bcp13">BCP 13</a>,
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc6838">RFC 6838</a>, DOI 10.17487/RFC6838, January 2013,
|
|
<<a href="http://www.rfc-editor.org/info/rfc6838">http://www.rfc-editor.org/info/rfc6838</a>>.
|
|
|
|
[<a id="ref-RFC6943">RFC6943</a>] Thaler, D., Ed., "Issues in Identifier Comparison for
|
|
Security Purposes", <a href="https://datatracker.ietf.org/doc/html/rfc6943">RFC 6943</a>, DOI 10.17487/RFC6943, May
|
|
2013, <<a href="http://www.rfc-editor.org/info/rfc6943">http://www.rfc-editor.org/info/rfc6943</a>>.
|
|
|
|
[<a id="ref-RFC6963">RFC6963</a>] Saint-Andre, P., "A Uniform Resource Name (URN) Namespace
|
|
for Examples", <a href="https://datatracker.ietf.org/doc/html/bcp183">BCP 183</a>, <a href="https://datatracker.ietf.org/doc/html/rfc6963">RFC 6963</a>, DOI 10.17487/RFC6963,
|
|
May 2013, <<a href="http://www.rfc-editor.org/info/rfc6963">http://www.rfc-editor.org/info/rfc6963</a>>.
|
|
|
|
[<a id="ref-RFC6973">RFC6973</a>] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
|
|
Morris, J., Hansen, M., and R. Smith, "Privacy
|
|
Considerations for Internet Protocols", <a href="https://datatracker.ietf.org/doc/html/rfc6973">RFC 6973</a>,
|
|
DOI 10.17487/RFC6973, July 2013,
|
|
<<a href="http://www.rfc-editor.org/info/rfc6973">http://www.rfc-editor.org/info/rfc6973</a>>.
|
|
|
|
[<a id="ref-RFC7254">RFC7254</a>] Montemurro, M., Ed., Allen, A., McDonald, D., and P.
|
|
Gosden, "A Uniform Resource Name Namespace for the Global
|
|
System for Mobile Communications Association (GSMA) and
|
|
the International Mobile station Equipment Identity
|
|
(IMEI)", <a href="https://datatracker.ietf.org/doc/html/rfc7254">RFC 7254</a>, DOI 10.17487/RFC7254, May 2014,
|
|
<<a href="http://www.rfc-editor.org/info/rfc7254">http://www.rfc-editor.org/info/rfc7254</a>>.
|
|
|
|
[<a id="ref-RFC7282">RFC7282</a>] Resnick, P., "On Consensus and Humming in the IETF",
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc7282">RFC 7282</a>, DOI 10.17487/RFC7282, June 2014,
|
|
<<a href="http://www.rfc-editor.org/info/rfc7282">http://www.rfc-editor.org/info/rfc7282</a>>.
|
|
|
|
[<a id="ref-RFC7320">RFC7320</a>] Nottingham, M., "URI Design and Ownership", <a href="https://datatracker.ietf.org/doc/html/bcp190">BCP 190</a>,
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc7320">RFC 7320</a>, DOI 10.17487/RFC7320, July 2014,
|
|
<<a href="http://www.rfc-editor.org/info/rfc7320">http://www.rfc-editor.org/info/rfc7320</a>>.
|
|
|
|
[<a id="ref-RFC7462">RFC7462</a>] Liess, L., Ed., Jesske, R., Johnston, A., Worley, D., and
|
|
P. Kyzivat, "URNs for the Alert-Info Header Field of the
|
|
Session Initiation Protocol (SIP)", <a href="https://datatracker.ietf.org/doc/html/rfc7462">RFC 7462</a>,
|
|
DOI 10.17487/RFC7462, March 2015,
|
|
<<a href="http://www.rfc-editor.org/info/rfc7462">http://www.rfc-editor.org/info/rfc7462</a>>.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 35]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-36"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
[<a id="ref-RFC7613">RFC7613</a>] Saint-Andre, P. and A. Melnikov, "Preparation,
|
|
Enforcement, and Comparison of Internationalized Strings
|
|
Representing Usernames and Passwords", <a href="https://datatracker.ietf.org/doc/html/rfc7613">RFC 7613</a>,
|
|
DOI 10.17487/RFC7613, August 2015,
|
|
<<a href="http://www.rfc-editor.org/info/rfc7613">http://www.rfc-editor.org/info/rfc7613</a>>.
|
|
|
|
[<a id="ref-UAX31">UAX31</a>] The Unicode Consortium, "Unicode Standard Annex #31:
|
|
Unicode Identifier and Pattern Syntax", Unicode 9.0.0,
|
|
June 2015, <<a href="http://unicode.org/reports/tr31/">http://unicode.org/reports/tr31/</a>>.
|
|
|
|
[<a id="ref-UNICODE">UNICODE</a>] The Unicode Consortium, "The Unicode Standard",
|
|
<<a href="http://www.unicode.org/versions/latest/">http://www.unicode.org/versions/latest/</a>>.
|
|
|
|
[<a id="ref-URI-Registry">URI-Registry</a>]
|
|
IANA, "Uniform Resource Identifier (URI) Schemes",
|
|
<<a href="http://www.iana.org/assignments/uri-schemes">http://www.iana.org/assignments/uri-schemes</a>>.
|
|
|
|
[<a id="ref-XML-BASE">XML-BASE</a>] Marsh, J. and R. Tobin, "XML Base (Second Edition)", W3C
|
|
Recommendation REC-xmlbase-20090128, January 2009,
|
|
<<a href="http://www.w3.org/TR/2009/REC-xmlbase-20090128">http://www.w3.org/TR/2009/REC-xmlbase-20090128</a>>.
|
|
|
|
[<a id="ref-XML-NAMES">XML-NAMES</a>]
|
|
Thompson, H., Hollander, D., Layman, A., Bray, T., and R.
|
|
Tobin, "Namespaces in XML 1.0 (Third Edition)", W3C
|
|
Recommendation REC-xml-names-20091208, December 2009,
|
|
<<a href="http://www.w3.org/TR/2009/REC-xml-names-20091208">http://www.w3.org/TR/2009/REC-xml-names-20091208</a>>.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 36]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-37"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
<span class="h2"><a class="selflink" id="appendix-A" href="https://datatracker.ietf.org/doc/html/rfc8141#appendix-A">Appendix A</a>. Registration Template</span>
|
|
|
|
Namespace Identifier: Requested of IANA (formal) or assigned by IANA
|
|
(informal).
|
|
|
|
Version: The version of the registration, starting with 1 and
|
|
incrementing by 1 with each new version.
|
|
|
|
Date: The date when the registration is requested of IANA, using the
|
|
format YYYY-MM-DD.
|
|
|
|
Registrant: The person or organization that has registered the NID,
|
|
including the name and address of the registering organization, as
|
|
well as the name and contact information (email, phone number, or
|
|
postal address) of the designated contact person. If the
|
|
registrant is a recognized standards development organization,
|
|
scientific society, or similar body requesting the fast-track
|
|
registration procedure (see <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.3">Section 6.3</a>), that information should
|
|
be clearly indicated in this section of the template.
|
|
|
|
Purpose: Described in <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.4.1">Section 6.4.1</a> of this document.
|
|
|
|
Syntax: Described in <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.4.2">Section 6.4.2</a> of this document. Unless the
|
|
registration explicitly describes the semantics of r-components,
|
|
q-components, and f-components in the context of this URN
|
|
namespace, those semantics are undefined.
|
|
|
|
Assignment: Described in <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.4.3">Section 6.4.3</a> of this document.
|
|
|
|
Security and Privacy: Described in <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.4.4">Section 6.4.4</a> of this document.
|
|
|
|
Interoperability: Described in <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.4.5">Section 6.4.5</a> of this document.
|
|
|
|
Resolution: Described in <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.4.6">Section 6.4.6</a> of this document.
|
|
|
|
Documentation: A pointer to an RFC, a specification published by
|
|
another standards development organization, or another stable
|
|
document that provides further information about this URN
|
|
namespace.
|
|
|
|
Additional Information: Described in <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.4.7">Section 6.4.7</a> of this document.
|
|
|
|
Revision Information: Description of changes from prior version(s).
|
|
(Applicable only when earlier registrations have been revised.)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 37]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-38"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
<span class="h2"><a class="selflink" id="appendix-B" href="https://datatracker.ietf.org/doc/html/rfc8141#appendix-B">Appendix B</a>. Changes from <a href="https://datatracker.ietf.org/doc/html/rfc2141">RFC 2141</a></span>
|
|
|
|
This document makes substantive changes from the syntax and semantics
|
|
of [<a href="https://datatracker.ietf.org/doc/html/rfc2141" title=""URN Syntax"">RFC2141</a>]:
|
|
|
|
<span class="h3"><a class="selflink" id="appendix-B.1" href="https://datatracker.ietf.org/doc/html/rfc8141#appendix-B.1">B.1</a>. Syntax Changes from <a href="https://datatracker.ietf.org/doc/html/rfc2141">RFC 2141</a></span>
|
|
|
|
The syntax of URNs as provided in [<a href="https://datatracker.ietf.org/doc/html/rfc2141" title=""URN Syntax"">RFC2141</a>] was defined before the
|
|
updated specification of URIs in [<a href="https://datatracker.ietf.org/doc/html/rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>]. The definition of URN
|
|
syntax is updated in this document to do the following:
|
|
|
|
o Ensure consistency with the URI syntax.
|
|
|
|
o Facilitate the use of URNs with parameters similar to URI queries
|
|
and fragments.
|
|
|
|
o Permit parameters influencing URN resolution.
|
|
|
|
o Ease the use of URNs with non-URN identifier systems that include
|
|
the "/" character.
|
|
|
|
In particular, this specification does the following:
|
|
|
|
o Extends URN syntax to explicitly allow the characters "/", "?",
|
|
and "#", which were reserved for future use by <a href="https://datatracker.ietf.org/doc/html/rfc2141">RFC 2141</a>. This
|
|
change also effectively allows several components of the URI
|
|
syntax although without necessarily tying those components to URI
|
|
semantics.
|
|
|
|
o Defines general syntax for an additional component that can be
|
|
used in interactions with a URN resolution service.
|
|
|
|
o Disallows "-" at the end of the NID.
|
|
|
|
o Allows the "/", "~", and "&" characters in the NSS.
|
|
|
|
o Makes several smaller syntax adjustments.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 38]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-39"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
<span class="h3"><a class="selflink" id="appendix-B.2" href="https://datatracker.ietf.org/doc/html/rfc8141#appendix-B.2">B.2</a>. Other Changes from <a href="https://datatracker.ietf.org/doc/html/rfc2141">RFC 2141</a></span>
|
|
|
|
o Formally registers "urn" as a URI scheme.
|
|
|
|
o Allows what are now called r-components, q-components, and
|
|
f-components.
|
|
|
|
In addition, some of the text has been updated to be consistent with
|
|
the definition of URIs [<a href="https://datatracker.ietf.org/doc/html/rfc3986" title=""Uniform Resource Identifier (URI): Generic Syntax"">RFC3986</a>] and the processes for registering
|
|
information with the IANA [<a href="https://datatracker.ietf.org/doc/html/rfc5226" title="">RFC5226</a>], as well as more modern guidance
|
|
with regard to security [<a href="https://datatracker.ietf.org/doc/html/rfc3552" title=""Guidelines for Writing RFC Text on Security Considerations"">RFC3552</a>], privacy [<a href="https://datatracker.ietf.org/doc/html/rfc6973" title=""Privacy Considerations for Internet Protocols"">RFC6973</a>], and identifier
|
|
comparison [<a href="https://datatracker.ietf.org/doc/html/rfc6943" title=""Issues in Identifier Comparison for Security Purposes"">RFC6943</a>].
|
|
|
|
<span class="h2"><a class="selflink" id="appendix-C" href="https://datatracker.ietf.org/doc/html/rfc8141#appendix-C">Appendix C</a>. Changes from <a href="https://datatracker.ietf.org/doc/html/rfc3406">RFC 3406</a></span>
|
|
|
|
This document makes the following substantive changes from [<a href="https://datatracker.ietf.org/doc/html/rfc3406" title=""Uniform Resource Names (URN) Namespace Definition Mechanisms"">RFC3406</a>]:
|
|
|
|
1. Relaxes the registration policy for formal URN namespaces from
|
|
"IETF Review" to "Expert Review" as discussed in <a href="https://datatracker.ietf.org/doc/html/rfc8141#section-6.2">Section 6.2</a>.
|
|
|
|
2. Removes the category of experimental URN namespaces, consistent
|
|
with [<a href="https://datatracker.ietf.org/doc/html/rfc6648" title=""Deprecating the "">RFC6648</a>]. Experimental URN namespaces were denoted by
|
|
prefixing the namespace identifier with the string "X-". Because
|
|
experimental URN namespaces were never registered, removing the
|
|
experimental category has no impact on the existing registries.
|
|
Because experimental URN namespaces are not managed, strings
|
|
conforming to URN syntax within experimental URN namespaces are
|
|
not valid URNs. Truly experimental usages may, of course, employ
|
|
the "example" namespace [<a href="https://datatracker.ietf.org/doc/html/rfc6963" title=""A Uniform Resource Name (URN) Namespace for Examples"">RFC6963</a>].
|
|
|
|
3. Adds some information to, but generally simplifies, the URN
|
|
namespace registration template.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<span class="grey">Saint-Andre & Klensin Standards Track [Page 39]</span></pre>
|
|
<hr class="noprint"><!--NewPage--><pre class="newpage"><span id="page-40"></span>
|
|
<span class="grey"><a href="https://datatracker.ietf.org/doc/html/rfc8141">RFC 8141</a> URNs April 2017</span>
|
|
|
|
|
|
Acknowledgements
|
|
|
|
Many thanks to Marc Blanchet, Leslie Daigle, Martin Duerst, Juha
|
|
Hakala, Ted Hardie, Alfred Hoenes, Paul Jones, Barry Leiba, Sean
|
|
Leonard, Larry Masinter, Keith Moore, Mark Nottingham, Julian
|
|
Reschke, Lars Svensson, Henry S. Thompson, Dale Worley, and other
|
|
participants in the URNBIS working group for their input. Alfred
|
|
Hoenes in particular edited an earlier draft version of this document
|
|
and served as co-chair of the URNBIS working group.
|
|
|
|
Juha Hakala deserves special recognition for his dedication to
|
|
successfully completing this work, as do Andrew Newton and Melinda
|
|
Shore in their roles as working group co-chairs and Barry Leiba in
|
|
his role as area director and then as co-chair.
|
|
|
|
Contributors
|
|
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc2141">RFC 2141</a>, which provided the basis for the syntax portion of this
|
|
document, was authored by Ryan Moats.
|
|
|
|
<a href="https://datatracker.ietf.org/doc/html/rfc3406">RFC 3406</a>, which provided the basis for the namespace portion of this
|
|
document, was authored by Leslie Daigle, Dirk-Willem van Gulik,
|
|
Renato Iannella, and Patrik Faltstrom.
|
|
|
|
Their work is gratefully acknowledged.
|
|
|
|
Authors' Addresses
|
|
|
|
Peter Saint-Andre
|
|
Filament
|
|
P.O. Box 787
|
|
Parker, CO 80134
|
|
United States of America
|
|
|
|
Phone: +1 720 256 6756
|
|
Email: peter@filament.com
|
|
URI: <<a href="https://filament.com/">https://filament.com/</a>>
|
|
|
|
|
|
John C. Klensin
|
|
1770 Massachusetts Ave, Ste 322
|
|
Cambridge, MA 02140
|
|
United States of America
|
|
|
|
Phone: +1 617 245 1457
|
|
Email: john-ietf@jck.com
|
|
|
|
|
|
|
|
|
|
|
|
Saint-Andre & Klensin Standards Track [Page 40]
|
|
</pre>
|
|
</div>
|
|
|
|
</div>
|
|
|
|
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
<script>$(".visible-nojs").removeClass("visible-nojs");</script>
|
|
<script>$(".hidden-nojs").removeClass("hidden-nojs");</script>
|
|
|
|
<script type="text/javascript"><!--
|
|
var legend_html = "Colour legend:<br /> \
|
|
<table> \
|
|
<tr><td>Unknown:</td> <td><span class='cplate bgwhite'> </span></td></tr> \
|
|
<tr><td>Draft:</td> <td><span class='cplate bgred'> </span></td></tr> \
|
|
<tr><td>Informational:</td> <td><span class='cplate bgorange'> </span></td></tr> \
|
|
<tr><td>Experimental:</td> <td><span class='cplate bgyellow'> </span></td></tr> \
|
|
<tr><td>Best Common Practice:</td> <td><span class='cplate bgmagenta'> </span></td></tr> \
|
|
<tr><td>Proposed Standard:</td> <td><span class='cplate bgblue'> </span></td></tr> \
|
|
<tr><td>Draft Standard (old designation):</td> <td><span class='cplate bgcyan'> </span></td></tr> \
|
|
<tr><td>Internet Standard:</td> <td><span class='cplate bggreen'> </span></td></tr> \
|
|
<tr><td>Historic:</td> <td><span class='cplate bggrey'> </span></td></tr> \
|
|
<tr><td>Obsolete:</td> <td><span class='cplate bgbrown'> </span></td></tr> \
|
|
</table>";
|
|
function showLegend() {
|
|
var elem = document.getElementById('legend');
|
|
elem.innerHTML = legend_html
|
|
elem.style.visibility='visible';
|
|
}
|
|
function hideLegend() {
|
|
var elem = document.getElementById('legend');
|
|
elem.style.visibility='hidden';
|
|
elem.innerHTML = "";
|
|
}
|
|
// -->
|
|
</script>
|
|
|
|
|
|
|
|
|
|
</body></html> |