idnits 2.17.1 draft-seantek-xmlns-rdf-urns-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 24, 2015) is 3138 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2119' is defined on line 357, but no explicit reference was found in the text == Unused Reference: 'RFC2276' is defined on line 391, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-22) exists of draft-ietf-urnbis-rfc2141bis-urn-13 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Leonard 3 Internet-Draft Penango, Inc. 4 Intended status: Standards Track September 24, 2015 5 Expires: March 27, 2016 7 URN Namespaces for XML Namespaces and RDF IRIs 8 draft-seantek-xmlns-rdf-urns-01 10 Abstract 12 XML segregates elements into namespaces, which can be used to mix 13 tags with different semantics in a composite XML document. XML 14 namespaces are identified by URIs (XML 1.0) or IRIs (XML 1.1). 15 Similarly, RDF contains "nodes" that are identified by "URI 16 references" (RDF 1.0) or "IRIs" (RDF 1.1). This document defines 17 URNs specifically for XML namespaces and RDF nodes. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on March 27, 2016. 36 Copyright Notice 38 Copyright (c) 2015 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 1. Introduction 53 XML segregates elements into namespaces, which can be used to mix 54 tags with different semantics in a composite XML document. XML 55 namespaces are identified by URIs [XML1.0] or IRIs [XML1.1]. 56 Similarly, RDF identifies nodes by "URI reference" [RDF1.0] or "IRI" 57 [RDF1.1]. This document defines URN namespace identifiers (NIDs) 58 specifically for identifying XML namespaces and RDF nodes. 60 Experience suggests that several URN namespace registrations have 61 been proposed over the years, where the primary (yet only 62 occasionally stated) purpose is to create concise, targeted resource 63 identifiers for XML or RDF use. An designer now has the option of 64 choosing a concise, mnemonic identifier without the cost of 65 maintaining and relying upon a long-lived network location (such as 66 an HTTP URL), and without the hassle of registering a URN namespace 67 identifier via IETF Consensus. One exemplary advantage of using an 68 xmlns URN over an HTTP URL is that even if the organization hosting 69 the original XML schema ceases to exist, the URI will remain 70 functional without needing to commandeer back an embedded domain 71 name. 73 A name in the urn:xmlns namespace uniquely and persistently 74 identifies an abstract XML namespace resource. The abstract resource 75 does not have any particular concrete representation (such as a type 76 of content identified by Internet media type), although concrete 77 representations (referenced by URIs) may be associated with it as 78 discussed in Section 4. Abstract parts of the abstract resource can 79 be identified with fragment identifiers. 81 A name in the urn:rdf namespace uniquely and persistently identifies 82 an abstract RDF node resource ("URI reference" per [RDF1.0], or "IRI" 83 per [RDF1.1]). The abstract resource does not have any particular 84 concrete representation (such as a type of content identified by 85 Internet media type), although concrete representations (referenced 86 by URIs) may be associated with it. Abstract parts of the abstract 87 resource can be identified with fragment identifiers. 89 Two distinct namespaces are valuable because each namespace 90 represents a different abstract resource type, which can have type- 91 specific concrete representations. For example, 92 "urn:xmlns:foobar2015" could represent some foobar2015 XML namespace, 93 with associated XML schema definitions. In contrast, 94 "urn:rdf:foobar2015" could represent some RDF node (or some RDF node 95 prefix), with associated description resources. 97 1.1. Definitions 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119. 103 The term "divider" means a punctuation character such as colon ":" 104 that serves to divide a name into parts. 106 The term "part" means the characters between divisions (dividers or 107 the ends of the name). 109 While a name "divided" into "parts" can be seen as forming a tree or 110 hierarchy, names in this specification are not hierarchical in the 111 [RFC3986] sense, and have no hierarchical semantic content. Names 112 SHOULD be treated as opaque identifiers that are only compared for 113 equality. 115 The term "initial prefix" means the first part of a name. 117 The term "DIGIT" is from the ABNF production in [RFC5234], i.e., the 118 US-ASCII characters 0 through 9. 120 2. Registration Template for xmlns NID 122 Namespace ID: 123 xmlns 125 Registration Information: 126 Version: 1 127 Date: 2015-09-24 129 Declared registrant of the namespace: 130 IETF 132 Declaration of syntactic structures: 133 An xmlns name is any 134 valid XML name corresponding to "Name" in Section 2.3 135 of [XML1.0] (production 5), with the following restrictions: 136 1. The name MUST be at least four characters. 137 2. Colons MAY be used as intra-name dividers. 138 3. Colons MUST NOT appear at the beginning or end of the name. 139 4. Consecutive colons MUST NOT appear. 140 and the following relaxation: 141 5. The first part of the name preceding the first colon MAY 142 be comprised of DIGITs (which are intended to correspond 143 to registered IANA Private Enterprise Numbers); 144 further discussion is in 145 "Process of identifier assignment". 147 The ABNF of a name is: 149 urn-xmlns-name = [DIGIT+ ":"] NoColonNameStartChar 150 *([":"] NoColonNameChar) 152 Where the productions NoColonNameStartChar and NoColonNameChar 153 are respectively taken from NameStartChar (production 4) 154 and NameChar (production 4a) in [XML1.0], with ":" omitted. 155 Although ABNF is formally US-ASCII only, the domain of 156 this production includes the whole Unicode range. 158 The name is used as the basis of the 159 Namespace Specific String (NSS) as follows. 160 When the NSS is encoded in a URN in a URI protocol slot, 161 Unicode code points beyond U+007F 162 are encoded as percent-encoded UTF-8. Conveniently, 163 all XML name characters in the US-ASCII range are in the 164 [RFC3986] unreserved set. 165 When the NSS is encoded in a URN in a IRI protocol slot, 166 Unicode code points beyond U+007F in the unreserved set 167 are encoded as-is; they MUST NOT be percent-encoded. 169 Relevant ancillary documentation: 170 [XML1.0], [XML1.1]. 172 Identifier uniqueness considerations: 173 The meaning of an identifier is registered in the registry, 174 and thus is unique. 176 Identifier persistence considerations: 177 Once an identifier is registered, its meaning cannot be changed. 179 Process of identifier assignment: 180 Identifiers are registered with IANA on a First-Come, First-Served 181 basis. One-character initial prefixes are reserved for further 182 use. Two- and three-character initial prefixes are intended to 183 correlate with language tags and regional codes; however, they 184 have no such semantic content when used in an xmlns name. Whole 185 number initial prefixes are intended to represent IANA 186 Private Enterprise Numbers. 187 Registrants are free to register names with reserved two-character 188 and three-character initial prefixes, such as "au:flag" or 189 "en:us:ca:lax". Registrants are also free to register names with 190 whole number prefixes, such as "20:10-250": these names have a 191 particular registration process since they implicitly relate 192 relate to IANA Private Enterprise Numbers. 194 The IANA Considerations section fully defines the 195 registration processes. 197 Process for identifier resolution: 198 The registration for a particular identifier MAY include 199 any number of URIs that a URN resolver MAY use to resolve 200 the URN to return specific resources. The registered 201 URIs are not equivalent to the registered URN, so an XML document 202 that refers to that particular namespace MUST use the registered 203 URN as the XML namespace URI. IANA will maintain the resolution 204 database--see Section 4. 205 A URN resolver SHALL pass any [RFC3986] fragment component in the 206 urn: URI or IRI through to the resolved URI if the registered URI 207 does not have a fragment component. See [URNBIS]. 208 If the registered URI has a fragment component, a URN resolver 209 SHALL NOT pass any [RFC3986] fragment component in the urn: URI 210 or IRI; the fragment component SHALL be ignored. 212 Rules for Lexical Equivalence: 213 The NSS is compared case sensitively. 214 If a URI and a IRI are compared against each other, the 215 UTF-8 percent-encoded octets in the URI representing code points 216 in the unreserved set beyond U+007F SHALL be treated 217 as the Unicode code points 218 in the IRI. An IRI that contains UTF-8 percent-encoded octets 219 in the unreserved set beyond U+007F is not supposed to exist; 220 it is a protocol error. 221 Fragments (delimited by the # character) are not considered 222 part of the name, the NSS, or the URN, so a fragment would not 223 affect lexical equivalence. Nevertheless, a urn: URI or IRI 224 might be produced with a fragment component. 226 Conformance with URN Syntax: 227 The URN of this namespace conforms to new URN Syntax 228 [URNBIS], old URN syntax [RFC2141], and Uniform Resource Identifier 229 (URI): Generic Syntax [RFC3986]. 231 Validation mechanism: 232 An XMLNS URN may be validated by looking it up in the IANA Registry. 234 Scope: 235 Global. 237 3. Registration Template for rdf NID 238 Namespace ID: 239 rdf 241 Registration Information: 242 Version: 1 243 Date: 2015-09-24 245 [[TODO: paste xmlns content and make rdf substitutions.]] 247 Scope: 248 Global. 250 4. IANA Considerations 252 This document requests the assignment of formal URN namespace IDs 253 "xmlns" and "rdf". 255 This document requests the creation of an IANA registry called 256 "urn:xmlns Names", and an IANA registry called "urn:rdf Names". The 257 registries are First-Come, First-Served [RFC5226]. Each registration 258 shall contain: 260 a. the name conforming to this document 262 1) in Unicode characters and 264 2) with characters beyond U+007F percent-encoded in UTF-8, 266 b. an optional description, 268 c. optional [RFC3986] conforming URIs that are not URNs that are to 269 be used for URN resolution, and 271 d. contact information for the registrant. 273 After submitting a new registration, the registration SHALL be 274 effective and entered into the registry after 120 hours (5 days). 275 Registrants or their successors may update their entries from time to 276 time. After submitting an updated registration, the registration 277 SHALL be effective and entered into the registry after 48 hours (2 278 days). During the waiting period, a registrant MAY withdraw the 279 proposed registration for any reason. 281 The registration template SHALL be encoded in UTF-8. 283 If a registrant attempts to register a name that is confusingly 284 similar to other registered names (such as only differing by case, or 285 differing by code points but generating the same or confusingly 286 similar visual representations), the registrants of the prior names 287 are to receive a warning notification of the registration. IANA 288 SHOULD implement a modern algorithm to detect such confusingly 289 similar names. 291 If a registrant attempts to register a name that contains a whole 292 number initial prefix, the number MUST correspond to an existing IANA 293 Private Enterprise Number. The registrant of the corresponding IANA 294 Private Enterprise Number is to receive a notification of the 295 impending registration. The PEN registrant MAY veto the impending 296 registration during this time. Otherwise, the registration will 297 succeed. 299 IANA is to maintain these registries at designated URIs on its 300 website, currently www.iana.org. Regardless of other formatting, 301 IANA will designate URIs of the form: {pre}/{name}, where {pre} is 302 IANA's chosen name registry prefix over HTTP or HTTPS, and {name} is 303 the name (with UTF-8 percent-encoding). The response to an HTTP GET 304 request at one of these URIs SHALL be a text/plain document with 305 UTF-8 encoding ("charset=UTF-8") formatted as follows: 307 urn:{xmlns or rdf}:{name} 308 Description: {description} 309 Contact Information: {contact information} 311 {URI 0} 312 {URI 1} 313 {...} 315 The Description and Contact Information fields MAY span multiple 316 lines by ending the line and including one space (U+0020) on the 317 subsequent line. Semantically, the line-ending and space mean "end 318 of line" only. URN resolvers MAY use this database (whether IANA's 319 customary form, or the form specified by this section) when resolving 320 URNs to URIs to access particular resources. 322 The purpose of these registered URIs is to assist protocol designers, 323 systems analysts, and software engineers with understanding the 324 nature of the XML namespace or RDF node, rather than for general 325 consumption. For example, one registered URI could forward to a 326 text/html resource that is a standards document describing a protocol 327 that uses the URN. [[NB: compare with xml.resource.org for I-Ds.]] 328 Consequently, the traffic burden imposed on IANA is expected to be 329 negligible. 331 5. Security Considerations 333 XML processors use XML namespaces to validate XML content. This 334 document is not expected to introduce any additional security 335 considerations beyond those inherent in XML processing. 337 RDF processors use RDF URI references (RDF 1.0) or IRIs (RDF 1.1) to 338 identify nodes (subjects, predicates, and objects). This document is 339 not expected to introduce any additional security considerations 340 beyond those inherent in RDF processing. 342 6. References 344 6.1. Normative References 346 [RDF1.0] Klyne, G. and J. Carroll, "Resource Description Framework 347 (RDF): Concepts and Abstract Syntax", World Wide Web 348 Consortium Recommendation REC-rdf-concepts-20040210, 349 February 2004, 350 . 352 [RDF1.1] Cyganiak, R., Wood, D., and M. Lanthaler, "RDF 1.1 353 Concepts and Abstract Syntax", World Wide Web Consortium 354 Recommendation REC-rdf11-concepts-20140225, February 2014, 355 . 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, March 1997. 360 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 362 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 363 Resource Identifier (URI): Generic Syntax", STD 66, RFC 364 3986, January 2005. 366 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 367 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 368 May 2008. 370 [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax 371 Specifications: ABNF", STD 68, RFC 5234, January 2008. 373 [URNBIS] Saint-Andre, P. and J. Klensin, "Uniform Resource Names 374 (URNs)", draft-ietf-urnbis-rfc2141bis-urn-13 (work in 375 progress), September 2015. 377 [XML1.0] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 378 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 379 Edition)", World Wide Web Consortium Recommendation REC- 380 xml-20081126, November 2008, 381 . 383 [XML1.1] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., 384 Yergeau, F., and J. Cowan, "Extensible Markup Language 385 (XML) 1.1 (Second Edition)", World Wide Web Consortium 386 Recommendation REC-xml11-20060816, August 2006, 387 . 389 6.2. Informative References 391 [RFC2276] Sollins, K., "Architectural Principles of Uniform Resource 392 Name Resolution", RFC 2276, January 1998. 394 Author's Address 396 Sean Leonard 397 Penango, Inc. 398 5900 Wilshire Boulevard 399 21st Floor 400 Los Angeles, CA 90036 401 USA 403 Email: dev+ietf@seantek.com 404 URI: http://www.penango.com/