Internet DRAFT - draft-seantek-xmlns-urn
draft-seantek-xmlns-urn
Network Working Group S. Leonard
Internet-Draft Penango, Inc.
Intended status: Informational November 10, 2014
Expires: May 14, 2015
A Uniform Resource Name (URN) Namespace for XML Namespaces
draft-seantek-xmlns-urn-00
Abstract
XML segregates elements into namespaces, which can be used to mix
tags with different semantics in a composite XML document. XML
namespaces are identified by URIs. This document defines a URN
specifically for identifying XML namespaces.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on May 14, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Leonard Expires May 14, 2015 [Page 1]
Internet-Draft XMLNS URN November 2014
1. Introduction
XML segregates elements into namespaces, which can be used to mix
tags with different semantics in a composite XML document. XML
namespaces are identified by URIs. This document defines a URN
specifically for identifying XML namespaces.
Experience suggests that several URN namespace registrations have
been proposed over the years, where the primary (yet only
occasionally stated) purpose is to create short URIs for the
registrant's XML namespaces. An XML namespace designer now has the
option of choosing a short, memorable identifier without the cost of
maintaining and relying upon a long-lived network location (such as
an HTTP URL), and without the hassle of registering a URN namespace
identifier via IETF Consensus.
A name in the urn:xmlns namespace uniquely and persistently
identifies an abstract XML namespace resource. The abstract resource
does not have any particular concrete representation (such as a type
of content identified by Internet media type), although concrete
representations may be associated with it. Abstract parts of the
abstract resource can be identified with fragment identifiers.
1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.
2. Registration Template
Namespace ID:
xmlns
Registration Information:
Version: 1
Date: 2014-11-10
Declared registrant of the namespace:
IETF
Declaration of syntactic structures:
The structure of the Namespace Specific String is any
valid XML name corresponding to the "Name" production in
Section 2.3 of [XML] (production 5), with the following restrictions:
1. The name MUST be at least four characters.
2. Colons MAY be used as arbitrary intra-name dividers.
3. Colons MUST NOT appear at the beginning or end of the name.
Leonard Expires May 14, 2015 [Page 2]
Internet-Draft XMLNS URN November 2014
4. Consecutive colons are PROHIBITED.
and the following relaxation:
5. The first part of the name preceding the first colon MAY
be a whole decimal number as discussed in
"Process of identifier assignment".
When encoded in a URN, Unicode code points beyond U+007F
are encoded as percent-encoded UTF-8. Conveniently, all XML name
characters in the US-ASCII range are in the [RFC3986] unreserved set.
Relevant ancillary documentation:
[XML].
Identifier uniqueness considerations:
Once a name is registered in the IANA registry, it is unique.
Identifier persistence considerations:
Once a name is registered in the IANA registry, it is permanent.
Process of identifier assignment:
Identifiers are registered with IANA on a First-Come, First-Served
basis. One-character names and prefixes are RESERVED for further
use. Two- and three-character names and prefixes are RESERVED
for language tags and regional codes; however, those names
have no such semantic content when used in an XMLNS URN. Whole
number prefixes are RESERVED for IANA Private Enterprise Numbers.
Registrants are free to register names with reserved two-character
and three-character prefixes, such as "au:flag" or "en:us:ca:lax".
Registrants are also free to register names with reserved whole
number prefixes, such as "20:10-250".
Process for identifier resolution:
The registration for a particular identifier MAY include
any number of URIs that a URN resolver MAY use to resolve
the URN to return specific resources. The registered
URIs are not equivalent to the registered URN, so an XML document
that refers to that particular namespace MUST use the registered
URN as the XML namespace URI.
Fragments (delimited by the # character) are not considered
part of the namespace-specific string, so a fragment would not
affect lexical equivalence. Nevertheless, a urn: URI might be
produced with a fragment component. For compatibility purposes,
a URN resolver SHALL pass any [RFC3986] fragment component in the
urn: URI through to the resolved URI if the registered URI
does not have a fragment component. If the registered URI has
a fragment component, a URN resolver SHALL NOT pass any [RFC3986]
fragment component in the urn: URI; the fragment component
SHALL be ignored.
Leonard Expires May 14, 2015 [Page 3]
Internet-Draft XMLNS URN November 2014
Rules for Lexical Equivalence:
The namespace-specific string (NSS) is compared case sensitively.
Conformance with URN Syntax:
The URN of this namespace conforms to new URN Syntax
[URNBIS], old URN syntax [RFC2141], and Uniform Resource Identifier
(URI): Generic Syntax [RFC3986].
Validation mechanism:
An XMLNS URN may be validated by looking it up in the IANA Registry.
Scope:
Global.
3. IANA Considerations
This document requests the assignment of formal URN namespace ID
"xmlns".
This document requests the creation of an IANA registry called
"urn:xmlns Names". The registry is First-Come, First-Served
[RFC5226]. Each registration shall contain:
a. the name conforming to this document
1) in Unicode characters and
2) with characters beyond U+007F percent-encoded in UTF-8,
b. an optional description,
c. optional [RFC3986] conforming URIs that are not URNs that are to
be used for URN resolution, and
d. contact information for the registrant.
Registrants or their successors may update their entries from time to
time. The registration template SHALL be encoded in UTF-8.
If a registrant attempts to register a name that is confusingly
similar to other registered names (such as only differing by case, or
differing by code points but generating the same or confusingly
similar visual representations), the registrants of the prior names
are to receive a warning notification of the impending registration.
However, there is no protest mechanism; the registration will still
succeed unless withdrawn by the registrant. IANA SHOULD implement a
modern algorithm to detect such confusingly similar names.
Leonard Expires May 14, 2015 [Page 4]
Internet-Draft XMLNS URN November 2014
If a registrant attempts to register a name that contains a whole
number prefix, the registrant of the corresponding IANA Private
Enterprise Number is to receive a warning notification of the
impending registration. However, there is no protest mechanism; the
registration will still succeed unless withdrawn by the registrant.
4. Security Considerations
XML processors use XML namespaces to validate XML content. This
document is not expected to introduce any additional security
considerations beyond those inherent in XML processing.
5. References
5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC
3986, January 2005.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[URNBIS] Saint-Andre, P., "Uniform Resource Name (URN) Syntax",
draft-ietf-urnbis-rfc2141bis-urn-07 (work in progress),
January 2014.
[XML] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, November 2008,
<http://www.w3.org/TR/2008/REC-xml-20081126>.
5.2. Informative References
[RFC2276] Sollins, K., "Architectural Principles of Uniform Resource
Name Resolution", RFC 2276, January 1998.
Leonard Expires May 14, 2015 [Page 5]
Internet-Draft XMLNS URN November 2014
Author's Address
Sean Leonard
Penango, Inc.
5900 Wilshire Boulevard
21st Floor
Los Angeles, CA 90036
USA
Email: dev+ietf@seantek.com
URI: http://www.penango.com/
Leonard Expires May 14, 2015 [Page 6]
