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/