[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: (RFC 2141) 00 01 02 draft-ietf-urnbis-rfc2141bis-urn

IETF                                                      A. Hoenes, Ed.
Internet-Draft                                                    TR-Sys
Obsoletes: 2141 (if approved)                             March 24, 2010
Intended status: Standards Track
Expires: September 25, 2010


                   Uniform Resource Name (URN) Syntax
                       draft-ah-rfc2141bis-urn-00

Abstract

   Uniform Resource Names (URNs) are intended to serve as persistent,
   location-independent, resource identifiers.  This document serves as
   the foundation of the 'urn' URI Scheme according to RFC 3986 and sets
   forward the canonical syntax for URNs, which subdivides URNs into
   "namespaces".  A discussion of both existing legacy and new
   namespaces and requirements for URN presentation and transmission are
   presented.  Finally, there is a discussion of URN equivalence and how
   to determine it.  This document supersedes RFC 2141.

   The requirements and procedures for URN Namespace registration
   documents are currently set forth in RFC 3406, which is also expected
   to be updated by an independent, revised specification soon.

Discussion

   This draft version has been obtained by importing the text from RFC
   2141 into modern tools and making a first round of updating steps.
   It is intended to serve as one of the starting points for an effort
   to bring URN RFCs in alignment with STD 63, STD 68, BCP 26, and the
   requirements from emerging distributed national and international URN
   resolution systems, and advance them on the IETF Standards Track.

   Until a more specific mailing list is established, comments are
   welcome on the uri-review@ietf.org mailing list (or sent to the
   document editor).

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



Hoenes                 Expires September 25, 2010               [Page 1]


Internet-Draft                 URN Syntax                     March 2010


   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 September 25, 2010.

Copyright Notice

   Copyright (c) 2010 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.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.




















Hoenes                 Expires September 25, 2010               [Page 2]


Internet-Draft                 URN Syntax                     March 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Historical Perspective . . . . . . . . . . . . . . . . . .  4
     1.2.  Objective of this RFC  . . . . . . . . . . . . . . . . . .  5
     1.3.  Requirement Language . . . . . . . . . . . . . . . . . . .  5
   2.  URN Syntax . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.1.  Namespace Identifier Syntax  . . . . . . . . . . . . . . .  7
     2.2.  Namespace Specific String Syntax . . . . . . . . . . . . .  7
     2.3.  Special and Reserved Characters  . . . . . . . . . . . . .  9
       2.3.1.  Delimiter Characters . . . . . . . . . . . . . . . . .  9
       2.3.2.  The '%' character  . . . . . . . . . . . . . . . . . . 10
       2.3.3.  Other Excluded Characters  . . . . . . . . . . . . . . 10
   3.  Support of Existing Legacy Naming Systems and New Naming
       Systems  . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   4.  URN Presentation and Transport . . . . . . . . . . . . . . . . 11
   5.  Lexical Equivalence in URNs  . . . . . . . . . . . . . . . . . 11
     5.1.  Examples of Lexical Equivalence  . . . . . . . . . . . . . 12
   6.  Functional Equivalence in URNs . . . . . . . . . . . . . . . . 12
   7.  The 'urn' URI Scheme . . . . . . . . . . . . . . . . . . . . . 12
     7.1.  Registration of URI Scheme 'urn' . . . . . . . . . . . . . 12
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 15
     11.2. Informative References . . . . . . . . . . . . . . . . . . 15
   Appendix A.  How to Locate IETF Documents (Informative)  . . . . . 17
   Appendix B.  Handling of URNs by URL Resolvers/Browsers  . . . . . 17
   Appendix C.  Collected ABNF (Informative)  . . . . . . . . . . . . 17
   Appendix D.  Changes since RFC 2141 (Informative)  . . . . . . . . 18
     D.1.  Essential Changes from RFC 2141  . . . . . . . . . . . . . 18
     D.2.  Changes from RFC 2141 to draft -00 . . . . . . . . . . . . 18


















Hoenes                 Expires September 25, 2010               [Page 3]


Internet-Draft                 URN Syntax                     March 2010


1.  Introduction

   'urn' is a particular URI Scheme (according to STD 63, RFC 3986
   [RFC3986] and BCP 35, RFC 4395 [RFC4395]) that is dedicated to
   forming a hierarchical framework for persistent identifiers.

   Uniform Resource Names (URNs) are intended to serve as persistent,
   location-independent, resource identifiers and are designed to make
   it easy to map other namespaces (which share the properties of URNs)
   into URI-space.  Therefore, the URN syntax provides a means to encode
   character data in a form that can be sent in existing protocols,
   transcribed on most keyboards, etc.

   The first level of hierarchy is given by the classification of URIs
   into "URI Schemes", and for URNs, the second level is organized into
   "URN Namespaces".

1.1.  Historical Perspective

   For the intended audience of this RFC, which is expected to include
   groups interested in persistent identifiers in general and not in
   continuous contact with the IETF and the RFC series, this section
   gives a brief outline of the evolution of the matter over time.
   Appendix A gives hints on how to obtain RFCs and related information.

   Attempts to define generally applicable identifiers for network
   resources go back to the mid-1970 years.  Among the applicable RFCs
   is RFC 615 [RFC0615], which subsequently has been obsoleted by
   RFC 645 [RFC0645].

   The seminal document in the RFC series regarding URIs (Uniform
   Resource Identifiers) for use with the WWW has been RFC 1630
   [RFC1630], published in 1994.  In the same year, the general concept
   or Uniform Resource Names has been laid down in RFC 1737 [RFC1737].
   and that of Uniform Resource Locators in RFC 1736 [RFC1736].

   The original formal specification of URN Syntax, RFC 2141 [RFC2141]
   has been adopted in 1997.  This document was based on the original
   specification of URLs (Uniform Resource Locators) in RFC 1738
   [RFC1738] and RFC 1808 [RFC1808], which later on, in 1998, has been
   generalized and consolidated in the Generic URI specification, RFC
   2396 [RFC2396].  Most parts of these URI/URL documents have been
   superseded in 2005 by STD 63, RFC 3986 [RFC3986].

   Over time, the terms "URI", "URL", and "URN" have been refined and
   slightly shifted according to emerging insight and use.  This has
   been clarified in a joint effort of the IETF and the World Wide Web
   Council, published for the IETF in RFC 3305 [RFC3305].



Hoenes                 Expires September 25, 2010               [Page 4]


Internet-Draft                 URN Syntax                     March 2010


   The wealth of URI Schemes and URN Namespaces needs to be organized in
   a persistent way, in order to guide application developers and users
   to the standardized top level branches and the related
   specifications.  These registries are maintained by the Internet
   Assigned Numbers Authority (IANA) [IANA] at [IANA-URI] and
   [IANA-URN], respectively.  Registration procedures for URI Schemes
   originally had been laid down in RFC 2717 [RFC2717] and guidelines
   for the related specification documents were given in RFC 2718
   [RFC2718].  These documents have been obsoleted and consolidated into
   BCP 35, RFC 4395 [RFC4395], which is based on, and aligned with, RFC
   3986.  Similarly, the URN Namespace definition and registration
   mechanisms originally have been specified in RFC 2611 [RFC2611],
   which has been obsoleted by BCP 66, RFC 3406 [RFC3406].  Guidelines
   for documents prescribing IANA procedures have been revised as well
   over the years, and at the time of this writing, BCP 26, RFC 5226
   [RFC5226] is the normative document.  Neither RFC 4395 nor RFC 3406
   conform with RFC 5226.

   Over the years, the IETF has shifted to the use of a predominant
   formal language used to define the syntax of textual protocol
   elements, Augmented Backus-Naur Form (ABNF).  The specification of
   ABNF also has evolved and now STD 68, RFC 5234 [RFC5234] is the
   normative document (that also will be used in this RFC).

1.2.  Objective of this RFC

   RFC 2141 does not seamlessly match current Internet Standards.  The
   primary objective of this document is the alignment with the URI
   Standard [RFC3986] and guidelines [RFC4395], the ABNF Standard
   [RFC5234] and the current IANA Guidelines [RFC5226] in general.

   Further, experience from emerging international efforts to establish
   a general, distributed, stable URN resolution service are expected to
   be taken into account during the draft stage of this document.

   Thus, this replacement document for RFC 2141 should make it possible
   to advance the URN framework step by step on the Internet Standard
   maturity ladder.  All other related documents depend on it; therefore
   this is the first step to undertake.

   Out of scope for this document is a revision of the URN Namespace
   Definition Mechanisms document, BCP 66 [RFC3406].

1.3.  Requirement 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 [RFC2119].



Hoenes                 Expires September 25, 2010               [Page 5]


Internet-Draft                 URN Syntax                     March 2010


2.  URN Syntax

   This document defines the URI Scheme 'urn'.  Hence, URNs are specific
   URIs as specified in RFC 3986 [RFC3986].  Syntax definitions below
   are given in ABNF according to RFC 5234 [RFC5234] and make use of
   some "Core Rules" specified in Appendix B of that Standard and
   generic rules defined in Appendix A of RFC 3986.

   The syntax definitions below do, and syntax definitions in dependent
   documents MUST, conform to the URN syntax specified in RFC 3986, in
   the sense that additional syntax rules must only constrain the
   general rules from RFC 3986.  In other words: a general URI parser
   based on RFC 3986 MUST be able to parse any legal URN, and specific
   semantics can be obtained from URN-specific parsing.

      NOTE: The remainder of this section still requires MUCH work!

   URNs conform to the <path-rootless> variant of the general URI syntax
   specifed in Section 3 of [RFC3986] :

      URI = scheme ":" path-rootless [ "?" query ] [ "#" fragment ]

      path-rootless = segment-nz *( "/" segment )

      segment-nz    = 1*pchar
      segment       = *pchar

      pchar = unreserved / pct-encoded / sub-delims / ":" / "@"

   with

      scheme     = "urn"

   and the following additional syntax rule superimposed on <path-
   rootless> to establish a level of hierarchy called "Namespace":

      urn-path   = NID ":" NSS

   Here "urn" is the URI scheme name, <NID> is the Namespace Identifier,
   and <NSS> is the Namespace Specific String.  The colons are REQUIRED
   separator characters.

   Per RFC 3986, the URN Scheme name (here "urn") is case-insensitive.

   The Namespace ID (also a case-insensitive string) determines the
   syntactic structure and the semantic interpretation of the Namespace
   Specific String.  Generic details on NID syntax can be found below
   in Section 2.1 and the NSS syntax is elaborated upon in Section 2.2.



Hoenes                 Expires September 25, 2010               [Page 6]


Internet-Draft                 URN Syntax                     March 2010


   Each particular namespace is based on a specific document that must
   normatively describe (among other things) the details of the <NSS>
   values allowed in conjunction with the respective <NID>.  The
   specification requirements and registration procedures for URN
   namespaces are the subject of a dedicated document, currently RFC
   3406 [RFC3406].

   Note:
      RFC 2141 has deferred the decision on whether <query> and
      <fragment> components are applicable to URNs and reserved the use
      of bare (unencoded) question mark ("?") and hash ("#") characters
      in URNs.

      There is evidence of desire to be able to use these components in
      URNs, and thus this draft version tentatively aims at allowing
      these in the general syntax.  These components however are only
      allowed if and only if the specification document for a particular
      URN namespace specifically does say so.

2.1.  Namespace Identifier Syntax

   The following is the syntax for the Namespace Identifier.  To (a) be
   consistent with all potential resolution schemes and (b) not put any
   undue constraints on any potential resolution scheme, Namespace
   Identifiers are ASCII strings with the syntax:

      NID = ( ALPHA / DIGIT ) 0*31 ( ALPHA / DIGIT / "-" )

   Namespace Identifiers are case-insensitive, so that for instance
   "ISBN" and "isbn" refer to the same namespace.

   To avoid confusion with the URI Scheme name "urn", the NID "urn" is
   permanently reserved by this RFC and MUST NOT be used.

2.2.  Namespace Specific String Syntax

   As already required by RFC 1737, there is a single canonical
   representation of the NSS portion of an URN.

      Note:  If the DISCUSSes above and below can be affirmed (allowing
      optional <question> and <fragment> components as well as "&" and
      "~" in the path), the syntax could be simplified very much to:

         NSS   = 1*pchar   ; or equivalent:    NSS   = segment-nz

   The format of this single canonical form follows:





Hoenes                 Expires September 25, 2010               [Page 7]


Internet-Draft                 URN Syntax                     March 2010


         NSS         = 1*URN-char

         URN-char    = trans / pct-encoded

         trans       = ALPHA / DIGIT / u-other
    ; NO?            / reserved
    ; Issue: This lead to ambiguity in RFC 2141 wrt "%".

         u-other     = ":" / "@"
                       ; those from RFC 3986 <gen-delims>
                       ; specifically allowed in <pchar>.
    ; From RFC 3986:
    ;    gen-delims  = ":" / "/" / "?" / "#" / "[" / "]" / "@"

                     / "!" / "$" /       "'" / "(" / ")"
                     / "*" / "+" / "," / ";" / "="
                       ; this is RFC 3986 <sub-delims> except "&".
    ; From RFC 3986:
    ;    sub-delims  = "!" / "$" / "&" / "'" / "(" / ")"
    ;                / "*" / "+" / "," / ";" / "="
    ; Issue: can/should "&" be allowed ?
    ; If we allow <question> and <fragment> according to the
    ; generic URI syntax, there seems to be no more need to exclude "&".

                     / "-" / "." / "_"   ; <unreserved> except "~"
    ; From RFC 3986:
    ;    unreserved  = ALPHA / DIGIT
    ;                / "-" / "." / "_" / "~"
    ; Issue: can/should "~" be allowed as well ?

    ; If we allow "&" and "~" , <trans> becomes <pchar> ,
    ; greatly simplifying the syntax rules and parsers!

    ; from RFC 2141:
    ;    reserved  = '%" / "/" / "?" / "#"         ; SIC!

   Depending on the rules governing a namespace, valid identifiers in a
   namespace might contain characters that are not members of the URN
   character set above (<URN-char>).  Such strings MUST be translated
   into canonical NSS format before using them as protocol elements or
   otherwise passing them on to other applications.  Translation is done
   by encoding each character outside the URN character set as a
   sequence of octets using UTF-8 encoding [RFC3629], and the "percent-
   encoding" of each of those octets as "%" followed by two <HEXDIG>
   characters.  The two characters give the hexadecimal representation
   of that octet.





Hoenes                 Expires September 25, 2010               [Page 8]


Internet-Draft                 URN Syntax                     March 2010


2.3.  Special and Reserved Characters

   The remaining printable characters left to be discussed above
   comprise the generic delimiters and the reserved characters, which
   are restricted for special use only.  These characters are discussed
   below, giving the specifics of why each character is special or
   reserved.

2.3.1.  Delimiter Characters

   RFC 3986 [RFC3986] defines the general delimiter characters used in
   URIs:

      gen-delims = ":" / "/" / "?" / "#" / "[" / "]" / "@"

   From among the <gen-delims>, ":" and "@" are also included in <pchar>
   and hence allowed in the path components of URIs.

   The at-character ("@") in generic URIs only has a specific meaning
   when contained in the <authority> part, which is absent in URNs.
   Hence, "@" is available in the <NSS> part of URNs.

   With URNs, the colon (":") is used as a delimiter character not only
   between the scheme name ("urn") and the <NID>, but also between the
   latter and the <NSS>, and many existing URN namespaces additionally
   use ":" to further subdivide a single RFC 3986 path segment in the
   <NSS> in a hierarchical manner.

   Note: Using ":" as a sub-delimiter in the path in favor of "/" is
   attractive because it avoids possible complications that could arise
   from the inappropriate use of relative URI references [RFC3986] for
   URNs.

   The characters "/", "?", and "#" separate path components and the
   <question> and <fragment> parts in the generic URI syntax; they are
   restricted to this role in URNs as well, although the <path> in URNs
   only admits a single <segment> and hence "/" is not allowed.
   Therefore, these characters MUST NOT appear in the <NSS> part of a
   URN in unencoded form.  Namespaces that need these characters MUST
   employ in their URNs the appropriate percent-encoding for each
   character.

   The square brackets ("[" and "]") also play a particular role when
   contained in the <authority> part, which is absent in URNs.  However,
   for conformance with the generic URI syntax, they are not allowed
   literally in the <NSS> component of URNs.  If a specific URN
   namespace reflects semantics that require these characters, they MUST
   be percent-encoded in the respective URNs.



Hoenes                 Expires September 25, 2010               [Page 9]


Internet-Draft                 URN Syntax                     March 2010


2.3.2.  The '%' character

   The "%" character is reserved in the URN syntax for introducing the
   escape sequence for an octet that is either not a printable ASCII
   character or reserved for special purposes, as described in this
   section.  Literal use of the "%" character in a namespace must be
   encoded as "%25" in URNs for that namespace.  The presence of a "%"
   character in a URN MUST always be followed by two <HEXDIG>
   characters, which three together semanticaly form an abstract <pct-
   encoded> octet.

   Namespaces MAY designate one or more characters from the URN
   character set as having special meaning for that namespace.  If the
   namespace also uses that character in a literal sense as well, the
   character used in a literal sense MUST be encoded with "%" followed
   by the hexadecimal representation of that octet.  Further, a
   character MUST NOT be percent-encoded if the character is not a
   reserved character.  Therefore, the process of registering a
   namespace identifier shall include publication of a definition of
   which characters have a special meaning to that namespace.

2.3.3.  Other Excluded Characters

   The following list is included only for the sake of completeness.  It
   includes the characters discussed in Sections 2.3.1 and 2.3.2.  Any
   octets/characters on this list are explicitly NOT part of the URN
   <NSS> character set, and if used in an URN, MUST be percent-encoded.

              excluded = CTL / SP        ; control characters and space
                       / DQUOTE          ; "
                       / "#"             ; from <gen-delims>
                       / "%"             ; see above
      ; DISCUSS!       / "&"             ; DISCUSS -- see above!
                       / "/"             ; from <gen-delims>
                       / "<" / ">"
                       / "?"             ; from <gen-delims>
                       / "["             ; from <gen-delims>
                       / "\"
                       / "]"             ; from <gen-delims>
                       / "^"
                       / "`"
                       / "{" / "|" / "}"
      ; DISCUSS!       / "~"             ; DISCUSS -- see above!
                       / %x7F            ; DEL (control character)
                       / %x80-FF         ; non-ASCII

   In addition, the NUL octet (0 hex) SHOULD never be used, in either
   unencoded or percent-encoded form.



Hoenes                 Expires September 25, 2010              [Page 10]


Internet-Draft                 URN Syntax                     March 2010


   A URN ends when an octet/character from the excluded character set
   (<excluded>) is encountered.  The character from the excluded
   character set is NOT part of the URN.

   [ Does that still make sense? -- it collides with possible question /
     fragment! ]

3.  Support of Existing Legacy Naming Systems and New Naming Systems

   Any namespace (existing or newly-devised) that is proposed as an URN-
   namespace and fulfills the criteria of URN-namespaces MUST be
   expressed in this syntax.  If names in these namespaces contain
   characters other than those defined for the URN character set, they
   MUST be translated into canonical form as discussed in Section 2.2.

4.  URN Presentation and Transport

   The URN syntax defines the canonical format for URNs and all URN
   transport and interchanges MUST take place in this format.  Further,
   all URN-aware applications MUST offer the option of displaying URNs
   in this canonical form to allow for direct transcription (for example
   by cut and paste techniques).  Such applications MAY support display
   of URNs in a more human-friendly form and may use a character set
   that includes characters that aren't permitted in URN syntax as
   defined in this RFC (that is, they may replace %-notation by
   characters in some extended character set in display to humans).

5.  Lexical Equivalence in URNs

   For various purposes such as caching, it is often desirable to
   determine whether two URNs are the same without resolving them.  The
   general purpose means of doing so is by testing for "lexical
   equivalence" as defined below.

   Two URNs are lexically equivalent if they are octet-by-octet equal
   after the following preprocessing:
      1. normalize the case of the leading "urn" scheme;
      2. normalize the case of the NID;
      3. normalizing the case of any percent-encoding.
   Note that percent-encoding MUST NOT be removed.

   Some namespaces may define additional lexical equivalences, such as
   case-insensitivity of the NSS (or parts thereof).  Additional lexical
   equivalences MUST be documented as part of namespace registration,
   MUST always have the effect of eliminating some of the false
   negatives obtained by the procedure above, and MUST NEVER say that
   two URNs are not equivalent if the procedure above says they are
   equivalent.



Hoenes                 Expires September 25, 2010              [Page 11]


Internet-Draft                 URN Syntax                     March 2010


5.1.  Examples of Lexical Equivalence

   The following URN comparisons highlight the lexical equivalence
   definitions:

      1- URN:foo:a123,456
      2- urn:foo:a123,456
      3- urn:FOO:a123,456
      4- urn:foo:A123,456
      5- urn:foo:a123%2C456
      6- URN:FOO:a123%2c456

   URNs 1, 2, and 3 are all lexically equivalent.  URN 4 is not
   lexically equivalent to any of the other URNs of the above set.
   URNs 5 and 6 are only lexically equivalent to each other.

6.  Functional Equivalence in URNs

   Functional equivalence is determined by practice within a given
   namespace and managed by resolvers for that namespace.  Thus, it is
   beyond the scope of this document.  Namespace registrations must
   include guidance on how to determine functional equivalence for that
   namespace, i.e. when two URNs are identical within a namespace.

7.  The 'urn' URI Scheme

   At the time of publication of RFC 2141, no formal registration
   procedure for URI Schemes had been established yet, and so IANA only
   informally has registered the 'urn' URI Scheme with a reference to
   [RFC2141].

   Section 7.1 below contains the URI scheme registration template for
   the 'urn' scheme, in accordance with RFC 4395 [RFC4395].

7.1.  Registration of URI Scheme 'urn'

   [ RFC Editor: please replace "XXXX" in all instances of "RFC XXXX"
     below by the RFC number assigned to this document. ]

   URI scheme name:  urn

   Status:  permanent

   URI scheme syntax:

      See Section 2 of RFC XXXX.





Hoenes                 Expires September 25, 2010              [Page 12]


Internet-Draft                 URN Syntax                     March 2010


   URI scheme semantics:

      'urn' URIs, known as Universal Resource Names (URNs), serve as
      persistent, location-independent, resource identifiers for
      concrete and abstract objects that have network accessible
      instances and/or metadata.

      URNs are structured hierarchically into URN Namespaces the
      management of which is delegated to namespace-specific
      authorities.  Each such URN namespace is founded in an independent
      specification and registered with IANA, following the guidelines
      and procedures of BCP 66 (at the time of this registration: RFC
      3406 [RFC3406]).

   Encoding considerations:

      All URNs are ASCII strings conforming to the general URI syntax
      from STD 66.  As described in Sections 2.2 and 2.3.2 of RFC XXXX,
      characters needed by the URN namespace specific semantics but not
      contained in the US-ASCII charset MUST be encoded in UTF-8
      according to STD 63; any octets outside the allowed character set
      MUST then be percent-encoded.

   Applications/protocols that use this URI scheme:

      URNs that serve to identify abstract resources for protocol
      purposes are expected to be recognized directly by the
      implementations of these portocols.

      In general, resolution systems for URNs are specified on a per-
      namespace basis.  If appropriate for the namespace, these systems
      resolve URNs to (possibly multiple) URIs that allow the network
      access to the identified object or metadata on it.

      "Architectural Principles of Uniform Resource Name Resolution"
      (RFC 2276) explains the basic concepts.  Some resolution systems
      laid down in IETF specifications are:

      *  Trivial HTTP-based URN Resolution (RFC 2169)

      *  Dynamic Delegation Discovery System (DDDS, RFCs 3401-3404)

      *  Service Location Protocol (SLPv2, RFC 2608)

   Interoperability Considerations:

      Persistence and stability of URNs require appropriate resolution
      systems.



Hoenes                 Expires September 25, 2010              [Page 13]


Internet-Draft                 URN Syntax                     March 2010


   Security Considerations:

      See Section 8 of RFC XXXX.

   Contact:

      Provisionally: the authors of this draft.
      This registration will be discussed on the following IETF lists:
      uri-review and urn-nid.
      It is expected that a "urnbis" WG be formed in the IETF and take
      over control of this document, and that subsequently the Chairs
      and mailing list of that WG serve as the primary contact.

   Author / Change controller:

      The authors of this draft.
      Change control is with the IESG.

   References:

      RFC XXXX.

      Procedures for the specification and registration of URN
      namespaces are detailed in BCP 66 (at the time of this writing:
      RFC 3406; a rfc3406-bis document is expected as a deliverable of
      the planned "urnbis" WG).

8.  Security Considerations

   This document specifies the syntax for URNs.  As such, the general
   security considerations of STD 66 [RFC3986] apply.  However, each URN
   namespace will have specific security considerations.  While some
   namespaces may assign special meaning to certain of the characters of
   the Namespace Specific String, any security consideration resulting
   from such assignment are outside the scope of this document.  It is
   REQUIRED by BCP 66 [RFC3406] that the process of registering a
   namespace identifier include any such considerations.

9.  IANA Considerations

   IANA is asked to update the existing informal registration of the
   'urn' URI Scheme using the template in Section 7.1 above and list
   this RFC as the current normative reference in [IANA-URI].

   IANA is asked to add a note to [IANA-URN] that 'urn' is a permanently
   reserved formal namespace identifier string that cannot be
   registered, in order to avoid confusion with the 'urn' URI scheme.




Hoenes                 Expires September 25, 2010              [Page 14]


Internet-Draft                 URN Syntax                     March 2010


10.  Acknowledgements

   This document is heavily based on RFC 2141, which contained the
   following Acknowledgements:

      Thanks to various members of the URN working group for comments on
      earlier drafts of this document.  This document is partially
      supported by the National Science Foundation, Cooperative
      Agreement NCR-9218179.

   This document also heavily relies on and acknowledges the work done
   for STD 66 [RFC3986].

   Your name could go here ...

11.  References

11.1.  Normative References

   [RFC2119]   Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC3629]   Yergeau, F., "UTF-8, a transformation format of ISO
               10646", STD 63, RFC 3629, November 2003.

   [RFC3986]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
               Resource Identifier (URI): Generic Syntax", STD 66,
               RFC 3986, January 2005.

   [RFC4395]   Hansen, T., Hardie, T., and L. Masinter, "Guidelines and
               Registration Procedures for New URI Schemes", BCP 35,
               RFC 4395, February 2006.

   [RFC5234]   Crocker, D. and P. Overell, "Augmented BNF for Syntax
               Specifications: ABNF", STD 68, RFC 5234, January 2008.

11.2.  Informative References

   [IANA]      IANA, "The Internet Assigned Numbers Authority",
               <http://www.iana.org/>.

   [IANA-URI]  IANA, "URI Schemes Registry",
               <http://www.iana.org/assignments/uri-schemes/>.

   [IANA-URN]  IANA, "URN Namespace Registry",
               <http://www.iana.org/assignments/urn-namespaces/>.

   [RFC0615]   Crocker, D., "Proposed Network Standard Data Pathname
               syntax", RFC 615, March 1974.


Hoenes                 Expires September 25, 2010              [Page 15]


Internet-Draft                 URN Syntax                     March 2010


   [RFC0645]   Crocker, D., "Network Standard Data Specification
               syntax", RFC 645, June 1974.

   [RFC1630]   Berners-Lee, T., "Universal Resource Identifiers in WWW:
               A Unifying Syntax for the Expression of Names and
               Addresses of Objects on the Network as used in the World-
               Wide Web", RFC 1630, June 1994.

   [RFC1736]   Kunze, J., "Functional Recommendations for Internet
               Resource Locators", RFC 1736, February 1995.

   [RFC1737]   Sollins, K. and L. Masinter, "Functional Requirements for
               Uniform Resource Names", RFC 1737, December 1994.

   [RFC1738]   Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
               Resource Locators (URL)", RFC 1738, December 1994.

   [RFC1808]   Fielding, R., "Relative Uniform Resource Locators",
               RFC 1808, June 1995.

   [RFC2141]   Moats, R., "URN Syntax", RFC 2141, May 1997.

   [RFC2396]   Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
               Resource Identifiers (URI): Generic Syntax", RFC 2396,
               August 1998.

   [RFC2611]   Daigle, L., van Gulik, D., Iannella, R., and P.
               Faltstrom, "URN Namespace Definition Mechanisms", BCP 33,
               RFC 2611, June 1999.

   [RFC2717]   Petke, R. and I. King, "Registration Procedures for URL
               Scheme Names", BCP 35, RFC 2717, November 1999.

   [RFC2718]   Masinter, L., Alvestrand, H., Zigmond, D., and R. Petke,
               "Guidelines for new URL Schemes", RFC 2718,
               November 1999.

   [RFC3305]   Mealling, M. and R. Denenberg, "Report from the Joint
               W3C/IETF URI Planning Interest Group: Uniform Resource
               Identifiers (URIs), URLs, and Uniform Resource Names
               (URNs): Clarifications and Recommendations", RFC 3305,
               August 2002.

   [RFC3406]   Daigle, L., van Gulik, D., Iannella, R., and P.
               Faltstrom, "Uniform Resource Names (URN) Namespace
               Definition Mechanisms", BCP 66, RFC 3406, October 2002.

   [RFC5226]   Narten, T. and H. Alvestrand, "Guidelines for Writing an



Hoenes                 Expires September 25, 2010              [Page 16]


Internet-Draft                 URN Syntax                     March 2010


               IANA Considerations Section in RFCs", BCP 26, RFC 5226,
               May 2008.

Appendix A.  How to Locate IETF Documents (Informative)

   Request For Comments (RFCs) are available from the RFC Editor site
   using the canonical URIs <http://www.rfc-editor.org/rfc/rfcNNNN.txt>
   or <ftp://ftp.rfc-editor.org/in-notes/rfcNNNN.txt> (where 'NNNN' is
   the serial number of the RFC), and from numerous mirror sites.
   Additional metadata for any RFC, including possible Errata, are
   available from <http://www.rfc-editor.org/info/rfcNNNN> (where 'NNNN'
   again is the serial number of the RFC).  A HTML-ized version of each
   RFC and a PDF facsimile are available from the IETF Tools site at
   <http://tools.ietf.org/http/rfcNNNN> and
   <http://tools.ietf.org/pdf/rfcNNNN>, respectively.

   Current Internet Draft documents are available via the search engines
   at <http://www.ietf.org/id-info/> and
   <http://www.rfc-editor.org/idsearch.html>; archival copies of older
   IETF documents can be found at <http://tools.ietf.org/id/>.

Appendix B.  Handling of URNs by URL Resolvers/Browsers

   The URN syntax has been defined so that URNs can be used in places
   where URLs are expected.  A resolver that conforms to the current URI
   syntax specification [RFC3986] will extract a scheme value of "urn"
   rather than a scheme value of "urn:<nid>".

   An URN MUST be considered an opaque URI by URL resolvers and passed
   (with the "urn:" tag) to an URN resolver for resolution.  The URN
   resolver can either be an external resolver that the URL resolver
   knows of, or it can be functionality built into the URL resolver.

   To avoid confusion of users, an URL browser SHOULD display the
   complete URN (including the "urn:" tag) to ensure that there is no
   confusion between URN namespace identifiers and URI scheme
   identifiers.

Appendix C.  Collected ABNF (Informative)

   As a service to implementers specifically interested in URN syntax,
   after consolidation of Section 2, the complete ABNF for URNs will be
   collected here, including the referenced rules from [RFC5234] and
   [RFC3986].  In case of (unexpected) inconsistencies, these documents
   remain normative for the respective productions.

   T.B.D.

   ...


Hoenes                 Expires September 25, 2010              [Page 17]


Internet-Draft                 URN Syntax                     March 2010


Appendix D.  Changes since RFC 2141 (Informative)

D.1.  Essential Changes from RFC 2141

   [ RFC Editor: please remove the Appendix D.1 headline and all
   subsequent subsections starting with Appendix D.2. ]

   T.B.D.

D.2.  Changes from RFC 2141 to draft -00

   T.B.D.

Author's Address

   Alfred Hoenes (editor)
   TR-Sys
   Gerlinger Str. 12
   Ditzingen  D-71254
   Germany

   EMail: ah@TR-Sys.de





























Hoenes                 Expires September 25, 2010              [Page 18]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/