idnits 2.17.1 draft-rsalz-qname-urn-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 7, 2010) is 5126 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' -- Possible downref: Non-RFC (?) normative reference: ref. 'XMLNS' ** Obsolete normative reference: RFC 3406 (Obsoleted by RFC 8141) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group D. Orchard 3 Internet-Draft Ayogo Games, Inc. 4 Expires: September 8, 2010 R. Salz 5 IBM 6 J. Reschke, Ed. 7 greenbytes 8 March 7, 2010 10 The QName URN Namespace 11 draft-rsalz-qname-urn-02 13 Abstract 15 This specification defines a Uniform Resource Name namespace for XML 16 namespace-qualified names, QNames. As long as the URN is encoded in 17 the same character set as the document containing the original QName, 18 the Qname URN provides enough information to maintain the semantics, 19 and optionally the exact syntax, of the original name. 21 Editorial Note (To be removed by RFC Editor before publication) 23 Please send comments to the xml-dev mailing list 24 (). 26 XML versions, latest edits and the issues list for this document are 27 available from 28 . 30 Status of this Memo 32 This Internet-Draft is submitted to IETF in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF), its areas, and its working groups. Note that 37 other groups may also distribute working documents as Internet- 38 Drafts. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 The list of current Internet-Drafts can be accessed at 46 http://www.ietf.org/ietf/1id-abstracts.txt. 48 The list of Internet-Draft Shadow Directories can be accessed at 49 http://www.ietf.org/shadow.html. 51 This Internet-Draft will expire on September 8, 2010. 53 Copyright Notice 55 Copyright (c) 2010 IETF Trust and the persons identified as the 56 document authors. All rights reserved. 58 This document is subject to BCP 78 and the IETF Trust's Legal 59 Provisions Relating to IETF Documents 60 (http://trustee.ietf.org/license-info) in effect on the date of 61 publication of this document. Please review these documents 62 carefully, as they describe your rights and restrictions with respect 63 to this document. Code Components extracted from this document must 64 include Simplified BSD License text as described in Section 4.e of 65 the Trust Legal Provisions and are provided without warranty as 66 described in the BSD License. 68 This document may contain material from IETF Documents or IETF 69 Contributions published or made publicly available before November 70 10, 2008. The person(s) controlling the copyright in some of this 71 material may not have granted the IETF Trust the right to allow 72 modifications of such material outside the IETF Standards Process. 73 Without obtaining an adequate license from the person(s) controlling 74 the copyright in such materials, this document may not be modified 75 outside the IETF Standards Process, and derivative works of it may 76 not be created outside the IETF Standards Process, except to format 77 it for publication as an RFC or to translate it into languages other 78 than English. 80 Table of Contents 82 1. Introduction and Motivation . . . . . . . . . . . . . . . . . 4 83 2. Namespace Registration Template . . . . . . . . . . . . . . . 4 84 3. Security Considerations . . . . . . . . . . . . . . . . . . . 7 85 4. Normative References . . . . . . . . . . . . . . . . . . . . . 7 86 Appendix A. Change Log (to be removed by RFC Editor before 87 publication) . . . . . . . . . . . . . . . . . . . . 7 88 A.1. Since draft-rsalz-qname-urn-00 . . . . . . . . . . . . . . 7 89 A.2. Since draft-rsalz-qname-urn-01 . . . . . . . . . . . . . . 7 90 Appendix B. Resolved issues (to be removed by RFC Editor 91 before publication) . . . . . . . . . . . . . . . . . 8 92 B.1. contacts . . . . . . . . . . . . . . . . . . . . . . . . . 8 93 B.2. mailing-list . . . . . . . . . . . . . . . . . . . . . . . 8 94 B.3. registrant . . . . . . . . . . . . . . . . . . . . . . . . 8 95 B.4. xml11 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 96 Appendix C. Open issues (to be removed by RFC Editor prior to 97 publication) . . . . . . . . . . . . . . . . . . . . 8 98 C.1. edit . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 99 C.2. curie . . . . . . . . . . . . . . . . . . . . . . . . . . 9 100 C.3. qname-vs-expname . . . . . . . . . . . . . . . . . . . . . 9 101 C.4. i18n . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 102 C.5. reg-info . . . . . . . . . . . . . . . . . . . . . . . . . 9 103 C.6. any-uri . . . . . . . . . . . . . . . . . . . . . . . . . 9 104 C.7. examples . . . . . . . . . . . . . . . . . . . . . . . . . 10 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 107 1. Introduction and Motivation 109 This specification defines a Uniform Resource Name namespace for XML 110 namespace-qualified names, QNames. As long as the URN is encoded in 111 the same character set as the document containing the original QName, 112 the Qname URN provides enough information to maintain the semantics, 113 and optionally the exact syntax, of the original name. 115 There are a variety of situations when a QName may need to be mapped 116 to a URI. For example, when exchanging (or referencing) an 117 identifier for an XML element contained within a document, and the 118 medium of exchange prefers URIs to QNames, such as an XML Schema 119 anyURI data type. Another scenario is for comparing the identifiers, 120 which can be simpler by comparing just a string without having to 121 also compare the context setting XML namespace attribute that may be 122 declared arbitrarily earlier in the document. 124 The XML Namespaces specification [XMLNS] does not provide a canonical 125 mapping between QNames and URIs. Any XML specification that wants to 126 enable identifier exchanges must define a language specific QName to 127 URI mapping. There have emerged a variety of different algorithms 128 and solutions for the mapping. To date, there have been no 129 standardized algorithms available that they can re-use, which has 130 increased their efforts. A standardized mapping, such as this, 131 should provide increased productivity. 133 Almost all of the algorithms for Qname to URI mappings are based upon 134 concatenation of the URI and the name with variations based upon 135 prefix inclusion, namespace name and name separator, etc. These are 136 typically problematic because it is difficult to recover the QName 137 from the URI as the namespace name and name separator may have 138 already been used in the namespace name. Having the namespace name 139 at the end of the identifier string avoids these and other problems. 141 2. Namespace Registration Template 143 The following paragraphs contain the URN namespace registration data, 144 as defined in [RFC3406]. 146 Namespace ID: 148 qname 150 Registration Information: 152 Version number: 2 153 Registration date: 2010-03-07 155 Declared registrant of the namespace: 157 Julian Reschke (see Authors' 158 Adresses Section). 160 Declaration of syntactic structure: 162 The QName URN is structured as four colon-separated fields. Note 163 that colons within the fourth field, the URI part, are not 164 significant; the entire fourth field is treated as a single opaque 165 entity by this URN scheme. 167 The first field identifies the naming scheme. The second contains 168 the QName prefix, or an empty string if the QName comes from the 169 default namespace, or an asterisk if the prefix is not 170 significant. 172 A QName URN is defined by the following ABNF [RFC5234]: 174 qnameURN = "qname" ":" prefix ":" localname ":" uri 175 prefix = ncname / "" / "*" 176 localname = ncname 177 uri = 178 ncname = 180 Here are three examples of a QName URN: 182 urn:qname:foo:OK:http://example.com/ws/foo.xsd 183 urn:qname::OK:http://example.com/ws/foo.xsd 184 urn:qname:*:Reject:http://w3.org/2002/xkms# 186 The first correspond to the following element content QNames (the 187 element name is not significant): 189 foo:OK 190 foo:OK 192 The third example would match both of the others, as well as an 193 inifinite number of QNames, since the namespace prefix is 194 explicitly marked as "don't-care." 196 Relevant ancillary documentation: 198 [XML] [XMLNS] 200 Identifier uniqueness considerations: 202 An XML QName is semantically defined as a (namespace-uri, 203 localname) pair; the namespace prefix is not significant. For 204 some applications, such as signature functions, the prefix is 205 important and must be preserved. 207 The QName URN provides both a one-to-one mapping, that preserves 208 the uniquess of the underlying QName, and an explicit many-to-one 209 mapping, that does not preserve the uniquess when it is not 210 important to do so. 212 Identifier persistence considerations: 214 QName URN's have the same persistance as the underlying XML QName 215 from which they are derived. 217 Process of identifier assignment: 219 Assignment of identifiers depends on the original XML QName, 220 typically deferring to the namespace URI. Anyone with access to 221 an XML QName can create an equivalent QName URN; no registration 222 is required. 224 Process for identifier resolution: 226 Inherited from the QName resolution rules (typically the namespace 227 URI) from which the QName URN is created. 229 Rules for Lexical Equivalence: 231 If necessary, convert each QName URN to the same encoding. The 232 encoding of a QName URN is determined by context, and depends on 233 the encoding of the document in which it appears. 235 To be lexically equivalent the resultant QName URN's must be 236 identical when compared byte-for-byte. To be semantically 237 equivalent, ignore the prefix field when comparing bytes. 239 Conformance with URN Syntax: 241 Fully conformant. 243 Validation mechanism: 245 Inherited from the namespace URI of the original QName. 247 Scope: 249 Inherited from the original QName. 251 3. Security Considerations 253 QName URN's provide a way to transcribe XML QName's into and out of 254 URN syntax. Any security considerations are inherited from the 255 original QName. 257 4. Normative References 259 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 260 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 261 Edition)", W3C REC-xml-20081126, November 2008, 262 . 264 [XMLNS] Bray, T., Hollander, D., Layman, A., Tobin, R., and H. 265 Henry, "Namespaces in XML 1.0 (Third Edition)", W3C REC- 266 xml-names-20091208, December 2009, 267 . 269 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 270 "Uniform Resource Names (URN) Namespace Definition 271 Mechanisms", BCP 33, RFC 3406, October 2002. 273 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 274 Specifications: ABNF", STD 68, RFC 5234, January 2008. 276 Appendix A. Change Log (to be removed by RFC Editor before publication) 278 A.1. Since draft-rsalz-qname-urn-00 280 Updated references and fix reference to XMLNS which was meant to 281 reference XMLNS11. Add a set of issues: "any-uri", "contacts", 282 "curie", "examples", "i18n", "mailing-list", "qname-vs-expname", 283 "reg-info", "registrant", "xml11". 285 A.2. Since draft-rsalz-qname-urn-01 287 Close issues "contacts" and "mailing-list" as resolved (already in 288 -01). Close issues "registrant" and "xml11". Update registration 289 info ("reg-info"). 291 Appendix B. Resolved issues (to be removed by RFC Editor before 292 publication) 294 Issues that were either rejected or resolved in this version of this 295 document. 297 B.1. contacts 299 Type: edit 301 julian.reschke@greenbytes.de (2009-12-11): Update author information. 303 Resolution (2010-03-07): Done in -01. 305 B.2. mailing-list 307 Type: edit 309 julian.reschke@greenbytes.de (2009-12-12): In the boilerplate, state 310 where this Internet Draft should be discussed. Proposal: xml-dev. 312 Resolution (2010-03-07): Done in -01. 314 B.3. registrant 316 In Section 2: 318 Type: edit 320 julian.reschke@greenbytes.de (2009-12-11): Update registrant info. 322 Resolution (2010-03-07): Make the editor the registrant. 324 B.4. xml11 326 Type: change 328 julian.reschke@greenbytes.de (2009-12-11): Consider removing any 329 material related to XML 1.1. 331 Resolution (2010-03-07): Done. 333 Appendix C. Open issues (to be removed by RFC Editor prior to 334 publication) 336 C.1. edit 338 Type: edit 340 julian.reschke@greenbytes.de (2010-03-07): Umbrella issue for 341 editorial changes. 343 C.2. curie 345 Type: edit 347 julian.reschke@greenbytes.de (2009-12-12): Maybe we should clarify 348 the relation with CURIEs (which can be confused with QNames)? 350 C.3. qname-vs-expname 352 Type: edit 354 julian.reschke@greenbytes.de (2009-12-12): There's a risk that we 355 confuse people by claiming this is about QNames. What we map to URNs 356 is the triple (namespace-name, local-name, prefix), where the prefix 357 is optional. The tuple (namespace-name, local-name) is the *expanded 358 name*, not the QName. Options: (1) just clarify the prose, (2) 359 rename the URN scheme (is it in use already?) to something like 360 "xmlname". 362 C.4. i18n 364 Type: change 366 julian.reschke@greenbytes.de (2009-12-11): Need to state how non- 367 ASCII characters are mapped to the URN. 369 C.5. reg-info 371 In Section 2: 373 Type: edit 375 julian.reschke@greenbytes.de (2009-12-11): Update registration info. 377 C.6. any-uri 379 In Section 2: 381 Type: change 383 julian.reschke@greenbytes.de (2009-12-12): Need a grammar for "any 384 valid URI". Do we follow stricly XMLNS, which would make it a "URI 385 reference" as per RFC 3986, or do we tolerate junk and/or IRIs (no 386 offense). Also, we need to state that this part of the URN will be 387 empty for elements that are in no namespace (right?). 389 julian.reschke@greenbytes.de (2010-03-07): In particular: how do we 390 treat namespace names that use a fragment identifier? We can't allow 391 the "#" character in the URN (by definition). 393 C.7. examples 395 In Section 2: 397 Type: change 399 julian.reschke@greenbytes.de (2009-12-11): Having just examples of 400 QNames in element content might be confusing to people not familiar 401 with that use case; we also should have at least one example for an 402 XML element name, and for a QName in content. (potentially also move 403 the examples out of the registration template?) 405 Authors' Addresses 407 David Orchard 408 Ayogo Games, Inc. 410 Email: orchard@pacificspirit.com 412 Rich Salz 413 IBM 415 Email: rsalz@us.ibm.com 417 Julian F. Reschke (editor) 418 greenbytes GmbH 419 Hafenweg 16 420 Muenster, NW 48155 421 Germany 423 Email: julian.reschke@greenbytes.de 424 URI: http://greenbytes.de/tech/webdav/