Subject: [URN] Planning for Memphis
From: Leslie Daigle <[email-masked]>
To: [email-masked]
Date: Wed, 26 Feb 1997 14:52:02 -0500

The scramble for Memphis hotel rooms seems to be the sign that it's time
to talk about what we will attempt to achieve before that meeting.  A
number of people have been working hard since San Jose, so we've been making
a good deal of progress.

Meeting dates:   Memphis IETF meeting is April 7-11, 1997.

Internet-Draft CUTOFF date: Wednesday, March 26, 1997 at 5pm ET

Document status/plan:

	Architecture:

	  . URN syntax (Ryan Moats -- almost to last call)
	  . UDS requirements (Karen Sollins -- new draft by Memphis)
	  . Namespace requirements (Renato Iannella; Ron Daniel has provided
		some starting structure -- draft by Memphis)
	  . (URI?) Resolution Service Definitions (Need volunteer -- draft
		by Memphis)

	Implementation

	  . NAPTR (Ron Daniel -- almost to last call)  - should refer to the 
		UDS requirements doc
	  . THTTP  (Ron Daniel -- almost to last call) - should refer to the 
		Resolution Services Def'n
	  . Existing Namespace (some work being done with SICI's)
	  . New, generic namespace -- waiting on Namespace requirements doc

I've been in touch with most editors directly at this point, and I think
the above is achievable.  At this point, I'm looking for a volunteer to
take the Trivial HTTP draft and extract from it a generic statement about
Resolution Service Definitions for that last architecture draft.  As a first
approximation, I think this should include:

       . definitions of each service
       . definitions of responses for each service.   This includes
         how to handle exceptions/error conditions.

         For example, N2Ls:
               . says that a list of URLs for the resource are returned;
                 resolution service definitions must include statements
                 about how these are carried (e.g., in the THTTP it is
                 described as tex/uri-list media type, etc).
               . defines _what_ URLs are to be returned for the URN
                 (i.e., this is what nails the semantics of what you should
                 _expect_ to get at the end of that URL -- the definitive
                 resource?  resource-du-jour?)
               . describes what exceptions are possible:  unknown, not
                 available, not accessible (security).

Thoughts?  Volunteers?  Let me know!

Leslie.

----------------------------------------------------------------------------

  "_Be_                                           Leslie Daigle
             where  you                           
                          _are_."                 Bunyip Information Systems
                                                  (514) 875-8611
                      -- ThinkingCat              [email-masked]
----------------------------------------------------------------------------

From: Masataka Ohta <[email-masked]>
Subject: Re: [URN] Re: URL internationalization!
To: [email-masked] (Alain LaBont/e'/)
Date: Wed, 26 Feb 97 9:43:43 JST
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Masataka Ohta <[email-masked]>

Alain;

> [Alain

Stop using to insist on ISO-8859-1 for fully Internationalized
communication. Use ASCII only.

> >> Turkish is probably the worst case btw. Turkish uses the latin script
> but...
> 
> [Masataka Ohta] :
> >These days, there are annoying live demonstrations in ietf ML that
> >Turkish is just fine with ASCII. Have you done something?
> 
> [Alain
> No, I am not aware of this. But I know that the Turks would not agree.

All the people of IETF ML is aware that you are wrong.

> >> If they pronounce it they have it wrong all the time. On a speakerphone in
> >> an airport a Turk might not recognize his/her own name.
> 
> [Masataka Ohta] :
> >??? How can the speakerphone operator pronounce my name written in
> >Kanji?
> 
> [Alain] :
> The sub-thread (a perenthesis open by Jan, pronounced Yan) of this
> discussion, I believe, dealt with the use of the International Phonetic
> Alphabet for machine-readable passports or for airline tickets.

That's not even a subthread.

> But to come back to the sub-thread, with the IPA any human-pronounceable
> sound can be represented,

So with ASCII, or just a binary sequence of '0' and '1'.

The only difference is that, with ASCII, there already exists formal
notations transcribable by anyone and readable/writable/pronoucible
by those who know the language.

							Masataka Ohta

Date: Tue, 25 Feb 1997 12:54:14 -0600
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: [email-masked]
Subject: [URN] Syntax v 2.1 (pre-release of syntax-03)
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

This is a multi-part message in MIME format.

--------------33B96FF35FDA
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Folks-

Moving right along with the syntax, attached is v2.1 of the URN syntax
draft.  I've made changes based on Ron's comments.  If nobody
has any serious qualms, I'd like to issue v3 next week (3/3) and
then go to whatever our equivalent of "WG last call" is so that
we can submit this to the IETF by mid-March (Leslie, any problems
with this?)

Ryan

--------------33B96FF35FDA
Content-Type: text/plain; charset=us-ascii; name="urn.syntax.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="urn.syntax.txt"

Internet-Draft                                                Ryan Moats
draft-ietf-urn-syntax-03.txt                                        AT&T
Expires in six months                                         March 1997

                               URN Syntax
                 Filename: draft-ietf-urn-syntax-03.tx

Status of This Memo

      This document is an Internet-Draft.  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.''

      To learn the current status of any Internet-Draft, please check
      the ``1id-abstracts.txt'' listing contained in the Internet-
      Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
      (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
      Coast), or ftp.isi.edu (US West Coast).

Abstract

   Uniform Resource Names (URNs) are intended to serve as persistent,
   location-independent, resource identifiers. This document sets
   forward the canonical syntax for URNs.  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.

1. Introduction

   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 URN-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.

Expires 9/30/97                                                 [Page 1]

INTERNET DRAFT                 URN Syntax                     March 1997

2. Syntax

   All URNs have the following syntax (phrases enclosed in quotes are
   REQUIRED):

                     <URN> ::= "urn:" <NID> ":" <NSS>

   where <NID> is the Namespace Identifier, and <NSS> is the Namespace
   Specific String.  The leading "urn:" sequence is case-insensitive.
   The Namespace ID determines the _syntactic_ interpretation of the
   Namespace Specific String (as discussed in [1]).

   RFC 1630 [2] and RFC 1737 [3] each presents additional considerations
   for URN encoding, which have implications as far as limiting syntax.
   On the other hand, the requirement to support existing legacy naming
   systems has the effect of broadening syntax.  Thus, we discuss the
   acceptable syntax for both the Namespace Identifier and the Namespace
   Specific String separately.

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, the syntax for
   the Namespace Identifier is:

   <NID>         ::= <let-num> [ 1,31<let-num-hyp> ]

   <let-num-hyp> ::= <upper> | <lower> | <number> | "-"

   <let-num>     ::= <upper> | <lower> | <number>

   <upper>       ::= "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"

   <lower>       ::= "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"

   <number>      ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
                     "8" | "9"

   This is slightly more restrictive that what is stated in [4] (which

Expires 9/30/97                                                 [Page 2]

INTERNET DRAFT                 URN Syntax                     March 1997

   allows the characters "." and "+").  Further, the Namespace
   Identifier is case insensitive, so that "ISBN" and "isbn" refer to
   the same namespace.

   To avoid confusion with the "urn:" identifier, the NID "urn" is
   reserved and MUST NOT be used.

2.2 Namespace Specific String Syntax

   As required by RFC 1737, there is a single canonical representation
   of the NSS portion of an URN.   The format of this single canonical
   form follows:

   <NSS>         ::= 1*<URN chars>

   <URN chars>   ::= <trans> | "%" <hex> <hex>

   <trans>       ::= <upper> | <lower> | <number> | <other> | <reserved>

   <hex>         ::= <number> | "A" | "B" | "C" | "D" | "E" | "F" |
                     "a" | "b" | "c" | "d" | "e" | "f"

   <other>       ::= "(" | ")" | "+" | "," | "-" | "." |
                     ":" | "=" | "@" | ";" | "$" |
                     "_" | "!" | "*" | "'"

   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 chars>).  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 one to six octets using UTF-8 encoding, and the encoding
   of each of those octets as "%" followed by two characters from the
   <hex> character set above. The two characters give the hexadecimal
   representation of that octet.

2.3 Reserved characters

   The remaining character set left to be discussed above is the
   reserved character set, which contains various characters reserved
   from normal use.  The reserved character set follows, with a
   discussion on the specifics of why each character is reserved.

   The reserved character set is:

   <reserved>    ::= '%" | "/" | "?" | "#"

Expires 9/30/97                                                 [Page 3]

INTERNET DRAFT                 URN Syntax                     March 1997

2.3.1 The "%" character

   The "%" character is reserved in the URN syntax for introducing the
   escape sequence for an octet.  Literal use of the "%" character in a
   namespace must be encoded using "%25" in URNs for that namespace.
   The presence of an "%" character in an URN MUST be followed by two
   characters from the <hex> character set.

   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 "%"-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.2 The other reserved characters

   RFC 1630 [2] reserves the characters "/", "?", and "#" for particular
   purposes. The URN-WG has not yet debated the applicability and
   precise semantics of those purposes as applied to URNs. Therefore,
   these characters are RESERVED for future developments.  Namespace
   developers SHOULD NOT use these characters in unencoded form, but
   rather use the appropriate %-encoding for each character.

2.4 Excluded characters

   The following list is included only for the sake of completeness.
   Any octets/characters on this list are explicitly NOT part of the URN
   character set, and if used in an URN, MUST be %encoded:

   <excluded> ::= octets 1-32 (1-20 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
   (<excluded>) is encountered.  The character from the excluded
   character set is NOT part of the URN.

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

Expires 9/30/97                                                 [Page 4]

INTERNET DRAFT                 URN Syntax                     March 1997

   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's often desirable to determine
if 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:" token
        2. normalize the case of the NID
        3. normalizing the case of any %-escaping

Note that %-escaping 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.

6. 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

Expires 9/30/97                                                 [Page 5]

INTERNET DRAFT                 URN Syntax                     March 1997

           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 any of the other URNs of the above set.  URNs 5
   and 6 are only lexically equivalent to each other.

7. Functional Equivalence in URNs

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

8. Security considerations

   This document specifies the syntax for URNs.  While some namespaces
   resolvers 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
   strongly recommended that the process of registering a namespace
   identifier include any such considerations.

9. Acknowledgments

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

10. References

   Request For Comments (RFC) and Internet Draft documents are available
   from <URL:ftp://ftp.internic.net> and numerous mirror sites.

         [1]         K. R. Sollins, "Requirements and a Framework for
                     URN Resolution Systems," Internet Draft (work in
                     progress),  November 1996.

         [2]
          T. Berners-Lee, "Universal Resource Identifiers in WWW," RFC
          1630, June 1994.

         [3]         K. Sollins and L. Masinter,  "Functional Require-
                     ments for Uniform Resource Names," RFC 1737.
                     December 1994.

Expires 9/30/97                                                 [Page 6]

INTERNET DRAFT                 URN Syntax                     March 1997

         [4]         T. Berners-Lee, R. Fielding, L. Masinter, "Uniform
                     Resource Locators (URL)," Internet Draft (work in
                     progress),  December 1996.

11. Editor's address

   Ryan Moats
   AT&T
   15621 Drexel Circle
   Omaha, NE 68135-2358
   USA

   Phone:  +1 402 894-9456
   EMail:  [email-masked]

Appendix A. 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 URL
   syntax specification [3] will extract a scheme value of "urn:"
   rather than a scheme value of "urn:<nid>".

   An URN MUST be considered an opaque URL 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-in to the URL resolver.

   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-
   fusion between URN namespace identifiers and URL scheme identifiers.

              This Internet Draft expires September 30, 1997.

Expires 9/30/97                                                 [Page 7]

--------------33B96FF35FDA--

From: [email-masked]
Date: Tue, 25 Feb 1997 10:30:49 -0800
Posted-Date: Tue, 25 Feb 1997 10:30:49 -0800
To: [email-masked], [email-masked]
Subject: [URN] Re: URI-protocol mapping (was Re: How to add new "protocols" ?)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]

> From [email-masked] Fri Feb 21 09:39:57 1997
> 
> [email-masked] wrote:
> > 
> > > OK, I'll bite: how is it that "location-dependent" vs.
> > > "location-independent" is a technical distinction?
> 
> > It's very technical. The host requirements RFC specifies locations
> > as either fully-qualified DNS names or IP addresses. And that's what
> > you have here. I.e., you have as much of a location as the internet
> > allows.
> 
> Ah! I wan't aware of that. I really appreciate you pointing
> that out.
> 
> OK, I'm happy with 'location-independent' as a technical
> term if 'location' is defined as 'FQDN or IP
> address'. I inferred the more geographic connotations.

> A quick scan of the URN requirements/framework draft[1]
> and the URN requirements RFC[2] doesn't
> show a similar definition of 'location'. And there's
> no reference to the host requirements RFC.

That is a clear inconsistency. Given that HTTP/1.1 does ref it.

> Hang on... I went to add it to my glossary of web
> architecture terms[3], but a brief scan of the
> host requirements RFC[4] shows:
> 
> |the DNS provides globally-unique,
> |              location-independent names.
> 
> If a FQDNs are locations, how does DNS provide
> location-independent names?

We're confusing the term location here, as is probably obvious.

The DNS provides globally-unique, 
	(geographically) location-independent names.

FQDNs are locations, just not geographic ones.

Joe

----------------------------------------------------------------------
Joe Touch - [email-masked]		    http://www.isi.edu/~touch/
ISI / Project Leader, ATOMIC-2, LSAM       http://www.isi.edu/atomic2/
USC / Research Assistant Prof.                http://www.isi.edu/lsam/

Date: Tue, 25 Feb 1997 10:44:24
To: Masataka Ohta <[email-masked]>
From: "Alain LaBont/e'/" <[email-masked]>
Subject: Re: [URN] Re: URL internationalization!
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "Alain LaBont/e'/" <[email-masked]>

A 00:03 97-02-26 JST, Masataka Ohta a icrit :

[Alain LaBonti] :
>> Turkish is probably the worst case btw. Turkish uses the latin script
but...

[Masataka Ohta] :
>These days, there are annoying live demonstrations in ietf ML that
>Turkish is just fine with ASCII. Have you done something?

[Alain LaBonti] :
No, I am not aware of this. But I know that the Turks would not agree. It
is one of the best examples to show that ASCII is unsuited to represent the
whole Latin script.

[Masataka Ohta] :
>> If they pronounce it they have it wrong all the time. On a speakerphone in
>> an airport a Turk might not recognize his/her own name.

[Masataka Ohta] :
>??? How can the speakerphone operator pronounce my name written in
>Kanji?

[Alain] :
The sub-thread (a perenthesis open by Jan, pronounced Yan) of this
discussion, I believe, dealt with the use of the International Phonetic
Alphabet for machine-readable passports or for airline tickets. I said that
I supported that idea fully, implicitly regreting that it is utopic (but I
believe in Utopia sometimes (: ) Of course Kanji is a problem as even a
Japanese needs to be initiated to transform it into kana. That is not the
point. Kanji should be allowed in URLs though, as I believe in the use of
*a* universal character set reproducible everywhere on earth, temporarily
with a fallback if necessary.

But to come back to the sub-thread, with the IPA any human-pronounceable
sound can be represented, your name as well as the most delightful Cockney
accent in English. Its use would make all humans equal as far as name
pronunciation is involved. It could even be represented in some URLs (:

Alain LaBonti (pronounce LaBontay - also note that "ain" and "on" are pure 
                 nasal vowel sounds, not diphthongs! and these sounds can't
be 
                 represented in ASCII without long explanations on how to
                 reconfigure your internal mouth and tongue (: )
Quibec (pronounce Kaybec, even in standard English!)

From: Masataka Ohta <[email-masked]>
Subject: Re: [URN] Re: URL internationalization!
To: [email-masked] (Alain LaBont/e'/)
Date: Wed, 26 Feb 97 0:03:46 JST
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Masataka Ohta <[email-masked]>

Alain LaBont;

> [Masataka Otha]:
> >Look at international airline tickets of people from France, Japan,
> >Thai, Arab and India and tell me what is wrong.
> 
> [Alain LaBont:
> I don't know for others (I suspect that it is not good either) but my name
> is not respected when LABONTE is written on my airline ticket.

When my name is written in Kanji on international airine ticket,
I can't use the ticket outside of Japan.

> In fact as
> it is not considered transliteration

Of course, it is not transliteration but just a formal notation
of Airline operators.

> Turkish is probably the worst case btw. Turkish uses the latin script but...

These days, there are annoying live demonstrations in ietf ML that
Turkish is just fine with ASCII. Have you done something?

> If they pronounce it they have it wrong all the time. On a speakerphone in
> an airport a Turk might not recognize his/her own name.

??? How can the speakerphone operator pronounce my name written in
Kanji?

							Masataka Ohta

Date: Fri, 21 Feb 1997 11:21:00 -0600
From: Dan Connolly <[email-masked]>
Organization: World Wide Web Consortium
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] Re: URI-protocol mapping (was Re: How to add new "protocols" ?)
Sender: [email-masked]
Reply-To: Dan Connolly <[email-masked]>

[email-masked] wrote:
> 
> > OK, I'll bite: how is it that "location-dependent" vs.
> > "location-independent" is a technical distinction?

> It's very technical. The host requirements RFC specifies locations
> as either fully-qualified DNS names or IP addresses. And that's what
> you have here. I.e., you have as much of a location as the internet
> allows.

Ah! I wan't aware of that. I really appreciate you pointing
that out.

OK, I'm happy with 'location-independent' as a technical
term if 'location' is defined as 'FQDN or IP
address'. I inferred the more geographic connotations.

I want that in the specs though. If I didn't
know it, I'm sure lots of other folks didn't know it.

A quick scan of the URN requirements/framework draft[1]
and the URN requirements RFC[2] doesn't
show a similar definition of 'location'. And there's
no reference to the host requirements RFC.

Hang on... I went to add it to my glossary of web
architecture terms[3], but a brief scan of the
host requirements RFC[4] shows:

|the DNS provides globally-unique,
|              location-independent names.

If a FQDNs are locations, how does DNS provide
location-independent names?

In fact, I don't see this definition of location
that you refer to at all in the host requirements RFC[4].
Could you elaborate?

[1] ftp://ftp.ietf.org/internet-drafts/draft-ietf-urn-req-frame-00.txt
[2] http://ds.internic.net/rfc/rfc1737.txt
[3] http://www.w3.org/pub/WWW/Architecture/Terms
[4] ftp://ftp.math.utah.edu/pub/rfc/rfc1123.txt

From: Masataka Ohta <[email-masked]>
Subject: [URN] Re: URL internationalization!
To: [email-masked] (Jonathan Rosenne)
Date: Fri, 21 Feb 97 19:06:59 JST
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Masataka Ohta <[email-masked]>

> >ASCII script is rich enough to denote French, Japanese, Thai,
> >Arabic, Hindi...
> 
> How would you denote Arabic in ASCII?

???

> Arabic has more consonants than ASCII
> has letters.

So does English. Can you pronounce "th", "sh", "ch", "ng"...

							Masataka Ohta

From: [email-masked]
Date: Wed, 19 Feb 1997 14:21:32 -0500
Original-From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: Leslie Daigle <[email-masked]>
Cc: [email-masked]
Subject: [URN] URN Mailing List Archives....
Sender: [email-masked]
Reply-To: [email-masked]

Leslie (and all the URN folks)-

To help me find previous mail on various topics (especially related to
repeat issues on the syntax draft ;-) I have set up a mirror of the
URN mailing list archives from bunyip.com to the various ds.internic.net
machines.  These mirrored archives are available from

http://ds.internic.net/ietf/urn/urn-archives
ftp://ds.internic.net/ietf/urn/urn-archives

Further, these archives are searchable by WAIS.  To search these
archives, either

1. Telnet to any ds.internic.net machine, log in as user "wais" and
search the database urn-mail-archives, or
2. Use the WWW interface at http://ds.internic.net/ds/urnwais.html

Hope others find this as useful as I have (now that most of the kinks
are out of it)

Ryan

Date: Thu, 20 Feb 1997 10:25:26 -0500
To: Masataka Ohta <[email-masked]>, [email-masked] (YON - Jan C. Hardenbergh)
From: "Alain LaBont/e'/" <[email-masked]>
Subject: Re: [URN] Re: URL internationalization!
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "Alain LaBont/e'/" <[email-masked]>

A 14:50 97-02-20 JST, Masataka Ohta a icrit :
>> > ASCII script is rich enough to denote French, Japanese, Thai,
>> > Arabic, Hindi...

[Jan C. Hardenbergh]:
>> This is just wrong!

[Masataka Otha]:
>Look at international airline tickets of people from France, Japan,
>Thai, Arab and India and tell me what is wrong.

[Alain LaBonti]:
I don't know for others (I suspect that it is not good either) but my name
is not respected when LABONTE is written on my airline ticket. In fact as
it is not considered transliteration (it is downgrading the same script) it
is even more wrong than transliteration from another script to the Latin.
Turkish is probably the worst case btw. Turkish uses the latin script but...

If they try to match this with a database, they have trouble all the time.

If they pronounce it they have it wrong all the time. On a speakerphone in
an airport a Turk might not recognize his/her own name.

There is a movement to have OCR-B modified on machine-readable passports
because this using of the plain English alphabet is a mess.

Personally I would prefer to use the plain IPA to make all people of the
earth equal if we were *not to use* a canonical universal characater set.

Furthermore expected pronounciation for teh main interested people could be
perfectly rendered by a machine.

Alain LaBonti
Quibec

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-http-conv-01.txt
Date: Thu, 20 Feb 1997 09:35:17 -0500
Sender: [email-masked]
Reply-To: [email-masked]

--NextPart

 A Revised Internet-Draft is available from the on-line Internet-Drafts 
 directories. This draft is a work item of the Uniform Resource Names 
 Working Group of the IETF.                                                

       Title     : A Trivial Convention for using HTTP in URN Resolution   
       Author(s) : R. Daniel
       Filename  : draft-ietf-urn-http-conv-01.txt
       Pages     : 6
       Date      : 02/19/1997

The Uniform Resource Names Working Group (URN-WG) was formed to specify 
persistent, location-independent names for network accessible resources, as
well as resolution mechanisms to retrieve the resources given such a name. 
At this time the URN-WG is considering one particular resolution mechanism,
the NAPTR proposal [1]. That proposal specifies how a client may find a 
"resolver" for a URN. A resolver is a database that can provide information
about the resource identified by a URN, such as the resource's location, a 
bibliographic description, or even the resource itself. The protocol used 
for the client to communicate with the resolver is not specified in the 
NAPTR proposal. Instead, the NAPTR resource record provides a field that 
indicates the "resolution protocol" and "resolution service requests" 
offered by the resolver.  

This document specifies the "THTTP" resolution protocol - a trivial 
convention for encoding resolution service requests and responses as 
HTTP 1.0 or 1.1 requests and responses.  The primary goal of THTTP 
is to be simple to implement so that existing HTTP servers may easily 
add support for URN resolution. We expect that the databases used by
early resolvers will be useful when more sophisticated esolution protocols
are developed later.                    

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
     "get draft-ietf-urn-http-conv-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-http-conv-01.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  ftp.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  [email-masked]. In the body type: 
     "FILE /internet-drafts/draft-ietf-urn-http-conv-01.txt".
							
NOTE: The mail server at ds.internic.net can return the document in
      MIME-encoded form by using the "mpack" utility.  To use this
      feature, insert the command "ENCODING mime" before the "FILE"
      command.  To decode the response(s), you will need "munpack" or
      a MIME-compliant mail reader.  Different MIME-compliant mail readers
      exhibit different behavior, especially when dealing with
      "multipart" MIME messages (i.e., documents which have been split
      up into multiple messages), so check your local documentation on
      how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader 
implementation to automatically retrieve the ASCII version
of the Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-urn-http-conv-01.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-urn-http-conv-01.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-naptr-02.txt
Date: Thu, 20 Feb 1997 09:35:12 -0500
Sender: [email-masked]
Reply-To: [email-masked]

--NextPart

 A Revised Internet-Draft is available from the on-line Internet-Drafts 
 directories. This draft is a work item of the Uniform Resource Names 
 Working Group of the IETF.                                                

       Title     : Resolution of Uniform Resource Identifiers using the 
                   Domain Name System                                      
       Author(s) : R. Daniel, M. Mealling
       Filename  : draft-ietf-urn-naptr-02.txt
       Pages     : 14
       Date      : 02/19/1997

Uniform Resource Locators (URLs) are the foundation of the World Wide Web, 
and are a vital Internet technology. However, they have proven to be 
brittle in practice. The basic problem is that URLs typically identify a 
particular path to a file on a particular host. There is no graceful way of
changing the path or host once the URL has been assigned. Neither is there 
a graceful way of replicating the resource located by the URL to achieve 
better network utilization and/or fault tolerance. Uniform Resource Names 
(URNs) have been hypothesized as a adjunct to URLs that would overcome such
problems. URNs and URLs are both instances of a broader class of 
identifiers known as Uniform Resource Identifiers (URIs). 

This document describes a new DNS Resource Record, NAPTR (Naming Authority 
PoinTeR), that provides rules for mapping parts of URIs to domain names.  
By changing the mapping rules, we can change the host that is contacted 
to resolve a URI.   This will allow a more graceful handling of URLs 
over long time periods, and forms the foundation for a new proposal 
for Uniform Resource Names.    

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
     "get draft-ietf-urn-naptr-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-naptr-02.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  ftp.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  [email-masked]. In the body type: 
     "FILE /internet-drafts/draft-ietf-urn-naptr-02.txt".
							
NOTE: The mail server at ds.internic.net can return the document in
      MIME-encoded form by using the "mpack" utility.  To use this
      feature, insert the command "ENCODING mime" before the "FILE"
      command.  To decode the response(s), you will need "munpack" or
      a MIME-compliant mail reader.  Different MIME-compliant mail readers
      exhibit different behavior, especially when dealing with
      "multipart" MIME messages (i.e., documents which have been split
      up into multiple messages), so check your local documentation on
      how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader 
implementation to automatically retrieve the ASCII version
of the Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-urn-naptr-02.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-urn-naptr-02.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

Date: Thu, 20 Feb 1997 10:03:27 -0500
To: Masataka Ohta <[email-masked]>, [email-masked] (Alain LaBont/e'/)
From: "Alain LaBont/e'/" <[email-masked]>
Subject: [URN] Re: URL internationalization!
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "Alain LaBont/e'/" <[email-masked]>

A 12:49 97-02-20 JST, Masataka Ohta a icrit :
>If you don't want to insulate yourself within ISO-8859-1 community,
>don't use ISO-8859-1.

I am surprised that you said in an earlier note that you say ISO/IEC 2022
is not a problem and that you can't process ISO/IEC 8859-1 which is just a
subset of ISO/IEC 2022 code extension etchnique. If you support ISO/IEC
2022 you have to support all of the ISO/IEC SC2 character set registry. You
have to go to the limit of your own arguments.

>The more conservative you send, the more people can read it.
>
>ASCII script is rich enough to denote French, Japanese, Thai,
>Arabic, Hindi...

How do you distinguish in ASCII:

ENFANTS LEGITIMES DE LOUIS XIV and
ENFANTS LIGITIMIS DE LOUIS XIV ?

Just curious... French can't be vehicled in ASCII. Period.

I must also tell you that you mix "script" and "character set". ASCII is a
character set, the Latin characters are a script. The Latin script includes
many more characters than the character repertoire of ASCII.

Alain LaBonti
Quibec

Date: Thu, 20 Feb 1997 09:59:07 -0500
From: Jonathan Rosenne <[email-masked]>
Subject: [URN] Re: URL internationalization!
To: Masataka Ohta <[email-masked]>
Cc: URN List <[email-masked]>, URL List <[email-masked]>
Sender: [email-masked]
Reply-To: Jonathan Rosenne <[email-masked]>

>ASCII script is rich enough to denote French, Japanese, Thai,
>Arabic, Hindi...

How would you denote Arabic in ASCII? Arabic has more consonants than ASCII
has letters.

Jonathan

Date: Thu, 20 Feb 1997 15:57:21 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: Masataka Ohta <[email-masked]>
Cc: "YON - Jan C. Hardenbergh" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: URL internationalization!
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

Masataka -

> Multi-language support is doable with ASCII only and is orthogonal
> to multi-script support.

A very crude multilingual support is doable with the basic Latin
script only. And at some point, there were even people that claimed
that all languages would have to switch to it to keep up with
computer technology. But actually, computer technology has improved
a lot, and this is no longer necessary nor desirable.

> > Besides, all you ASCII lovers should be exceptionally excited by
> > Martin's proposal because ASCII is a subset of utf8 (RFC 2044)
> 
> No, not at all. ISO-2022-{JP, KR, CN, JP-2} are all supersets
> of ASCII and better than utf8 in all aspects.

Definitely not. I already mentionned several serious problems
with ISO-2022. I got reminded here of one I forgot, but which
is rather crucial:

- ISO-2022 interferes with URL reserved characters. ISO-2022-JP,
	for example, can contain, in stretches that encode
	Japanese characters, octets with the same values as
	"/" or "#" and so on.

> UTF8 is not a proper charset at all. Look at RFC 1815 on how
> to construct proper charsets from ISO 10646.

There is nothing in the relevant definitions of MIME "charset"s
that prescribes that a sender or receiver would be required
to display all of the characters that can be encoded with a
given "charset".

Regards,	Martin.

Date: Thu, 20 Feb 1997 09:55:34 -0500
To: Masataka Ohta <[email-masked]>
From: "Alain LaBont/e'/" <[email-masked]>
Subject: [URN] Re: URL internationalization!
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "Alain LaBont/e'/" <[email-masked]>

A 12:49 97-02-20 JST, Masataka Ohta m'a icrit :
>The current detouring attempt of Unicode/ISO 10646 on local script
>support is that they are confusing people like you with no real
>internationzalization expertise not to be able to distinguish
>"language" and "script".

For your information I've been working on internationalization for more
than 10 yers and I am project editor of international standards in the
field, member of ISO/IEC JTC1/SC22/WG20 (internationalization of
applications).

You're invited to join the international team of ISO on the subject, most
welcome.

I know perfectly well the difference between script and language, between
character set and glyph and so on... that said promoting a worldwide
canonical character set definitely has to do with internationalization.

Alain LaBonti
Quibec

Date: Wed, 19 Feb 1997 21:12:46 PST
From: Larry Masinter <[email-masked]>
Organization: Xerox PARC
To: "YON - Jan C. Hardenbergh" <[email-masked]>
Cc: Masataka Ohta <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: URL internationalization!
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

Folks,

This particular flame war belongs on [email-masked], which 
is the only forum for discussion of the URL generic syntax
document.

From: Masataka Ohta <[email-masked]>
Subject: Re: [URN] Re: URL internationalization!
To: [email-masked] (YON - Jan C. Hardenbergh)
Date: Thu, 20 Feb 97 15:15:59 JST
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Masataka Ohta <[email-masked]>

YON

> > > > ASCII script is rich enough to denote French, Japanese, Thai,
> > > > Arabic, Hindi...
> > >
> > > This is just wrong!
> > 
> > Look at international airline tickets of people from France, Japan,
> > Thai, Arab and India and tell me what is wrong.
> 
> I was trying to decipher my airline ticket the other day. The first
> problem is that NO ONE can pronounce anyone's name.

Very good point. Still, anyone can transcribe your name.

Don't make NO ONE can pronouce nor transcibe anyone's URL.

> Living in the US
> with a name like Jan makes this a hot button for me.

Does "Jan" contain non-ASCII characters?

> > We are not interested in transcribing pronounciation of various
> > language to the accuracy of IPA, which is sometimes excessive
> > and somtimes insufficient.
> 
> Show me the way.

Of what?

> > Each language already has its own denotation system in basic 26
> > Latin alphabets, most, if not all, of them are unrelated to IPA.
> 
> Spec'd by whom?

In Japan, it's ministry of foreign affairs.

You should ask airline office.

> > Multi-language support is doable with ASCII only and is orthogonal
> > to multi-script support.
> 
> ???

Let's see the following Japanese translation of my sentence above:

	Maruchi ringaru sapohto ha asukii dakede dekirunode atte,
	maruchi sukuriputo sapohto toha chokkou suru gainen da.

which is a sentence of Japanese language with Latin script.

That is, this mail is a bi-lingual mail with ASCII only.

> > > Besides, all you ASCII lovers should be exceptionally excited by
> > > Martin's proposal because ASCII is a subset of utf8 (RFC 2044)
> > 
> > No, not at all. ISO-2022-{JP, KR, CN, JP-2} are all supersets
> > of ASCII and better than utf8 in all aspects.
> 
> Font management with ISO 2022 is intractable! 

Wrong. It is only that whether some font is available or not.

So is ISO 10646. Read RFC 1815.

And, it is usually the case that when someone does not have a font
of some character, that person can't read the character, anyway.

Still, I can type "Jan". Isn't it a great multilingual monoscript
internationalization accomplished by ASCII?

> > UTF8 is not a proper charset at all. Look at RFC 1815 on how
> > to construct proper charsets from ISO 10646.
> 
> Of course utf8 is not a charset. It is an encoding of ISO 10646.

Absolutely.

						Masataka Ohta

Date: Wed, 19 Feb 1997 22:00:08 -0800
From: "YON - Jan C. Hardenbergh" <[email-masked]>
Organization: Netscape Communications
To: Masataka Ohta <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: URL internationalization!
Sender: [email-masked]
Reply-To: "YON - Jan C. Hardenbergh" <[email-masked]>

Masataka Ohta wrote:
> 
> > > ASCII script is rich enough to denote French, Japanese, Thai,
> > > Arabic, Hindi...
> >
> > This is just wrong!
> 
> Look at international airline tickets of people from France, Japan,
> Thai, Arab and India and tell me what is wrong.

I was trying to decipher my airline ticket the other day. The first
problem is that NO ONE can pronounce anyone's name. Living in the US
with a name like Jan makes this a hot button for me.

> > Perhaps, if you used the ASCII hacking of the IPA, I could go along
> > with that.
> 
> No, we don't.
> 
> We are not interested in transcribing pronounciation of various
> language to the accuracy of IPA, which is sometimes excessive
> and somtimes insufficient.

Show me the way.

> Each language already has its own denotation system in basic 26
> Latin alphabets, most, if not all, of them are unrelated to IPA.

Spec'd by whom?

> Multi-language support is doable with ASCII only and is orthogonal
> to multi-script support.

???

> > Besides, all you ASCII lovers should be exceptionally excited by
> > Martin's proposal because ASCII is a subset of utf8 (RFC 2044)
> 
> No, not at all. ISO-2022-{JP, KR, CN, JP-2} are all supersets
> of ASCII and better than utf8 in all aspects.

Font management with ISO 2022 is intractable! 

> UTF8 is not a proper charset at all. Look at RFC 1815 on how
> to construct proper charsets from ISO 10646.

Of course utf8 is not a charset. It is an encoding of ISO 10646.

YON

From: Masataka Ohta <[email-masked]>
Subject: Re: [URN] Re: URL internationalization!
To: [email-masked] (YON - Jan C. Hardenbergh)
Date: Thu, 20 Feb 97 14:50:35 JST
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Masataka Ohta <[email-masked]>

> > ASCII script is rich enough to denote French, Japanese, Thai,
> > Arabic, Hindi...
> 
> This is just wrong!

Look at international airline tickets of people from France, Japan,
Thai, Arab and India and tell me what is wrong.

> Perhaps, if you used the ASCII hacking of the IPA, I could go along
> with that.

No, we don't.

We are not interested in transcribing pronounciation of various
language to the accuracy of IPA, which is sometimes excessive
and somtimes insufficient.

Each language already has its own denotation system in basic 26
Latin alphabets, most, if not all, of them are unrelated to IPA.

Multi-language support is doable with ASCII only and is orthogonal
to multi-script support.

> Besides, all you ASCII lovers should be exceptionally excited by
> Martin's proposal because ASCII is a subset of utf8 (RFC 2044)

No, not at all. ISO-2022-{JP, KR, CN, JP-2} are all supersets
of ASCII and better than utf8 in all aspects.

UTF8 is not a proper charset at all. Look at RFC 1815 on how
to construct proper charsets from ISO 10646.

						Masataka Ohta

Date: Wed, 19 Feb 1997 21:06:59 -0800
From: "YON - Jan C. Hardenbergh" <[email-masked]>
Organization: Netscape Communications
To: Masataka Ohta <[email-masked]>
Cc: "Alain LaBont/e'/" <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: URL internationalization!
Sender: [email-masked]
Reply-To: "YON - Jan C. Hardenbergh" <[email-masked]>

> ASCII script is rich enough to denote French, Japanese, Thai,
> Arabic, Hindi...

This is just wrong!

Perhaps, if you used the ASCII hacking of the IPA, I could go along
with that. http://www.arts.gla.ac.uk/IPA/ipa.html

Besides, all you ASCII lovers should be exceptionally excited by
Martin's proposal because ASCII is a subset of utf8 (RFC 2044)

IPA: YON
ASCII: Jan C. Hardenbergh
Vanity: www.jch.com/~jch/

From: Masataka Ohta <[email-masked]>
Subject: [URN] Re: URL internationalization!
To: [email-masked] (Alain LaBont/e'/)
Date: Thu, 20 Feb 97 12:49:54 JST
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Masataka Ohta <[email-masked]>

Alain;

> The moral of the story is that we ought to use a worlwide character set
> where even Japanese characters are integrity-preserved everywhere!

It has nothing to do with URL internationalization.

We don't use worldwide characters on our international airline tickets.

> Any
> language can be used internationally, not only English.

The issue is not language, but script.

ASCII-only Latin script is perfectly fine as a formal notation of,
say, Japanese. For example, Japanese sentence "Doumo" in ASCII
means "Hi" in English.

> We should not detour
> the issue.

OK.

The current detouring attempt of Unicode/ISO 10646 on local script
support is that they are confusing people like you with no real
internationzalization expertise not to be able to distinguish
"language" and "script".

So, if you don't want to detour, never say "language-tag" when
what you need is "script-tag", which is MIME charset.

> The net result to use ASCII worldwide plus a local character set
> only on a cultural island would be that English would dominate everywhere
> and other languages at a major disadvantage.

Sure. That's exactly why Unicde/ISO 10646 is no good.

But, it has nothing to do with the attempt of URL localization.

> This is not what I call
> internationalization, that is insularization.

If you don't want to insulate yourself within ISO-8859-1 community,
don't use ISO-8859-1.

The more conservative you send, the more people can read it.

ASCII script is rich enough to denote French, Japanese, Thai,
Arabic, Hindi...

> The main moral of the story is that ASCII is not the solution!

ASCII is not the solution of plain text internationalization to
support mixed multiple scripts, nor is ISO 10646.

But, it has nothing to do with the fact that localized URLs are
agaist internationalization.

							Masataka Ohta

Date: Wed, 19 Feb 1997 09:27:04 -0500
To: "Martin J. Duerst" <[email-masked]>, Masataka Ohta <[email-masked]>
From: "Alain LaBont/e'/" <[email-masked]>
Subject: [URN] Re: URL internationalization!
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "Alain LaBont/e'/" <[email-masked]>

@ 11:09 97-02-19 +0100, Martin J. Duerst icrit :
>Masataka -
>
>On Wed, 19 Feb 1997, you wrote:
>
>> Alain;
>> 
>> > In Canada that is done all the time... there are URLs in newspapers (in
>> > English and in French), on all TV channels (in many languages), in email
>> > (many languages too), on the radio networks (polyglot), through our ears
>> > (also polyglot (: )... We have to type, transcribe and mail URLs all
the time.
>> > 
>> > So I do not understand the objection to Martin D|rst.
>> 
>> Because you haven't read Martin. You don't have to, though. He
>> said you are not doing that.
>
>No, I didn't say so. What I said is that the practice of using
>characters besides ASCII without a specification of how the
>server will interpret them is not guaranteed to work. In the
>case of Canada, it will work in many cases because iso-8859-1
>is well established there in the context of the web. However,
>it will not work worldwide.

Right. That is why I support the idea that you submitted, Martin, that we
decide for a canonical worldwide character set for URLs. It should be
supported everywhere, and if display can't be done temporarily, that data
integrity be preserved at all time so that at some point, copies of copies
of copies will fall on the desk of somebody who can display.

Copies should be able to be cut-and-pasted and preserved integrity too.

Keyboarding is useful requirement too. There is a standard for this, ISO/IEC
14755.

Alain LaBonti
Quibec

Date: Wed, 19 Feb 1997 09:37:07 -0500
To: Masataka Ohta <[email-masked]>, [email-masked] (Martin J. Duerst)
From: "Alain LaBont/e'/" <[email-masked]>
Subject: [URN] Re: URL internationalization!
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "Alain LaBont/e'/" <[email-masked]>

At 19:31 97-02-19 JST, Masataka Ohta wrote:
>> No, I didn't say so. What I said is that the practice of using
>> characters besides ASCII without a specification of how the
>> server will interpret them is not guaranteed to work. In the
>> case of Canada, it will work in many cases because iso-8859-1
>> is well established there in the context of the web. However,
>> it will not work worldwide.
>
>The moral of the story is that interEuropeanization is not
>internationalization.

The moral of the story is that we ought to use a worlwide character set
where even Japanese characters are integrity-preserved everywhere! Any
language can be used internationally, not only English. We should not detour
the issue. The net result to use ASCII worldwide plus a local character set
only on a cultural island would be that English would dominate everywhere
and other languages at a major disadvantage. This is not what I call
internationalization, that is insularization.

The main moral of the story is that ASCII is not the solution!

Alain LaBonti
Quibec

From: Masataka Ohta <[email-masked]>
Subject: [URN] Re: URL internationalization!
To: [email-masked] (Martin J. Duerst)
Date: Wed, 19 Feb 97 19:31:07 JST
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Masataka Ohta <[email-masked]>

> No, I didn't say so. What I said is that the practice of using
> characters besides ASCII without a specification of how the
> server will interpret them is not guaranteed to work. In the
> case of Canada, it will work in many cases because iso-8859-1
> is well established there in the context of the web. However,
> it will not work worldwide.

The moral of the story is that interEuropeanization is not
internationalization.

						Masataka Ohta

Date: Wed, 19 Feb 1997 11:09:27 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: Masataka Ohta <[email-masked]>
Cc: "Alain LaBont/e'/" <[email-masked]>, [email-masked], [email-masked]
Subject: [URN] Re: URL internationalization!
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

Masataka -

On Wed, 19 Feb 1997, you wrote:

> Alain;
> 
> > In Canada that is done all the time... there are URLs in newspapers (in
> > English and in French), on all TV channels (in many languages), in email
> > (many languages too), on the radio networks (polyglot), through our ears
> > (also polyglot (: )... We have to type, transcribe and mail URLs all the time.
> > 
> > So I do not understand the objection to Martin Dürst.
> 
> Because you haven't read Martin. You don't have to, though. He
> said you are not doing that.

No, I didn't say so. What I said is that the practice of using
characters besides ASCII without a specification of how the
server will interpret them is not guaranteed to work. In the
case of Canada, it will work in many cases because iso-8859-1
is well established there in the context of the web. However,
it will not work worldwide.

Regards,	Martin.

Date: Tue, 18 Feb 1997 20:28:50 -0800 (PST)
From: "Gregory J. Woodhouse" <[email-masked]>
To: "Alain LaBont/e'/" <[email-masked]>
Cc: Masataka Ohta <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: URL internationalization!
Sender: [email-masked]
Reply-To: "Gregory J. Woodhouse" <[email-masked]>

I always thought the original comment about transcribability was meant as
irony. You know: no one needs to transcribe URLs, except ...

---
[email-masked]    /    http://www.wnetc.com/home.html
If you're going to reinvent the wheel, at least try to come
up with a better one.

Comments: Authenticated sender is <[email-masked]>
From: "Alain LaBont/e'/" <[email-masked]>
To: [email-masked] (Alain LaBont/e'/), Masataka Ohta <[email-masked]>
Date: Tue, 18 Feb 1997 23:17:21 +0005
Comments: Sender has elected to use 8-bit data in this message. If problems arise, refer to postmaster at sender's site.
Subject: [URN] Re: URL internationalization!
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Priority: normal
Sender: [email-masked]
Reply-To: "Alain LaBont/e'/" <[email-masked]>

> From:          Masataka Ohta <[email-masked]>
> Subject:       Re: URL internationalization!
> To:            [email-masked] (Alain LaBont/e'/)
> Date:          Wed, 19 Feb 97 12:54:58 JST
> Cc:            [email-masked], [email-masked], [email-masked],
>                [email-masked]

> Alain;
> 
> > In Canada that is done all the time... there are URLs in newspapers (in
> > English and in French), on all TV channels (in many languages), in email
> > (many languages too), on the radio networks (polyglot), through our ears
> > (also polyglot (: )... We have to type, transcribe and mail URLs all the time.
> > 
> > So I do not understand the objection to Martin D|rst.
> 
> Because you haven't read Martin. You don't have to, though. He
> said you are not doing that.
> 
> 						Masataka Ohta

??????

Alain LaBonti
Quibec

From: Masataka Ohta <[email-masked]>
Subject: [URN] Re: URL internationalization!
To: [email-masked] (Alain LaBont/e'/)
Date: Wed, 19 Feb 97 12:54:58 JST
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Masataka Ohta <[email-masked]>

Alain;

> In Canada that is done all the time... there are URLs in newspapers (in
> English and in French), on all TV channels (in many languages), in email
> (many languages too), on the radio networks (polyglot), through our ears
> (also polyglot (: )... We have to type, transcribe and mail URLs all the time.
> 
> So I do not understand the objection to Martin D|rst.

Because you haven't read Martin. You don't have to, though. He
said you are not doing that.

						Masataka Ohta

Date: Tue, 18 Feb 1997 22:46:38 -0500
To: Masataka Ohta <[email-masked]>, [email-masked] (Martin J. Duerst)
From: "Alain LaBont/e'/" <[email-masked]>
Subject: [URN] Re: URL internationalization!
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "Alain LaBont/e'/" <[email-masked]>

A 12:23 97-02-19 JST, Masataka Ohta a icrit :
>Martin;
>
>The discussion that the Internetionalized URL is the ASCII-only
>URL has already finished a few years ago.
>
>You have raised no now point.
>
>Perhaps, you have never used WWW browsers yet, but, those of us
>who have know that we don't need URL human readable unless it
>is keyboarded, transcribed or mailed.

In Canada that is done all the time... there are URLs in newspapers (in
English and in French), on all TV channels (in many languages), in email
(many languages too), on the radio networks (polyglot), through our ears
(also polyglot (: )... We have to type, transcribe and mail URLs all the time.

So I do not understand the objection to Martin D|rst.

Saionara. Gru_.

Alain LaBonti
Quibec

From: Masataka Ohta <[email-masked]>
Subject: [URN] Re: URL internationalization!
To: [email-masked] (Martin J. Duerst)
Date: Wed, 19 Feb 97 12:23:45 JST
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Masataka Ohta <[email-masked]>

Martin;

The discussion that the Internetionalized URL is the ASCII-only
URL has already finished a few years ago.

You have raised no now point.

Perhaps, you have never used WWW browsers yet, but, those of us
who have know that we don't need URL human readable unless it
is keyboarded, transcribed or mailed.

Try, for example, Netscape.

							Masataka Ohta

Date: Tue, 18 Feb 1997 10:04:19 -0700
To: "Gregory J. Woodhouse" <[email-masked]>, [email-masked]
From: "Ron Daniel Jr." <[email-masked]>
Subject: Re: [URN] What to use for NID's?
Cc: [email-masked]
Sender: [email-masked]
Reply-To: "Ron Daniel Jr." <[email-masked]>

At 05:50 AM 2/18/97 -0800, Gregory J. Woodhouse wrote:
>On Tue, 18 Feb 1997 [email-masked] wrote:
>
>> I've been looking at Ron's conventions draft and playing around with
>> setting up a couple of namespaces and I got to wondering...
>> 
>> I believe that we still have to put together a document covering
>> the registration requirements of a namespace (which I am not
>> volunteering
>> to do ;-), 

I'm appending some rough material tha tmight be used to start such a
draft.

>>but are we willing to allow the "x-" convention?
>
>Why not? We miht want to make a distinction between globally unique names
>and globally resolvable names. I can understand concern over the
>possibility of NIDs in the x- namespace that aren't globally unique (even
>then, an argument could be made), but why not allow names that can only be
>resolved locally? I've been thinking about doing something like this where
>the names would reference database records.

While I am not adamantly opposed to "x-", I know people who are and I
find their arguments pretty sound. There are two major goals for URNs,
persistence and location-independence. It seems to me that "x-" violates
the intent of persistence, and are not necessary for local experiments.

Assume you have used "x-foo" for a local namespace identifier in an
experiment. The experiment is declared a success and you want to start
using "foo" as the NID. All your old documents and citations have to be
changed - exactly what we are trying to avoid with URNs.

For local experiments, do what we are doing. Our proxy looks at the
incoming URNs to see if the NID is one that we have local knowledge
of. (e.g. we are starting to use SICIs to identify e-journal articles.
We have a local repository of those articles, so our proxy checks our
local repository before doing the fallback to sici.urn.net.) So,
if your proxy can trap requests for the local "foo" NID, there is no
need for "x-". 

====

Namespace Requirements - fodder for a future Internet Draft

URN namespaces will need to be unique, which implies IANA or a similar
organization will need to run a registry for them. Here are some rules
that they might apply when deciding to register namespaces:

0a: Does the namespace meet the requirements of uniqueness, transcribability,
    etc. from the URN Requirements RFC?
0b: Does its encoding as a URN meet the URN Syntax draft/RFC?

1a: Is it an already-existing internationally standardized namespace?
1b: Is the entity making the request a duly-authorized representative
    of an organization that has a legitimate claim to register the
    namespace?
1c: Are any resolution procedures (such a NAPTR records) in accordance
    with the rules of conduct in that namespace and common business
    practices?

This set of rules seems restrictive, but is intended to allow for the
quick grandfathering of already-established namespaces of broad utility.
Examples of such namespaces are ISBN (International Standard Book Number),
ISAN (intl. Std. Audiovisual Number), ISWC (Intl. Std. Work Code), UPC
(Uniform Product Code), FPI (Formal Public Identifier). These are all
namespaces that have been standardized by ISO, so the first question
is answered. Not just anyone can claim to represent such a namespace.
Namespaces will typically identifiy one or more registration agencies
who have responsibility for the daily operation of the namespace. If the
reqistration request does not come from a authorized representative of such
a registration agency, it shall be denied. The third question is to ensure
even competition for name resolution services. If multiple companies are
already in the business of resolving identifiers from a namespace, they should
all have an equal chance to have their resolver contacted.

2a: If not an international standard, is the namespace from a National
    standards-setting body?
2b: (See 1b)
2c: (See 1c)

If the namespace is the product of a national standards organization, it shall
be registered unless the namespace has already been considered by an
international standards organization and rejected or modified.

3a: Does the namespace come from a national or international industry
    association that does not have Standards-developing status?
3b, 3c as above
3d: Is there no internationally standardized namespace that fulfills
    the same role, or into which this namespace can be "reasonably"
    grandafthered?

Namespaces may arise from organizations like the Natl. Association of
Manufacturers.

4a: If the namespace is the product of a commercial organization, can it
    accomodate a reasonably large set of other organizations?
4b, 4c, 4d as above.

This is to allow organizations like the barcode vendors, Dunn&Bradstreet,
etc. to register their namespaces, while trying to preclude vanity namespaces.
I think we want to explicitly discourage vanity namespaces. If Disney wants
to use urn:disney:whatever to identify their videos, etc. we should ask them
to justify why namespaces such as UPC (which they already use) and ISAN are
inappropriate. 

5a: Is it early enough in the experimental period, and did the namespace
    applicants buy the registry administrators enough beer, that the
    registry administrators decide to make a special case?

This is called "bowing to reality" :-)

Ron Daniel Jr.              voice:+1 505 665 0597
Advanced Computing Lab        fax:+1 505 665 4939
MS B287                     email:[email-masked]
Los Alamos National Lab      http://www.acl.lanl.gov/~rdaniel
Los Alamos, NM, USA, 87545  

Date: Tue, 18 Feb 1997 16:10:41 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: [email-masked]
Subject: Re: [URN] URL internationalization!
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

On Tue, 18 Feb 1997, Martin J. Duerst wrote:

> Hello everybody,
> 
> In the next mail to this list and its counterpart, I will make
> proposals for changes/additions to the syntax or the process draft.
> These changes are designed to set the direction for consistent
> internationalization (i18n) of URLs in the future.
> [The current state is best characterized by the word "chaos".]

I appologize that this mail went to the URN list, it was intended
to the URI and URL list. Anyway, maybe you like to see what's going
on, URNs are not unaffeced by it.

Regards,	Martin.

Date: Tue, 18 Feb 1997 12:53:05 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: URL mailing list <[email-masked]>, [email-masked]
Subject: [URN] URL internationalization!
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

Hello everybody,

[Please appologize if you receive this mail twice.]

In the next mail to this list and its counterpart, I will make
proposals for changes/additions to the syntax or the process draft.
These changes are designed to set the direction for consistent
internationalization (i18n) of URLs in the future.
[The current state is best characterized by the word "chaos".]

As is customary for standards, language is limited to the facts,
without much background. To give you this background, and show
that the direction pointed to is very reasonable, I am sending
this mail with detailled explanations to show that it actually
works. If you have any further questions, I will be glad to
answer them. If the changes proposed are approved, I will
convert and expand the main part of this mail into an internet
draft.

My proposals to the URL process and syntax draft are based on
many discussions in conferences and on IETF mailing lists, and
talks on this issue in the last Unicode conference and at the
Multilinguism workshop in Sevilla.

Overview
--------

0. The Current State
1. The Solution
2. The Proposals
3. The Second Step
4. Backwards Compatibility and Upgrade Path

0. The Current State
--------------------

URLs currently are sequences of a limited subset of ASCII characters.
To encode other characters, arbitrary and unspecified character
encodings ("charset"s) are used, and the resulting octets are encoded
using the %HH escaping mechanism.

The first step of this is highly unsatisfactory because
it cannot be inverted, i.e. you cannot derive the characters from
the octets, and because even forward conversion cannot be done without
some additional information, i.e. if you know the characters of a file
name, you can't construct the URL, because you don't know the encoding
that the server will expect.

The above is current practice, and can't be changed overnight,
especially because a lot of protocols and software is affected.
But it is possible to specify the direction to go, and to start
moving in that direction.

Maybe you ask why caring about the internationalization of URLs
is necessary at all. Well, for some parts of URLs (in particular
the query part), i18n is undeniably necessary, and for others,
not doing it is putting people and communities using something
else than basic Latin at an unnecessary disadvantage.
Of course, no information provider will be forced to use these
features. But as an example, take the Hong Kong Turist Association
adventising Hong Kong in the US and in Japan. It will only help
them if the URL to their Japanese site is as understandable,
memorizable, transcribable, or guessable for Japanese speakers
as the ASCII URL is for English speakers.

The arguments that i18n URLs cannot be keyboarded, transcribed,
or mailed may have had some significance in the past, but are
getting less and less valid. On the Web, with forms and Java,
it's easy to offer a keyboarding service for the whole of UNicode.

Anyway, the proposals I am making here are not at all going that
far. I am just mentionning these things above and below to show
that it's actually workable and desirable. Discussions on the
URN list have shown that some people are still very sceptical
about transcribability. The work on HTML 2.0 and HTML i18n
has shown that it is possible to move towards i18n in a
well-defined way even at a rather late stage.

1. The Solution
---------------

To solve the problem that character encodings are not known,
there could be different solutions. Using tags (a la RFC 1522)
is ugly because these tags would have to be carried around
on paper and everywhere. Having every scheme and mechanism use
different conventions is also rather impracticable because this
leads to confusion (e.g. if the dns part of an URL is different
from the path part because dns and http use different conventions).
Inventing new schemes for internationalization (e.g. ftp->iftp)
is likewise too clumsy.

The solution that remains is to specify preference for a single
character encoding. Because this has to encompass a very wide
range of characters, the Universal Character Set (UCS) of
Unicode/ISO 10646 is the only solution. To be compatible with
ASCII, there exist two UCS Transform Formats, UTF-7 and UTF-8.
UTF-7, however, has various disadvantages. Some of the characters
it uses can have special functions inside URLs. It is not completely
compatible with ASCII. And it has some potential limitations with
regards to the full space of UCS (although the later point is rather
theoretical).

UTF-8, designed by Rob Pike and others at Bell labs, is not perfect
for URLs either. But it is fully ASCII-compatible, and doesn't
interfere with URL syntax. Also, the problem that it uses all 8 bits
per octet is solved by the widely deployed %HH-encoding of URLs.
The problem that with %HH-ecoding, some URLs can get rather long,
will hopefully be addressed by the direct use of the characters
themselves somewhere in the future (see below).

UTF-8 has an additional addvantage, namely that it is
with high probability easily distinguishable from legacy
encodings. This was one of the reasons it was adopted for
internationalizing FTP (see draft-ietf-ftpext-intl-ftp-00.txt).
URNs also have adopted UTF-8 and %HH-encoding (see
draft-ietf-urn-syntax-02.txt). This is important because
URLs and URNs are both part of URIs, and are otherwise
kept in synch syntacticatly. Also, the general recommendation
from the Internet Architecture Board is to use UTF-8 in
situations where ASCII-compatibility is necessary
(see draft-weider-iab-char-wrkshop-00.txt).

This has lead to the conclusion, in the various discussions I have
been involved, that UTF-8 is the solution. A good documentation
on this can found at http://www.alis.com:8085/~yergeau/url-00.html).
Actually, Francois Yergeau was faster than me to realize that UTF-8
is the way to go, and we wouldn't be where we are now if it weren't
for his efforts.

2. The Proposals
----------------

In Sevilla, I proposed two steps to move towards the solution.
The first step is to specify UTF-8 as the preferred character
encoding for URLs, while leaving URLs unchanged otherwise.
This brings the target for URLs in sync with the spec for URNs.
For reasons already explained, the proposals for changes to the
syntax and process draft I make cover only the first step.
For most people caring about i18n, this looks like "not enough".
But it is important to set the basic infrastructure first.
Once we have that, the rest will come almost without effort.

The two important points in the first step are "no enforcement"
and "canonical form" (a better name for the later might be
lowest common denominator).

Canonical form means that %HH-escaping is compulsory, and no 8-bit
or native encoding is allowed. This is important to stay in sync
with URNs, to allow UTF-8 URL software and actual URLs to deploy
before raising the expectations of users too much, and to address
the concerns about transcribability of those in the URI community
not very familliar with i18n issues.
Of course, as with URNs, even with the canonical form only, it
will be possible rather quickly to offer nice user interfaces
hiding the %HH (once you know how the conversion is done!).

Due to current use, it is impossible to mandate any character
encoding for URLs; a lot of URLs would immediately become illegal.
Also, URLs are a "hat" over many very different protocols and
mechanisms, which all have their own communities and special
needs. Some URLs, such as the "data:" URL, do not encode characters
at all (but most actually do :-). Others might have very specific
requirements that preclude the use of UTF-8, or may not need
i18n at all for some good reason. However, please note that
there is no need for the protocol or mechanism itself to use
UTF-8 for internationalization. Assuming the protocol or mechanism
is internationalized, with a well-defined way to encode the characters
of UCS, a mapping from UTF-8 to that specific encoding can be defined.
This is preferable to exposing the scheme-specific i18n in URLs,
because it greatly simplifies URL handling and user interface
issues. For examples of scheme- or mechanism-specific i18n,
please see IMAP [RFC 2060, section 5.1.3], defining "modified UTF-7",
and the "UTF-5" from my proposal for domain name i18n
(draft-duerst-dns-i18n-00.txt).

3. The Second Step
------------------

Once the direction towards using UTF-8 as the character encoding
for URL is firmly set, and other i18n aspects are nicely covered
by software such as browsers and servers, it will be time for
step two, I hope. This means that %HH-escaping will not be
mandatory anymore. Note that this does not mean that binary
UTF-8 will be placed in the middle of an ASCII-only document,
or in a Latin-X document, or in a UCS2/UTF-16 document.

In these cases, and in all others where the character encoding
is implicitly or explicitly known, those characters that can
be represented natively will be encoded using the native encoding.
For the rest of the characters, UTF-8 and %HH-encoding will
be used. This is crucial to make transcoding, for example
in response to an "Accept-Charset:" header in HTTP, as well
as e.g. when cutting/pasting text in a GUI interface, work
correctly. It also conforms what is done currently with the
basic URL characters e.g. in a document encoded in EBCDIC.

4. Backwards Compatibility and Upgrade Path
-------------------------------------------

Backwards compatibility is fully guaranteed. No URL that was
legal up to now is made illegal. No URL that works now is
stopping to work. And it is actually possible to convert
to using UTF-8 gradually, without the servers depending on
all clients to be upgraded or vice versa. And even those
cases that already use native document encoding for their
URLs, and rely on them being interpreted octet-wise, can
be dealt with, to the extent they have been working up to
now.

If a server e.g. has a Latin-X filesystem locally, and gets an URL
that could be UTF-8, it converts it to Latin-X and looks if the
resource is there. If the resource is not found, it tests using
the raw octets directly. Because of the heuristic separation between
UTF-8 and other encodings, and the usually extremely sparse use of
namespace on a server (except for forms input, see below), chances
for collision are exorbitantly small. If somebody is not satisfied
with this, it's easy to add an extension that checks all current
resource names and assures that there are no conflicting resource
names, or that in case of conflict, the user gets a choice.

A similar thing can happen on the browser side. A native URL,
in whatever encoding, is converted to UTF-8 and used to probe the
server. If it fails, another probe is made with the raw octet form
of the native URL. Initially, it could be done the other way round,
as long as that can be expected to yield more hits. Caching of the
encoding that led to the last hit, on whatever granularity desirable,
can help to reduce unnecessary connections. And the time penalty is
not that significant, because the current use of native character
representation with the expectation of binary interpretation has
never been guaranteed to work anyway.

Now for those URLs that the server creates on the fly, in particular
the query part that results from form input. This currently is the
biggest headache to people actually working on i18n of browsers and
servers, and an uniform convention to use UTF-8 would improve the
situation a lot. Unfortunately, however, the namespace in this case
is more tightly populated. A server has a reasonable chance, depending
on the character encodings it is expecting, to detect UTF-8. But a
client doesn't have many clues about the server.

Because this is a rather old problem, several solutions have been
proposed and some of them are (partially) implementated. The first
is (in the context of HTTP) to use a GET with a multipart body,
where each of the parts has an appropriate "charset" tag. The second
is to incorporate a hidden field into the FORM, and guess the encoding
by reasonably assuming that the client is sending the same characters
back, although maybe in a different encoding, and that all fields
use the same character encoding. The third is to use the encoding
of the document that was sent, with UTF-8 also in the case of
UCS2/UTF-16 or raw UCS4. However, it is not sure that on a server
that can transcode to Unicode, all the scripts will be able to
accept Unicode. The fourth is to use the "Accept-Charset=" attribute
defined in RFC 2070 for the <INPUT> and <TEXTAREA> elements in
HTML <FORM>s to signal to the client that the server can handle
UTF-8 forms input. If the legacy text encoding for query parts is
known, this could even be handled transparently by the server.
Because these features are only defined in HTML, it is important
to agree on a single encoding to not bother other formats with
similar hassles.

Again, if you have any questions or comments, please contact me.

With kind regards,	Martin.

----
Dr.sc.  Martin J. Du"rst			    ' , . p y f g c R l / =
Institut fu"r Informatik			     a o e U i D h T n S -
der Universita"t Zu"rich			      ; q j k x b m w v z
Winterthurerstrasse  190			     (the Dvorak keyboard)
CH-8057   Zu"rich-Irchel   Tel: +41 1 257 43 16
 S w i t z e r l a n d	   Fax: +41 1 363 00 35   Email: [email-masked]
----

Date: Tue, 18 Feb 1997 05:50:14 -0800 (PST)
From: "Gregory J. Woodhouse" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [URN] What to use for NID's?
Sender: [email-masked]
Reply-To: "Gregory J. Woodhouse" <[email-masked]>

On Tue, 18 Feb 1997 [email-masked] wrote:

> I've been looking at Ron's conventions draft and playing around with
> setting up a couple of namespaces and I got to wondering...
> 
> I believe that we still have to put together a document covering
> the registration requirements of a namespace (which I am not
> volunteering
> to do ;-), but are we willing to allow the "x-" convention?
> 
> That is, namespace id's that begin with "x-" are considered
> experimental,
> etc., etc.
> 
> What do people think?
> 
> Ryan
> 

Why not? We miht want to make a distinction between globally unique names
and globally resolvable names. I can understand concern over the
possibility of NIDs in the x- namespace that aren't globally unique (even
then, an argument could be made), but why not allow names that can only be
resolved locally? I've been thinking about doing something like this where
the names would reference database records.

---
[email-masked]    /    http://www.wnetc.com/home.html
If you're going to reinvent the wheel, at least try to come
up with a better one.

From: [email-masked]
Date: Tue, 18 Feb 1997 08:10:40 -0500
Original-From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: [email-masked]
Subject: [URN] What to use for NID's?
Sender: [email-masked]
Reply-To: [email-masked]

I've been looking at Ron's conventions draft and playing around with
setting up a couple of namespaces and I got to wondering...

I believe that we still have to put together a document covering
the registration requirements of a namespace (which I am not
volunteering
to do ;-), but are we willing to allow the "x-" convention?

That is, namespace id's that begin with "x-" are considered
experimental,
etc., etc.

What do people think?

Ryan

From: [email-masked]
Date: Tue, 18 Feb 1997 08:04:53 -0500
Original-From: WebFinder Administration <[email-masked]>
Organization: InterNIC Directory and Database Services
To: Leslie Daigle <[email-masked]>
Cc: Ryan Moats <[email-masked]>, "Ron Daniel Jr." <[email-masked]>, [email-masked]
Subject: Re: [URN] New URN syntax draft
Sender: [email-masked]
Reply-To: [email-masked]

Leslie Daigle wrote:
> 
> [From Ryan's message:]
> > > >7. Functional Equivalence in URNs
> > >
> > > Do we really need this section?
> >
> > I don't know.  If we can get rid of it, that would be fine with me
> > (shorter is
> > ALMOST ALWAYS better).
> 
> Although, given my stature, I definitely concur with the appreciation of
> shortness ;-)  I think we need to leave this section in.  It may say
> more than it ought at this point (in terms of defining how functional
> equivalence must be defined by each namespace).  However, I think it is
> important to have words in here that make it clear that it is NOT the
> job of the general URN spec to define equivalence beyond the metrics of
> the already-defined lexical equivalence.  If we don't have words in the
> draft, those that follow us may think it hadn't occurred to us to consider
> the problem, when in fact we are specifically pushing it out of our space.
> 
> Leslie.

Ok.  I will see about shortening this section when I work on the draft
later this week.

Further, I plan on incorporating most of Ron's suggestions since nobody
has complained about them, and they make pretty good sense to me.

So, be on the lookout for a pre-release of -03 of the document (I 
call it -02.1 ;-).  I want to try and go to WG final call in late Feb/
early March so we can move forward.

Ryan

From: [email-masked] (Leslie Daigle)
Date: Fri, 14 Feb 1997 18:22:00 -0500
To: Ryan Moats <[email-masked]>, "Ron Daniel Jr." <[email-masked]>
Subject: Re: [URN] New URN syntax draft
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked] (Leslie Daigle)

[From Ryan's message:]
> > >7. Functional Equivalence in URNs
> > 
> > Do we really need this section?
> 
> I don't know.  If we can get rid of it, that would be fine with me
> (shorter is
> ALMOST ALWAYS better).

Although, given my stature, I definitely concur with the appreciation of
shortness ;-)  I think we need to leave this section in.  It may say
more than it ought at this point (in terms of defining how functional
equivalence must be defined by each namespace).  However, I think it is
important to have words in here that make it clear that it is NOT the
job of the general URN spec to define equivalence beyond the metrics of
the already-defined lexical equivalence.  If we don't have words in the
draft, those that follow us may think it hadn't occurred to us to consider
the problem, when in fact we are specifically pushing it out of our space.

Leslie.

-- 

----------------------------------------------------------------------------

  "_Be_                                           Leslie Daigle
             where  you                           
                          _are_."                 Bunyip Information Systems
                                                  (514) 875-8611
                      -- ThinkingCat              [email-masked]
----------------------------------------------------------------------------

From: "Ronald E. Daniel" <[email-masked]>
Date: Fri, 14 Feb 1997 12:22:26 -0700 (MST)
To: [email-masked]
Subject: [URN] NAPTR draft
Sender: [email-masked]
Reply-To: "Ronald E. Daniel" <[email-masked]>

Hi,

Here is the latest version of the NAPTR draft.

Ron
===

INTERNET DRAFT                                                  Ron Daniel
draft-ietf-urn-naptr-02.txt                 Los Alamos National Laboratory
                                                          Michael Mealling
                                                   Network Solutions, Inc.
                                                             14 Feb., 1996

                Resolution of Uniform Resource Identifiers
                       using the Domain Name System

Status of this Memo
===================

    This document is an Internet-Draft.  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.''
  
    To learn the current status of any Internet-Draft, please check
    the ``1id-abstracts.txt'' listing contained in the Internet-
    Drafts Shadow Directories on ftp.is.co.za (Africa),
    nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
    ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).

    This draft expires 22 August, 1997.

Abstract:
=========

Uniform Resource Locators (URLs) are the foundation of the World Wide
Web, and are a vital Internet technology. However, they have proven to
be brittle in practice. The basic problem is that URLs typically
identify a particular path to a file on a particular host. There is no
graceful way of changing the path or host once the URL has been
assigned. Neither is there a graceful way of replicating the resource
located by the URL to achieve better network utilization and/or fault
tolerance. Uniform Resource Names (URNs) have been hypothesized as a
adjunct to URLs that would overcome such problems. URNs and URLs are
both instances of a broader class of identifiers known as Uniform
Resource Identifiers (URIs).

This document describes a new DNS Resource Record, NAPTR (Naming
Authority PoinTeR), that provides rules for mapping parts of URIs to
domain names.  By changing the mapping rules, we can change the host
that is contacted to resolve a URI. This will allow a more graceful
handling of URLs over long time periods, and forms the foundation for a
new proposal for Uniform Resource Names.

In addition to locating resolvers, the NAPTR provides for other naming
systems to be grandfathered into the URN world, provides independence
between the name assignment system and the resolution protocol system,
and allows multiple services (Name to Location, Name to Description,
Name to Resource, ...) to be offered.  In conjunction with the SRV RR,
the NAPTR record allows those services to be replicated for the purposes
of fault tolerance and load balancing.

Introduction:
=============

Uniform Resource Locators have been a significant advance in retrieving
Internet-accessible resources. However, their  brittle nature over time
has been recognized for several years. The Uniform Resource Identifier
working group proposed the development of Uniform Resource Names to serve
as persistent, location-independent identifiers for Internet resources
in order to overcome most of the problems with URLs. RFC-1737 [1] sets
forth requirements on URNs.

During the lifetime of the URI-WG, a number of URN proposals were
generated. The developers of several of those proposals met in a series
of meetings, resulting in a compromise known as the Knoxville framework.
The major principle behind the Knoxville framework is that the resolution
system must be separate from the way names are assigned. This is in
marked contrast to most URLs, which identify the host to contact and
the protocol to use. Readers are referred to [2] for background on the
Knoxville framework and for additional information on the context and
purpose of this proposal.

Separating the way names are resolved from the way they are constructed
provides several benefits. It allows multiple naming approaches and
resolution approaches to compete, as it allows different protocols and
resolvers to be used. There is just one problem with such a separation -
how do we resolve a name when it can't give us directions to its
resolver?

For the short term, DNS is the obvious candidate for the resolution
framework, since it is widely deployed and understood. However, it is
not appropriate to use DNS to maintain information on a per-resource
basis. First of all, DNS was never intended to handle that many
records. Second, the limited record size is inappropriate for catalog
information. Third, domain names are not appropriate as URNs.

Therefore our approach is to use DNS to locate "resolvers" that can
provide information on individual resources, potentially including the
resource itself. To accomplish this, we "rewrite" the URI into a domain
name following the rules provided in NAPTR records. Rewrite rules
provide considerable power, which is important when trying to meet the
goals listed above. However, collections of rules can become difficult
to understand. To lessen this problem, the NAPTR rules are *always*
applied to the original URI, *never* to the output of previous rules.

Locating a resolver through the rewrite procedure may take multiple
steps, but the beginning is always the same. The start of the URI
is scanned to extract its colon-delimited prefix. (For URNs, the
prefix is always "urn:" and we extract the following colon-delimited
namespace identifier. [3]). NAPTR resolution begins by taking the
extracted string, appending the well-known suffix ".urn.net", and
querying the DNS for NAPTR records at that domain name.  Based on the
results of this query, zero or more additional DNS queries may be
needed to locate resolvers for the URI. The details of the conversation
between the client and the resolver thus located are outside the bounds
of this draft. Three brief examples of this procedure are given in the
next section.

The NAPTR RR provides the level of indirection needed to keep the
naming system independent of the resolution system, its protocols, and
services.  Coupled with the new SRV resource record proposal[4] there
is also the potential for replicating the resolver on multiple hosts,
overcoming some of the most significant problems of URLs. This is an
important and subtle point. Not only do the NAPTR and SRV records allow
us to replicate the resource, we can replicate the resolvers that know
about the replicated resource. Preventing a single point of failure at
the resolver level is a significant benefit. Separating the resolution
procedure from the way names are constructed has additional benefits.
Different resolution procedures can be used over time, and resolution
procedures that are determined to be useful can be extended to deal
with additional namespaces.

Caveats
=======

The NAPTR proposal is the first resolution procedure to be considered
by the URN-WG. There are several concerns about the proposal which have
motivated the group to recommend it for publication as an Experimental
rather than a standards-track RFC.

First, URN resolution is new to the IETF and we wish to gain
operational experience before recommending any procedure for the
standards track. Second, the NAPTR proposal is based on DNS and
consequently inherits concerns about security and administration. The
recent advancement of the DNSSEC and secure update drafts to Proposed
Standard reduce these concerns, but we wish to experiment with those
new capabilities in the context of URN administration.  A third area of
concern is the potential for a noticeable impact on the DNS.  We
believe that the proposal makes appropriate use of caching and
additional information, but it is best to go slow where the potential
for impact on a core system like the DNS is concerned. Fourth, the
rewrite rules in the NAPTR proposal are based on regular expressions.
Since regular expressions are difficult for humans to construct
correctly, concerns exist about the usability and maintainability of
the rules. This is especially true where international character sets
are concerned.

Terminology
===========

"Must" or "Shall" - Software that does not behave in the manner that this
           document says it must is not conformant to this document.
"Should" - Software that does not follow the behavior that this document
           says it should may still be conformant, but is probably broken
           in some fundamental way.
"May" -    Implementations may or may not provide the described behavior,
           while still remaining conformant to this document.

Brief overview and examples of the NAPTR RR:
============================================

A detailed description of the NAPTR RR will be given later, but to give
a flavor for the proposal we first give a simple description of the
record and three examples of its use.

The key fields in the NAPTR RR are order, preference, service, flags,
regexp, and replacement:

* The order field specifies the order in which records MUST be processed
  when multiple NAPTR records are returned in response to a single query.
  A naming authority may have delegated a portion of its namespace to
  another agency. Evaluating the NAPTR records in the correct order is
  necessary for delegation to work properly.

* The preference field specifies the order in which records SHOULD be
  processed when multiple NAPTR records have the same value of "order".
  This field lets a service provider specify the order in which resolvers
  are contacted, so that more capable machines are contacted in preference
  to less capable ones.

* The service field specifies the resolution protocol and resolution
  service(s) that will be available if the rewrite specified by the
  regexp or replacement fields is applied. Resolution protocols are
  the protocols used to talk with a resolver. They will be specified in
  other documents, such as [5]. Resolution services are operations such
  as N2R (URN to Resource), N2L (URN to URL), N2C (URN to URC), etc.
  These will be discussed in the URN Resolution Services document[6], and
  their behavior in a particular resolution protocol will be given in
  the specification for that protocol (see [5] for a concrete example).

* The flags field contains modifiers that affect what happens in the
  next DNS lookup, typically for optimizing the process. Flags may also
  affect the interpretation of the other fields in the record, therefore,
  clients MUST skip NAPTR records which contain an unknown flag value.

* The regexp field is one of two fields used for the rewrite rules, and
  is the core concept of the NAPTR record. The regexp field is a String
  containing a sed-like substitution expression. (The actual grammar
  for the substitution expressions is given later in this draft). The
  substitution expression is applied to the original URN to determine
  the next domain name to be queried. The regexp field should be used
  when the domain name to be generated is conditional on information in
  the URI. If the next domain name is always known, which is
  anticipated to be a common occurrence, the replacement field should
  be used instead.

* The replacement field is the other field that may be used for the
  rewrite rule. It is an optimization of the rewrite process for the
  case where the next domain name is fixed instead of being conditional
  on the content of the URI. The replacement field is a domain name
  (subject to compression if a DNS sender knows that a given recipient
  is able to decompress names in this RR type's RDATA field). If the
  rewrite is more complex than a simple substitution of a domain name,
  the replacement field should be set to . and the regexp field used.

Note that the client applies all the substitutions and performs all
lookups, they are not performed in the DNS servers. Note also that it
is the belief of the developers of this document that regexps should
rarely be used. The replacement field seems adequate for the vast
majority of situations. Regexps are only necessary when portions of a
namespace are to be delegated to different resolvers. Finally, note
that the regexp and replacement fields are, at present, mutually
exclusive. However, developers of client software should be aware that
a new flag might be defined which requires values in both fields.

Example 1
---------

Consider a URN that uses the hypothetical DUNS namespace. DUNS numbers
are identifiers for approximately 30 million registered businesses
around the world, assigned and maintained by Dunn and Bradstreet. The
URN might look like:

                 urn:duns:002372413:annual-report-1997

The first step in the resolution process is to find out about the DUNS
namespace. The namespace identifier, "duns", is extracted from the URN,
prepended to urn.net, and the NAPTRs for duns.urn.net looked up. It
might return records of the form:

duns.urn.net
;;      order pref flags service          regexp        replacement
 IN NAPTR 100  10  "s"  "dunslink+N2L+N2C"  ""   dunslink.udp.isi.dandb.com
 IN NAPTR 100  20  "s"  "rcds+N2C"          ""   rcds.udp.isi.dandb.com
 IN NAPTR 100  30  "s"  "http+N2L+N2C+N2R"  ""   http.tcp.isi.dandb.com

The order field contains equal values, indicating that no name
delegation order has to be followed. The preference field indicates
that the provider would like clients to use the special dunslink
protocol, followed by the RCDS protocol, and that HTTP is offered as a
last resort. All the records specify the "s" flag, which will be
explained momentarily.  The service fields say that if we speak
dunslink, we will be able to issue either the N2L or N2C requests to
obtain a URL or a URC (description) of the resource. The Resource
Cataloging and Distribution Service (RCDS)[7] could be used to get a
URC for the resource, while HTTP could be used to get a URL, URC, or
the resource itself.  All the records supply the next domain name to
query, none of them need to be rewritten with the aid of regular
expressions.

The general case might require multiple NAPTR rewrites to locate a
resolver, but eventually we will come to the "terminal NAPTR". Once we
have the terminal NAPTR, our next probe into the DNS will be for a SRV
or A record instead of another NAPTR. Rather than probing for a
non-existent NAPTR record to terminate the loop, the flags field is
used to indicate a terminal lookup. If it has a value of "s", the next
lookup should be for SRV RRs, "a" denotes that A records should sought.
A "p" flag is also provided to indicate that the next action is
Protocol-specific, but that looking up another NAPTR will not be part
of it.

Since our example RR specified the "s" flag, it was terminal. Assuming
our client does not know the dunslink protocol, our next action is to
lookup SRV RRs for rcds.udp.isi.dandb.com, which will tell us hosts that
can provide the necessary resolution service. That lookup might return:

 ;;                          Pref Weight Port Target
 rcds.udp.isi.dandb.com IN SRV 0    0    1000 defduns.isi.dandb.com
                        IN SRV 0    0    1000 dbmirror.com.au
                        IN SRV 0    0    1000 ukmirror.com.uk

telling us three hosts that could actually do the resolution, and
giving us the port we should use to talk to their RCDS server.
(The reader is referred to the SRV proposal [4] for the interpretation
of the fields above).

There is opportunity for significant optimization here. We can return
the SRV records as additional information for terminal NAPTRs (and the
A records as additional information for those SRVs). While this
recursive provision of additional information is not explicitly blessed
in the DNS specifications, it is not forbidden, and BIND does take
advantage of it [8]. This is a significant optimization. In conjunction
with a long TTL for *.urn.net records, the average number of probes to
DNS for resolving DUNS URNs would approach one. Therefore, DNS server
implementors SHOULD provide additional information with NAPTR
responses. The additional information will be either SRV or A records.
If SRV records are available, their A records should be provided as
recursive additional information.

Note that the example NAPTR records above are intended to represent the
reply the client will see. They are not quite identical to what the
domain administrator would put into the zone files. For one thing, the
administrator should supply the trailing '.' character on replacement
domain names. An additional difference will be illustrated later.

Example 2 
---------

Consider a URN namespace based on MIME Content-Ids. The URN might look
like this:
  
        urn:cid:[email-masked]

(Note that this example is chosen for pedagogical purposes, and does
not conform to the recently-approved CID URL scheme.)

The first step in the resolution process is to find out about the CID
namespace. The namespace identifier, cid, is extracted from the URN,
prepended to urn.net, and the NAPTR for cid.urn.net looked up. It might
return records of the form:
 
 cid.urn.net
  ;;       order pref flags service        regexp           replacement
   IN NAPTR 100   10   ""     ""  "/urn:cid:.+@([^@]+)$/\1/i"    .
 
We have only one NAPTR response, so ordering the responses is not
a problem.  The replacement field is empty, so we check the regexp
field and use the pattern provided there. We apply that regexp to the
entire URN to see if it matches, which it does.  The \1 part of the
substitution expression returns the string "mordred.gatech.edu". Since
the flags field does not contain "s" or "a", the lookup is not terminal
and our next probe to DNS is for more NAPTR records: lookup(query=NAPTR,
"mordred.gatech.edu").

While mordred could have its very own NAPTR, maintaining those records
on all the machines at a site as large as Georgia Tech would be an
intolerable burden. Instead, a wildcard may be used so that the domain
administrator at Georgia Tech has only a single NAPTR record to
maintain. That record might look like:

*.gatech.edu IN NAPTR
;;       order pref flags service           regexp  replacement
  IN NAPTR 100  50  "s"  "z3950+N2L+N2C"     ""    z3950.tcp.gatech.edu.
  IN NAPTR 100  50  "s"  "rcds+N2C"          ""    rcds.udp.gatech.edu.
  IN NAPTR 100  50  "s"  "http+N2L+N2C+N2R"  ""    http.tcp.gatech.edu.

(Unlike all the other example records in this draft, the one above
is the contents of a zone file, not the response received by the
client. That is so that the wildcard can be seen.)

Continuing with our example, we note that the values of the order and
preference fields are equal in all records, so the client is free to
pick any record. The flags field tells us that these are the last NAPTR
patterns we should see, and after the rewrite (a simple replacement in
this case) we should look up SRV records to get information on the
hosts that can provide the necessary service.

Assuming we prefer the Z39.50 protocol, our lookup might return:
 
;;                        Pref Weight   Port Target
z3950.tcp.gatech.edu IN SRV 0    0      1000 z3950.gatech.edu
                     IN SRV 0    0      1000 z3950.cc.gatech.edu
                     IN SRV 0    0      1000 z3950.uga.edu

telling us three hosts that could actually do the resolution, and
giving us the port we should use to talk to their Z39.50 server.

Recall that the regular expression used \1 to extract a domain name
from the CID. There is a significant caveat about the use of
backslashes in DNS zone files. DNS treats backslashes as the escape
character so that '.' can be escaped when necessary. This means that
when a regular expression is entered into the zone file, the
backslashes must be escaped by another backslash.  For the case of the
cid.urn.net record above, the regular expression entered into the zone
file should be "/.+@([^@]+)/\\1/i".  When the client code actually
receives the record, the pattern will have been converted to
"/.+@([^@]+)/\1/i".

Example 3
---------

Even if URN systems were in place now, there would still be a
tremendous number of URLs.  It should be possible to develop a URN
resolution system that can also provide location independence for those
URLs.  This is related to the requirement in [1] to be able to
grandfather in names from other naming systems, such as ISO Formal
Public Identifiers, Library of Congress Call Numbers, ISBNs, ISSNs,
etc.

The NAPTR RR could also be used for URLs that have already been assigned.
Assume we have the URL for a very popular piece of software that the
publisher wishes to mirror at multiple sites around the world:

     http://www.foo.com/software/latest-beta.exe

We extract the prefix, "http", and lookup NAPTR records for
http.urn.net. This might return a record of the form

http.urn.net IN NAPTR
;;  order   pref flags service      regexp             replacement
     100     90   ""      ""   "!http://([^/:]+)!\1!i"       .

This expression returns everything after the first double slash and
before the next slash or colon. (We use the '!' character to delimit the
parts of the substitution expression. Otherwise we would have to use
backslashes to escape the forward slashes, and would have a regexp in
the zone file that looked like "/http:\\/\\/([^\\/:]+)/\\1/i".).

Applying this pattern to the URL extracts "www.foo.com". Looking up NAPTR
records for that might return:

www.foo.com
;;       order pref flags   service  regexp     replacement
 IN NAPTR 100  100  "s"   "http+L2R"   ""    http.tcp.foo.com
 IN NAPTR 100  100  "s"   "ftp+L2R"    ""    ftp.tcp.foo.com

Looking up SRV records for http.tcp.foo.com would return information
on the hosts that foo.com has designated to be its mirror sites. The
client can then pick one for the user. 

NAPTR RR Format
===============

The format of the NAPTR RR is given below. The DNS type code for
NAPTR is 35.

    Domain TTL Class Order Preference Flags Service Regexp Replacement 

where:

Domain
       The domain name this resource record refers to.
TTL
       Standard DNS Time To Live field
Class
       Standard DNS meaning
Order
       A 16-bit integer specifying the order in which the NAPTR records
       MUST be processed to ensure correct delegation of portions
       of the namespace over time. Low numbers are processed before
       high numbers, and once a NAPTR is found that "matches" a URN,
       the client MUST NOT consider any NAPTRs with a higher value
       for order.

Preference
       A 16-bit integer which specifies the order in which NAPTR records
       with equal "order" values SHOULD be processed, low numbers
       being processed before high numbers.  This is similar to the
       preference field in an MX record, and is used so domain
       administrators can direct clients towards more capable hosts
       or lighter weight protocols. 

Flags
       A String giving flags to control aspects of the rewriting and
       interpretation of the fields in the record. Flags are single
       characters from the set [A-Z0-9]. The case of the alphabetic
       characters is not significant.

       At this time only three flags, "S", "A", and "P", are defined.
       "S" means that the next lookup should be for SRV records instead
       of NAPTR records. "A" means that the next lookup should be for A
       records. The "P" flag says that the remainder of the resolution
       shall be carried out in a Protocol-specific fashion, and we
       should not do any more DNS queries.

       The remaining alphabetic flags are reserved. The numeric flags
       may be used for local experimentation. The S, A, and P flags are
       all mutually exclusive, and resolution libraries MAY signal an
       error if more than one is given. (Experimental code and code for
       assisting in the creation of NAPTRs would be more likely to
       signal such an error than a client such as a browser). We
       anticipate that multiple flags will be allowed in the future, so
       implementers MUST NOT assume that the flags field can only
       contain 0 or 1 characters. Finally, if a client encounters a
       record with an unknown flag, it MUST ignore it and move to the
       next record. This test takes precedence even over the "order"
       field. Since flags can control the interpretation placed on
       fields, a novel flag might change the interpretation of the
       regexp and/or replacement fields such that it is impossible to
       determine if a record matched a URN.

Service 
       Specifies the resolution service(s) available down this rewrite
       path. It may also specify the particular protocol that is used
       to talk with a resolver. A protocol MUST be specified if the
       flags field states that the NAPTR is terminal. If a protocol is
       specified, but the flags field does not state that the NAPTR is
       terminal, the next lookup MUST be for a NAPTR. The client MAY
       choose not to perform the next lookup if the protocol is
       unknown, but that behavior MUST NOT be relied upon.

       The service field may take any of the values below (using the
       Augmented BNF of RFC 822[9]):

           service_field = [ [protocol] *("+" rs)]
           protocol      = ALPHA *31ALPHANUM
           rs            = ALPHA *31ALPHANUM
        // The protocol and rs fields are limited to 32
        // characters and must start with an alphabetic.
        // The current set of "known" strings are:
        // protocol      = "rcds" / "thttp" / "hdl" / "rwhois" / "z3950"
        // rs            = "N2L" / "N2Ls" / "N2R" / "N2Rs" / "N2C"
        //               / "N2Ns" / "L2R" / "L2Ns" / "L2Ls" / "L2C"

       i.e. an optional protocol specification followed by 0 or more
       resolution services. Each resolution service is indicated by
       an initial '+' character.

       Note that the empty string is also a valid service field. This
       will typically be seen at the top levels of a namespace, when it
       is impossible to know what services and protocols will be offered
       by a particular publisher within that name space.

       At this time the known protocols are rcds[7], hdl[10] (binary,
       UDP-based protocols),  thttp[5] (a textual, TCP-based protocol),
       rwhois[11] (textual, UDP or TCP based), and Z39.50[12] (binary,
       TCP-based). More will be allowed later.  The names of the
       protocols must be formed from the characters [a-Z0-9]. Case of
       the characters is not significant.

       The service requests currently allowed will be described in more
       detail in [6], but in brief they are:
             N2L  - Given a URN, return a URL
             N2Ls - Given a URN, return a set of URLs
             N2R  - Given a URN, return an instance of the resource.
             N2Rs - Given a URN, return multiple instances of the resouce,
                    typically encoded using multipart/alternative.
             N2C  - Given a URN, return a collection of meta-information
                    on the named resource. The format of this response is
                    the subject of another document.
             N2Ns - Given a URN, return all URNs that are also identifers
                    for the resource.
             L2R  - Given a URL, return the resource.
             L2Ns - Given a URL, return all the URNs that are identifiers
                    for the resource.
             L2Ls - Given a URL, return all the URLs for instances of
                    of the same resource.
             L2C  - Given a URL, return a description of the resource.

       The actual format of the service request and response will be
       determined by the resolution protocol, and is the subject for
       other documents (e.g. [5]). Protocols need not offer all
       services. The labels for service requests shall be formed from
       the set of characters [A-Z0-9]. The case of the alphabetic
       characters is not significant.

Regexp
       A STRING containing a substitution expression that is applied to
       the original URI in order to construct the next domain name to
       lookup. The grammar of the substitution expression is given in
       the next section.

Replacement
       The next NAME to query for NAPTR, SRV, or A records depending on
       the value of the flags field. As mentioned above, this may be
       compressed.

Substitution Expression Grammar:
================================

The content of the regexp field is a substitution expression. True sed(1)
substitution expressions are not appropriate for use in this application for a
variety of reasons, therefore the contents of the regexp field MUST follow the
grammar below:

  subst_expr   = delim-char  ere  delim-char  repl  delim-char  *flags
  delim-char   = "/" / "!" / ... (Any non-digit or non-flag character other
                 than backslash '\'. All occurances of a delim_char in a
                 subst_expr must be the same character.)
  ere          = POSIX Extended Regular Expression (see [13], section 2.8.4)
  repl         = dns_str /  backref / repl dns_str  / repl backref
  dns_str      = domain name (see RFC-1123 [14]).
  backref      = "\" 1POS_DIGIT
  flags        = "i" 
  DNS_CHAR     = "_" / "0" / "1" / ... / "9" / "a" / ... / "z"
  POS_DIGIT    = "1" / "2" / ... / "9"  ; 0 is not an allowed backref value

The result of applying the substitution expression to the original URI shall
be a legal domain name. Since it is possible for the regexp field to be
improperly specified, such that a non-conforming domain name can be
constructed, client software SHOULD verify that the result is a legal
domain name before making queries on it. 

Backref expressions in the repl portion of the substitution expression
are replaced by the (possibly empty) string of characters enclosed by '('
and ')' in the ERE portion of the substitution expression. N is a single
digit from 1 through 9, inclusive. It specifies the N'th backref expression,
the one that begins with the N'th '(' and continues to the matching ')'.
For example, the ERE
                   (A(B(C)DE)(F)G)
has backref expressions:
                    \1  = ABCDEFG
                    \2  = BCDE
                    \3  = C
                    \4  = F
                \5..\9  = error - no matching subexpression
                 
The "i" flag indicates that the ERE matching SHALL be performed in a
case-insensitive fashion. Furthermore, any backref replacements MAY be
normalized to lower case when the "i" flag is given.

The first character in the substitution expression shall be used as the
character that delimits the components of the substitution expression.
There must be exactly three non-escaped occurrences of the delimiter
character in a substitution expression. Since escaped occurrences of
the delimiter character will be interpreted as occurrences of that
character, digits MUST NOT be used as delimiters. Backrefs would be
confused with literal digits were this allowed. Similarly, if flags are
specified in the substitution expression, the delimiter character must not
also be a flag character. 

Advice to domain administrators:
================================

Beware of regular expressions. Not only are they a pain to get
correct on their own, but there is the previously mentioned interaction
with DNS. Any backslashes in a regexp must be entered twice in a zone
file in order to appear once in a query response. More seriously, the
need for double backslashes has probably not been tested by all
implementors of DNS servers. We anticipate that urn.net will be the
heaviest user of regexps. Only when delegating portions of namespaces
should the typical domain administrator need to use regexps.

On a related note, beware of interactions with the shell when manipulating
regexps from the command line. Since '\' is a common escape character in
shells, there is a good chance that when you think you are saying "\\" you
are actually saying "\".  Similar caveats apply to characters such as
'*', '(', etc.

The "a" flag allows the next lookup to be for A records rather than
SRV records. Since there is no place for a port specification in the
NAPTR record, when the "A" flag is used the specified protocol must
be running on its default port. 

The URN-WG is discussing the use of international characters in URNs.
Regular expressions for strings in international character sets are likely
to be essentially impossible to read or write by hand.

Usage
=====

For the edification of implementers, pseudocode for a client routine
using NAPTRs is given below. This code is provided merely as a
convience, it does not have any weight as a standard way to process
NAPTR records. Also, as is the case with pseudocode, it has never been
executed and may contain logical errors. You have been warned.

    //
    // findResolver(URN)
    // Given a URN, find a host that can resolve it.
    // 
    findResolver(string URN) {
      // prepend prefix to urn.net
      sprintf(key, "%s.urn.net", extractNS(URN));
      do {
        rewrite_flag = false;
        terminal = false;
	if (key has been seen) {
	  quit with a loop detected error
	}
	add key to list of "seens"
	records = lookup(type=NAPTR, key); // get all NAPTR RRs for 'key'

        sort NAPTR records by "order" field and "preference" field
            (with "order" being more significant than "preference").
        n_naptrs = number of NAPTR records in response.
        curr_order = records[0].order;
        max_order = records[n_naptrs-1].order;
        
        // Process current batch of NAPTRs according to "order" field.
        for (j=0; j < n_naptrs && records[j].order <= max_order; j++) {
          if (unknown_flag) // skip this record and go to next one
             continue; 
          newkey = rewrite(URN, naptr[j].replacement, naptr[j].regexp);
          if (!newkey) // Skip to next record if the rewrite didn't match
             continue;  
          // We did do a rewrite, shrink max_order to current value
          // so that delegation works properly
          max_order = naptr[j].order;
          // Will we know what to do with the protocol and services
          // specified in the NAPTR? If not, try next record.
          if(!isKnownProto(naptr[j].services)) {
            continue;
          }
          if(!isKnownService(naptr[j].services)) {
            continue;
          }

          // At this point we have a successful rewrite and we will know
          // how to speak the protocol and request a known resolution
          // service. Before we do the next lookup, check some
          // optimization possibilities.
          
          if (strcasecmp(flags, "S")
           || strcasecmp(flags, "P"))
           || strcasecmp(flags, "A")) {
             terminal = true;
             services = naptr[j].services;
             addnl = any SRV and/or A records returned as additional info
                     for naptr[j].
          }
          key = newkey;
          rewriteflag = true;
          break;
        }
      } while (rewriteflag && !terminal);

      // Did we not find our way to a resolver?
      if (!rewrite_flag) {
         report an error
         return NULL;
      }

      // Leave rest to another protocol?
      if (strcasecmp(flags, "P")) {
         return key as host to talk to;
      }

      // If not, keep plugging
      if (!addnl) { // No SRVs came in as additional info, look them up
        srvs = lookup(type=SRV, key);
      }  

      sort SRV records by preference, weight, ...
      foreach (SRV record) { // in order of preference
        try contacting srv[j].target using the protocol and one of the
            resolution service requests from the "services" field of the
            last NAPTR record.
        if (successful)
          return (target, protocol, service);
          // Actually we would probably return a result, but this
          // code was supposed to just tell us a good host to talk to.
      }
      die with an "unable to find a host" error;
    }

Notes:
======
  -  A client MUST process multiple NAPTR records in the order specified by
     the "order" field, it MUST NOT simply use the first record that provides
     a known protocol and service combination.
  -  If a record at a particular order matches the URI, but the client
     doesn't know the specified protocol and service, the client SHOULD
     continue to examine records that have the same order. The client
     MUST NOT consider records with a higher value of order. This is
     necessary to make delegation of portions of the namespace work.
     The order field is what lets site administrators say "all requests for
     URIs matching pattern x go to server 1, all others go to server 2".
     (A match is defined as:
        1)  The NAPTR provides a replacement domain name
        or
        2) The regular expression matches the URN
     )
  -  When multiple RRs have the same "order", the client should use
     the value of the preference field to select the next NAPTR to
     consider. However, because of preferred protocols or services,
     estimates of network distance and bandwidth, etc. clients
     may use different criteria to sort the records.
  -  If the lookup after a rewrite fails, clients are strongly encouraged
     to report a failure, rather than backing up to pursue other rewrite
     paths.
  -  When a namespace is to be delegated among a set of resolvers, regexps
     must be used. Each regexp appears in a separate NAPTR RR. Administrators
     should do as little delegation as possible, because of limitations on
     the size of DNS responses.
  -  Note that SRV RRs impose additional requirements on clients.

Acknowledgments:
=================

The editors would like to thank Keith Moore for all his consultations
during the development of this draft. We would also like to thank Paul
Vixie for his assistance in debugging our implementation, and his answers
on our questions. Finally, we would like to acknowledge our enormous
intellectual debt to the participants in the Knoxville series of meetings,
as well as to the participants in the URI and URN working groups.

References:
===========

[1]  RFC-1737, "Functional Requirements for Uniform Resource Names", Karen
     Sollins and Larry Masinter, Dec. 1994.

[2]  The URN Implementors, Uniform Resource Names: A Progress Report,
     http://www.dlib.org/dlib/february96/02arms.html, D-Lib Magazine,
     February 1996.

[3]  Ryan Moats, "URN Syntax", draft-ietf-urn-syntax-02.txt, Feb. 1997.

[4]  RFC 2052, "A DNS RR for specifying the location of services (DNS SRV)",
     A. Gulbrandsen and P. Vixie, October 1996.

[5]  RFC-xxxx, "Conventions for the Use of HTTP for Resolution of URNs",
     Ron Daniel Jr., currently available as draft-ietf-urn-http-conv-01.txt,
     Dec. 1996.

[6]  RFC-xxxx, "URN Resolution Services", ???, draft-ietf-urn-???
     (This document is on the URN-WG's list of documents to prepare, but
     has not yet been written. It will get its start from the treatment of
     resolution services in [4]).

[7]  Keith Moore, Shirley Browne, Jason Cox, and Jonathan Gettler,
     Resource Cataloging and Distribution System, Technical Report CS-97-346,
     University of Tennessee, Knoxville, December 1996

[8]  Paul Vixie, personal communication.

[9]  RFC-822, "Standard for the Format of ARPA Internet Text Messages",
     Dave H. Crocker, August 1982.  

[10] Charles Orth, Bill Arms; Handle Resolution Protocol Specification,
     http://www.handle.net/docs/client_spec.html

[11] RFC-1714, "Referral Whois Protocol (RWhois)", S. Williamson and
     M. Kosters, November 1994.

[12] Information Retrieval (Z39.50): Application Service Definition and
     Protocol Specification, ANSI/NISO Z39.50-1995, July 1995.

[13] IEEE Standard for Information Technology - Portable Operating System
     Interface (POSIX) - Part 2: Shell and Utilities (Vol. 1); IEEE Std
     1003.2-1992; The Institute of Electrical and Electronics Engineers;
     New York; 1993. ISBN:1-55937-255-9

[14] RFC-1123, "Requirements for Internet Hosts - Application and Support"
     R. Braden, Oct. 1989.

Security Considerations
=======================
  The use of "urn.net" as the registry for URN namespaces is subject to
  denial of service attacks, as well as other DNS spoofing attacks. The
  interactions with DNSSEC are currently being studied. It is expected
  that NAPTR records will be signed with SIG records once the DNSSEC
  work is deployed. 

  The rewrite rules make identifiers from other namespaces subject to
  the same attacks as normal domain names. Since they have not been
  easily resolvable before, this may or may not be considered a problem.

  Regular expressions should be checked for sanity, not blindly passed
  to something like PERL. 

Author Contact Information:
===========================

Ron Daniel
Los Alamos National Laboratory
MS B287
Los Alamos, NM, USA, 87545
voice:  +1 505 665 0597
fax:    +1 505 665 4939
email:  [email-masked]

Michael Mealling
Network Solutions
505 Huntmar Park Drive
Herndon, VA  22070
voice: (703) 742-0400
fax: (703) 742-9552
email: [email-masked]
URL: http://www.netsol.com/

    This draft expires 22 August, 1997.

Ron Daniel Jr.                   email: [email-masked]
Advanced Computing Lab, MS B287  voice: (505) 665-0597
Los Alamos National Laboratory     fax: (505) 665-4939
Los Alamos, NM, USA 87545         http://www.acl.lanl.gov/~rdaniel/
Want to buy: "The Five Laws of Library Science" by S.R. Ranganathan

From: "Ronald E. Daniel" <[email-masked]>
Date: Fri, 14 Feb 1997 12:11:34 -0700 (MST)
To: [email-masked]
Subject: [URN] HTTP Conventions draft
Sender: [email-masked]
Reply-To: "Ronald E. Daniel" <[email-masked]>

Hi,

Since I didn't hear any objections to the changes I planned for
the NAPTR and HTTP Conventions drafts, I made those changes.
The HTTP Conventions draft is appended, I will send the NAPTR
draft in another message.

Regards,
Ron
=====

INTERNET DRAFT                                                  Ron Daniel
draft-ietf-urn-http-conv-01.txt             Los Alamos National Laboratory
                                                              14 Feb, 1997

         A Trivial Convention for using HTTP in URN Resolution

Status of this Memo
===================

    This document is an Internet-Draft.  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.''
  
    To learn the current status of any Internet-Draft, please check
    the ``1id-abstracts.txt'' listing contained in the Internet-
    Drafts Shadow Directories on ftp.is.co.za (Africa),
    nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
    ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).

    This draft expires 22 August, 1997.

Abstract:
=========

The Uniform Resource Names Working Group (URN-WG) was formed to specify
persistent, location-independent names for network accessible
resources, as well as resolution mechanisms to retrive the resources
given such a name. At this time the URN-WG is considering one
particular resolution mechanism, the NAPTR proposal [1]. That proposal
specifies how a client may find a "resolver" for a URN. A resolver is a
database that can provide information about the resource identified by
a URN, such as the resource's location, a bibliographic description, or
even the resource itself. The protocol used for the client to
communicate with the resolver is not specified in the NAPTR proposal.
Instead, the NAPTR resource record provides a field that indicates the
"resolution protocol" and "resolution service requests" offered by the
resolver.

This document specifies the "THTTP" resolution protocol - a trivial
convention for encoding resolution service requests and responses as
HTTP 1.0 or 1.1 requests and responses.  The primary goal of THTTP is
to be simple to implement so that existing HTTP servers may easily add
support for URN resolution. We expect that the databases used by early
resolvers will be useful when more sophisticated resolution protocols
are developed later.

1.0  Introduction:
==================

The NAPTR specification[1] defined a new DNS resource record which may
be used to discover resolvers for Uniform Resource Identifiers. That
resource record provides the "services" field to specify the "resolution
protocol" spoken by the resolver, as well as the "resolution services"
it offers. Resolution protocols mentioned in that specification are
Z3950, THTTP, RCDS, HDL, and RWHOIS. (That list is expected to grow
over time). The NAPTR specification also lists a variety of resolution
services, such as N2L (given a URN, return a URL); N2R (Given a URN,
return the named resource), etc.

This document specifies the "THHTP" (Trivial HTTP) resolution protocol.
THHTP is a simple convention for encoding resolution service requests and
responses as HTTP 1.0 or 1.1 requests and responses. The primary goal
of THTTP is to have a URN resolution protocol that can easily be
added to existing HTTP daemons. Other resolution protocols are expected
to arise over time, so this document serves a secondary purpose of
illustrating the information that needs to be specified for a URN
resolution protocol. One of the resolution protocols we expect to be
developed is an extension of HTTP with new methods for the resolution
services. Therefore, we use "thhtp" as the identifier for this
protocol to leave "http" for later developments.

The reader is assumed to be familiar with the HTTP/1.0 [2] and 1.1 [3]
specifications. Implementors of this specification should be familiar with
CGI scripts, or server-specific interfaces, for database lookups.

2.0 General Approach:
=====================

The general approach used to encode resolution service requests in THTTP
is quite simple: 

    GET /uri-res/<service>?<uri>  HTTP/1.0

For example, if we have the URN "urn:foo:12345-54321" and want a URL,
we would send the request:

    GET /uri-res/N2L?urn:foo:12345-54321 HTTP/1.0

The request could also be encoded as an HTTP 1.1 request. This would look
like:

    GET /uri-res/N2L?urn:foo:12345-54321 HTTP/1.1
    Host: <whatever host we are sending the request to>

Responses from the HTTP server follow standard HTTP practice. Status
codes, such as 200 (OK) or 404 (Not Found) shall be returned.
The normal rules for determining cachability, negotiating formats, etc.
apply.

Handling these requests on the server side is easy to implement using
CGI or other, server-specific, extension mechanisms.
CGI scripts will see the incoming URI in the QUERY_STRING environment
variable. Any %encoded characters in the URN will remain in their
%encoded state in that string. The script can take the URN, look it
up in a database, and return the requested information.

One caveat should be kept in mind. The URN syntax draft[4] discusses
the notion of lexical equivalance. This means that two URIs are equivalent
under certain conditions of case-insensitivity. Resolvers MUST return
identical results for all lexically equivalent encodings of a URI. For
example, the requests below must return identical results:
    GET /uri-res/N2L?urn:cid:[email-masked] HTTP/1.0
    GET /uri-res/N2L?URN:CID:[email-masked] HTTP/1.0

3.0 Service-specific details:
=============================

This section goes through the various resolution services established
in the URN services draft[5] and states how to encode each of them,
how the results should be returned, and any special status codes that
are likely to arise.

Unless stated otherwise, the THTTP requests are formed according to
the simple convention above, either for HTTP/1.0 or HTTP/1.1. The response
is assumed to be an entity with normal headers and body unless stated
otherwise. (N2L is the only request that need not return a body).

3.1  N2L (URN to URL):
----------------------

The request is encoded as above. The URL MUST be returned in a Location:
header for the convienience of the user in the most common case of wanting
the resource. If the lookup is successful, a 30X status line SHOULD be
returned. HTTP/1.1 clients should be sent the 303 status code. HTTP/1.0
clients should be sent the 302 (Moved temporarily) status code unless the
resolver has particular reasons for using 301 (moved permanently) or 304
(not modified) codes.

Note that access controls may be applied to this, or any other, resolution
service request. Therefore the 401 (unauthorized) and 403 (forbidden)
status codes are legal responses. The server may wish to provide a body
in the response to explain the reason for refusing access, and/or to provide
alternate information about the resource, such as the price it will cost
to obtain the resource's URL.

3.2  N2Ls (URN to URLs):
------------------------

The request is encoded as above. The result is a list of 0 or
more URLs. The Internet Media Type (aka ContentType) of the result
may be negotiated using standard HTTP mechanisms if desired. At a
minimum the resolver should support the text/uri-list media type.
(See Appendix A for the definition of this media type). That media
type is suitable for machine-processing of the list of URLs. Resolvers
may also return the results as text/html, text/plain, or any other
media type they deem suitable.

No matter what the particular media type, the result MUST be a list
of the URLs which may be used to obtain an instance of the resource
identified by the URN. All URIs shall be encoded according to the
URI specification [6].

If the client has requested the result be returned as text/html or
application/html, the result should be a valid HTML docment containg
the fragment:
<UL>
<LI><A HREF="...url 1...">...url 1...</A>
<LI><A HREF="...url 2...">...url 2...</A>
 etc.
</UL>
where the strings ...url n... are replaced by the n'th URL in the list.

3.3  N2R (URN to Resource):
---------------------------

The request is encoded as above. The resource is returned using
standard HTTP mechanisms. The request may be modified using the
Accept: header as in normal HTTP to specify that the result
be given in a preferred Internet Media Type.

3.4  N2Rs (URN to Resources):
-----------------------------

This resolution service returns multiple instances of a resource,
for example, GIF and JPEG versions of an image. The judgment about
the resources being "the same" resides with the naming authority that
issued the URN.

The request is encoded as above. The result shall be a MIME
multipart/alternative message with the alternative versions of the
resource in seperate body parts. If there is only one version of
the resource identified by the URN, it MAY be returned without the
multipart/alternative wrapper. Resolver software SHOULD look at the
Accept: header, if any, and only return versions of the resource
that are acceptable according to that header. 

3.5  N2C (URN to URC):
----------------------

URCs (Uniform Resource Characteristics) are descriptions of other
resources. This request allows us to obtain a description of the
resource identified by a URN, as opposed to the resource itself.
The description might be a bibliographic citation, a digital signature,
a revision history, etc. This draft does not specify the content of
any response to a URC request. That content is expected to vary from
one resolver to another.

The format of any response to a N2C request MUST be communicated using the
ContentType header, as is standard HTTP practice. The Accept: header
SHOULD be honored.

3.6  N2Ns (URN to URNs):
------------------------

While URNs are supposed to identify one and only one resource, that
does not mean that a resource may have one and only one URN. For
example, consider a resource that has something like
"current-weather-map" for one URN and "weather-map-for-datetime-x" for
another URN. The N2Ns service request lets us obtain lists of URNs that
are believed equivalent at the time of the request. As the weathermap
example shows, some of the equivalances will be transitory, so the
standard HTTP mechanisms for communicating cachability MUST be honored.

The request is encoded as above. The result is a list of all the
URNs, known to the resolver, which identify the same resource as the
input URN. The result shall be encoded as for the N2Ls request
above (text/uri-list unless specified otherwise by an Accept: header).

3.7  L2Ns (URL to URNs):
----------------------

The request is encoded as above. The response is a list of any URNs
known to be assigned to the resource at the given URL. The result
shall be encoded as for the N2Ls and N2Ns requests.

3.8  L2Ls (URL to URLs):
------------------------

The request is encoded as described above. The result is a list of
all the URLs that the resolver knows are associated with the resource
located by the given URL. This is encoded as for the N2Ls, N2Ns, and L2Ns
requests.

3.9  L2C (URL to URC):
----------------------

The request is encoded as above, the response is the same as for the
N2C request.

Appendix A: The text/uri-list Internet Media Type
=================================================
[This appendix will be augmented or replaced by the registration
of the text/uri-list IMT once that registration has been performed].

Several of the resolution service requests, such as N2Ls, N2Ns, L2Ns,
L2Ls, result in a list of URIs being returned to the client. The
text/uri-list Internet Media Type is defined to provide a simple format
for the automatic processing of such lists of URIs.

The format of text/uri-list resources is:
1) Any lines beginning with the '#' character are comment lines
   and are ignored during processing. (Note that '#' is a character
   that may appear in URIs, so it only denotes a comment when it is the
   first character on a line).
2) The remaining non-comment lines MUST be URIs (URNs or URLs), encoded
   according to the URI specification RFC[6]. Each URI shall appear on
   one and only one line.
3) As for all text/* formats, lines are terminated with a CR LF pair,
   although clients should be liberal in accepting lines with only
   one of those characters.

In applications where one URI has been mapped to a list of URIs, such
as in response to the N2Ls request, the first line of the text/uri-list
response SHOULD be a comment giving the original URI. 

An example of such a result for the N2L request is shown below in figure 1.

     # urn:cid:[email-masked]
     http://www.huh.org/cid/foo.html
     http://www.huh.org/cid/foo.pdf
     ftp://ftp.foo.org/cid/foo.txt

               Figure 1: Example of the text/uri-list format

Appendix B:  n2l.pl script
==========================

This is a simple CGI script for the N2L resolution service. It
assumes the presence of a DBM database to store the URN to URL
mappings. This script does not specify standard behavior, it is
provided merely as a courtesy for implementors. In fact, this
script does not process incoming Accept: headers, nor does it
generate status codes. Such behavior should be part of a real
script for any of the resolution services.

    #!/bin/perl
    # N2L  - performs urn to url  resolution 

    $n2l_File = "...filename for DBM database...";

    $urn = $ENV{'QUERY_STRING'} ;

    # Sanity check on the URN. Minimum length of a valid URN is
    # 7 characters - "urn:", a 1-character Namespace ID, ":", and
    # a 1-character namespace-specific string. More elaborate
    # sanity checks should be part of a real resolver script.
    if(length($urn)<7)
    {
        $error=1;
    }

    if(!$error)
    {
        # Convert lexically equivalent versions of a URI into
        # a canonical version for DB lookups.
        $urn =~ s/^urn:([^:]*):(.*)$/sprintf("urn:%s:%s", lc $1, $2)/ie;

        dbmopen(%lu,$n2l_File,0444);
        if($lu{$urn})
        {
            $url=$lu{$urn};
            print STDOUT "Location: $url\n\n";
        }else{
            $error=2;
        }
        dbmclose(%lu);
    }

    if($error)
    {
        print "Content-Type: text/html \n\n";
        print "<html>\n";
        print "<head><title>URN Resolution: N2L</title></head>\n";
        print "<BODY>\n";
        print "<h1>URN to URL resolution failed for the URN:</h1>\n";
        print "<hr><h3>$urn</h3>\n";
        print "</body>\n";
        print "</html>\n";
    }

    exit;

References:
===========

[1] Ron Daniel and Michael Mealling, "Resolution of Uniform Resource
    Identifiers using the Domain Name System", draft-ietf-urn-naptr-02.txt,
    February, 1997.

[2] RFC 1945, "Hypertext Transfer Protocol -- HTTP/1.0", T. Berners-Lee,
    R. Fielding, H. Frystyk, May 1996.

[3] R. Fielding, J. Gettys, J.C. Mogul, H. Frystyk, T. Berners-Lee,
    "Hypertext Transfer Protocol -- HTTP/1.1", draft-ietf-http-v11-spec-06,
    July 1996.

[4] R. Moats, "URN Syntax", draft-ietf-urn-syntax-02, Jan. 1997.

[5] URN Resolution Services Draft -  (That document is in preparation.
    It will actually be strongly based on the content of this document and
    the NAPTR draft[1]). 

[6] RFC 1630, "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", T. Berners-Lee, June 1994.

Security Considerations
=======================
  Communications with a resolver may be of a sensitive nature. Some
  resolvers will hold information that should only be released to
  authorized users. The results from resolvers may be the target of
  spoofing, especially once electronic commerce transactions are common
  and there is money to be made by directing users to pirate repositories
  rather than repositories which pay royalties to rightsholders. Resolution
  requests may be of interest to traffic analysts. The requests may also
  be subject to spoofing.

  The requests and responses in this draft are amenable to encoding,
  signing, and authentication in the manner of any other HTTP traffic.

Author Contact Information:
===========================

Ron Daniel
Advanced Computing Lab, MS B287
Los Alamos National Laboratory
Los Alamos, NM, USA, 87545
voice:  +1 505 665 0597
fax:    +1 505 665 4939
email:  [email-masked]

    This draft expires 22 August, 1997.
Ron Daniel Jr.                   email: [email-masked]
Advanced Computing Lab, MS B287  voice: (505) 665-0597
Los Alamos National Laboratory     fax: (505) 665-4939
Los Alamos, NM, USA 87545         http://www.acl.lanl.gov/~rdaniel/
Want to buy: "The Five Laws of Library Science" by S.R. Ranganathan

To: IETF-Announce:;
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-syntax-02.txt
Date: Wed, 12 Feb 1997 09:34:13 -0500
Sender: [email-masked]
Reply-To: [email-masked]

--NextPart

 A Revised Internet-Draft is available from the on-line Internet-Drafts 
 directories. This draft is a work item of the Uniform Resource Names 
 Working Group of the IETF.                                                

       Title     : URN Syntax                                              
       Author(s) : R. Moats
       Filename  : draft-ietf-urn-syntax-02.txt
       Pages     : 7
       Date      : 02/11/1997

Uniform Resource Names (URNs) are intended to serve as persistent resource 
identifiers. This document sets forward the canonical syntax for URNs.  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.                     

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
     "get draft-ietf-urn-syntax-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-syntax-02.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  ftp.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  [email-masked]. In the body type: 
     "FILE /internet-drafts/draft-ietf-urn-syntax-02.txt".
							
NOTE: The mail server at ds.internic.net can return the document in
      MIME-encoded form by using the "mpack" utility.  To use this
      feature, insert the command "ENCODING mime" before the "FILE"
      command.  To decode the response(s), you will need "munpack" or
      a MIME-compliant mail reader.  Different MIME-compliant mail readers
      exhibit different behavior, especially when dealing with
      "multipart" MIME messages (i.e., documents which have been split
      up into multiple messages), so check your local documentation on
      how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader 
implementation to automatically retrieve the ASCII version
of the Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type:  Message/External-body;
        access-type="mail-server";
        server="[email-masked]"

Content-Type: text/plain
Content-ID: <[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-urn-syntax-02.txt

--OtherAccess
Content-Type:   Message/External-body;
        name="draft-ietf-urn-syntax-02.txt";
        site="ds.internic.net";
        access-type="anon-ftp";
        directory="internet-drafts"

Content-Type: text/plain
Content-ID: <[email-masked]>

--OtherAccess--

--NextPart--

Date: Wed, 12 Feb 1997 08:16:06 -0500
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: "Ron Daniel Jr." <[email-masked]>
Cc: [email-masked]
Subject: Re: [URN] New URN syntax draft
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

Ron Daniel Jr. wrote:
> 
> One other thought on this subject. The "excluded" characters
> say that 00-20(hex) need to be %encoded. Do we want to warn
> people that they should not use %00?
> 

Oog.  Good point.

Ryan

Date: Tue, 11 Feb 1997 13:50:22 -0700
To: [email-masked]
From: "Ron Daniel Jr." <[email-masked]>
Subject: [URN] retry: intentions
Sender: [email-masked]
Reply-To: "Ron Daniel Jr." <[email-masked]>

Hi,

Sorry if you get this twice, it didn't seem to go out the first time.

Hi Folks,

I'm going to try and get the NAPTR and HTTP conventions drafts done
to my satisfaction this week (or by next week if there are any mildly
contentious points). Rather than plop a few KB of drafts in your laps,
let me summarize the changes I am making and we can see if any of
those points are controversial.

NAPTR:

I'm cleaning up the references (finally), the only substantive changes
to this draft will deal with the list of resolution protocols. There are
two changes. First, after talking with some people who are interested
in Z39.50, I'm going to it to the list of resolution protocols.
Second, I'm going to change the string used for identifying the
use of HTTP according to the "conventions" draft to "thhtp" which
stands for "trivial HTTP". This is to leave "http" as an identifier for
a possible alternative use of HTTP which would be standards-track.
I will also change the BNF so that any reasonable-length string
of alphanumerics can be a protocol.

So, the BNF for the service field will become:
  protocol = ALPHA *15ALPHANUM  ; 1-16 alphanumerics with initial alpha
with a note that the current set of protocol IDs is:
  "rcds" / "thttp" / "hdl" / "rwhois" / "z3950"

HTTP Conventions

This draft gets some major changes based on experience. First, the
title will be changed to something like "Trivial Convention for using
HTTP as a URN Resolution Protocol" to line up with the "thttp"
label mentioned above. The draft will state that it defines the
"thttp" protocol in NAPTR resource records. The major change is a
one-character change to the syntax of the requests from
  GET /uri-res/<service>/<uri>
to
  GET /uri-res/<service>?<uri>

This comes about because of our experiences with %encoded characters such
as '/'. We would have to do a major rewrite of Apache's URI processing
to continue using the '/' character, while switching to '?' lets the
query string and all its encoded characters go to the service scripts
unimpeded.

I'll edit the drafts according to the plans above, but will change the plans
if the WG consensus is to do so.

Regards,

Ron Daniel Jr.              voice:+1 505 665 0597
Advanced Computing Lab        fax:+1 505 665 4939
MS B287                     email:[email-masked]
Los Alamos National Lab      http://www.acl.lanl.gov/~rdaniel
Los Alamos, NM, USA, 87545  

Date: Tue, 11 Feb 1997 12:19:55 -0700
To: [email-masked]
From: "Ron Daniel Jr." <[email-masked]>
Subject: Re: [URN] New URN syntax draft
Cc: [email-masked]
Sender: [email-masked]
Reply-To: "Ron Daniel Jr." <[email-masked]>

One other thought on this subject. The "excluded" characters
say that 00-20(hex) need to be %encoded. Do we want to warn
people that they should not use %00?

Ron Daniel Jr.              voice:+1 505 665 0597
Advanced Computing Lab        fax:+1 505 665 4939
MS B287                     email:[email-masked]
Los Alamos National Lab      http://www.acl.lanl.gov/~rdaniel
Los Alamos, NM, USA, 87545  

Date: Tue, 11 Feb 1997 12:04:55 -0700
To: [email-masked]
From: "Ron Daniel Jr." <[email-masked]>
Subject: [URN] intentions
Sender: [email-masked]
Reply-To: "Ron Daniel Jr." <[email-masked]>

Hi Folks,

I'm going to try and get the NAPTR and HTTP conventions drafts done
to my satisfaction this week (or by next week if there are any mildly
contentious points). Rather than plop a few KB of drafts in your laps,
let me summarize the changes I am making here and we can see if any of
those points are controversial.

NAPTR:

I'm cleaning up the references (finally), the only substantive changes
to this draft will deal with the list of resolution protocols. There are
two changes. First, after talking with some people who are interested
in Z39.50, I'm going to it to the list of resolution protocols.
Second, I'm going to change the string used for identifying the
use of HTTP according to the "conventions" draft to "thhtp" which
stands for "trivial HTTP". This is to leave "http" as an identifier for
a possible alternative use of HTTP which would be standards-track.

So, the BNF for the service field will become:
  protocol = "rcds" / "thttp" / "hdl" / "rwhois" / "z3950"

HTTP Conventions

This draft gets some major changes based on experience. First, the
title will be changed to something like "Trivial Convention for using
HTTP as a URN Resolution Protocol". It will state that it defines the
"thttp" protocol in NAPTR resource records. The major change is a
one-character change to the syntax of the requests from
  GET /uri-res/<service>/<uri>
to
  GET /uri-res/<service>?<uri>

This comes about because of our experiences with %encoded characters such
as '/'. We would have to do a major rewrite of Apache's URI processing
to continue using the '/' character, while switching to '?' lets the
query string and all its encoded characters go to the service scripts
unimpeded.

I'll edit the drafts according to the plans above, but will change the plans
if the WG consensus is to do so.

Regards,

Ron Daniel Jr.              voice:+1 505 665 0597
Advanced Computing Lab        fax:+1 505 665 4939
MS B287                     email:[email-masked]
Los Alamos National Lab      http://www.acl.lanl.gov/~rdaniel
Los Alamos, NM, USA, 87545  

Date: Tue, 11 Feb 1997 13:02:56 -0500
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: "Ron Daniel Jr." <[email-masked]>
Cc: [email-masked]
Subject: Re: [URN] New URN syntax draft
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

Ron Daniel Jr. wrote:
> Looks pretty good to me. A few questions/suggestions:
> 
> >Abstract
> >
> >   Uniform Resource Names (URNs) are intended to serve as persistent
> >   resource identifiers.
> 
> persistent, location-independent, resource identifiers.
> 
> Same  thing for first sentence in the Intro section.
> 

A good point for both spots.

> >2.1 Namespace Identifier Syntax
> 
> Do we want to place a length restriction on the NID?
> 
> Although I am not usually in favor of arbitrary limits, I can just see
> somebody having a 4kB (or larger) NID, which seems bizzare and makes it more
> difficult for resolution systems. I would not mind seeing
> this restricted to 32 characters or less.

I agree with Ron here.  I don't particular care if 32 is the "magic
number"
or something else, but I do think a length limit is a good idea...

> 
> >2.2 Namespace Specific String Syntax
> >   <other>       ::= "(" | ")" | "+" | "," | "-" | "." |
> >                     ":" | "=" | "?" | "@" | ";" | "$" |
> >                     "_" | "!" | "~" | "*" | "'"
> 
> I recommend moving '?' to the list of reserved characters and moving
> '~' to the list of excluded characters.

I personally have no problem with either of these, but am willing to see
what
working group consensus is.

> >2.3.1 The "%" character
> 
> Do we need to add a sentence here that one should only do %encoding
> when necessary? This interacts with the statement in the lexical
> equivalance section that %encoding MUST NOT be removed when comparing
> 2 URNs. Earlier I had thought that people were free to encode any
> thing they wanted to. However, this makes it a pain to obtain the
> "canonical" form for a URN. If a legal character is %encoded, is it
> because it is a literal occurance of a character that would have a
> reserved meaning in the namespace, or is it just because someone went
> a little wild with their encoding? If the former, we shouldn't remove
> the encoding because that makes the character move from its literal
> appearance to its namespace-specific reserved meaning.
> 
> So, I suggest adding such a statement that normal characters must not
> be %encoded unless it is to allow a literal occurance of a character
> with a otherwise reserved meaning.

This is my "bad" (more american slang).  I have always had the position
that "%"-encoding only occurs in the case stated, because there is only
one canonical URN representation.  However, there is no specific
statement
to this effect in the draft :-(

> Also, this rule would apply across all namespaces. New namespace developers
> are free to specify characters with a reserved meaning in their namespace,
> but their lexical equivalance procedure must still not remove any
> %encodings.

This is necessary (in my opinion) to avoid the potential interaction
with section
5, where it is stated that Namespaces can add new equivalencies.

> >not equivalent if the procedure above says they are equivalent.
> >6. Examples of lexical equivalence
> 
> Put some space between those lines.  (I told you I thought we were
> pretty close to being done with this draft. :-)

;-)
 
> >           1- URN:foo:a123/456
> >           2- urn:foo:a123/456
> >           3- urn:FOO:a123/456
> >           4- urn:foo:A123/456
> >           5- urn:foo:a123%2F456
> >           6- URN:FOO:a123%2f456
> 
> Since '/' is reserved, maybe another character should be used in
> these examples.

Another oopsie.  I have changed these to "," and "%2D".

> >7. Functional Equivalence in URNs
> 
> Do we really need this section?

I don't know.  If we can get rid of it, that would be fine with me
(shorter is
ALMOST ALWAYS better).

Ryan

To: [email-masked]
Cc: Cynthia Clark <[email-masked]>, [email-masked]
Subject: [URN] Re: New URN syntax draft 
Date: Tue, 11 Feb 1997 10:26:06 -0500
From: Cynthia Clark <[email-masked]>
Sender: [email-masked]
Reply-To: Cynthia Clark <[email-masked]>

Ryan,

Just for your information, I am currently working on your
Internet-Draft <draft-ietf-urn-syntax-02.txt>.  I'll probably 
send an announcement to the entire IETF regarding 
your I-D sometime tomorrow or the next day.
       
Kind Regards,
Cynthia 
------------------------------------------------------
Cynthia Clark, IETF Internet-Drafts Administrator
E-mail Address Preference:  <[email-masked]>
-------------------------------------------------------

Date: Tue, 11 Feb 1997 10:00:28 -0700
To: Ryan Moats <[email-masked]>
From: "Ron Daniel Jr." <[email-masked]>
Subject: Re: [URN] New URN syntax draft
Cc: [email-masked]
Sender: [email-masked]
Reply-To: "Ron Daniel Jr." <[email-masked]>

At 08:20 AM 2/11/97 -0500, Ryan Moats wrote:
>Attached is draft-ietf-urn-syntax-02.txt

Looks pretty good to me. A few questions/suggestions:

>Abstract
>
>   Uniform Resource Names (URNs) are intended to serve as persistent
>   resource identifiers.

persistent, location-independent, resource identifiers.

Same  thing for first sentence in the Intro section.

>2.1 Namespace Identifier Syntax

Do we want to place a length restriction on the NID?

Although I am not usually in favor of arbitrary limits, I can just see
somebody having a 4kB (or larger) NID, which seems bizzare and makes it more
difficult for resolution systems. I would not mind seeing
this restricted to 32 characters or less.

>2.2 Namespace Specific String Syntax
>   <other>       ::= "(" | ")" | "+" | "," | "-" | "." |
>                     ":" | "=" | "?" | "@" | ";" | "$" |
>                     "_" | "!" | "~" | "*" | "'"

I recommend moving '?' to the list of reserved characters and moving
'~' to the list of excluded characters.

>2.3 Reserved characters
[...]
>   The reserved character set is:
>
>   <reserved>    ::= "/" | "%"

I suggest making this '/', '%', '?', and '#' to be morein line with
URI syntax.

>2.3.1 The "%" character

Do we need to add a sentence here that one should only do %encoding
when necessary? This interacts with the statement in the lexical
equivalance section that %encoding MUST NOT be removed when comparing
2 URNs. Earlier I had thought that people were free to encode any
thing they wanted to. However, this makes it a pain to obtain the
"canonical" form for a URN. If a legal character is %encoded, is it
because it is a literal occurance of a character that would have a
reserved meaning in the namespace, or is it just because someone went
a little wild with their encoding? If the former, we shouldn't remove
the encoding because that makes the character move from its literal
appearance to its namespace-specific reserved meaning.

So, I suggest adding such a statement that normal characters must not
be %encoded unless it is to allow a literal occurance of a character
with a otherwise reserved meaning.

Also, this rule would apply across all namespaces. New namespace developers
are free to specify characters with a reserved meaning in their namespace,
but their lexical equivalance procedure must still not remove any
%encodings.

>not equivalent if the procedure above says they are equivalent.
>6. Examples of lexical equivalence

Put some space between those lines.  (I told you I thought we were
pretty close to being done with this draft. :-)

>           1- URN:foo:a123/456
>           2- urn:foo:a123/456
>           3- urn:FOO:a123/456
>           4- urn:foo:A123/456
>           5- urn:foo:a123%2F456
>           6- URN:FOO:a123%2f456

Since '/' is reserved, maybe another character should be used in
these examples.

>7. Functional Equivalence in URNs

Do we really need this section?

Regards,

Ron Daniel Jr.              voice:+1 505 665 0597
Advanced Computing Lab        fax:+1 505 665 4939
MS B287                     email:[email-masked]
Los Alamos National Lab      http://www.acl.lanl.gov/~rdaniel
Los Alamos, NM, USA, 87545  

Date: Tue, 11 Feb 1997 08:20:51 -0500
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: [email-masked]
Cc: [email-masked]
Subject: [URN] New URN syntax draft
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

This is a multi-part message in MIME format.

--------------4AEFFFD164C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Attached is draft-ietf-urn-syntax-02.txt

Thanks,

Ryan Moats
InterNIC Directory and Database Services

--------------4AEFFFD164C
Content-Type: text/plain; charset=us-ascii; name="urn.syntax.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="urn.syntax.txt"

Internet-Draft                                                Ryan Moats
draft-ietf-urn-syntax-02.txt                                        AT&T
Expires in six months                                       January 1997

                               URN Syntax
                 Filename: draft-ietf-urn-syntax-02.txt

Status of This Memo

      This document is an Internet-Draft.  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.''

      To learn the current status of any Internet-Draft, please check
      the ``1id-abstracts.txt'' listing contained in the Internet-
      Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
      (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
      Coast), or ftp.isi.edu (US West Coast).

Abstract

   Uniform Resource Names (URNs) are intended to serve as persistent
   resource identifiers. This document sets forward the canonical syntax
   for URNs.  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.

1. Introduction

   Uniform Resource Names (URNs) are intended to serve as persistent
   resource identifiers and are designed to make it easy to map other
   namespaces (which share the properties of URNs) into URN-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.

Expires 7/31/97                                                 [Page 1]

INTERNET DRAFT                 URN Syntax                   January 1997

2. Syntax

   All URNs have the following syntax (phrases enclosed in quotes are
   REQUIRED):

                     <URN> ::= "urn:" <NID> ":" <NSS>

   where <NID> is the Namespace Identifier, and <NSS> is the Namespace
   Specific String.  The leading "urn:" sequence is case-insensitive.
   The Namespace ID determines the _syntactic_ interpretation of the
   Namespace Specific String (as discussed in [1]).

   RFC 1630 [2] and RFC 1737 [3] each presents additional considerations
   for URN encoding, which have implications as far as limiting syntax.
   On the other hand, the requirement to support existing legacy naming
   systems has the effect of broadening syntax.  Thus, we discuss the
   acceptable syntax for both the Namespace Identifier and the Namespace
   Specific String separately.

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, the syntax for
   the Namespace Identifier is:

   <NID>         ::= <let-num> [ *<let-num-hyp> ]

   <let-num-hyp> ::= <upper> | <lower> | <number> | "-"

   <let-num>     ::= <upper> | <lower> | <number>

   <upper>       ::= "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"

   <lower>       ::= "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"

   <number>      ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
                     "8" | "9"

   This is slightly more restrictive that what is stated in [4] (which

Expires 7/31/97                                                 [Page 2]

INTERNET DRAFT                 URN Syntax                   January 1997

   allows the characters "." and "+").  Further, the Namespace
   Identifier is case insensitive, so that "ISBN" and "isbn" refer to
   the same namespace.

   To avoid confusion with the "urn:" identifier, the NID "urn" is
   reserved and MUST NOT be used.

2.2 Namespace Specific String Syntax

   As required by RFC 1737, there is a single canonical representation
   of the NSS portion of an URN.   The format of this single canonical
   form follows:

   <NSS>         ::= 1*<URN chars>

   <URN chars>   ::= <trans> | "%" <hex> <hex>

   <trans>       ::= <upper> | <lower> | <number> | <other> | <reserved>

   <hex>         ::= <number> | "A" | "B" | "C" | "D" | "E" | "F" |
                     "a" | "b" | "c" | "d" | "e" | "f"

   <other>       ::= "(" | ")" | "+" | "," | "-" | "." |
                     ":" | "=" | "?" | "@" | ";" | "$" |
                     "_" | "!" | "~" | "*" | "'"

   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 chars>).  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 one to six octets using UTF-8 encoding, and the encoding
   of each of those octets as "%" followed by two characters from the
   <hex> character set above. The two characters give the hexadecimal
   representation of that octet.

2.3 Reserved characters

   The remaining character set left to be discussed above is the
   reserved character set, which contains various characters reserved
   from normal use.  The reserved character set follows, with a
   discussion on the specifics of why each character is reserved.

   The reserved character set is:

   <reserved>    ::= "/" | "%"

Expires 7/31/97                                                 [Page 3]

INTERNET DRAFT                 URN Syntax                   January 1997

2.3.1 The "%" character

   The "%" character is reserved in the URN syntax for introducing the
   escape sequence for an octet.  Literal use of the "%" character in a
   namespace must be encoded using "%25" in URNs for that namespace.
   The presence of an "%" character in an URN MUST be followed by two
   characters from the <hex> character set.

   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.  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.2 The "/" character

   The "/" character is RESERVED for future developments.  It might be
   used for denoting hierarchy to allow for relative URN processing, but
   the WG has not yet reached consensus on this, so such developments
   will be documented separately.  Meanwhile, namespace developers
   SHOULD NOT use an unencoded "/", but rather use %-encoding for "/"
   ("%2F").

2.4 Excluded characters

   The following list is included only for the sake of completeness.
   Any octets/characters on this list are explicitly NOT part of the URN
   character set, and if used in an URN, MUST be %encoded:

   <excluded> ::= octets 0-32 (0-20 hex) | "\" | """ | "#" | "&" | "<"
                  | ">" | "[" | "]" | "^" | "`" | "{" | "|" | "}" | octets 127-255 (7F-FF hex)

   An 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.

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.

Expires 7/31/97                                                 [Page 4]

INTERNET DRAFT                 URN Syntax                   January 1997

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's often desirable to determine
if 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:" token
        2. normalize the case of the NID
        3. normalizing the case of any %-escaping

Note that %-escaping 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.
6. 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%2F456
           6- URN:FOO:a123%2f456
   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
   and 6 are only lexically equivalent to each other.

Expires 7/31/97                                                 [Page 5]

INTERNET DRAFT                 URN Syntax                   January 1997

7. Functional Equivalence in URNs

   Functional equivalence is determined by practice within a given
   namespace and managed by resolvers for that namespeace. Namespace
   registration must include guidance on how to determine functional
   equivalence for that namespace, i.e. when two URNs are the identical
   within a namespace.

8. Security considerations

   This document specifies the syntax for URNs.  While some namespaces
   resolvers 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
   strongly recommended that the process of registering a namespace
   identifier include any such considerations.

9. Acknowledgments

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

10. References

   Request For Comments (RFC) and Internet Draft documents are available
   from <URL:ftp://ftp.internic.net> and numerous mirror sites.

         [1]         K. R. Sollins, "Requirements and a Framework for
                     URN Resolution Systems," Internet Draft (work in
                     progress),  November 1996.

         [2]
          T. Berners-Lee, "Universal Resource Identifiers in WWW," RFC
          1630, June 1994.

         [3]         K. Sollins and L. Masinter,  "Functional Require-
                     ments for Uniform Resource Names," RFC 1737.
                     December 1994.

         [4]         T. Berners-Lee, R. Fielding, L. Masinter, "Uniform
                     Resource Locators (URL)," Internet Draft (work in
                     progress),  December 1996.

Expires 7/31/97                                                 [Page 6]

INTERNET DRAFT                 URN Syntax                   January 1997

11. Editor's address

   Ryan Moats
   AT&T
   15621 Drexel Circle
   Omaha, NE 68135-2358
   USA

   Phone:  +1 402 894-9456
   EMail:  [email-masked]

Appendix A. 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 URL
   syntax specification [3] will extract a scheme value of "urn:"
   rather than a scheme value of "urn:<nid>".

   An URN MUST be considered an opaque URL by URL resolvers and either
   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-in to the URL resolver.

   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-
   fusion between URN namespace identifiers and URL scheme identifiers.

                This Internet Draft expires July 31, 1997.

Expires 7/31/97                                                 [Page 7]

--------------4AEFFFD164C--

From: Daniel LaLiberte <[email-masked]>
Date: Mon, 10 Feb 1997 12:55:17 -0600 (CST)
To: "Martin J. Duerst" <[email-masked]>
Cc: urn-ietf <[email-masked]>
Subject: Re: [URN] Scalable resolution
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Martin J. Duerst writes:
 > > The path scheme resolution mechanism takes advantage
 > > of the lower level DNS resolution which caches DNS information.  HTTP,
 > > FTP, and any other schemes that include DNS names also do the same.
 > 
 > Syntactically, the DNS hierarchy has nothing to do with the "/"
 > hierarchy. And where it does, in your "path:" scheme, it is again
 > scheme-specific.

It is the semantics of DNS we are interested in making use of in the
path scheme, not the syntax.  In the path scheme resolution mechanism,
'/'-separated components are extracted from paths and used to generate
the reversed, dot-separated DNS names.  The information returned from
a DNS request may be cached by the local DNS resolver.  HTTP and FTP
URLs use the DNS syntax, but that is not as relevant as the semantics.

In other words, we want to use the '/'-separated hierarchy of
components in URIs to *enable* use of other hierarchies such as DNS.
Use of DNS caches is independent of URI scheme; DNS doesn't know what
URI scheme you are using when you make DNS requests.

But I would agree that whether and how one translates from a URI
scheme to use of DNS is scheme specific.

 > And while the cashing mechanism will be general in case of NAPTR,
 > the cashing strategy will be decided by the providers of NAPTR
 > entries (in contrast to domain names, where it is tied to
 > domain name syntax).

I don't see what you mean.  DNS is blind to its use for retrieving
NAPTR records.  NAPTR records may have a TTL specified by the
provider, just as other type of record might.  But all records, NAPTR
included, are looked up by domain name as the primary key (and other
criteria secondarily).  Domain names are not necessarily "host names"
corresponding to actual machines with IP addresses.

 > The regexps allow for vast flexibility way beyond the "/".

Certainly they do.  But the only *advertised* mechanism for supporting
hierarchies in URIs is the use of '/'.  And the only widely deployed
hierarchical system that supports caches (that I know of) is DNS.
Putting the two together involves a simple translation to the DNS syntax
which is not much of a problem.

If the hierarchy is not advertised to clients, then the clients must
rely on remote servers to process the hierarchy, which defeats caching.

Actually, this is not quite true if local caches can be used to fetch
information about how to iteratively transform the URI.  This is what
the NAPTR mechanism provides.  So hierarchy is not required as long as
the information for how to *process* the URI may be cached.  This is
what I meant by caching of services.

Any other syntax for supporting hierarchy in URIs would be scheme
specific at this point.  Actually, use of DNS names directly in URIs
is also well established, though the '//' syntax has been
overspecified to denote "host name follows", as Tim B.L. argues.

 > I have nothing against namespaces being hierarchical. But there are
 > big differences between a namespace *having* some hierarchical
 > structure, a namespace *showing* some hierarchical structure (with
 > whatever syntactical means), some kind of hierarchy (even from
 > back to front, which is closer to hashing than to hierarchy)
 > being used for cashing and quick resolution, and a specific
 > syntaxt (namely the "/") being used to patch together BASEs
 > and relative parts.

I agree that those are important distinctions.

 > It's only the last one that's necessarily
 > generic, and it doesn't apply very much to URNs.

Use of common infrastructure semantics, such as use of DNS, can also
be generic, depending on what you mean.  Nevertheless,...

Your claim is that relativity doesnt apply much to URNs (how much does
it apply?), though hierarchy might be OK, and might not be advertised.
Relativity clearly requires advertised hierarchy, so advertised
hierarchy *enables* relativity.  My claim in this thread is that
advertised hierarchy also *enables* scalable resolution, which is
indeed important.

 > > Just as Karen mentioned, I don't know how to do scalable resolution in
 > > a matrix space, 

 [...]

 > As for the rest, it's easy to calculate the amount of duplication
 > of index information that you need if out of N attributes, R
 > are known, and you don't want to access any surplus areas
 > of the search space.

I'm not clear on what you mean by "surplus areas of the search space?"

Rather than duplicating *all* information (duplicating *some* is
usually desirable), I would make use of external servers to resolve
the unknown attributes.  This could be done recursively or iteratively,
using DNS terminology.

 > > ...  More organization and distribution is
 > > preferred to less since it allows the client and local servers to do
 > > more.  The trick is to make the organization be more persistent even
 > > while it is being reorganized.  (The path scheme does that trick.)
 > 
 > Neat trick. How does it work?

First, consider the server which used to serve a part of the name
space that has moved.  If the server still exists and is cooperative,
it can redirect queries to a new "location".  Verifying that the
server is telling the truth is a security concern.  This redirection
might be repeated several times.

Second, if the server does not exist, or does not cooperate, then the
parent server in the hierarchy can be asked.  If the parent fails, we
ask its parent, etc, up to the root.  If the root fails, then as a
last resort, we can try other resolvers that advertise archive
services for particular old name spaces.

This second mechanism, the fallback mechanism of climbing up the
hierarchy, seems like it will be a problem for the higher-level
servers since, over time, higher-level servers will tend to be queried
about more old names.  But the situation is not so bad for a couple
reasons.

First, multiple names for resources may exist, so we need to support
that.  Some names will be preferred (by providers or by clients) over
others.  Old names based on old organizations of the name space are
not usually preferred over new names based on new organizations.  New
resources will tend to make use of the preferred names (whether new or
old), and it is the new, or updated, resources that are usually more
popular.  It is possible that an old resource referencing old names
may suddenly become popular again, but I suspect this will be
relatively rare.  Furthermore, caches of the redirection information
may be used even so, so the load can be distributed away from the high
level servers.

Second, consider the alternatives.  If you are not given information
about where to go to resolve a name, where in the whole galaxy do you
go?  There might be many alternative resolvers and going to all of
them or trying one after another with no clue as to whether they might
succeed is wasteful of both the clients time and all the remote
servers time.  This is the "last resort" mechanism.  We are better off
providing clues if we can, a trail of redirections to the new
location, than providing no clues.

The NAPTR mechanism provides for a two level hierarchy (or more levels
with hierarchical naming authorities), but no fallback mechanism.  In
fact, there are words to the effect that fallback should *not* be
used.

By the way, a matrix space might provide even greater persistence
since even if resolution based on one attribute fails, we can still
try the other attributes.  We only get to the last resort mechanism
after all the attributes fail.

Greater persistence comes at the expense of greater resolution time.
But we are OK if most of the time we don't have to spend much time.

--
Daniel LaLiberte ([email-masked])
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/

Date: Mon, 10 Feb 1997 16:41:04 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: Daniel LaLiberte <[email-masked]>
Cc: urn-ietf <[email-masked]>
Subject: Re: [URN] Scalable resolution
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

On Thu, 6 Feb 1997, Daniel LaLiberte wrote:

>  > > Moreover, exposing the structure permits more scalable resolution.
>  > > Information obtained at intermediate levels can be cached so the
>  > > client can use that information in subsequent similar requests rather
>  > > than requesting it again.  
>  > 
>  > If that is done, it will be scheme/namespace-specific.
> 
> Not necessarily.

All the examples you cite below are scheme/namespace-specific.
or they are not tied to the "/".

> The path scheme resolution mechanism takes advantage
> of the lower level DNS resolution which caches DNS information.  HTTP,
> FTP, and any other schemes that include DNS names also do the same.

Syntactically, the DNS hierarchy has nothing to do with the "/"
hierarchy. And where it does, in your "path:" scheme, it is again
scheme-specific.

> Even the NAPTR resolution mechanism uses DNS.  The information that is
> cached includes not only IP addresses but other strings and resource
> data.  In fact, the NAPTR mechanism *may* be used to support the path
> scheme resolution mechanism all the way down to the "terminal
> resolver".

There is nothing that prevents the definition of NAPTR regular
expressions to be alligned with the "/" hierarchy. But there is
also nothing that prevents NAPTR regular expressions to use some
kind of hashing, or some other strategy.
And while the cashing mechanism will be general in case of NAPTR,
the cashing strategy will be decided by the providers of NAPTR
entries (in contrast to domain names, where it is tied to
domain name syntax). The regexps allow for vast flexibility
way beyond the "/".

> Scheme specific caching is also useful, though more difficult to
> deploy as discussed next.
> 
>  > Currently,
>  > the closest thing to this is the ftp: scheme, where you *could* have
>  > a connection open over subsequent downloads and move across the
>  > directories with "cd" commands.
> 
> Leaving a connection open (whether ftp or http) is a further
> optimization that works with URIs that have common prefixes.
> Both "caching connections" and caching data are useful.
> 
> With Java applets, we can begin to cache services, not just static
> data or connections to remote services.

And we move even farther from any ties to the "/" hierarchy.
Any kind of similarity between two different URIs can be taken
advantage of, if there is indeed an advantage in this similarity.

>  > It's not possible now with URLs
>  > to deduce some "localized" information just from the fact that
>  > an URL contains some slashes.
> 
> There is, in fact, some cached data that is relative to the internals
> of http servers.  HTTP authentication realms and cookies are stored
> relative to a prefix of http URLs, including the path down to the last
> component.  These data are cached by each client rather than by cache
> servers.

Nice to know. But again scheme-specific.

>  > We shoudn't try to introduce such an assumption for URNs, where
>  > relativity seems to have less merrit than for URLs.
> 
> I don't agree that relativity and hierarchy have less merit for URNs.
> If you are arguing against hierarchical name spaces you are arguing
> *for* flat name spaces, unless there is another direction that makes
> sense.

I have nothing against namespaces being hierarchical. But there are
big differences between a namespace *having* some hierarchical
structure, a namespace *showing* some hierarchical structure (with
whatever syntactical means), some kind of hierarchy (even from
back to front, which is closer to hashing than to hierarchy)
being used for cashing and quick resolution, and a specific
syntaxt (namely the "/") being used to patch together BASEs
and relative parts. It's only the last one that's necessarily
generic, and it doesn't apply very much to URNs.

> Just as Karen mentioned, I don't know how to do scalable resolution in
> a matrix space, although I wouldnt discount it without some proof.
> Probably each of the attribute names should be organized in a
> hierarchy, with a small top level just as for DNS, so that resolution
> of one set of attribute-value pairs amounts to the sum of the
> resolutions of each pair.  This is not unlike general attribute-value
> queries of a database, but the database is highly distributed.

Well, in DNS, you actually have the beginning of a matrix space.
You can look up something according to domain name or according
to internet number. Dealing with many "?" wildcards as in Karin's
example, the problem lies primarily with the size of the remaining
search space itself, and not with the structure.

As for the rest, it's easy to calculate the amount of duplication
of index information that you need if out of N attributes, R
are known, and you don't want to access any surplus areas
of the search space. It's the number of combinations of R
elements out of a set of N (written nCr on my pocket calculator).
That's a maximum of 10 for N=5, 20 for N=6, 35 for N=7, and 252
for N=10. The numbers are so that it is difficult to speak both
of a proof and of a disproof. It depends no the individual case.

Organizing the whole thing, of course, is a different matter.
In case of X.500, it might be rather impossible to tell some
site: Well, in addition to the records for your organization,
you also are going to take care for the "inverted" records
for all people named "Karin" on the net. Privacy issues
would be a first showstopper.

>  > >   http://union.ncsa.uiuc.edu/~liberte/scalability.html
>  > > 
>  > > In order of preference we have:
>  > > 1. No distribution - one server
>  > > 2. Random distribution
>  > > 3. Organized distribution
>  > 
>  > So no distribution is preferable to random distribution which is
>  > preferable to organized distribution?
> 
> I meant the other way around.  More organization and distribution is
> preferred to less since it allows the client and local servers to do
> more.  The trick is to make the organization be more persistent even
> while it is being reorganized.  (The path scheme does that trick.)

Neat trick. How does it work?

Regards,	Martin.

Date: Fri, 07 Feb 1997 10:55:04 -0700
To: omar syed <[email-masked]>, Daniel LaLiberte <[email-masked]>
From: "Ron Daniel Jr." <[email-masked]>
Subject: Re: [URN] Re: Relative URLs and URNs
Cc: URL mailing list <[email-masked]>, [email-masked]
Sender: [email-masked]
Reply-To: "Ron Daniel Jr." <[email-masked]>

Thus spoke omar syed (at least at 10:58 AM 2/3/97 -0500)

>To resolve a URN to a location, resource or citation, a client
>always needs to consult a remote resolver and pass it the
>complete URN or partially processed URN.  Is this not always true?

Always? No. A client may have an internal namespace, such as
"about:" that it never sends to a remote resolver.

Most of the time? Yes.

Ron Daniel Jr.                       email: [email-masked]
Advanced Computing Lab,  MS B287     voice: +1 505 665 0597
Los Alamos National Laboratory         fax: +1 505 665 4939
Los Alamos, NM, USA  87545            http://www.acl.lanl.gov/~rdaniel/
 Want to buy: "The Five Laws of Library Science" by S.R. Ranganathan

From: Fisher Mark <[email-masked]>
To: urn-ietf <[email-masked]>
Subject: RE: [URN] Scalable resolution
Date: Thu, 06 Feb 97 15:05:00 EST
Encoding: 31 TEXT
Sender: [email-masked]
Reply-To: Fisher Mark <[email-masked]>

Daniel LaLiberte writes in <D7BAE2C53C80D011B07500805F623C93>:
>I don't agree that relativity and hierarchy have less merit for URNs.
>If you are arguing against hierarchical name spaces you are arguing
>*for* flat name spaces, unless there is another direction that makes
>sense.
>
>Just as Karen mentioned, I don't know how to do scalable resolution in
>a matrix space, although I wouldnt discount it without some proof.
>Probably each of the attribute names should be organized in a
>hierarchy, with a small top level just as for DNS, so that resolution
>of one set of attribute-value pairs amounts to the sum of the
>resolutions of each pair.  This is not unlike general attribute-value
>queries of a database, but the database is highly distributed.

Although some namespaces may desire or even demand flatness (or at least a 
non-user-visible hierarchy or matrix), IMHO there is no reason to prohibit 
hierarchies or matrices.  If the creators of the namespace desire flatness, 
there is nothing in the current syntax that prevents them from having a flat 
namespace.  Namespace creators that desire a hierarchy or a matrix (or a 
combo) can create their namespace with those properties.

For long-lived resources, I can see a day where many long-lived resources, 
ranging from Internet RFC's to Thomson Consumer Electronics' latest 
newsletter, are commonly known by URNs.  We should let the "marketplace of 
URN ideas" shake out which are the viable namespace schemes and which are 
not -- we are too early in the development process to definitely say whether 
all namespaces should be flat, hierarchical, matrix, or hierarchy+matrix.
======================================================================
Mark Leighton Fisher                   Thomson Consumer Electronics
[email-masked]                   Indianapolis, IN

From: Daniel LaLiberte <[email-masked]>
Date: Thu, 6 Feb 1997 12:43:52 -0600 (CST)
To: urn-ietf <[email-masked]>
Cc: [email-masked]
Subject: [URN] Scalable resolution
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

[Hope the URN list is still working.  I got a flood of bounces on
Sunday - and I'm not sure my message went out. Maybe starting with
some text will avoid erroneous processing by the list server.]

Martin J. Duerst writes:
 > But the idea of a client
 > using the relative structure to find something more quickly
 > will not work (it might work on a resolver close to the client,
 > and for a certain namespace, though).

The client *could* find something more quickly, but perhaps not for
the reason you thought I meant (I'm not sure what you thought I
meant).  

Here is an abstract view of what can happen - see more concrete
examples below.  While resolving an identifier, the client may receive
information during intermediate steps of the resolution process that
it may use for resolution of other similar identifiers at a later
time.  For example, the location of the server corresponding to
"path:/A/B" may be used to start the resolution process at that same
place whenever the prefix of an identifier is the same.
"path:/A/B/C1" and "path:/A/B/C2" both start with the same prefix.

 > > Moreover, exposing the structure permits more scalable resolution.
 > > Information obtained at intermediate levels can be cached so the
 > > client can use that information in subsequent similar requests rather
 > > than requesting it again.  
 > 
 > If that is done, it will be scheme/namespace-specific.

Not necessarily.  The path scheme resolution mechanism takes advantage
of the lower level DNS resolution which caches DNS information.  HTTP,
FTP, and any other schemes that include DNS names also do the same.
Even the NAPTR resolution mechanism uses DNS.  The information that is
cached includes not only IP addresses but other strings and resource
data.  In fact, the NAPTR mechanism *may* be used to support the path
scheme resolution mechanism all the way down to the "terminal
resolver".

Scheme specific caching is also useful, though more difficult to
deploy as discussed next.

 > Currently,
 > the closest thing to this is the ftp: scheme, where you *could* have
 > a connection open over subsequent downloads and move across the
 > directories with "cd" commands.

Leaving a connection open (whether ftp or http) is a further
optimization that works with URIs that have common prefixes.
Both "caching connections" and caching data are useful.

With Java applets, we can begin to cache services, not just static
data or connections to remote services.

 > It's not possible now with URLs
 > to deduce some "localized" information just from the fact that
 > an URL contains some slashes.

There is, in fact, some cached data that is relative to the internals
of http servers.  HTTP authentication realms and cookies are stored
relative to a prefix of http URLs, including the path down to the last
component.  These data are cached by each client rather than by cache
servers.

Martin Hamilton and I wrote a proposal on indexing and searching
extensions for HTTP in which the idea of collections is mentioned.  A
collection corresponds to a node in the hierarchy.  Information about
each collection (such as the names of components) may be cached and
used to resolve later requests.

 > We shoudn't try to introduce such an assumption for URNs, where
 > relativity seems to have less merrit than for URLs.

I don't agree that relativity and hierarchy have less merit for URNs.
If you are arguing against hierarchical name spaces you are arguing
*for* flat name spaces, unless there is another direction that makes
sense.

Just as Karen mentioned, I don't know how to do scalable resolution in
a matrix space, although I wouldnt discount it without some proof.
Probably each of the attribute names should be organized in a
hierarchy, with a small top level just as for DNS, so that resolution
of one set of attribute-value pairs amounts to the sum of the
resolutions of each pair.  This is not unlike general attribute-value
queries of a database, but the database is highly distributed.

 > >   http://union.ncsa.uiuc.edu/~liberte/scalability.html
 > > 
 > > In order of preference we have:
 > > 1. No distribution - one server
 > > 2. Random distribution
 > > 3. Organized distribution
 > 
 > So no distribution is preferable to random distribution which is
 > preferable to organized distribution?

I meant the other way around.  More organization and distribution is
preferred to less since it allows the client and local servers to do
more.  The trick is to make the organization be more persistent even
while it is being reorganized.  (The path scheme does that trick.)

--
Daniel LaLiberte ([email-masked])
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/

From: Daniel LaLiberte <[email-masked]>
Date: Tue, 4 Feb 1997 01:51:13 -0600 (CST)
To: "Karen R. Sollins" <[email-masked]>
Cc: [email-masked]
Subject: Re: [URN] Global URNs and relative URIs
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

This definition of "global" is an ideal, fairly abstract concept
dependent on the meaning of "same" and "meaning" itself.  But it is
similar to my own concept of "global", though I take a more practical
view of the problem.  How do you *know* that you get the same meaning
as I do when using a name.  Assuming we can arrange for some
verification, there is a prior problem that is even more basic: How do
we even *begin* to use a name in such a way that we have a chance of
getting the same meaning?  With many "global" services available, the
services I use may be different from the services you use.  I may not
even be able to get *any* meaning for some URN while you may. Before
we can compare notes on the meaning of a URN, we have to first compare
notes on the services we use, and how we identify those services, etc.
We have to start from some shared knowledge, perhaps hardwired into
our brains.

 >    What you can do with a URN is *intended* to be even more flexible than
 >    what you can do with a URL.  One thing you might do with a URN is pull
 >    apart its known structure to begin resolving it.  Its known structure
 >    is an implicit context, hardwired into the client code, or a proxy.
 > 
 > Second, you seem to forget that the internal strvcture of a URN is not
 > necessarily exposed.

Not at all.  By saying one can "pull apart its known structure", that
means that if the structure of a URN is not exposed, it is not known,
so you cannot pull apart anything.   But you have to start somewhere
as you and I both point out:

 > It may be the case that only the generator of
 > the URN (aka naming authority) knows the internal structure of a URN.

So you should be able to pull out the naming authority at least so you
can look up some service that knows how to parse the structure, if
any.  

 > Lack of exposure of the
 > internal structure of a URN should not make it less useful.

Lack of exposure of the internal structure of a URN makes it
impossible for the client to do anything with the URN itself other
than to pass it on to some external server that does know what to do
with the URN.  You may find benefit in that (e.g. centralized
control), but I see mostly lack of scalability.

 > Just because the NAPTR proposal for a UDS
 > is built on an assumption that structure must be exposed

The only structure necessarily exposed by the NAPTR mechanism is what
I believe you agree should be exposed: the naming authority.  More
structure *may* be defined for particular name spaces, by way of
regular expressions that match the parts of the URN.
If not even the naming authority must be exposed, then indeed you
have a very flat name space.

By the way, the scheme name itself, if it were not just "urn:", could
be used to tell how and where to start the resolution.

 > Those of us who look further into the future

I assume you are including me.  I was inspired by Larry Masinter's 500
year vision.

 > assume that naming authorities and the structures they choose may
 > come and go as will name resolution paradigms.

I have no problem with that.  Note that even with a structured name,
its structure need not be used, or it may be used in different ways
than originally intended.  And these alternative uses of the
structured name do not break its persistence, etc.  But given no
structure, there is no way to use a structure that is not there to
begin with.

 > It is not difficult to imagine a UDS that simply looks at
 > the names as opaque strings and looks them up as such.

I can imagine it, but I imagine it will be difficult to make such a
resolution mechanism scalable.  The CNRI handle resolution mechanism
is designed to work with large numbers of URNs, but at the expense and
risk of centralized control.  [But even they distribute the resolution
service randomly based on the character encoding of the URN, which is
structure though at a semantically meaningless level.]

 > NAPTR is intended for a subset of all
 > URNs - a subset that exposes its internal structure and is prepared to
 > have that structure used to find a local resolution service for the
 > named resources.

It doesn't expose more than the naming authority.  Is that too much?
If not that, then we have no structure at all - no clues as to where
to start the lookup, so where do we go?

 >    Back to the resolution process.  Once you get some info back from
 >    the urn.net server about the authority, you can continue to interpret
 >    the remainder of the URN relative to that info.  Etc.
 > 
 > Again, see my comments above.

Are you really assuming that it is proper for clients to not be
involved in the resolution process?  You better have a plan for how to
make that resolution scalable.

 > Third, maybe you don't worry about relative URLs escaping and maybe
 > lots of other people also join you in not worrying, but I for one am
 > concerned about it and I have certainly seen it cause things run amok.
 > It isn't always easy to get it right and the result can be a
 > misunderstanding about a reference, exactly what URNs are supposed be
 > addressing.

If URNs are resolved (starting from UDS look up) by dozens or hundreds
of alternative servers, not all of which resolve all URNs, and not all
providing the same associated services regarding URNs (e.g. metadata),
then I can see potentially lots of misunderstandings regarding URN
references.

For any identifier, URL or URN, you have to be sure that whoever is
interpretting it has the proper context.  How hard it is to keep that
context around (or to reference it) varies with the problem.  Keeping
the base URI around for resolution of relative URIs is a relatively
simple problem.

 >    Yep, clients can do whatever they want, if they can get away with it.
 > 
 > Fourth, this is exactly my point.  We should be letting the word out
 > that clients should be extremely careful about local representations
 > of things as relative anythings because it is really difficult to
 > guarantee that you are getting away with it.

I don't see what the big problem is.  What is expected of clients regarding
relative URIs is simple and well defined.

 > As discussed above, just because hierarchical structure is known and
 > tightly coupled to the UDS in the current proposal does not mean that
 > it will be forever, so letting relative URLs out beyond the privacy of
 > one's own playpen means that we would be requiring that structure
 > always to be known and reconstruction of absolute URNs a facility of
 > all future UDSs.

Your conclusion is false.  If a document uses relative URIs with a
base URN, it is the *client* that constructs absolute URNs from the
base URN and the relative URIs, and then the absolute URNs may be
resolved by whatever services the client may use regardless of any
structure.  Nothing regarding the structure is required of those
services.  What is required of those services is that the URNs
themselves remain resolvable, if they resolve to anything at all.

 > I would hate to see us put that kind of onus on
 > future generations.

I would too, but fortunately we don't have to worry about that.

 >    Maybe the problem is in calling "relative URNs" URNs at all, since they
 >    are not URNs until they are global, by your definition.  I'd actually
 >    prefer to call them just relative URIs.  That is more accurate anyway
 >    since the very same relative URI might be used with different base
 >    URIs to end up being a URL or a URN.
 > 
 > Lastly, I bit my fingers (tongue) during some of the previous
 > discussion, but let me try to say it briefly here.  I think we both
 > agree that as you are using it here "URI" is a syntax, a way of
 > expresing structure.  URNs and URLs are not syntaxes, but rather
 > semantic entities - identifiers and locators.

We don't agree.  I don't see it that way.  But to explain my position,
I would be tempted to launch into why the semantic differences between
URNs and URLs are non-existent.  I'll steer clear of that for now.

If anything, URNs and URLs are both types of identifiers, URIs.  Each
URI scheme has a syntax (a way of expressing or notating the
identifiers) and an *intended* semantics.  There is also a generic URI
syntax which applies to all schemes, and some generic semantics, such
as implied hierarchy and relative URI processing which applies to some
schemes.  (How we distinguish between syntax and semantics is somewhat
arbitrary anyway, but that is another subject.)

 > They have different
 > requirements, different functionality, and different resolutions.
 > They are abstractions.

Part of the problem might be that these abstractions, as you think of
them, do not exist in the real distributed, anarchistic world.  At
best, we have *intended* semantics.  At best, we have a "global" that
is maybe popularly recognized as the same thing by most people and
services.

 > What are considered addresses by one layer are considered names by
 > the next one down. This holds for URNs and URLs

So does this mean that URNs could be considered addresses at one layer
higher up?  Just as DNS names are considered (by some) addresses in
URLs?

This layered separation between names and addresses is only necessary
if you believe it is necessary to map from name to address, and from
there to the resource itself.  Do you believe in that necessity?  I
have shown in the path scheme that it is *not* necessary to go through
an address.  Would you argue, as I think you did in the past, that the
path scheme is therefore not a URN scheme, but merely a "persistent
URL" scheme?  Does this mean that if we add hierarchy to any URN
scheme, it suddenly ceases being a URN scheme?  If so, you are saying
that names *must* be flat and structureless.  If it is not the
hierarchy, what is it about the path scheme that disqualifies it for
URNhood in your mind?

dan

Path Scheme: http://union.ncsa.uiuc.edu/~liberte/www/path.html

Date: Mon, 03 Feb 1997 18:09:20 -0500
From: omar syed <[email-masked]>
Organization: NASA Lewis Research Center
To: "Karen R. Sollins" <[email-masked]>
Cc: [email-masked]
Subject: Re: [URN] Reltive URNs
Sender: [email-masked]
Reply-To: omar syed <[email-masked]>

Karen R. Sollins wrote:
> 
>>    If a new HTML tag similar to the <BASE> tag is introduced, (maybe
>>    something like <BASEURN HREF="URN">) and any resource that uses
>>    "relative URNs" is required to indicate the "base URN" using this
>>    new tag, then one can guarantee that a relative URN would never escape
>>    its context without being converted to its global form.
>> 
>>    Unlike the <BASE> tag which may only appear in the header, the
>>    <BASEURN> would need to appear in the body and have a scope
>>    (i.e. <BASEURN> .... </BASEURN>).  This is because a resource may
>>    have multiple contexts and some "relative URNs" may be valid in
>>    some contexts, but not in others.
>> 
>>    Omar
> 
> Omar (and others I think),
> 
> >From past discussions two things are clear.  First, there will
> hopefully be a variety of naming schemes that will have different
> syntaxes, so creating a a global URN from a relative one plus its base
> will mean that the syntax must be known.  But, second,q Ron Daniel has
> gone further than that.  He has suggested that within the privacy of a
> sub-sub-...-subdelegated namespace one ought to be completely free to
> pick the syntax for that part of the space.  My recollection is that
> Ron wasn't alone in this view (I don't mean to pick on Ron, but rather
> find a consistent position for the whole group.)  Thus, for example,
> within gov/lanl/cs there may be a scheme for naming TRs that involves
> group names, dates, perhaps author names, etc. and the need not be in
> any order predetermined by "gov" or "lanl" nor even the highest level
> scheme, call it "dns:" for now.  This means that for any such
> subdelegated namespace, its full syntax must be exposed globally, if
> relative names are ever to be used within its scope.  If not,
> reconstruction of the full URN, even given the base and relative name
> would be impossible.  This doesn't sound promising to me, but maybe
> I'm missing something here about how globally people will want to or
> be able to expose their internal structures and syntaxes.
> 
>                         Karen

Karen,

I agree that the knowledge of the full syntax (and symantics) of a name 
space should not be exposed globally so that a new URN can be
reconstructed 
from a base and relative URN pair.  I think that if the URN specs define
a procedure (and set aside reserved characters) by which a client
can syntacticly manipulate a base and relative URN pair to generate
a new URN, knowledge of the *full* syntax of a name space would not have 
to be exposed.  But all name spaces (which want to take advantage of
relative URNs) would have to conform to defined specifications.

What would be even better is if the client could pass the base and 
relative URN pair to the top level name space resolver and get back
the new URN.  Maybe something like a P2N (pair to name) capablity
provided by the resolver in addition to the others (N2L, N2R, N2C).
This would allow the clients to treat the base and relative URNs
in a completely opaque manner and no knowledge of the syntax or
symantics of the name space would be required on the client end and
no constraints would be imposed on name space syntax by the URN
specifications.

Omar

Date: Mon, 3 Feb 1997 16:26:42 -0500
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [URN] Reltive URNs
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

   If a new HTML tag similar to the <BASE> tag is introduced, (maybe
   something like <BASEURN HREF="URN">) and any resource that uses
   "relative URNs" is required to indicate the "base URN" using this
   new tag, then one can guarantee that a relative URN would never escape
   its context without being converted to its global form.

   Unlike the <BASE> tag which may only appear in the header, the
   <BASEURN> would need to appear in the body and have a scope
   (i.e. <BASEURN> .... </BASEURN>).  This is because a resource may
   have multiple contexts and some "relative URNs" may be valid in
   some contexts, but not in others.

   Omar

Omar (and others I think),

>From past discussions two things are clear.  First, there will
hopefully be a variety of naming schemes that will have different
syntaxes, so creating a a global URN from a relative one plus its base
will mean that the syntax must be known.  But, second,q Ron Daniel has
gone further than that.  He has suggested that within the privacy of a
sub-sub-...-subdelegated namespace one ought to be completely free to
pick the syntax for that part of the space.  My recollection is that
Ron wasn't alone in this view (I don't mean to pick on Ron, but rather
find a consistent position for the whole group.)  Thus, for example,
within gov/lanl/cs there may be a scheme for naming TRs that involves
group names, dates, perhaps author names, etc. and the need not be in
any order predetermined by "gov" or "lanl" nor even the highest level
scheme, call it "dns:" for now.  This means that for any such
subdelegated namespace, its full syntax must be exposed globally, if
relative names are ever to be used within its scope.  If not,
reconstruction of the full URN, even given the base and relative name
would be impossible.  This doesn't sound promising to me, but maybe
I'm missing something here about how globally people will want to or
be able to expose their internal structures and syntaxes.

			Karen

From: Daniel LaLiberte <[email-masked]>
Date: Mon, 3 Feb 1997 15:16:11 -0600 (CST)
To: Scott Seligman <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [URN] Re: Relative URLs and URNs 
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Scott Seligman writes:
 > An excellent insight:  we must be careful to distinguish between
 > syntactic transformations and semantic "knowledge".  The rules for
 > processing relative URIs are an example of the former.

Well, whether it is a syntactic transformation or semantic knowledge
is ... just semantics (i.e. it's an arbitrary distinction), especially
in this case.  A syntactic transformation based on rules about a '/'
separated list of components is essentially implicit, innate knowledge
about the corresponding hierarchy.  What kind of semantic knowledge
are you thinking about that is knowledge about a hierarchy but
distinguishable (not derivable) from the transformation rules?

One thing that *might* be different (if we agree on the following) is
that you cannot assume anything more about the hierarchy than you
operate on given a set of relative URIs that climb around in the
hierarchy.  For example, if none of the relative URIs you operate on
start with '.' or '..', they never climb up the hierarchy, so you
don't know if you are allowed to, even if there are '/'s in the base
URI.  But what you do know about is at least partial knowledge of the
hierarchy.

But I don't think that I even agree with the previous paragraph.  If
URIs can only use '/' to imply hierarchy so that relative URIs can be
used, there are some other things that the knowledge of the existence
of a hierachy can be used for.  Some web crawlers explore by looking
at all prefixes of a known URL to find other URLs.  These new URLs may
return a directory index or an index.html file, for example.  All
these generated URIs can be requested, but any particular URI, even
one that looks like an intermediate node in a hierarchy, might
correspond to nothing.

Something that exists for one user might not (apparently) exist
for another user, for security reasons.

But if an opaque URI scheme can use '/' for whatever it want besides
hierarchy, you have to know at least whether the scheme is opaque
before you can infer any hierarchy.

--
Daniel LaLiberte ([email-masked])
National Center for Supercomputing Applications
http://union.ncsa.uiuc.edu/~liberte/

To: [email-masked], [email-masked]
Subject: Re: [URN] Re: Relative URLs and URNs 
Date: Mon, 03 Feb 1997 10:50:19 -0800
From: Scott Seligman <[email-masked]>
Sender: [email-masked]
Reply-To: Scott Seligman <[email-masked]>

Martin J. Duerst writes:
>
>First, relative operations are purely syntactical, so the client will
>just chop off on the URN and either construct something (or get
>stuck). This is actually in contrast with what Daniel suggests
>or supposes in some of his mails, namely that the browser is using
>some knowledge about the hierarchy for retrieval: It doesn't
>presently for URLs.

An excellent insight:  we must be careful to distinguish between
syntactic transformations and semantic "knowledge".  The rules for
processing relative URIs are an example of the former.

>For those that are sceptical with respect to relative namespaces,
>it means just not to allow slashes in your namespace or your URNs.

There's no need to be even this strong.  If relative naming is
inappropriate for a particular URI namespace, then don't publish
relative URIs for that namespace.  All the issues about whether and
how slashes should be interpreted then become moot.

The guidance that the RFCs should give is this:  If a namespace designer
chooses to use a slash in a (semantic) manner that is inconsistent with
current practice, then even if no syntactic difficulties are caused,
he will be at risk of generating "much heat (but maybe little light)"
and should think carefully.

Scott
[email-masked]

Date: Mon, 03 Feb 1997 11:05:24 -0600
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: [email-masked]
Subject: [URN] Pre-release #3 of syntax -02 draft...
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

This is a multi-part message in MIME format.

--------------762F7F53594C
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Thanks to everyone for comments, and especially thanks to Leslie for
putting them together.  Attached is the pre-release #3 of 
the syntax draft (or is it #4?).

Changes from last pre-release are:

Addition of reserved character set and discussion section (2.3).
"%" and "/" are now moved to the reserved character set.  The
discussion of "%" and %-encoding now moved to this section.  Discussion
added for "/".

Any more comments, or can we go with this as -02?

Ryan

--------------762F7F53594C
Content-Type: text/plain; charset=us-ascii; name="urn.syntax.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline; filename="urn.syntax.txt"

Internet-Draft                                                Ryan Moats
draft-ietf-urn-syntax-02.txt                                        AT&T
Expires in six months                                       January 1997

                               URN Syntax
                 Filename: draft-ietf-urn-syntax-02.txt

Status of This Memo

      This document is an Internet-Draft.  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.''

      To learn the current status of any Internet-Draft, please check
      the ``1id-abstracts.txt'' listing contained in the Internet-
      Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net
      (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East
      Coast), or ftp.isi.edu (US West Coast).

Abstract

   Uniform Resource Names (URNs) are intended to serve as persistent
   resource identifiers. This document sets forward the canonical syntax
   for URNs.  Support for both existing legacy and new namespaces is
   discussed. Requirements for URN presentation and transmission are
   presented.  Finally, there is a discussion of URN equivalence and how
   to determine it.

1. Introduction

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

Expires 7/31/97                                                 [Page 1]

INTERNET DRAFT                 URN Syntax                   January 1997

2. Syntax

   All URNs have the following syntax:

                     <URN> ::= "urn:" <NID> ":" <NSS>

   <NID> is the Namespace Identifier, and <NSS> is the Namespace
   Specific String.  The leading case-insensitive "urn:" sequence is
   required.  The Namespace ID is used to determine the _syntactic_
   interpretation of the Namespace Specific String (as discussed in
   [1]).

   RFC 1737 [2] presents additional requirements on URN encoding, which
   all have implications as far as limiting syntax.  On the other hand,
   the requirement to support existing legacy naming systems has the
   effect of broadening syntax.  Thus, we discuss the acceptable syntax
   for both the Namespace Identifier and the Namespace Specific String
   separately.

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, the syntax for
   the Namespace Identifier is:

   <NID>         ::= <let-num> [ *<let-num-hyp> ]

   <let-num-hyp> ::= <upper> | <lower> | <number> | "-"

   <let-num>     ::= <upper> | <lower> | <number>

   <upper>       ::= "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"

   <lower>       ::= "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"

   <number>      ::= "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
                     "8" | "9"

   This is slightly more restrictive that what is stated in [3] (which

Expires 7/31/97                                                 [Page 2]

INTERNET DRAFT                 URN Syntax                   January 1997

   allows the characters "." and "+").  Further, the Namespace
   Identifier is case insensitive, so that "ISBN" and "isbn" refer to
   the same namespace.

   To avoid confusion with the "urn:" identifier, the NID "urn" is
   reserved and MUST NOT be used.

2.2 Namespace Specific String Syntax

   As required by 1737, there is a single canonical representation of
   the NSS portion of an URN.   The format of this single canonical form
   follows:

   <NSS>         ::= 1*<URN chars>

   <URN chars>   ::= <trans> | "%" <hex> <hex>

   <trans>       ::= <upper> | <lower> | <number> | <other> | <reserved>

   <hex>         ::= <number> | "A" | "B" | "C" | "D" | "E" | "F" |
                     "a" | "b" | "c" | "d" | "e" | "f"

   <other>       ::= "(" | ")" | "+" | "," | "-" | "." |
                     ":" | "=" | "?" | "@" | ";" | "$" |
                     "_" | "!" | "~" | "*" | "'"

   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 chars>).  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 one to six octets using UTF-8 encoding, and the encoding
   of each of those octets as "%" followed by two characters from the
   <hex> character set above. The two characters give the hexadecimal
   representation of that octet.

2.3 Reserved characters

   The remaining character set left to be discussed above is the
   reserved character set, which contains various characters reserved
   from normal use.  The reserved character set follows, with a
   discussion on the specifics of why each character is reserved.

   The reserved character set is:

   <reserved>    ::= "/" | "%"

Expires 7/31/97                                                 [Page 3]

INTERNET DRAFT                 URN Syntax                   January 1997

2.3.1 The "%" character

   The "%" character is reserved in the URN syntax for introducing the
   escape sequence for an octet.  Literal use of the "%" character in a
   namespace must be encoded using "%25" in URNs for that namespace.
   The presence of an "%" character in a URN MUST be followed by two
   characters from the <hex> character set.

   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.  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.2 The "/" character

   The "/" character is RESERVED for denoting relativity in the URN
   namespace (i.e. as part of the process of handling URNs).  A "/"
   should be %-encoded (i.e. %2F) if and only if:

         - in the particular namespace, "/" does not necessarily denote
           hierarchy (or other relative terms).
         - the designers of the namespace have determined that it is
           not desirable to expose that hierarchy _for_the_purposes_
           _of_describing_relationships_between_URNs (e.g., if some
           other hierarchy is desired)

2.4 Excluded characters

   The following list is included only for the sake of completeness.
   Any octets/characters on this list are explicitly NOT part of the URN
   character set, and if used in a URN, MUST be %encoded:

   <excluded> ::= octets 0-32 (0-20 hex) | "\" | """ | "#" | "&" | "<"
                  | ">" | "[" | "]" | "^" | "`" | "{" | "|" | "}" | octets 127-255 (7F-FF hex)

   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.

3. Support of existing legacy naming systems and new naming systems

   Any namespace (existing or newly-devised) that is proposed as a URN-
   namespace and fulfills the criteria of URN-namespaces MUST be
   expressed in this syntax.  If names in these namespaces contain

Expires 7/31/97                                                 [Page 4]

INTERNET DRAFT                 URN Syntax                   January 1997

   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

   URN-aware applications MAY support "natural" display of URNs which
   contain characters encoded using "%" notation.  However, they MUST
   provide for display of URNs in canonical form (i.e. in a format
   suitable for transcription).

   URNs MUST be transported in canonical format.

5. Lexical Equivalence in URNs

For various purposes, such as caching, it is necessary to determine
equivalence without actually resolving the URN. This done by testing for
"lexical equivalence". Two URNs are lexically equivalent if they are
octet-by-octet equal after the following preprocessing

        1. normalize the case of the leading "urn:" token
        2. normalize the case of the NID
        3. normalizing the case of any "%" escaping

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.

6. Functional Equivalence in URNs

   Functional equivalence is determined by URN resolvers and is
   therefore outside the scope of this document.  Namespace registration
   MUST include documentation on how to determine functional equivalence
   for that namespace.

7. Examples of equivalence

   The following URN comparisons highlight the difference between these
   types of equivalence:

     urn:isbn:1-23485-8-29, urn:isbn:1-23485-8-29 are lexically equiv.
     urn:isbn:1-23485-8-29, URN:ISBN:1-23485-8-29 are lexically equiv.
     urn:isbn:1-23485-8-29, urn:isbn:123485829 are not lexically equiv.
        but may be functionally equivalent.

Expires 7/31/97                                                 [Page 5]

INTERNET DRAFT                 URN Syntax                   January 1997

8. Security considerations

   This document specifies the syntax for URNs.  While some namespaces
   resolvers 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
   strongly recommended that the process of registering a namespace
   identifier include any such considerations.

9. Acknowledgments

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

10. References

   Request For Comments (RFC) and Internet Draft documents are available
   from <URL:ftp://ftp.internic.net> and numerous mirror sites.

         [1]         K. R. Sollins. "Requirements and a Framework for
                     URN Resolution Systems" Internet Draft (work in
                     progress).  November 1996.

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

         [3]         T. Berners-Lee, R. Fielding, L. Masinter. "Uniform
                     Resource Locators (URL)," Internet Draft (work in
                     progress).  December 1996.

11. Editor's address

   Ryan Moats
   AT&T
   15621 Drexel Circle
   Omaha, NE 68135-2358
   USA

   Phone:  +1 402 894-9456
   EMail:  [email-masked]

Expires 7/31/97                                                 [Page 6]

INTERNET DRAFT                 URN Syntax                   January 1997

Appendix A. 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 URL
   syntax specification [3] will extract a scheme value of "urn:"
   rather than a scheme value of "urn:<nid>".

   A URN MUST be considered an opaque URL by URL resolvers and either
   passed (with the "urn:" tag) to a 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-in to the URL resolver.

   To avoid confusion of users, a URL browser SHOULD display the com-
   plete URN (including the "urn:" tag) to ensure that there is no con-
   fusion between URN namespace identifiers and URL scheme identifiers.

                This Internet Draft expires July 31, 1997.

Expires 7/31/97                                                 [Page 7]

--------------762F7F53594C--

Date: Mon, 3 Feb 1997 18:00:23 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: Daniel LaLiberte <[email-masked]>
Cc: urn-ietf <[email-masked]>, URL mailing list <[email-masked]>
Subject: Re: [URN] Re: Relative URLs and URNs
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

On Fri, 31 Jan 1997, Daniel LaLiberte wrote:

> RFC 1808 describes a seven step process for constructing the absolute
> URL from the relative URL and the context.  We can just substitute URI
> (and therefore include URN) wherever it says URL.  The first step of
> the seven concerns finding the base URI, which I give here in brief
> since that is where the clarification is needed.
> 
> Use the first one that succeeds:
> 
> 1. Use the explicit base URI from the document content, if any.
> 2. Use the explicit base URI from the encapsulating entity, if any.
>    (e.g. http response message, another document, etc)
> 3. Use the URI used to retrieve the entity, if any.
> 4. Otherwise the base URI is undefined.
> 
> Step 3 should be clarified: If there is no explicit base URI
> found by step 1 and 2, we should use the *last* URI used
> to retrieve the entity, not the first or some intermediate.  This
> applies both for a chain of URL redirections or for a URN that is
> resolved into a URL.  Roy Fielding pointed this out to me when I
> thought it should be the first URI used, or perhaps the last
> permanent redirect.
> 
> So this clarification is an answer to your question above; whether
> the relative URI is applied to the name or the location depends on
> what the document and server say should be done.

Many thanks for the clarification. This means that *if* you have
some kind of resolution chain, then it is the last result in this
chain that is relevant. So in the case of a simple resolution chain
URN -> URL -> Resource, this means that it's the URL, and not
the URN, that is used for relative operation. This, and the
fact that you always can specify the base of the relative operations
with <BASE>, means that you always have a way out.

Now the next question is: What happens if resolution is "direct",
and the original URN becomes the base of relative operations?
Actually, that might not be as bad as some of us think. First,
relative operations are purely syntactical, so the client will
just chop off on the URN and either construct something (or get
stuck). This is actually in contrast with what Daniel suggests
or supposes in some of his mails, namely that the browser is using
some knowledge about the hierarchy for retrieval: It doesn't
presently for URLs.

Second, the document provider, which may not be identical
to the URN provider, but anyway has to be somewhat related to it,
and is certainly lumped together with it by the user on the client
side, has control over what the base of the document will be, and
knows whether the base, concatenated (more or less) with the
relative references in the document, lead to sensible things
(whether they be URLs or URNs).

Third, a spec for a certain scheme says whether this scheme is
generic or not, but the relativity processing machinery of the
client doesn't need to know. If it sees a relative reference
(no "urn:" prefix nor any scheme prefix and so on), and has
to resolve it, it just works ahead with the base and produces
something according to well-defined rules. If some HTML document
has <BASE HREF="mailto:[email-masked]">, and a relative reference
HREF="aaa/bbb", the client will just come up with a mailtool
for aaa/bbb (at least that was what I got on my few tests),
which means that it has, hopefully according to some provisions
in the relative URL spec, constructed an URL of mailto:aaa/bbb.

Fourth, the "/" is reserved for hierarchy (and nothing else)
according to RFC 1630, but not so according to RFC 1738.
An opaque scheme can use the "/" for whatever it wants.
Of course, this might not be a good idea because it might
give the impression of hierarchy where there is none, but
it's not a problem.

So for URN syntax and stuff, this may have the interesting
consequence that we don't really have to worry about it :-).
If an URN namespace wants to use the "/", for whatever purpose,
it can do so. If an URN producer wants to produce URNs with
a slash in them, (s)he may do so, given that the namespace
allows it (or may have to use slashes if the namespace requires it).
If a content provider wants to take advantage of hierarchical
resolution, (s)he may do so given that the URIs that will be
produced after the prescribed syntactical operations refer
to the intended resource.

The whole thing actually works on Netscape (Sun and Mac)
and probably on other browsers. For a document with
<BASE HREF="urn:isbn:xyz/"> and a link with <A HREF="abc/def">
I get the error:
	URN's not internally supported,
	use an HTTP proxy server: urn:isbn:xyz/abc/def
This, apart from the "'" in "URN's", makes good sense with
respect to the above.

So for Daniel, this means that the idea of having path:
and http: in parallel will work. But the idea of a client
using the relative structure to find something more quickly
will not work (it might work on a resolver close to the client,
and for a certain namespace, though).

For those that are sceptical with respect to relative namespaces,
it means just not to allow slashes in your namespace or your URNs.

For the syntax document, it means that "/" can be a character like
e.g. a letter, without any special provisions. If it's used in
a reserved function in a namespace, and this namespace has the
requirement to encode it in functions other than the reserved
function, it has to be escaped, as is the case for other characters.

We would have to add that in terms of relative addressing, URNs
are treated in the same way as URLs (if they ever have to be
treated that way).

The only thing that is not clear to me currently is what happens
with the "#". This is more dangerous than "/" because a "#" actually
means "don't send the part after me to the resolver", which is not
the thing that an average URN scheme might want to happen.
The examples I have just tested with my browser (where the part
after the "#" actually does get sent off sometimes), and my understanding
of relative processing are not as thourough to make any conclusions
on this issue. Another thing that might get in the way of "relative
URNs" is the second ":". In simple cases, it seems to work, but
I don't know about more complicated cases.

> Exposing the hierarchical structure *allows* use of relative URNs, but
> even with that structure, you wouldn't have to use relative URNs if
> you did not want to.

Agreed.

> Moreover, exposing the structure permits more scalable resolution.
> Information obtained at intermediate levels can be cached so the
> client can use that information in subsequent similar requests rather
> than requesting it again.  

If that is done, it will be scheme/namespace-specific. Currently,
the closest thing to this is the ftp: scheme, where you *could* have
a connection open over subsequent downloads and move across the
directories with "cd" commands. It's not possible now with URLs
to deduce some "localized" information just from the fact that
an URL contains some slashes. We shoudn't try to introduce such
an assumption for URNs, where relativity seems to have less merrit
than for URLs.

> I've written (long ago - rough draft) some more on this scaling issue at:
> 
>   http://union.ncsa.uiuc.edu/~liberte/scalability.html
> 
> In order of preference we have:
> 1. No distribution - one server
> 2. Random distribution
> 3. Organized distribution

So no distribution is preferable to random distribution which is
preferable to organized distribution? Why then do you stress
organised distribution so much?

Regards,	Martin.

Date: Mon, 03 Feb 1997 11:55:09 -0500
From: omar syed <[email-masked]>
Organization: NASA Lewis Research Center
To: "Karen R. Sollins" <[email-masked]>
Cc: [email-masked]
Subject: Re: [URN] Reltive URNs
Sender: [email-masked]
Reply-To: omar syed <[email-masked]>

Karen R. Sollins wrote:
> 
> Yes, URNs are intended not only to be persistent, but also to be
> global.  Furthermore, the closest we got in the URN requirements to
> humans was to say that they be "human transcribable".  We
> intentionally did not go further into the realm of human friendliness.
> Relative and global are contradictory in my model of this world,
> unless someone can _guarantee_ that a relative URN would NEVER escape
> the environment within which it is relative without being converted to
> its global representation.  But, if that's the case, it doesn't belong
> in a standard anyway; it's a private convention, and people can do
> anything they want in private, as long as it doesn't affect the
> outside world.
> 
> So, this whole discussion about "relative" URNs leaves me very puzzled.
> 
>                         Karen

If a new HTML tag similar to the <BASE> tag is introduced, (maybe
something like <BASEURN HREF="URN">) and any resource that uses
"relative URNs" is required to indicate the "base URN" using this
new tag, then one can guarantee that a relative URN would never escape
its context without being converted to its global form.

Unlike the <BASE> tag which may only appear in the header, the
<BASEURN> would need to appear in the body and have a scope
(i.e. <BASEURN> .... </BASEURN>).  This is because a resource may
have multiple contexts and some "relative URNs" may be valid in
some contexts, but not in others.

Omar

Date: Mon, 03 Feb 1997 11:34:31 -0500
From: omar syed <[email-masked]>
Organization: NASA Lewis Research Center
To: "Martin J. Duerst" <[email-masked]>
Cc: Daniel LaLiberte <[email-masked]>, "Ron Daniel Jr." <[email-masked]>, URL mailing list <[email-masked]>, urn-ietf <[email-masked]>
Subject: Re: [URN] Re: Relative URLs and URNs
Sender: [email-masked]
Reply-To: omar syed <[email-masked]>

Martin J. Duerst wrote:
> 
> On Fri, 31 Jan 1997, Daniel LaLiberte wrote:
> 
> >  > Thus spoke Omar Syed:
> >  > > 2. clients must treat <NSS> as an opaque string (i.e. do not interperet)
> >  >
> > Ron Daniel, Jr. writes:
> >  > I think assumption 2 is in error. Clients that know the structure of
> >  > a name in a particular namespace are likely to manipulate it.
> >
> > I agree.  Clients, of course, can do whatever they want (whatever they
> > can get away with) anyway, but they have to be able to interpret the
> > structure of an identifier in order to do as much processing of it on
> > their own as they can.  Forcing clients (if that were possible) to
> > always consult a remote server to process the whole identifier is a
> > sure way to make the system unscalable.
> 
> Forcing to consult a *remote* server is a bad thing. On the other
> hand, if we would require that a client *has to* understand anything
> about the structure of certain URNs, that might also be too much
> of a limitation.

I had always thought that one of the beauties of URNs (aside from
persistence) was that clients didn't have to understand anything
about the structure of the <NSS> portion of the URN.  Is there any
reason why they need to since they are going to be using a resolver
to do the N2L, N2R or N2C mapping.  The only reason I can see is
when a client want to create a new URN from a "relative URN" and a
previous "base URN".  If some rules for doing this are established
which apply to all URN name spaces or better yet, if the client
could consult a resolver to create the new URN, this one reason
could be eliminated.

In general, I think that the less processing the clients are required 
to do on the <NSS> the better.  This allows new URN schemes to be
introduced without having to modify all the clients.

Omar

Date: Mon, 03 Feb 1997 10:58:29 -0500
From: omar syed <[email-masked]>
Organization: NASA Lewis Research Center
To: Daniel LaLiberte <[email-masked]>
Cc: URL mailing list <[email-masked]>, [email-masked]
Subject: Re: [URN] Re: Relative URLs and URNs
Sender: [email-masked]
Reply-To: omar syed <[email-masked]>

Daniel LaLiberte wrote:
> 
>  > Thus spoke Omar Syed:
>  > > 2. clients must treat <NSS> as an opaque string (i.e. do not interperet)
>  >
> Ron Daniel, Jr. writes:
>  > I think assumption 2 is in error. Clients that know the structure of
>  > a name in a particular namespace are likely to manipulate it.
> 
> I agree.  Clients, of course, can do whatever they want (whatever they
> can get away with) anyway, but they have to be able to interpret the
> structure of an identifier in order to do as much processing of it on
> their own as they can.  Forcing clients (if that were possible) to
> always consult a remote server to process the whole identifier is a
> sure way to make the system unscalable.

To resolve a URN to a location, resource or citation, a client
always needs to consult a remote resolver and pass it the
complete URN or partially processed URN.  Is this not always true?

Omar

Date: Mon, 3 Feb 97 04:49:20 EST
From: [email-masked] (Tim Berners-Lee)
To: [email-masked], [email-masked]
Subject: Re:  [URN] another issue
Sender: [email-masked]
Reply-To: [email-masked] (Tim Berners-Lee)

Karen,

We have to remember that we are defining UR* so that
people can do sensible things with them.  The only time
that URIs (whether URN or URL) refer to more than
one resource is when they refer to a "generic" resource
such as say the Bible when different more specific
UR* would refer to more specific instances such as a Fr translation
of  the King James Version.  I can't see why anyone owning
any URL space woulduse the same URL to refer to both a manual
and a reference card.  The generation machinery would
generate either automaticallywhen asked for the URN or L in question.

Tim

Date: Sun, 2 Feb 1997 14:09:15 -0800 (PST)
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [URN] another issue
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

Karen writes:
| Consider the following example.  There are two documents a complete
| manual for a piece of software and summary of the commands.  They have
| different URNs because they are different resources.  Now, the way
| they are realized is that when someone wants a copy of one, a request
| (let's assume in HTTP, since what comes back is in HTML) to a URL.
| But in reality there is one document generator that generates these
| documents on demand.  Thus, both URNs will resolve to the same URL and
| the URN of the resource being requested had better be sent to the
| location in order that it generate the correct resource.

The URNs don't resolve to the URL.  I assume that the server infers
something about the user's wants from some information in addition
to the URL, oh, say, the user's IP address.  Is that right?

| The simple problem here is that I don't think HTTP supports this kind
| of request, but correct me if I'm wrong.  But there is a larger
| issue.  When a URN is translated into a URL, you can never know

URNs are not translated into URLs but rather mapped.

| whether the URN will be needed in order to get the resource you want,
| or whether you are lucky this time and the URL is the locaion of
| exactly one resource as identified by URNs.  So, I think I have landed

Always true, regardless of your premises.

| us in a place where we have to make a choice.  Either we have to say
| that a URL can only locate exactly one resource as identified by URNs
| and generators such as the one I described above is illegal, or we
| have put a requirement on any supporting transport protocol that it
| will include URNs in requests.
| 
| Opinions?  Comments?  Do we have any alternative options here?

Absent a fuller explanation, I don't see why this is an issue for
URNs at all.  Whoever sets up a system of this sort would do his
users a favor by sending the URN along with the document, including
a note explaining how the system works, though.  

Regards,
    Terry Allen    Fujitsu Software Corp.    [email-masked]
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

Date: Sun, 2 Feb 1997 10:12:39 -0800 (PST)
From: "Gregory J. Woodhouse" <[email-masked]>
To: "Karen R. Sollins" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [URN] Global URNs and relative URIs
Sender: [email-masked]
Reply-To: "Gregory J. Woodhouse" <[email-masked]>

I kind of have mixed feelings here. Since URNs are, by definition,
"relative URN" does seem like a bit of an oxymoron. Even so, it only seems
obvious that, as a practical matter, it is useful to refer to URNs in
relative format. As an example of what I mean, I recently asked a coworker
to retrieve a web page from 228. In this context, 228 is the last octet of
the IP address of my workstation. I could have given the complete IP
address, but it has become common practice  where I work to refer to hosts
without domain names by the host part of the IP address. Similarly, in the
case of DNS, it is common to refer to hosts in the same domain without
using the FQDN. 

Now, both IP addresses and domain names have something in common: They
reprersent hierarchical namespaces, and that is what makes abbreviate
references possible. There is, of course, a difference, and that is that
sofware often accpts domain names which are not fully qualified, but
generally IP addresses must be used in their complete form. I see the issue
with URNs as basically being whether abbreviated names are meant for human
consumption only (as is the case with IP addreses), or whther they can be
meaningful to software (as is the case with domain names).

Switching to another analogy, a kind of name which is never abbreviated is
the CLSID used in OLE/COM, but CLSIDs aren't meant to ever be seen by
humans. Instead, after registration, humans tend to deal with ProgIDs. In
OLE/COM it is feasible to have unique binary identifiers because there is
another mechanim which allows COM objects to be referenced by mnemonic
names. My understanding has always been that URNs are meant to be used
directly by users (or, what is essentially the same thing, embedded in
HTML) which means they function more like ProgIDs (except that ProgIDs
aren't globally unique!) than CLSIDs.

Okay, I'm rambling a bit here. What I'm attempting to say is that URNs will
generally be hierarchical (and likely must be) and are meant for human
consumption. This being the case, it seems tht some "official" mode of
abbreviated reference seems desirable. Whether the abbreviated URN is to be
termed a reltive URN seems to be the main point of contention. I tend to
favor having relative URNs, but it should be made clear that only absolute
URNs are globally unique identifiers.

---
[email-masked]    /    http://www.wnetc.com/home.html
If you're going to reinvent the wheel, at least try to come
to come up with a better one.

Date: Sun, 2 Feb 1997 14:08:15 -0500
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Subject: [URN] another issue
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

I'll get back to the global/relative naming thing, but I'm in a rush
right now, and there's another issue that has never really been
discussed here, that may need addressing.

Consider the following example.  There are two documents a complete
manual for a piece of software and summary of the commands.  They have
different URNs because they are different resources.  Now, the way
they are realized is that when someone wants a copy of one, a request
(let's assume in HTTP, since what comes back is in HTML) to a URL.
But in reality there is one document generator that generates these
documents on demand.  Thus, both URNs will resolve to the same URL and
the URN of the resource being requested had better be sent to the
location in order that it generate the correct resource.

The simple problem here is that I don't think HTTP supports this kind
of request, but correct me if I'm wrong.  But there is a larger
issue.  When a URN is translated into a URL, you can never know
whether the URN will be needed in order to get the resource you want,
or whether you are lucky this time and the URL is the locaion of
exactly one resource as identified by URNs.  So, I think I have landed
us in a place where we have to make a choice.  Either we have to say
that a URL can only locate exactly one resource as identified by URNs
and generators such as the one I described above is illegal, or we
have put a requirement on any supporting transport protocol that it
will include URNs in requests.

Opinions?  Comments?  Do we have any alternative options here?

			Karen

Date: Sun, 2 Feb 1997 12:33:02 -0500
To: [email-masked]
From: [email-masked] (David G. Durand)
Subject: Re: [URN] Some good ideas coming out of the "relative..."  discussions...
Sender: [email-masked]
Reply-To: [email-masked] (David G. Durand)

At 1:15 PM 1/30/97, Daniel LaLiberte wrote:
>David Durand writes:
> > ... Now, if we have to encode FPIs to
> > make them into URNs that is OK, but if the relative URN stuff comes
> > out, it will make sense to unescape the slashes again. So there will
> > be two canonical representations for the same URN, depending on  when
> > it was issued, kind of defeating the goals of persistence.
>
>Allowing multiple names for things does not defeat the persistence or
>uniqueness properties.  The persistence property is that the name is
>never used again for anything else.  The uniqueness property is that a
>name is only the name of one resource (which may be a mutable
>resource) not that the resource only has one name.

No, it does not, but it does mean that relative URNs (if they are a good
idea) will only work with one representation. Also, while we don't want to
prevent multiple names when they make sense, it does seem that it's not
such a bad idea to avoid creating them for avoidable syntactic reasons.

>
> > ... If we make no special allowances now,
> > and later decide that we really need relative URNs we could add
> > another kind of resolution service that takes a base URN and a
> > relative URN and returns the "real" URN.
>
>This service is call concatenation.  Clients can do it themselves.

The reason that I suggested this actually comes from Ron's correction to my
quick note; As he pointed out, in FPIs the hierarchy can be indicated by //
or :: depending on the particular URN (There are hierarchical names
contained as "path elements" of other hierarchical names). And some
organizations assign FPIs with spaces that _they_ perceive as hierarchical
even though they may not publicize that information.

And while that effectively moots my worries about the '/' character, it
points out that URN spaces may use arbitrary definitions of relative: In
the case of FPIs I could argue for discontinuous substitution: one
conceivable scheme for  FPIs  might give relative paths for both the
issuing authority (Owner) and the resource within that authority (Object
identifier). I am not arguing in favor of such a scheme or even for
relative URNs (they probably make sense in some schemes, but we can live
without them easily).

   But there are probably scheme dependencies in the recognition of what
URNs are relative and absolute, and then in the selection of the algorithm
to combine a relative URN with an absolute URN to produce a final result.

   We might want to avoid having every client have to implement this code
for every URN scheme. So some way to use a server to do this _might_ be
more useful.

   Or we might decide that it is a generality we don't need, or that costs
too much (in multiplication of servers),  or even that relative URNs are a
bad idea.

   But I think the a priori assumption that relative URLs and relative URNs
will work the same way is not totally well-founded, especially since URNs
will include grandfathered namespaces, including ones where relative URNs
are theoretically impossible.

   So maybe we should not assume that '/' characters will have anything at
all do to do with relativity of URNs.

   I think the current approach of allowing but discouraging unencoded '/'
may be the best practical solution.

  -- David

I am not a number. I am an undefined character.
_________________________________________
David Durand              [email-masked]  \  [email-masked]
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Date: Sat, 1 Feb 1997 19:24:19 -0500
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [URN] Global URNs and relative URIs
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

Dan,

Perhaps, we have some misunderstandings...so, let me take your points
one at a time.

   From: Daniel LaLiberte <[email-masked]>
   Date: Sat, 1 Feb 1997 00:15:41 -0600 (CST)
   References: <[email-masked]>
	   <[email-masked]>
   Sender: [email-masked]
   Precedence: bulk
   Reply-To: Daniel LaLiberte <[email-masked]>
   Errors-To: [email-masked]

   Karen R. Sollins writes:
    > Relative and global are contradictory in my model of this world,

   Even global identifiers must be interpreted relative to some context.
   If you have no context for interpretting an identifier, all you can do 
   with it is compare it to another identifier you might have lying
   around, and you can't even be sure you are doing that comparison right.

Let's start here at the beginning.  Global means that the context is
"global" - everywhere that we mere mortals and the things in our
rather mundane lives are.  The rather simple idea is that if a URN is
"used" in the ways it might be used in different places, it will have
the "same" meaning, resulting in the "same" effects.  Of course, then
we need to define "same", but since this group and its predecessor
have had many long discussions about "sameness" that do not bear
repeating let's take a rather simplistic example and leave it at that.
I have the URN of a book resource.  I give you a copy and you in
Illinois and I in Massachusetts look at the book.  As far as we can
tell when we compare notes, we have seen the same book.  Even that
simple example has a lot of baggage, but I don't think the ideas in it
are difficult to understand, so let's try to stay on track with this one.

   What you can do with a URN is *intended* to be even more flexible than
   what you can do with a URL.  One thing you might do with a URN is pull
   apart its known structure to begin resolving it.  Its known structure
   is an implicit context, hardwired into the client code, or a proxy.

Second, you seem to forget that the internal strvcture of a URN is not
necessarily exposed.  It may be the case that only the generator of
the URN (aka naming authority) knows the internal structure of a URN.
As you are probably well aware, not everyone wants to expose internal
structuring in order to publish specific resources.  (It is not
difficult to imagine organizations doing naming authority
subdelegation in parallel with their internal organizational structure
and not wanting to expose that structure.)  Lack of exposure of the
internal structure of a URN should not make it less useful.  It should
provide the same functions, identity of the resource and translation
into location information.  Just because the NAPTR proposal for a UDS
is built on an assumption that structure must be exposed doesn't mean
that that MUST be the case now and forever.  Those of us who look
further into the future assume that naming authorities and the
structures they choose may come and go as will name resolution
paradigms.  It is not difficult to imagine a UDS that simply looks at
the names as opaque strings and looks them up as such.

   The URN scheme being defined by this working group specifies the top
   few layers of the structure of the URN.  The first component is the
   authority name.  This authority name is interpreted relative to some
   context.  The NAPTR mechanism provides *one* context for interpreting
   the authority, relative to the urn.net domain name.  That domain name
   is found relative to the net domain and the DNS root.  The DNS root is
   well known, but there are in fact multiple replicas of the DNS root -
   which one you get might determine how your day goes, though one would
   hope all would be identical.

See my comment above - this is a characteristic of NAPTR, not a
requirement for URN resolution.  NAPTR is intended for a subset of all
URNs - a subset that exposes its internal structure and is prepared to
have that structure used to find a local resolution service for the
named resources.  This is NOT a requirement of URNs nor of URN
resolution as far as I've heard anyone say - certainly not me!  It is
a limitation in order to get somthing off the ground quickly.  But we
have to remember that that's all it is.

   Back to the resolution process.  Once you get some info back from
   the urn.net server about the authority, you can continue to interpret
   the remainder of the URN relative to that info.  Etc.

Again, see my comments above.

   So everything is relative, from start to end.  Nevertheless, I *think*
   I know what you mean by global.  But maybe you should define it anyway
   just so we know we are thinking alike.

    > unless someone can _guarantee_ that a relative URN would NEVER escape
    > the environment within which it is relative without being converted to
    > its global representation.

   URLs are global too.  Do we worry about relative URLs escaping the
   environment within which they are relative?  Web browsers generally
   only show the generated absolute URL, but a user who looks in the
   document source can see the relative URLs.

Third, maybe you don't worry about relative URLs escaping and maybe
lots of other people also join you in not worrying, but I for one am
concerned about it and I have certainly seen it cause things run amok.
It isn't always easy to get it right and the result can be a
misunderstanding about a reference, exactly what URNs are supposed be
addressing.

    > But, if that's the case, it doesn't belong in a standard anyway;
    > it's a private convention, and people can do anything they want in
    > private, as long as it doesn't affect the outside world.

   Yep, clients can do whatever they want, if they can get away with it.

Fourth, this is exactly my point.  We should be letting the word out
that clients should be extremely careful about local representations
of things as relative anythings because it is really difficult to
guarantee that you are getting away with it.  We as the people who
have lots of experience with this should be the ones, if anyone, to
help the rest of the community to understand the pitfalls and how to
avoid them, not encouraging others to fall into that.  That would be
nothing but irresponsible behavior, and I have confidence that you as
well as the other members of the WG intend to be as responsible about
all this as we all can be.

    > So, this whole discussion about "relative" URNs leaves me very puzzled.

   I'm not clear on why you are puzzled.

   The concern is over whether absolute URNs should support relative URNs
   to the extent that hierarchical structure is exposed.  

As discussed above, just because hierarchical structure is known and
tightly coupled to the UDS in the current proposal does not mean that
it will be forever, so letting relative URLs out beyond the privacy of
one's own playpen means that we would be requiring that structure
always to be known and reconstruction of absolute URNs a facility of
all future UDSs.  I would hate to see us put that kind of onus on
future generations.

   Maybe the problem is in calling "relative URNs" URNs at all, since they
   are not URNs until they are global, by your definition.  I'd actually
   prefer to call them just relative URIs.  That is more accurate anyway
   since the very same relative URI might be used with different base
   URIs to end up being a URL or a URN.

Lastly, I bit my fingers (tongue) during some of the previous
discussion, but let me try to say it briefly here.  I think we both
agree that as you are using it here "URI" is a syntax, a way of
expresing structure.  URNs and URLs are not syntaxes, but rather
semantic entities - identifiers and locators.  They have different
requirements, different functionality, and different resolutions.
They are abstractions.  At most levels (except of course the bottom),
we have names or identifiers for the entities of interest and locators
or addresses which are the things that layer of abstraction presents
to its supporting layer of abstraction (think of layers of protocols
or layers of abstraction in operating systems).  What are considered
addresses by one layer are considered names by the next one down. This
holds for URNs and URLs (or it should in order to avoid the long
laundry list of known "problems" with URLs, which arise from their
misuse as substitutes for names).  We can choose the same syntax for
them if it is suitable, but I have yet to see a compelling reason to
do this other than to save bits and perhaps trees.  If the syntax
permits relative strings, to me that is a compelling reason NOT to use
it.  But there may be other reasons as well.  In the case of UR*s the
syntax in question is the URI syntax.  But, let's be clear that it is
ONLY a syntax and as such to be used if appropriate, but not if not.
What is really important is to get the abstractions right and then
make sure the expression of them in the syntax doesn't violate the
model.  To the extent that can be done by reusing bits, that's fine,
but that's all it is, reusing a syntax.  

			Karen

From: Daniel LaLiberte <[email-masked]>
Date: Sat, 1 Feb 1997 00:34:37 -0600 (CST)
To: [email-masked]
Subject: Re: [URN] Re: Relative URLs and URNs
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Ron Daniel, Jr. writes:
 > I don't think that is quite true. Since the URN doesn't contain
 > resolution system info,

That lack of resolution info is an illusion.  If you have no info
about how to begin the resolution, you cannot begin to resolve the
URN.  In fact URNs will have resolution info in the form of the scheme
name (e.g. "urn") and the authority name.  Looking up the authority
name is part of the resolution process.

 > they get resolved through the use of a database
 > that can map the URN to a URL, set of URLs, metadata,
 > or the resource itself. 

What database is that?  Who created it?  Where does it reside?
Whatever it is, this database provides an alternative "global" context
for the interpretation of the URNs.  What is "global" if there are
alternative global contexts?  How do you know they are consistent
with each other?

I think Gregory was speaking to the practical issues of the
adoption/deployment process.  If people find it too inconvenient to
use URNs because all the necessary tools are not available, and the
advantages seem too distant, why will they bother.  Relative URIs make
it that much simpler.

dan

From: Daniel LaLiberte <[email-masked]>
Date: Sat, 1 Feb 1997 00:15:41 -0600 (CST)
To: [email-masked]
Subject: [URN] Global URNs and relative URIs
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Karen R. Sollins writes:
 > Relative and global are contradictory in my model of this world,

Even global identifiers must be interpreted relative to some context.
If you have no context for interpretting an identifier, all you can do 
with it is compare it to another identifier you might have lying
around, and you can't even be sure you are doing that comparison right.

What you can do with a URN is *intended* to be even more flexible than
what you can do with a URL.  One thing you might do with a URN is pull
apart its known structure to begin resolving it.  Its known structure
is an implicit context, hardwired into the client code, or a proxy.

The URN scheme being defined by this working group specifies the top
few layers of the structure of the URN.  The first component is the
authority name.  This authority name is interpreted relative to some
context.  The NAPTR mechanism provides *one* context for interpreting
the authority, relative to the urn.net domain name.  That domain name
is found relative to the net domain and the DNS root.  The DNS root is
well known, but there are in fact multiple replicas of the DNS root -
which one you get might determine how your day goes, though one would
hope all would be identical.

Back to the resolution process.  Once you get some info back from
the urn.net server about the authority, you can continue to interpret
the remainder of the URN relative to that info.  Etc.

So everything is relative, from start to end.  Nevertheless, I *think*
I know what you mean by global.  But maybe you should define it anyway
just so we know we are thinking alike.

 > unless someone can _guarantee_ that a relative URN would NEVER escape
 > the environment within which it is relative without being converted to
 > its global representation.

URLs are global too.  Do we worry about relative URLs escaping the
environment within which they are relative?  Web browsers generally
only show the generated absolute URL, but a user who looks in the
document source can see the relative URLs.

 > But, if that's the case, it doesn't belong in a standard anyway;
 > it's a private convention, and people can do anything they want in
 > private, as long as it doesn't affect the outside world.

Yep, clients can do whatever they want, if they can get away with it.

 > So, this whole discussion about "relative" URNs leaves me very puzzled.

I'm not clear on why you are puzzled.

The concern is over whether absolute URNs should support relative URNs
to the extent that hierarchical structure is exposed.  

Maybe the problem is in calling "relative URNs" URNs at all, since they
are not URNs until they are global, by your definition.  I'd actually
prefer to call them just relative URIs.  That is more accurate anyway
since the very same relative URI might be used with different base
URIs to end up being a URL or a URN.

From: Daniel LaLiberte <[email-masked]>
Date: Fri, 31 Jan 1997 23:31:02 -0600 (CST)
To: URL mailing list <[email-masked]>, [email-masked]
Subject: [URN] Opaque vs semi-opaque
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Ron Daniel, Jr. writes:
 > It seems to me that 1630 and other documents argue just the opposite -
 > that the semantics of '/', '#', ... are set so that clients can
 > slice and dice the URIs even if they don't know the scheme or
 > namespace. More importantly, the same slicing and dicing code can be
 > used across several known schemes.

I suppose the ambiguity is in what is meant by understanding a scheme.

I really did believe that for any scheme for which the client does
not in fact know that '/' etc can be interpretted, the client should
not do anything with it, i.e. it should treat the URI opaquely.  

But if there are no such schemes because all URI schemes must use
'/' only to represent hierarchy, if they use '/' at all, then clients
always understand at least something about every URI scheme.

If "opaque" doesn't really mean completely opaque, perhaps a different
word should be used to keep people like me from jumping to
conclusions.  (And I didn't even have any caffine today.)

dan