idnits 2.17.1 draft-duerst-iana-namespace-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 292. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 303. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 310. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 316. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 18, 2008) is 5906 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'Namespaces' -- Possible downref: Non-RFC (?) normative reference: ref. 'XML' Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Duerst 3 Internet-Draft Aoyama Gakuin University 4 Intended status: Best Current T. Bray 5 Practice Sun Microsystems 6 Expires: August 21, 2008 February 18, 2008 8 HTTP-based IETF Namespace URIs at IANA 9 draft-duerst-iana-namespace-00 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on August 21, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document creates a registry and defines a procedure to allow 43 IETF specifications to register XML Namespace Names with IANA which 44 are HTTP URIs and thus potentially useful for looking up information 45 about the namespace. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Registry Details . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. Namespace URI Syntax . . . . . . . . . . . . . . . . . . . 3 53 2.2. Namespace Documents . . . . . . . . . . . . . . . . . . . . 4 54 3. Registration Procedure . . . . . . . . . . . . . . . . . . . . 4 55 3.1. Registration Updates . . . . . . . . . . . . . . . . . . . 4 56 4. Expert Reviewer . . . . . . . . . . . . . . . . . . . . . . . . 4 57 5. Registration Template . . . . . . . . . . . . . . . . . . . . . 5 58 6. Benefits of HTTP URIs . . . . . . . . . . . . . . . . . . . . . 5 59 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 60 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 61 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 62 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 10.1. Normative References . . . . . . . . . . . . . . . . . . . 6 64 10.2. Informative References . . . . . . . . . . . . . . . . . . 7 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 66 Intellectual Property and Copyright Statements . . . . . . . . . . 8 68 1. Introduction 70 Many IETF specifications use [XML] with XML Namespaces [Namespaces]. 71 XML Namespace Names are URIs, and there are many options for 72 constructing them. One of the options is the use of HTTP URIs (those 73 whose scheme is "http:"). [RFC3688] created an IANA registry for XML 74 namespaces based on URNs, which take on the form 75 urn:ietf:params:xml:ns:foo. [RFC3470] observes that in the case of 76 namespaces in the IETF standards-track documents, it would be useful 77 if there were some permanent part of the IETF's own web space that 78 could be used to mint HTTP URIs. However, it seems to be more 79 appropriate and in line with IETF practice to delegate such a 80 registry function to IANA. This document proposes such a registry 81 with guidelines for its use. [RFC Editor: Please replace 'proposed 82 to do' with 'does' in the previous sentence before publication of 83 this document as an RFC.] 85 Please send comments on this document directly to the authors, or to 86 the mailing list discuss@ietf.org. 88 1.1. Notation 90 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 91 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 92 and "OPTIONAL" are to be interpreted as described in [RFC2119]. 94 2. Registry Details 96 This section describes the registry in detail. IANA maintains a 97 registry page listing the registered XML namespaces which use HTTP 98 URIs. For each registered namespace, the registry page includes a 99 human-readable name for the namespace, a link to the namespace 100 document,and the actual namespace URI. 102 2.1. Namespace URI Syntax 104 Namespaces created by IANA upon registration have the following form. 105 There is a common prefix, "http://www.iana.org/xmlns/" (this needs to 106 be agreed on with IANA), followed by a unique identifier. 108 The unique identifier SHOULD be a relatively short string of US-ASCII 109 letters, digits, and hyphens, where a digit cannot appear in first 110 position and a hyphen cannot appear in first or last position or in 111 successive positions. In addition, the unique identifier can end in 112 a sinle '/' or '#'. XML namespaces are case-sensitive, but all 113 registrations are REQUIRED to mutually differ even under case- 114 insensitive comparison. For uniformity, only lower letters SHOULD be 115 used. 117 A unique identifier is proposed by the requester, but IANA may change 118 it as they see fit, in consultation with the responsible Expert 119 Reviewer. 121 2.2. Namespace Documents 123 For each namespace registered, there MUST be a namespace document in 124 either HTML or XHTML which may be retrieved using the HTTP URI which 125 is the registered namespace name. It contains the template 126 information with appropriate markup. 128 3. Registration Procedure 130 The request for creation and registration of a HTTP XML Namespace URI 131 is made by including a completed registration template (see 132 Section 5) in the IANA Considerations section of an Internet-Draft. 133 Registration is limited to namespace names specified in documents 134 that go through IESG approval and where change control lies with the 135 IETF. 137 There is no review procedure separate from the procedure leading to 138 IESG approval. The actual registration is carried out as part of the 139 work that IANA does in scanning and processing documents being 140 published as RFCs. HTTP XML Namespace URIs are not intended for work 141 in progress, where a namespace independent of IANA MUST be used. 143 3.1. Registration Updates 145 Occasionally, there may be a need to update a registration. In 146 general, this is done by republishing the specification containing 147 the registration. In this case, the provisions above apply, with 148 appropriate adjustments for the fact that this is an update. 149 However, a more light-weight process is desirable to fix minor errors 150 and to add additional information. 152 A registration can be updated by a request to IANA detailing the 153 changes to be made (using the template in Section 5 where 154 appropriate). 156 4. Expert Reviewer 158 To help with reviewing registrations, the IETF Application Area 159 Directors appoint one or more Expert Reviewers. 161 5. Registration Template 163 Below is the registration template to be used for registrations, with 164 comments for each field. 165 Proposed namespace: http://www.iana.org/xmlns/[your component here] 167 Human readable title: [Should fit in part of one line] 169 Defining document: [draft-foo-bar-99.txt -> RFC XXXX] 171 Defining document status: [Standards track, other] 173 Additional information: [any helpful additional information] 175 In the final document, in the actual namespace document, and for 176 updates, "Proposed namespace" is changed to "Namespace". 178 6. Benefits of HTTP URIs 180 Software which uses XML namespace names typically treats them at 181 opaque strings at runtime, using them to decide whether some 182 particular markup tokens are to be selected for some particular 183 processing. Such software should have no concern at runtime for the 184 URI scheme. Thus, all properly-registered URI schemes are equally 185 suitable for runtime use. 187 HTTP URIs are distinguished by being associated with a widely- 188 deployed protocol. They can be used not only to identify, but also 189 to retrieve Web Resources. Thus, a human who recognizes an HTTP URI 190 may reasonably attempt to so use it. Note that this usage is 191 entirely unrelated to its runtime use in unambiguously naming markup 192 tokens. 194 Thus, HTTP URIs have the advantage that they may be usable by humans 195 (typically protocol implementors in this context) to educate 196 themselves about the nature and purpose of the markup tokens that are 197 in the namespace in question. A subsidiary benefit is that HTTP URIs 198 tend to be substantially more human-readable than URNs, and thus more 199 memorable. 201 Note that the use of an HTTP URI does not constitute an obligation to 202 make it dereferencable. Runtime software MUST NOT depend on whether 203 dereferencing is possible. The advantages only apply to human use 204 and in a pedagogic context. 206 7. Security Considerations 208 The use of HTTP URIs for XML namespace URIs as such does not raise 209 any security concerns. However, care has to be taken to not 210 inappropriately creating denial-of-service attacks by applications 211 that might automatically try to resolve a namespace URI. 213 The security considerations of [STD66] also apply and should be 214 considered carefully. 216 8. IANA Considerations 218 This whole document contains provisions affecting IANA. We invite 219 IANA to study it carefully and to comment on it to make sure that 220 IANA's concerns are fully addressed. 222 9. Acknowledgments 224 Starting with Tim Berners-Lee, many people have suggested that the 225 best form of XML Namespace URIs are HTTP URIs. The actual suggestion 226 to write this document is due to Chris Newman, who made it during a 227 discussion of namespace URI practice for an Atom extension. 229 10. References 231 10.1. Normative References 233 [Namespaces] 234 Bray, T., Hollander, D., Layman, A., and R. Tobin, 235 "Namespaces in XML (Second Edition)", World Wide Web 236 Consortium Recommendation, August 2006, 237 . 239 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 240 Requirement Levels", BCP 14, RFC 2119, March 1997. 242 [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 243 Resource Identifier (URI): Generic Syntax", STD 66, 244 RFC 3986, April 2004. 246 [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and 247 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Forth 248 Edition)", World Wide Web Consortium Recommendation, 249 August 2006, . 251 10.2. Informative References 253 [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for 254 the Use of Extensible Markup Language (XML) within IETF 255 Protocols", January 2003. 257 [RFC3688] Mealing, M., "The IETF XML Registry", January 2004. 259 Authors' Addresses 261 Martin Duerst (Note: Please write "Duerst" with u-umlaut wherever 262 possible, for example as "Dürst" in XML and HTML.) 263 Aoyama Gakuin University 264 5-10-1 Fuchinobe 265 Sagamihara, Kanagawa 229-8558 266 Japan 268 Phone: +81 42 759 6329 269 Fax: +81 42 759 6495 270 Email: mailto:duerst@it.aoyama.ac.jp 271 URI: http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/ 273 Tim Bray 274 Sun Microsystems 276 Email: tbray@textuality.com 278 Full Copyright Statement 280 Copyright (C) The IETF Trust (2008). 282 This document is subject to the rights, licenses and restrictions 283 contained in BCP 78, and except as set forth therein, the authors 284 retain all their rights. 286 This document and the information contained herein are provided on an 287 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 288 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 289 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 290 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 291 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 292 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 294 Intellectual Property 296 The IETF takes no position regarding the validity or scope of any 297 Intellectual Property Rights or other rights that might be claimed to 298 pertain to the implementation or use of the technology described in 299 this document or the extent to which any license under such rights 300 might or might not be available; nor does it represent that it has 301 made any independent effort to identify any such rights. Information 302 on the procedures with respect to rights in RFC documents can be 303 found in BCP 78 and BCP 79. 305 Copies of IPR disclosures made to the IETF Secretariat and any 306 assurances of licenses to be made available, or the result of an 307 attempt made to obtain a general license or permission for the use of 308 such proprietary rights by implementers or users of this 309 specification can be obtained from the IETF on-line IPR repository at 310 http://www.ietf.org/ipr. 312 The IETF invites any interested party to bring to its attention any 313 copyrights, patents or patent applications, or other proprietary 314 rights that may cover technology that may be required to implement 315 this standard. Please address the information to the IETF at 316 ietf-ipr@ietf.org. 318 Acknowledgment 320 Funding for the RFC Editor function is provided by the IETF 321 Administrative Support Activity (IASA).