As per Relevance of the word identifier, we have this rfc below:
Network Working Group R.
Request for Comments: 2141 AT&
Category: Standards Track May 1997
URN
Status of This
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Uniform Resource Names (URNs) are intended to serve as persistent
location-independent, resource identifiers. This document
forward the canonical syntax for URNs. A discussion of both
legacy and new namespaces and requirements for URN presentation
transmission are presented. Finally, there is a discussion of
equivalence and how to determine it
1.
Uniform Resource Names (URNs) are intended to serve as persistent
location-independent, resource identifiers and are designed to
it easy to map other namespaces (which share the properties of URNs
into URN-space. Therefore, the URN syntax provides a means to
character data in a form that can be sent in existing protocols
transcribed on most keyboards, etc
2.
All URNs have the following syntax (phrases enclosed in quotes
REQUIRED):
::= "urn:" ":"
where is the Namespace Identifier, and is the
Specific String. The leading "urn:" sequence is case-insensitive
The Namespace ID determines the _syntactic_ interpretation of
Namespace Specific String (as discussed in [1]).
Moats Standards Track [Page 1]
RFC 2141 URN Syntax May 1997
RFC 1630 [2] and RFC 1737 [3] each presents additional
for URN encoding, which have implications as far as limiting syntax
On the other hand, the requirement to support existing legacy
systems has the effect of broadening syntax. Thus, we discuss
acceptable syntax for both the Namespace Identifier and the
Specific String separately
2.1 Namespace Identifier
The following is the syntax for the Namespace Identifier. To (a)
consistent with all potential resolution schemes and (b) not put
undue constraints on any potential resolution scheme, the syntax
the Namespace Identifier is
::= [ 1,31 ]
::= | | | "-"
::= | |
::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" |
"I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" |
"Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" |
"Y" | "Z
::= "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |
"i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
"q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
"y" | "z
::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
"8" | "9"
This is slightly more restrictive that what is stated in [4] (
allows the characters "." and "+"). Further, the
Identifier is case insensitive, so that "ISBN" and "isbn" refer
the same namespace
To avoid confusion with the "urn:" identifier, the NID "urn"
reserved and MUST NOT be used
Moats Standards Track [Page 2]
RFC 2141 URN Syntax May 1997
2.2 Namespace Specific String
As required by RFC 1737, there is a single canonical
of the NSS portion of an URN. The format of this single
form follows
::= 1*
::= | "%"
::= | | | | <reserved
::= | "A" | "B" | "C" | "D" | "E" | "F" |
"a" | "b" | "c" | "d" | "e" | "f
::= "(" | ")" | "+" | "," | "-" | "." |
":" | "=" | "@" | ";" | "$" |
"_" | "!" | "*" | "'"
Depending on the rules governing a namespace, valid identifiers in
namespace might contain characters that are not members of the
character set above (). Such strings MUST be
into canonical NSS format before using them as protocol elements
otherwise passing them on to other applications. Translation is
by encoding each character outside the URN character set as
sequence of one to six octets using UTF-8 encoding [5], and
encoding of each of those octets as "%" followed by two
from the character set above. The two characters give
hexadecimal representation of that octet
2.3 Reserved
The remaining character set left to be discussed above is
reserved character set, which contains various characters
from normal use. The reserved character set follows, with
discussion on the specifics of why each character is reserved
The reserved character set is
<reserved> ::= '%" | "/" | "?" | "#"
2.3.1 The "%"
The "%" character is reserved in the URN syntax for introducing
escape sequence for an octet. Literal use of the "%" character in
namespace must be encoded using "%25" in URNs for that namespace
The presence of an "%" character in an URN MUST be followed by
characters from the character set
Moats Standards Track [Page 3]
RFC 2141 URN Syntax May 1997
Namespaces MAY designate one or more characters from the
character set as having special meaning for that namespace. If
namespace also uses that character in a literal sense as well,
character used in a literal sense MUST be encoded with "%"
by the hexadecimal representation of that octet. Further,
character MUST NOT be "%"-encoded if the character is not a
character. Therefore, the process of registering a
identifier shall include publication of a definition of
characters have a special meaning to that namespace
2.3.2 The other reserved
RFC 1630 [2] reserves the characters "/", "?", and "#" for
purposes. The URN-WG has not yet debated the applicability
precise semantics of those purposes as applied to URNs. Therefore
these characters are RESERVED for future developments.
developers SHOULD NOT use these characters in unencoded form,
rather use the appropriate %-encoding for each character
2.4 Excluded
The following list is included only for the sake of completeness
Any octets/characters on this list are explicitly NOT part of the
character set, and if used in an URN, MUST be %encoded
::= octets 1-32 (1-20 hex) | "\" | """ | "&" | "<"
| ">" | "[" | "]" | "^" | "`" | "{" | "|" | "}" | "~"
| octets 127-255 (7F-FF hex
In addition, octet 0 (0 hex) should NEVER be used, in
unencoded or %-encoded form
An URN ends when an octet/character from the excluded character
() is encountered. The character from the
character set is NOT part of the URN
3. Support of existing legacy naming systems and new naming
Any namespace (existing or newly-devised) that is proposed as
URN-namespace and fulfills the criteria of URN-namespaces MUST
expressed in this syntax. If names in these namespaces
characters other than those defined for the URN character set,
MUST be translated into canonical form as discussed in section 2.2.
Moats Standards Track [Page 4]
RFC 2141 URN Syntax May 1997
4. URN presentation and
The URN syntax defines the canonical format for URNs and all
transport and interchanges MUST take place in this format. Further
all URN-aware applications MUST offer the option of displaying
in this canonical form to allow for direct transcription (for
by cut and paste techniques). Such applications MAY support
of URNs in a more human-friendly form and may use a character
that includes characters that aren't permitted in URN syntax
defined in this RFC (that is, they may replace %-notation
characters in some extended character set in display to humans).
5. Lexical Equivalence in
For various purposes such as caching, it's often desirable
determine if two URNs are the same without resolving them.
general purpose means of doing so is by testing for "
equivalence" as defined below
Two URNs are lexically equivalent if they are octet-by-octet
after the following preprocessing
1. normalize the case of the leading "urn:"
2. normalize the case of the
3. normalizing the case of any %-
Note that %-escaping MUST NOT be removed
Some namespaces may define additional lexical equivalences, such
case-insensitivity of the NSS (or parts thereof). Additional
equivalences MUST be documented as part of namespace registration
MUST always have the effect of eliminating some of the
negatives obtained by the procedure above, and MUST NEVER say
two URNs are not equivalent if the procedure above says they
equivalent
6. Examples of lexical
The following URN comparisons highlight the lexical
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
Moats Standards Track [Page 5]
RFC 2141 URN Syntax May 1997
URNs 1, 2, and 3 are all lexically equivalent. URN 4 is
lexically equivalent any of the other URNs of the above set. URNs 5
and 6 are only lexically equivalent to each other
7. Functional Equivalence in
Functional equivalence is determined by practice within a
namespace and managed by resolvers for that namespeace. Thus, it
beyond the scope of this document. Namespace registration
include guidance on how to determine functional equivalence for
namespace, i.e. when two URNs are the identical within a namespace
8. Security
This document specifies the syntax for URNs. While some
resolvers may assign special meaning to certain of the characters
the Namespace Specific String, any security consideration
from such assignment are outside the scope of this document. It
strongly recommended that the process of registering a
identifier include any such considerations
9.
Thanks to various members of the URN working group for comments
earlier drafts of this document. This document is
supported by the National Science Foundation, Cooperative
NCR-9218179.
10.
Request For Comments (RFC) and Internet Draft documents are
from internic.net> and numerous mirror sites
[1] Sollins, K. R., "Requirements and a Framework
URN Resolution Systems," Work in Progress
[2] Berners-Lee, T., "Universal Resource Identifiers
WWW," RFC 1630, June 1994.
[3] Sollins, K. and L. Masinter, "Functional
for Uniform Resource Names," RFC 1737.
December 1994.
Moats Standards Track [Page 6]
RFC 2141 URN Syntax May 1997
[4] Berners-Lee, T., R. Fielding, L. Masinter, "
Resource Locators (URL)," Work in Progress
[5] Appendix A.2 of The Unicode Consortium, "
Unicode Standard, Version 2.0", Addison-
Developers Press, 1996. ISBN 0-201-48345-9.
11. Editor's
Ryan
AT&
15621 Drexel
Omaha, NE 68135-2358
Phone: +1 402 894-9456
EMail: jayhawk@ds.internic.
Moats Standards Track [Page 7]
RFC 2141 URN Syntax May 1997
Appendix A. Handling of URNs by URL resolvers/browsers
The URN syntax has been defined so that URNs can be used in
where URLs are expected. A resolver that conforms to the current
syntax specification [3] will extract a scheme value of "urn:"
than a scheme value of "urn:".
An URN MUST be considered an opaque URL by URL resolvers and
(with the "urn:" tag) to an URN resolver for resolution. The
resolver can either be an external resolver that the URL
knows of, or it can be functionality built-in to the URL resolver
To avoid confusion of users, an URL browser SHOULD display
complete URN (including the "urn:" tag) to ensure that there is
confusion between URN namespace identifiers and URL
identifiers
Moats Standards Track [Page 8]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
