From: http://www.ietf.org/internet-drafts/draft-duerst-iana-namespace-00.txt Title: HTTP-based IETF Namespace URIs at IANA Reference: IETF Network Working Group, Internet Draft 'draft-duerst-iana-namespace-00' Date: February 18, 2008 I-D Tracker: http://ietfreport.isoc.org/idref/draft-duerst-iana-namespace/ See also: Namespaces in XML 1.0 (Second Edition) - W3C Recommendation 16-August-2006 http://www.w3.org/TR/2006/REC-xml-names-20060816 Namespaces in XML http://xml.coverpages.org/namespaces.html ============================================================================== Network Working Group M. Duerst Internet-Draft Aoyama Gakuin University Intended status: Best Current T. Bray Practice Sun Microsystems Expires: August 21, 2008 February 18, 2008 HTTP-based IETF Namespace URIs at IANA draft-duerst-iana-namespace-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 21, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document creates a registry and defines a procedure to allow IETF specifications to register XML Namespace Names with IANA which are HTTP URIs and thus potentially useful for looking up information about the namespace. Duerst & Bray Expires August 21, 2008 [Page 1] Internet-Draft HTTP-based IETF Namespace URIs at IANA February 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Registry Details . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Namespace URI Syntax . . . . . . . . . . . . . . . . . . . 3 2.2. Namespace Documents . . . . . . . . . . . . . . . . . . . . 4 3. Registration Procedure . . . . . . . . . . . . . . . . . . . . 4 3.1. Registration Updates . . . . . . . . . . . . . . . . . . . 4 4. Expert Reviewer . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Registration Template . . . . . . . . . . . . . . . . . . . . . 5 6. Benefits of HTTP URIs . . . . . . . . . . . . . . . . . . . . . 5 7. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 10.1. Normative References . . . . . . . . . . . . . . . . . . . 6 10.2. Informative References . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Intellectual Property and Copyright Statements . . . . . . . . . . 8 Duerst & Bray Expires August 21, 2008 [Page 2] Internet-Draft HTTP-based IETF Namespace URIs at IANA February 2008 1. Introduction Many IETF specifications use [XML] with XML Namespaces [Namespaces]. XML Namespace Names are URIs, and there are many options for constructing them. One of the options is the use of HTTP URIs (those whose scheme is "http:"). [RFC3688] created an IANA registry for XML namespaces based on URNs, which take on the form urn:ietf:params:xml:ns:foo. [RFC3470] observes that in the case of namespaces in the IETF standards-track documents, it would be useful if there were some permanent part of the IETF's own web space that could be used to mint HTTP URIs. However, it seems to be more appropriate and in line with IETF practice to delegate such a registry function to IANA. This document proposes such a registry with guidelines for its use. [RFC Editor: Please replace 'proposed to do' with 'does' in the previous sentence before publication of this document as an RFC.] Please send comments on this document directly to the authors, or to the mailing list discuss@ietf.org. 1.1. Notation In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in [RFC2119]. 2. Registry Details This section describes the registry in detail. IANA maintains a registry page listing the registered XML namespaces which use HTTP URIs. For each registered namespace, the registry page includes a human-readable name for the namespace, a link to the namespace document,and the actual namespace URI. 2.1. Namespace URI Syntax Namespaces created by IANA upon registration have the following form. There is a common prefix, "http://www.iana.org/xmlns/" (this needs to be agreed on with IANA), followed by a unique identifier. The unique identifier SHOULD be a relatively short string of US-ASCII letters, digits, and hyphens, where a digit cannot appear in first position and a hyphen cannot appear in first or last position or in successive positions. In addition, the unique identifier can end in a sinle '/' or '#'. XML namespaces are case-sensitive, but all registrations are REQUIRED to mutually differ even under case- insensitive comparison. For uniformity, only lower letters SHOULD be Duerst & Bray Expires August 21, 2008 [Page 3] Internet-Draft HTTP-based IETF Namespace URIs at IANA February 2008 used. A unique identifier is proposed by the requester, but IANA may change it as they see fit, in consultation with the responsible Expert Reviewer. 2.2. Namespace Documents For each namespace registered, there MUST be a namespace document in either HTML or XHTML which may be retrieved using the HTTP URI which is the registered namespace name. It contains the template information with appropriate markup. 3. Registration Procedure The request for creation and registration of a HTTP XML Namespace URI is made by including a completed registration template (see Section 5) in the IANA Considerations section of an Internet-Draft. Registration is limited to namespace names specified in documents that go through IESG approval and where change control lies with the IETF. There is no review procedure separate from the procedure leading to IESG approval. The actual registration is carried out as part of the work that IANA does in scanning and processing documents being published as RFCs. HTTP XML Namespace URIs are not intended for work in progress, where a namespace independent of IANA MUST be used. 3.1. Registration Updates Occasionally, there may be a need to update a registration. In general, this is done by republishing the specification containing the registration. In this case, the provisions above apply, with appropriate adjustments for the fact that this is an update. However, a more light-weight process is desirable to fix minor errors and to add additional information. A registration can be updated by a request to IANA detailing the changes to be made (using the template in Section 5 where appropriate). 4. Expert Reviewer To help with reviewing registrations, the IETF Application Area Directors appoint one or more Expert Reviewers. Duerst & Bray Expires August 21, 2008 [Page 4] Internet-Draft HTTP-based IETF Namespace URIs at IANA February 2008 5. Registration Template Below is the registration template to be used for registrations, with comments for each field. Proposed namespace: http://www.iana.org/xmlns/[your component here] Human readable title: [Should fit in part of one line] Defining document: [draft-foo-bar-99.txt -> RFC XXXX] Defining document status: [Standards track, other] Additional information: [any helpful additional information] In the final document, in the actual namespace document, and for updates, "Proposed namespace" is changed to "Namespace". 6. Benefits of HTTP URIs Software which uses XML namespace names typically treats them at opaque strings at runtime, using them to decide whether some particular markup tokens are to be selected for some particular processing. Such software should have no concern at runtime for the URI scheme. Thus, all properly-registered URI schemes are equally suitable for runtime use. HTTP URIs are distinguished by being associated with a widely- deployed protocol. They can be used not only to identify, but also to retrieve Web Resources. Thus, a human who recognizes an HTTP URI may reasonably attempt to so use it. Note that this usage is entirely unrelated to its runtime use in unambiguously naming markup tokens. Thus, HTTP URIs have the advantage that they may be usable by humans (typically protocol implementors in this context) to educate themselves about the nature and purpose of the markup tokens that are in the namespace in question. A subsidiary benefit is that HTTP URIs tend to be substantially more human-readable than URNs, and thus more memorable. Note that the use of an HTTP URI does not constitute an obligation to make it dereferencable. Runtime software MUST NOT depend on whether dereferencing is possible. The advantages only apply to human use and in a pedagogic context. Duerst & Bray Expires August 21, 2008 [Page 5] Internet-Draft HTTP-based IETF Namespace URIs at IANA February 2008 7. Security Considerations The use of HTTP URIs for XML namespace URIs as such does not raise any security concerns. However, care has to be taken to not inappropriately creating denial-of-service attacks by applications that might automatically try to resolve a namespace URI. The security considerations of [STD66] also apply and should be considered carefully. 8. IANA Considerations This whole document contains provisions affecting IANA. We invite IANA to study it carefully and to comment on it to make sure that IANA's concerns are fully addressed. 9. Acknowledgments Starting with Tim Berners-Lee, many people have suggested that the best form of XML Namespace URIs are HTTP URIs. The actual suggestion to write this document is due to Chris Newman, who made it during a discussion of namespace URI practice for an Atom extension. 10. References 10.1. Normative References [Namespaces] Bray, T., Hollander, D., Layman, A., and R. Tobin, "Namespaces in XML (Second Edition)", World Wide Web Consortium Recommendation, August 2006, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, April 2004. [XML] Bray, T., Paoli, J., Sperberg-McQueen, C., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Forth Edition)", World Wide Web Consortium Recommendation, August 2006, . Duerst & Bray Expires August 21, 2008 [Page 6] Internet-Draft HTTP-based IETF Namespace URIs at IANA February 2008 10.2. Informative References [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for the Use of Extensible Markup Language (XML) within IETF Protocols", January 2003. [RFC3688] Mealing, M., "The IETF XML Registry", January 2004. Authors' Addresses Martin Duerst (Note: Please write "Duerst" with u-umlaut wherever possible, for example as "Dürst" in XML and HTML.) Aoyama Gakuin University 5-10-1 Fuchinobe Sagamihara, Kanagawa 229-8558 Japan Phone: +81 42 759 6329 Fax: +81 42 759 6495 Email: mailto:duerst@it.aoyama.ac.jp URI: http://www.sw.it.aoyama.ac.jp/D%C3%BCrst/ Tim Bray Sun Microsystems Email: tbray@textuality.com Duerst & Bray Expires August 21, 2008 [Page 7] Internet-Draft HTTP-based IETF Namespace URIs at IANA February 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Duerst & Bray Expires August 21, 2008 [Page 8]