draft-ietf-urn-syntax-02.txt   draft-ietf-urn-syntax-03.txt 
Internet-Draft Ryan Moats Internet-Draft Ryan Moats
draft-ietf-urn-syntax-02.txt AT&T draft-ietf-urn-syntax-03.txt AT&T
Expires in six months January 1997
URN Syntax URN Syntax
Filename: draft-ietf-urn-syntax-02.txt Filename: draft-ietf-urn-syntax-03.txt
Status of This Memo Status of This Memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its documents of the Internet Engineering Task Force (IETF), its
areas, and its working groups. Note that other groups may also areas, and its working groups. Note that other groups may also
distribute working documents as Internet-Drafts. distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other months and may be updated, replaced, or obsoleted by other
skipping to change at page 1, line 31 skipping to change at page 1, line 29
in progress.'' in progress.''
To learn the current status of any Internet-Draft, please check To learn the current status of any Internet-Draft, please check
the ``1id-abstracts.txt'' listing contained in the Internet- the ``1id-abstracts.txt'' listing contained in the Internet-
Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
(Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
Coast), or ftp.isi.edu (US West Coast). Coast), or ftp.isi.edu (US West Coast).
Abstract Abstract
Uniform Resource Names (URNs) are intended to serve as persistent Uniform Resource Names (URNs) are intended to serve as persistent,
resource identifiers. This document sets forward the canonical syntax location-independent, resource identifiers. This document sets
for URNs. A discussion of both existing legacy and new namespaces forward the canonical syntax for URNs. A discussion of both existing
and requirements for URN presentation and transmission are presented. legacy and new namespaces and requirements for URN presentation and
Finally, there is a discussion of URN equivalence and how to transmission are presented. Finally, there is a discussion of URN
determine it. equivalence and how to determine it.
1. Introduction 1. Introduction
Uniform Resource Names (URNs) are intended to serve as persistent Uniform Resource Names (URNs) are intended to serve as persistent,
resource identifiers and are designed to make it easy to map other location-independent, resource identifiers and are designed to make
namespaces (which share the properties of URNs) into URN-space. it easy to map other namespaces (which share the properties of URNs)
Therefore, the URN syntax provides a means to encode character data into URN-space. Therefore, the URN syntax provides a means to encode
in a form that can be sent in existing protocols, transcribed on most character data in a form that can be sent in existing protocols,
keyboards, etc. transcribed on most keyboards, etc.
2. Syntax 2. Syntax
All URNs have the following syntax (phrases enclosed in quotes are All URNs have the following syntax (phrases enclosed in quotes are
REQUIRED): REQUIRED):
<URN> ::= "urn:" <NID> ":" <NSS> <URN> ::= "urn:" <NID> ":" <NSS>
where <NID> is the Namespace Identifier, and <NSS> is the Namespace where <NID> is the Namespace Identifier, and <NSS> is the Namespace
Specific String. The leading "urn:" sequence is case-insensitive. Specific String. The leading "urn:" sequence is case-insensitive.
skipping to change at page 2, line 31 skipping to change at page 2, line 31
acceptable syntax for both the Namespace Identifier and the Namespace acceptable syntax for both the Namespace Identifier and the Namespace
Specific String separately. Specific String separately.
2.1 Namespace Identifier Syntax 2.1 Namespace Identifier Syntax
The following is the syntax for the Namespace Identifier. To (a) be The following is the syntax for the Namespace Identifier. To (a) be
consistent with all potential resolution schemes and (b) not put any consistent with all potential resolution schemes and (b) not put any
undue constraints on any potential resolution scheme, the syntax for undue constraints on any potential resolution scheme, the syntax for
the Namespace Identifier is: the Namespace Identifier is:
<NID> ::= <let-num> [ *<let-num-hyp> ] <NID> ::= <let-num> [ 1,31<let-num-hyp> ]
<let-num-hyp> ::= <upper> | <lower> | <number> | "-" <let-num-hyp> ::= <upper> | <lower> | <number> | "-"
<let-num> ::= <upper> | <lower> | <number> <let-num> ::= <upper> | <lower> | <number>
<upper> ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | <upper> ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" |
"I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" | "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" |
"Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" | "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" |
"Y" | "Z" "Y" | "Z"
skipping to change at page 3, line 27 skipping to change at page 3, line 27
<NSS> ::= 1*<URN chars> <NSS> ::= 1*<URN chars>
<URN chars> ::= <trans> | "%" <hex> <hex> <URN chars> ::= <trans> | "%" <hex> <hex>
<trans> ::= <upper> | <lower> | <number> | <other> | <reserved> <trans> ::= <upper> | <lower> | <number> | <other> | <reserved>
<hex> ::= <number> | "A" | "B" | "C" | "D" | "E" | "F" | <hex> ::= <number> | "A" | "B" | "C" | "D" | "E" | "F" |
"a" | "b" | "c" | "d" | "e" | "f" "a" | "b" | "c" | "d" | "e" | "f"
<other> ::= "(" | ")" | "+" | "," | "-" | "." | <other> ::= "(" | ")" | "+" | "," | "-" | "." |
":" | "=" | "?" | "@" | ";" | "$" | ":" | "=" | "@" | ";" | "$" |
"_" | "!" | "~" | "*" | "'" "_" | "!" | "*" | "'"
Depending on the rules governing a namespace, valid identifiers in a Depending on the rules governing a namespace, valid identifiers in a
namespace might contain characters that are not members of the URN namespace might contain characters that are not members of the URN
character set above (<URN chars>). Such strings MUST be translated character set above (<URN chars>). Such strings MUST be translated
into canonical NSS format before using them as protocol elements or into canonical NSS format before using them as protocol elements or
otherwise passing them on to other applications. Translation is done otherwise passing them on to other applications. Translation is done
by encoding each character outside the URN character set as a by encoding each character outside the URN character set as a
sequence of one to six octets using UTF-8 encoding, and the encoding sequence of one to six octets using UTF-8 encoding, and the encoding
of each of those octets as "%" followed by two characters from the of each of those octets as "%" followed by two characters from the
<hex> character set above. The two characters give the hexadecimal <hex> character set above. The two characters give the hexadecimal
skipping to change at page 3, line 50 skipping to change at page 3, line 50
2.3 Reserved characters 2.3 Reserved characters
The remaining character set left to be discussed above is the The remaining character set left to be discussed above is the
reserved character set, which contains various characters reserved reserved character set, which contains various characters reserved
from normal use. The reserved character set follows, with a from normal use. The reserved character set follows, with a
discussion on the specifics of why each character is reserved. discussion on the specifics of why each character is reserved.
The reserved character set is: The reserved character set is:
<reserved> ::= "/" | "%" <reserved> ::= '%" | "/" | "?" | "#"
2.3.1 The "%" character 2.3.1 The "%" character
The "%" character is reserved in the URN syntax for introducing the The "%" character is reserved in the URN syntax for introducing the
escape sequence for an octet. Literal use of the "%" character in a escape sequence for an octet. Literal use of the "%" character in a
namespace must be encoded using "%25" in URNs for that namespace. namespace must be encoded using "%25" in URNs for that namespace.
The presence of an "%" character in an URN MUST be followed by two The presence of an "%" character in an URN MUST be followed by two
characters from the <hex> character set. characters from the <hex> character set.
Namespaces MAY designate one or more characters from the URN Namespaces MAY designate one or more characters from the URN
character set as having special meaning for that namespace. If the character set as having special meaning for that namespace. If the
namespace also uses that character in a literal sense as well, the namespace also uses that character in a literal sense as well, the
character used in a literal sense MUST be encoded with "%" followed character used in a literal sense MUST be encoded with "%" followed
by the hexadecimal representation of that octet. Therefore, the by the hexadecimal representation of that octet. Further, a
process of registering a namespace identifier shall include character MUST NOT be "%"-encoded if the character is not a reserved
publication of a definition of which characters have a special character. Therefore, the process of registering a namespace
meaning to that namespace. identifier shall include publication of a definition of which
characters have a special meaning to that namespace.
2.3.2 The "/" character 2.3.2 The other reserved characters
The "/" character is RESERVED for future developments. It might be RFC 1630 [2] reserves the characters "/", "?", and "#" for particular
used for denoting hierarchy to allow for relative URN processing, but purposes. The URN-WG has not yet debated the applicability and
the WG has not yet reached consensus on this, so such developments precise semantics of those purposes as applied to URNs. Therefore,
will be documented separately. Meanwhile, namespace developers these characters are RESERVED for future developments. Namespace
SHOULD NOT use an unencoded "/", but rather use %-encoding for "/" developers SHOULD NOT use these characters in unencoded form, but
("%2F"). rather use the appropriate %-encoding for each character.
2.4 Excluded characters 2.4 Excluded characters
The following list is included only for the sake of completeness. The following list is included only for the sake of completeness.
Any octets/characters on this list are explicitly NOT part of the URN Any octets/characters on this list are explicitly NOT part of the URN
character set, and if used in an URN, MUST be %encoded: character set, and if used in an URN, MUST be %encoded:
<excluded> ::= octets 0-32 (0-20 hex) | "\" | """ | "#" | "&" | "<" <excluded> ::= octets 1-32 (1-20 hex) | "\" | """ | "&" | "<"
| ">" | "[" | "]" | "^" | "`" | "{" | "|" | "}" | octets 127-255 (7F-FF hex) | ">" | "[" | "]" | "^" | "`" | "{" | "|" | "}" | "~"
| octets 127-255 (7F-FF hex)
In addition, octet 0 (0 hex) should NEVER be used, in either
unencoded or %-encoded form.
An URN ends when an octet/character from the excluded character set An URN ends when an octet/character from the excluded character set
(<excluded>) is encountered. The character from the excluded (<excluded>) is encountered. The character from the excluded
character set is NOT part of the URN. character set is NOT part of the URN.
3. Support of existing legacy naming systems and new naming systems 3. Support of existing legacy naming systems and new naming systems
Any namespace (existing or newly-devised) that is proposed as an Any namespace (existing or newly-devised) that is proposed as an
URN-namespace and fulfills the criteria of URN-namespaces MUST be URN-namespace and fulfills the criteria of URN-namespaces MUST be
expressed in this syntax. If names in these namespaces contain expressed in this syntax. If names in these namespaces contain
skipping to change at page 5, line 19 skipping to change at page 5, line 22
all URN-aware applications MUST offer the option of displaying URNs all URN-aware applications MUST offer the option of displaying URNs
in this canonical form to allow for direct transcription (for example in this canonical form to allow for direct transcription (for example
by cut and paste techniques). Such applications MAY support display by cut and paste techniques). Such applications MAY support display
of URNs in a more human-friendly form and may use a character set 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 that includes characters that aren't permitted in URN syntax as
defined in this RFC (that is, they may replace %-notation by defined in this RFC (that is, they may replace %-notation by
characters in some extended character set in display to humans). characters in some extended character set in display to humans).
5. Lexical Equivalence in URNs 5. Lexical Equivalence in URNs
For various purposes such as caching, it's often desirable to determine For various purposes such as caching, it's often desirable to
if two URNs are the same without resolving them. The general purpose determine if two URNs are the same without resolving them. The
means of doing so is by testing for "lexical equivalence" as defined general purpose means of doing so is by testing for "lexical
below. equivalence" as defined below.
Two URNs are lexically equivalent if they are octet-by-octet equal after Two URNs are lexically equivalent if they are octet-by-octet equal
the following preprocessing: after the following preprocessing:
1. normalize the case of the leading "urn:" token 1. normalize the case of the leading "urn:" token
2. normalize the case of the NID 2. normalize the case of the NID
3. normalizing the case of any %-escaping 3. normalizing the case of any %-escaping
Note that %-escaping MUST NOT be removed. Note that %-escaping MUST NOT be removed.
Some namespaces may define additional lexical equivalences, such as Some namespaces may define additional lexical equivalences, such as
case-insensitivity of the NSS (or parts thereof). Additional lexical case-insensitivity of the NSS (or parts thereof). Additional lexical
equivalences MUST be documented as part of namespace registration, MUST equivalences MUST be documented as part of namespace registration,
always have the effect of eliminating some of the false negatives MUST always have the effect of eliminating some of the false
obtained by the procedure above, and MUST NEVER say that two URNs are negatives obtained by the procedure above, and MUST NEVER say that
not equivalent if the procedure above says they are equivalent. two URNs are not equivalent if the procedure above says they are
equivalent.
6. Examples of lexical equivalence 6. Examples of lexical equivalence
The following URN comparisons highlight the lexical equivalence The following URN comparisons highlight the lexical equivalence
definitions: definitions:
1- URN:foo:a123/456 1- URN:foo:a123,456
2- urn:foo:a123/456 2- urn:foo:a123,456
3- urn:FOO:a123/456 3- urn:FOO:a123,456
4- urn:foo:A123/456 4- urn:foo:A123,456
5- urn:foo:a123%2F456 5- urn:foo:a123%2C456
6- URN:FOO:a123%2f456 6- URN:FOO:a123%2c456
URNs 1, 2, and 3 are all lexically equivalent. URN 4 is not URNs 1, 2, and 3 are all lexically equivalent. URN 4 is not
lexically equivalent any of the other URNs of the above set. URNs 5 lexically equivalent any of the other URNs of the above set. URNs 5
and 6 are only lexically equivalent to each other. and 6 are only lexically equivalent to each other.
7. Functional Equivalence in URNs 7. Functional Equivalence in URNs
Functional equivalence is determined by practice within a given Functional equivalence is determined by practice within a given
namespace and managed by resolvers for that namespeace. Namespace namespace and managed by resolvers for that namespeace. Thus, it is
registration must include guidance on how to determine functional beyond the scope of this document. Namespace registration must
equivalence for that namespace, i.e. when two URNs are the identical include guidance on how to determine functional equivalence for that
within a namespace. namespace, i.e. when two URNs are the identical within a namespace.
8. Security considerations 8. Security considerations
This document specifies the syntax for URNs. While some namespaces This document specifies the syntax for URNs. While some namespaces
resolvers may assign special meaning to certain of the characters of resolvers may assign special meaning to certain of the characters of
the Namespace Specific String, any security consideration resulting the Namespace Specific String, any security consideration resulting
from such assignment are outside the scope of this document. It is from such assignment are outside the scope of this document. It is
strongly recommended that the process of registering a namespace strongly recommended that the process of registering a namespace
identifier include any such considerations. identifier include any such considerations.
skipping to change at page 7, line 23 skipping to change at page 7, line 29
Phone: +1 402 894-9456 Phone: +1 402 894-9456
EMail: jayhawk@ds.internic.net EMail: jayhawk@ds.internic.net
Appendix A. Handling of URNs by URL resolvers/browsers. Appendix A. Handling of URNs by URL resolvers/browsers.
The URN syntax has been defined so that URNs can be used in places 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 URL where URLs are expected. A resolver that conforms to the current URL
syntax specification [3] will extract a scheme value of "urn:" syntax specification [3] will extract a scheme value of "urn:"
rather than a scheme value of "urn:<nid>". rather than a scheme value of "urn:<nid>".
An URN MUST be considered an opaque URL by URL resolvers and either An URN MUST be considered an opaque URL by URL resolvers and passed
passed (with the "urn:" tag) to an URN resolver for resolution. The (with the "urn:" tag) to an URN resolver for resolution. The URN
URN resolver can either be an external resolver that the URL resolver resolver can either be an external resolver that the URL resolver
knows of, or it can be functionality built-in to the URL resolver. knows of, or it can be functionality built-in to the URL resolver.
To avoid confusion of users, an URL browser SHOULD display the com- To avoid confusion of users, an URL browser SHOULD display the com-
plete URN (including the "urn:" tag) to ensure that there is no con- plete URN (including the "urn:" tag) to ensure that there is no con-
fusion between URN namespace identifiers and URL scheme identifiers. fusion between URN namespace identifiers and URL scheme identifiers.
This Internet Draft expires July 31, 1997. This Internet Draft expires September 30, 1997.
 End of changes. 18 change blocks. 
56 lines changed or deleted 61 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/