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,
<http://www.w3.org/TR/REC-xml-names>.
[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, <http://www.w3.org/TR/REC-xml>.
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]
