Subject: [URN] Re: Comments on url-syntax-draft...
From: "Roy T. Fielding" <[email-masked]>
To: Ryan Moats <[email-masked]>
Cc: [email-masked], [email-masked]
Date: Sat, 28 Dec 1996 01:30:19 -0800

> I forsee problems in the URL draft with any potential "meta-scheme",
> an example of which is providing checksums for a URx if it maintains
> its current section 1.1 language.

I see no such problems.  For one thing, there is no such thing as a
"meta-scheme" which would have separate requirements from any "normal"
scheme.  If it can't be parsed by the generic-URL syntax, then it can't
be used in any context in which URLs are found, which would place it
well outside the bounds of the URN charter's definition of URNs.

> The point is that the current draft is unacceptable in its making a
> statement about URNs without realizing that URNs are a superset of URLs
> and should not be bound by the URL syntax (in fact one could argue the
> reverse).

Both points are in error.  URNs are not a superset of URLs -- both are
subsets of URI.

There does not exist a URN that cannot be *parsed* as a URL.  In fact,
the URL syntax is much less restrictive than the proposed URN syntax.
Claims that such a URI syntax is "too restrictive" are not useful
without an example of a legal URN which would be disallowed by the
URL syntax.  Personally, I have yet to even imagine one.

> One reason is that URNs are more general than URLs. 

How so?

> Another is that
> URN syntax pushes the deterministic structure off to the namespace
> resolver.

No it doesn't.  In order to parse a URN, you need to know where it
begins and where it ends.  That is the definition of an opaque URI.

> Another is that URLs are inherently tied to the underlying
> filesystem structure.

That is totally misinformed -- there is nothing in an http URL which
is inherently tied to any filesystem, and the same goes for news, mid,
cid, telnet, wais, etc.

The URL document contains the wording about URI in general because
there currently does not exist a standard reference for URI, which
is the thing that HTTP and HTML use in references.  Without that
wording, the HTML and HTTP specifications will have to restrict themselves
to using URLs, thus making an artificial distinction created for
political reasons part of the official standard.  Since I assume you want
to actually use URNs in HTML and HTTP and other areas where URLs are
currently found (I certainly do), it would be pretty stupid for us to
remove any mention of the URI syntax from the URL standard.  Waiting
for URNs to achieve the same standard status as URLs is not reasonable.

I included only the most basic of requirements in defining the URI syntax.
If the URN WG cannot live with the requirements as stated, then I cannot
possibly imagine that URNs can be used in the ways intended by your
own requirements documents.  But that can't be the case, since your own
syntax document is *more* restrictive than the URL spec.  I can only
assume that you need to read it again and point the actual problems
and not presuppositions.

....Roy

To: [email-masked]
Cc: [email-masked]
Subject: Re: [URN] Re: Comments on url-syntax-draft...
From: Larry Masinter <[email-masked]>
Date: Fri, 27 Dec 1996 18:57:08 PST
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

URLs aren't required to be a slash-separated hierarchy of symbolic
elements, it's just that relative URLs don't work with the ones that
aren't.

# If a namespace wants to define such a structure, that's OK.  URLs (on
# the other hand) do imply this structure across all non-opaque URL
# schemes.

Right. "urn:" can be thought of as an opaque URL scheme.

From: [email-masked]
Date: Fri, 27 Dec 96 13:33 CST
To: [email-masked]
Subject: [URN] Re: Comments on url-syntax-draft...
Content-Length: 1684
Sender: [email-masked]
Reply-To: [email-masked]

Foteos Macrides wrote:
> 
> Ryan Moats <[email-masked]> wrote:
> >[..]
> >One reason is that URNs are more general than URLs.  Another is that
> >URN syntax pushes the deterministic structure off to the namespace
> >resolver.  Another is that URLs are inherently tied to the underlying
> >filesystem structure.  There are more, but this should be a start.
> >[...]
> 
>         I don't understand your claim that URLs are inherently tied
> to the underlying filesystem strucure.  The path field in a generic
> URL is a "slash-separated hierarchy of symbolic elements" (*not* Unix
> filesystem paths 8-).  Each "symbolic element" and/or the overall
> path field can have mappings to the the local filesystem structure,
> (e.g., by server mappings and/or local system enviroment variables or
> symbolic links) but the URL syntax, itself, is platform/filesystem
> independent.

I'll grant your point for the sake of argument (I don't necessarily
agree with it, as I never said UNIX%C2%AE), but the point of prime
importance (from my previous discussion) is EXACTLY that 'The path field
in a generic URL is a "slash-separated hierarchy of symbolic elements."'
It is this hierarchy (or, otherwise put, implied structure) that is one
of the major (IMO) syntactical differences between URNs and URLs.   URNs
should not (and currently do not) impose such structure across all 
namespaces.  If a namespace wants to define such a structure, that's OK.
URLs (on the other hand) do imply this structure across all non-opaque
URL schemes.

Removing that argument from the above discussion by no means changes
my assertion that URNs and URLs should have different syntactical
structure.

Date: Fri, 27 Dec 1996 10:39:46 -0600
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: Larry Masinter <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: [URN] Re: Comments on url-syntax-draft...
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

Larry Masinter wrote:
> 
> Ryan,
> 
> I don't think we intend for 'a:b:c:d' to be parsed as belonging to
> scheme 'a:b:c', so I think we should fix the regular expression in
> appendix B to treat 'urn:isbn:1-32456-78902-X' as belonging to
> scheme 'urn' and not scheme 'urn:isbn'.
> 
> I don't know how to proceed on the issue of changing the URL draft to
> describe URNs and URN parsing. I think if we're going to proceed from
> Proposed Standard to Draft Standard that we are not supposed to add
> functionality, and that the only changes we can make are those that
> are consistent with current practice.

In my mind you have two options:  (1) Delete the text in Section 1.1
relating to URNs and URIs or (2) Change the Appendixes and elsewhere
to fix the problem above.  

I forsee problems in the URL draft with any potential "meta-scheme",
an example of which is providing checksums for a URx if it maintains
its current section 1.1 language.

The point is that the current draft is unacceptable in its making a
statement about URNs without realizing that URNs are a superset of URLs
and should not be bound by the URL syntax (in fact one could argue the
reverse).

> I don't know why URNs don't require any determinist structure to URNs
> while it seemed important that URLs require such a structure for URLs.

One reason is that URNs are more general than URLs.  Another is that
URN syntax pushes the deterministic structure off to the namespace
resolver.  Another is that URLs are inherently tied to the underlying
filesystem structure.  There are more, but this should be a start.

> (Actually, URLs don't make such a requirement, they just don't
> guarantee that relative URLs work if you don't use it.)

??? I don't see this.  I see that absolute URLs have a definite
structured syntax throughout the draft.

Ryan

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: [URN] Re: Comments on url-syntax-draft...
From: Larry Masinter <[email-masked]>
Date: Thu, 26 Dec 1996 22:18:20 PST
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

Ryan,

I don't think we intend for 'a:b:c:d' to be parsed as belonging to
scheme 'a:b:c', so I think we should fix the regular expression in
appendix B to treat 'urn:isbn:1-32456-78902-X' as belonging to
scheme 'urn' and not scheme 'urn:isbn'.

I don't know how to proceed on the issue of changing the URL draft to
describe URNs and URN parsing. I think if we're going to proceed from
Proposed Standard to Draft Standard that we are not supposed to add
functionality, and that the only changes we can make are those that
are consistent with current practice.

I don't know why URNs don't require any determinist structure to URNs
while it seemed important that URLs require such a structure for URLs.
(Actually, URLs don't make such a requirement, they just don't
guarantee that relative URLs work if you don't use it.)

Larry

Date: Thu, 26 Dec 1996 19:21:03 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: Ryan Moats <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

On Mon, 23 Dec 1996, Ryan Moats wrote:

> [email-masked] wrote:
> > Ok, here is a real example; P-R document references;
> > 
> > Country         They type (the keys/display on the screen)
> > France          #PEL/77124
> > UK              *PEL/77124  (Where the * is the oblique L
> >                              pound sign)
> > Greece          $PEL/77l24  (Note the 'l' instead of '1')
> > Holland         FlPEL/77l24 (Where fl is the florin symbol)
> > 
> > Luckily however the _wire_ format is perfectly sensible and
> > the same; But the fun bit is that they all happily print and
> > fax each other those references; and all know how to cope
> > with them just fine :-)
> > 
> > The point I am trying to make is that for some namespaces to
> > be grandfathered in have a stronger relation to their wire
> > octed stream than to the glyph/symbolic representation; so for
> > those you really want to ignore all you learned about really
> > neat UTF8 symbol encoding :-)

Yes, this is true. I proposed some text to take this into account.
But for the examples above, I guess there are other possibilities.

First, note that the "1" vs. "l" issue is really just a glyph issue,
it's a difference you see frequently between Europe and the US, for
example. Only the #/*/$/Fl is an octet issue. For this,
just taking the octet representation (# and * suggest it's %23,
but I might be wrong), resulting in urn:vangulikexample:%24PEL/77124,
is one solution. Because this happens to be a valid UTF-8 sequence,
URN interfaces may display that as #PEL/77124 or as %24PEL/77124.

Another is the one I have mentionned earlier, and which Ryan gives
the details below, namely accepting all different "spellings" and
defining namespacesspecific equivalence between them. This works
as long as there is no character that can lead to different octets
in different countries. It looks like this is not the case for
the example above, as otherwise faxes would lead to heavy confusion.

Another solution might be to drop the initial letter altogether,
leading to PEL/77124. This works in particular if the initial letter
is the same all the time and serves as a kind of namespace identificator
that would be replaced by the NIS anyway.

Another solution might be to decide on a new or improved scheme
for numbering for the first letter, e.g. replacing all the above
with "@" or "X" or whatever.

The best solution really depends on all kinds of details, and
is up to those that are responsible for the namespace. All solutions
are possible within the current syntax draft. The first solution
is the most technical, easiest to interface with the current system.
The others are more human- and future-oriented. While it is true
that humans can easily deal with the current #/*/$/Fl mess, it should
be clearly noted that this is an artefact produced by limitations
of early computers, and there is no strong reason to perpetuate it.

> I think somebody is confused (probably me), but I don't see what the
> problem with this example is.  All of those P-R document references
> do not have to map to the same URN.  In fact, based on how they are
> described above, the shouldn't.  Rather, the namespace that holds
> the above resource (call it foobar), will have the following 
> 4 URNs (I'll probably get this wrong, bear with me):
> 
> urn:foobar:%23PEL/77124
> urn:foobar:%C2%A3PEL/77124
> urn:foobar:%24PEL/77l24
> urn:foobar:%E0%86%92PEL/77l24
> 
> My main point having gotten here is this:
> 
> It's up to the namespace resolver for foobar to understand that these
> may all refer to the same resource, not the syntax. Therefore
> "wire-coding should be more important that glyph/symbolic
> representation" becomes a resolver issue, not a syntax issue.

Regards,	Martin.

Date: Thu, 26 Dec 1996 08:50:59 -0600
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: Larry Masinter <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: [URN] Comments on url-syntax-draft... 
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

Larry-

I've looked through your new draft especially with a view to
meshing with the URN syntax and I still have two major issues. 
Fortunately, I believe that a single solution will handle both.
I also have an editorial issue.  Once these are taken care of,
I believe that both drafts have been aligned on this issue.

1. Given the current URN spec, the "greedy" algorith in Appendix B
will pick up the urn scheme as "urn:<NID>".  For example the URN
urn:isbn:1-32456-78902-X will be parsed as being scheme "urn:isbn".

2. There is no general specification of structure for a URN NSS, it
is determined on a namespace by namespace basis.

I can see two solutions to item 1: (a) modify the scheme syntax
in Section 4.1 to include ":" or (b) add a section for URN handling
that states that a scheme including the "urn:" token should be
treated as an opaque URL because it is really a URN.  

I propose that option (b) be followed because the easiest solution
to item 2 is for the URL parser to declare a URN as an "opaque-URL"
and do no processing on it.  This would ensure that the NSS structure
doesn't confuse the URL parser.

I believe that an appendix for this would work the best, and I
add it below...

My editorial issue is that the section paragraph in section 1.1 is
potentially confusing.  There are requirements in the URL syntax that 
do not apply to the URN syntax.  I would prefer to see the following
paragraph in its place:

"This specification restricts its discussion to URLs.  URN syntax
is specified in [URN Syntax Ref].  URN and URL syntax have been
specified so that a URN may be used in any data field that might
otherwise hold a URL.   Details of how to handle a URN are provided
in Appendix X."

Ryan Moats

=======================Appendix on URN handling in a URL parser

Appendix X. URN Handling in URL parsers

URN syntax is specified in [URN Syntax Ref].  URNs include a leading
tag "urn:".  Thus, the "greedy" algorithm in
Appendix B will return a scheme that includes this tag.

In addition, URNs do not require any determinist strcuture to the
URN.  Rather, this is assigned on a namespace-by-namespace basis.

To enable a URL parser to handle a URN properly, 
A URL parser that detects a scheme that includes the "urn:" tag MUST
treat the URL as an opaque URL to be handed to a URN resolver for
further processing.

Date: Thu, 26 Dec 1996 08:50:54 -0600
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: [email-masked]
Subject: [URN] Second pre-release of 3rd syntax draft.
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

This is a multi-part message in MIME format.

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

Howdy, everybody-

As promised, here is the second pre-release of the 3rd syntax draft
(-02).  Changes from the previous pre-release:

1. Added a paragraph on the "%" character to align with the URL syntax
and clear up misconceptions about its presence in the URL character
set.

2. Moved the "\" character to the excluded character set.  This also
aligns the URN syntax with the URL syntax

The current schedule is to send this to the I-D editors 1/6/97.

Have a happy new year!

Ryan

--------------76D545817A4
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                                      December 1996

                               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 5/19/97                                                 [Page 1]

INTERNET DRAFT                 URN Syntax                  December 1996

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 5/19/97                                                 [Page 2]

INTERNET DRAFT                 URN Syntax                  December 1996

   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>

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

   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 prescence 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

Expires 5/19/97                                                 [Page 3]

INTERNET DRAFT                 URN Syntax                  December 1996

   publication of a definition of which characters have a special
   meaning to that namespace.

2.3 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
   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

Expires 5/19/97                                                 [Page 4]

INTERNET DRAFT                 URN Syntax                  December 1996

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.

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. "Requorements and a Framework for
                     URN Resolution Systems" Internet Draft (work in
                     progress).  November 1996.

Expires 5/19/97                                                 [Page 5]

INTERNET DRAFT                 URN Syntax                  December 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]

                 This Internet Draft expires May 19, 1997.

Expires 5/19/97                                                 [Page 6]

--------------76D545817A4--

From: [email-masked] (Leslie Daigle)
Date: Mon, 23 Dec 1996 13:41:16 -0500
To: [email-masked]
Subject: [URN] Re: DRAFT URN Meeting Minutes
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: [email-masked] (Leslie Daigle)

                   Minutes of the URN Working Group
                 37th IETF, San Jose, December 12, 1996

Group Co-Chairs: Leslie Daigle, [email-masked]
                 John Curran, [email-masked]

Minute-Meister:  Sally Hambridge,  Intel 

Leslie opened the meeting by reviewing the Charter and Milestones.  
Hot Spots in the milestones are: we lack a draft detailing 
N2L/N2R/etc resolution results.  We will probably use Ron Daniel's HTTP 
conventions draft as a start on this milestone.  We also need to 
submit a document describing one new namespace and a document 
which describes grandfathering in older naming schemes, as well 
as the Frameworks and Requirements draft.

Karen Sollins presented the open issues with the current 
Frameworks and Requirements document:

The document discusses the assumptions of longevity, delegation, 
and independence.  The requirements fall in 3 major areas:  
Evolution, Usability, and Security.  The framework looks like 
this:

URN:<NID><NSS>
   |
   |
Global NID registry
  |        |
  |        |
  |     Private URN resolution service
UDS server
  |
  |
Private URN resolution service

Karen includes a definition section which defines Local 
Resolution service - what transforms URNs into access to 
resources; Hints - information that helps to access the 
information; UDS - URN Resolution Service Discovery Service - how 
to find the right URN resolution service; HFN - Human friendly 
names.

The Security area will discuss access control on hints; server 
authenticity; Server distribution (a countermeasure on denial of 
service attacks) and Privacy - the users from resolution services 
and for publishers for their clients and publications lists.

Issues:  
	- Encouragement of separation of URNs from semantics
	- Efficiency as a goal or a requirement is in several places 
	  (documents) which need to be aggregated.
	- Whether there is a useful distinction to be made between long-
	  term and short-term hints
	- Acceptance by potential providers of UDS services.

Karen asked what's missing from the list of issues:
Internationalization (i18n) should be covered one way or another.
Name space ID - needs to be in a document but probably not this 
document.

Ryan Moats presented the issues with the URN syntax ID:

URN: should this be optional.  Please see the later discussion on 
this for the consensus.  

NID syntax: Why not use numbers and "-".  No reason - Ryan will 
change the draft.  There was a suggestion for following the RFC 
for URLs on this, but it was pointed out that this document is 
currently undergoing a revision.  NID namespace will have case 
insensitivity and add %escaping.  The NSS may be case sensitive.

URN Character set adds/deletes: Add "%" to the allowed character 
set and add a list of characters NOT part of the set to the 
draft.

%escaping: Will be allowed for escaping of reserved characters in 
addition to characters outside the URN character set; and allow 
for %HH escaping to use either upper or lower case.
Where does a URN end? At the first non-URN character set 
character.

Equivalency: Are things the same when they point to the same 
resource?  (Equivalency of resources was deemed to be a 
rathole).    Leslie offered that a URN could point to a specific 
day's weather and another could refer to today's weather, and 
these were pointing to the same thing but were not equivalent.
ROUGH CONSENSUS was reached that ONLY lexical equivalency will be 
covered in the draft.  Each namespace may have its own rules. 

For the Human readability - MUST/SHOULD the following text is 
being substituted:
  Any namespace (existing or newly-devised) that is proposed as a 
  URN-namespace 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

Ron Daniel discussed the NAPTR draft.

	- There will be verbiage to state that records with unknown 
	  flags must be ignored.
	- The Pseudo-code will get a strong disclaimer.
	- "R" Flag for treating Regex as "Raw"
	- Don't do "E" flag for encrypting Raw fields.
	- Flag field reserves 0-9 for experimentation. ROUGH CONSENSUS was to 
	  allow people to create new flags however they want, but that if 
	  you see a flag you don't recognize you ignore it. Ron is going to 
	  revise the wording of the draft so that people may place any 
	  interpretation they want on the various fields as long as they 
	  define a flag for it.

There was a question of the references to other drafts, and John 
Curran said he would find out if the text RFC xxx could be 
written and if the RFC editor would insert the correct numbers.

This draft will be going as an Experimental RFC.  There was 
discussion about how the experimental status will effect DNS and 
the regex substitutions.  We need to be explicit.  We need to 
say how this doesn't overload DNS and how DNS security will help 
and where it won't.  Also, there will probably be more than one 
discover service in the future and we don't want this one to be 
"The Standard".  We need operational experience.  The requiring 
resolution problem is not part of this draft.  We will have one 
more revision on the mailing list, then this goes to 
Experimental.

HTTP Conventions: Ron took this one too.

We need a simple resolver for testing, the goal is not 
Standards track.  The goal is to use the conventions on encoding 
on requests and responses on http:

GET /uri-res/<server>/<uri> HTTP 1.0

Open Discussion:

URN:  There was a question of rough consensus on the problem of 
whether to require urn:.  The room seems to indicate that urn: 
should be required on any part of the urn that was shipped around 
the Internet.  Whether or not implementors would use urn: was 
left up to them for their own local products, but in transmission 
the urn: would be required.  The problem with urn: seems to be at 
the user interface and user services level.  Don't confuse human 
friendly names with internal representation.

Documents:
We need a URN dereferencing document to discuss the resolution 
service and the resolution system.  These need the syntax (which 
is close) and the system requirements needs the framework (which 
is also close.) 

Assign URN - needs everything! We need namespace requirements.  
Renato Iannella was volunteered to create a first draft of this
document.  We need to have one new namespace and we need to bring in 1 
existing namespace.  We need to pay some attention to potential 
lawsuit issue.  It is important for someone who has authority for 
the namespace to say how it works in URN.  The proposal is for 
these to be experimental.  Dun and Bradstreet is interested in 
working on this as soon as the syntax is ready.  Clifford Lynch 
said that the NISO bibliographic IDs could move en masse.

We can create a resolution system which can be used outside the 
URN space, but we need to make it work there first.

Charter directions:

* We need to get a grip on bringing in an existing namespace
* We need a new namespace scheme
* We need the Name space requirements document (to see whether 
DNS-based  namespace will or won't work, and if not, what we can
do about a generically-accessible namespace)
* We need to look at the process of creating new namespaces

-- 

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

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

Date: Mon, 23 Dec 1996 12:34:08 -0600
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: [email-masked]
Cc: "Martin J. Duerst" <[email-masked]>, [email-masked]
Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

[email-masked] wrote:
> Ok, here is a real example; P-R document references;
> 
> Country         They type (the keys/display on the screen)
> France          #PEL/77124
> UK              *PEL/77124  (Where the * is the oblique L
>                              pound sign)
> Greece          $PEL/77l24  (Note the 'l' instead of '1')
> Holland         FlPEL/77l24 (Where fl is the florin symbol)
> 
> Luckily however the _wire_ format is perfectly sensible and
> the same; But the fun bit is that they all happily print and
> fax each other those references; and all know how to cope
> with them just fine :-)
> 
> The point I am trying to make is that for some namespaces to
> be grandfathered in have a stronger relation to their wire
> octed stream than to the glyph/symbolic representation; so for
> those you really want to ignore all you learned about really
> neat UTF8 symbol encoding :-)
> 

I think somebody is confused (probably me), but I don't see what the
problem with this example is.  All of those P-R document references
do not have to map to the same URN.  In fact, based on how they are
described above, the shouldn't.  Rather, the namespace that holds
the above resource (call it foobar), will have the following 
4 URNs (I'll probably get this wrong, bear with me):

urn:foobar:%23PEL/77124
urn:foobar:%C2%A3PEL/77124
urn:foobar:%24PEL/77l24
urn:foobar:%E0%86%92PEL/77l24

My main point having gotten here is this:

It's up to the namespace resolver for foobar to understand that these
may all refer to the same resource, not the syntax. Therefore
"wire-coding should be more important that glyph/symbolic
representation" becomes a resolver issue, not a syntax issue.

Ryan

Date: Mon, 23 Dec 1996 10:39:39 +0100 (MET)
From: [email-masked]
To: "Martin J. Duerst" <[email-masked]>
Cc: [email-masked], Ryan Moats <[email-masked]>, [email-masked]
Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt
Reply-Path: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]

On Sat, 21 Dec 1996, Martin J. Duerst wrote:

> On Sat, 21 Dec 1996 [email-masked] wrote:
> 
> > Ryan wrote:
> > > [email-masked] wrote:
> > > > 
> > > >         3. suggested escape hatch for (grandfathered in) namespaces
> > > >            where the glyph representation is confirmed ambigious. (For
> > > >            example the $, #, pound and yen sign).
> > > 
> > > This is already taken care of by the <excluded> character set.  The only
> > > way to put a character from this set in a URN is to use "%" encoding.
> > > Otherwise, the character terminates the URN.
> > 
> > > It dawns on me that you may be talking about what hex value to use
> > > for the "%" encoding.  My current position is that it is the
> > > UNICODE/10646 value via UTF-8.  
> > 
> > No Actually not, What I meant is that I've seen people in the document 
> > and library world using quite a few naming schemes where in different 
> > places they use say the '$' and '$' with two lines through it and the '#' 
> > and the L-shaped pound sign interchangably, depending on what keyboard 
> > and machine they are working. So in these spaces the glyph-to-wire 
> > encoding (using the % utf-8 encoding) is no longer trivial, as it is no 
> > longer the shape of the symbol which matters.
> 
> I start to understand. Real examples always make it easier.

Ok, here is a real example; P-R document references;

Country		They type (the keys/display on the screen)
France		#PEL/77124
UK		*PEL/77124  (Where the * is the oblique L 
			     pound sign)
Greece		$PEL/77l24  (Note the 'l' instead of '1')
Holland		FlPEL/77l24 (Where fl is the florin symbol)

Luckily however the _wire_ format is perfectly sensible and
the same; But the fun bit is that they all happily print and
fax each other those references; and all know how to cope 
with them just fine :-)

The point I am trying to make is that for some namespaces to
be grandfathered in have a stronger relation to their wire
octed stream than to the glyph/symbolic representation; so for
those you really want to ignore all you learned about really
neat UTF8 symbol encoding :-)

Dw.

Date: Sat, 21 Dec 1996 22:41:21 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: [email-masked]
Cc: Ryan Moats <[email-masked]>, [email-masked]
Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

On Sat, 21 Dec 1996 [email-masked] wrote:

> Ryan wrote:
> > [email-masked] wrote:
> > > 
> > >         3. suggested escape hatch for (grandfathered in) namespaces
> > >            where the glyph representation is confirmed ambigious. (For
> > >            example the $, #, pound and yen sign).
> > 
> > This is already taken care of by the <excluded> character set.  The only
> > way to put a character from this set in a URN is to use "%" encoding.
> > Otherwise, the character terminates the URN.
> 
> > It dawns on me that you may be talking about what hex value to use
> > for the "%" encoding.  My current position is that it is the
> > UNICODE/10646 value via UTF-8.  
> 
> No Actually not, What I meant is that I've seen people in the document 
> and library world using quite a few naming schemes where in different 
> places they use say the '$' and '$' with two lines through it and the '#' 
> and the L-shaped pound sign interchangably, depending on what keyboard 
> and machine they are working. So in these spaces the glyph-to-wire 
> encoding (using the % utf-8 encoding) is no longer trivial, as it is no 
> longer the shape of the symbol which matters.

I start to understand. Real examples always make it easier.
For the two cases above, the $ with | or || is not a problem,
as for them there is only one codepoint in UNicode. For the '#' and
the pound sign, they both have a codepoint in UNicode/10646.
What I think you should do for your namespace would be that you
define that '#' and pound sign are lexically equivalent.
The users can type whichever they want, and some component in
the architecture that will be built will equate them, as for
other namespaces, it would equate lower-case and upper-case.

So if all the problematic cases you had in mind have the same
structure, it turns out we already have taken care of that in
the syntax draft :-).

> Well this still does not quite solve it; but I think the underlying issue 
> is about what is the 'real' thing, a sequene of sybols or a sequence of 
> octeds.

There are several "real" things. The best defined is the URN as such,
a string of characters from a limited set. It is used to represent
a string of characters from a wider set, along certain rules, or
in some exceptions something else, which will have to be defined
separately. There are also, at some point, octets. They are
an intermediate stage when mapping from *represented* characters
to *representing* characters. And they can be a "point of attachment"
when a namespace exists in digital form only, and has to be brougt
into an URN.
The question of what is the "real" thing is a question of philosophy,
not a question of protocol specification.

Regards,	Martin.

Date: Sat, 21 Dec 1996 22:26:48 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: [email-masked]
Cc: Larry Masinter <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

> On Fri, 20 Dec 1996, Larry Masinter wrote:
> 
> > I've come to understand that %XX encoding of UTF8 is particularly
> > ugly, and that some variation of UTF7 (if not UTF7 itself) would be
> > better for contexts where 7-bit-safe channels should be assumed.

On Sat, 21 Dec 1996 [email-masked] wrote:

> yes, you are quite right; but this was brought up before, and there
> was some good reasoining as why to go UTF8 anyway.
> 
> Martin, could you re-elaborate ?

- The main reason we have a limited character set and %HH is transcribability,
	not 7-bit channels.
- The basic syntactical equivalence between URLs and URNs is very important.
	URLs have %HH.
- Other parallels between URLs and URNs are also valuable. URLs, hopefully,
	will move towards UTF-8. (The ftp URL scheme is already moving in
	that direction). There have been a lot of discussions about
	other alternatives, but UTF-8 is generally viewed as the best
	solution.
- 7-bit channels are still existing, but getting fewer and fewer.
	They are ugly by themselves, and don't "deserve" beauty.
	If we design something that looks "nice" for the remaining
	7-bit channels, it will look ugly for 8-bit channels and
	so forever.
- Once we are reasonably sure that i18n text, and URLs/URNs in
	i18n text, are treated decently, we can move on to allow
	a text to include as such those URN *represended* characters
	it can represent, and only use %HH for characters that
	cannot be represented and non-character %HH.

Regards,	Martin.

Date: Sat, 21 Dec 1996 22:03:33 +0100 (MET)
From: [email-masked]
To: Ryan Moats <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt
Reply-Path: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]

Ryan wrote:
> [email-masked] wrote:
> > 
> 
> I think you may have missed my mail on URN/URL potential
> incompatibilities.  The current text of the draft on the "%" issue 
> is the following:
> 
> "...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.
>  
> 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
> precence of an "%" character in a URN MUST be followed by two characters
> from the <hex> character set.

Sorry about that; I should have double checked wether I used the last 
draft, I apoliogize !.
 
> >         3. suggested escape hatch for (grandfathered in) namespaces
> >            where the glyph representation is confirmed ambigious. (For
> >            example the $, #, pound and yen sign).
> 
> This is already taken care of by the <excluded> character set.  The only
> way to put a character from this set in a URN is to use "%" encoding.
> Otherwise, the character terminates the URN.

> It dawns on me that you may be talking about what hex value to use
> for the "%" encoding.  My current position is that it is the
> UNICODE/10646 value via UTF-8.  

No Actually not, What I meant is that I've seen people in the document 
and library world using quite a few naming schemes where in different 
places they use say the '$' and '$' with two lines through it and the '#' 
and the L-shaped pound sign interchangably, depending on what keyboard 
and machine they are working. So in these spaces the glyph-to-wire 
encoding (using the % utf-8 encoding) is no longer trivial, as it is no 
longer the shape of the symbol which matters.

> >         4. suggested escape hatch for namespaces where the identifiers
> >            have no meaningfull representation in the urn syntax (at
> > 	     least meaningfull in the sense that a UA could gain
> >	     something by showing it to the user) such as spaces which
> >	     have a purely binary object identifiers; base64 is the
> >	     _should_ wannabe.
> 
> I don't have a problem with this, so long as such information
> is included in the namespace registration documentation.
> 
Yes, I had hoped I made that clear in the remainder of the doc.

> > If a proposed namespace identifier is already in use as a protocol
> > specifier in the URI space, such as for example ftp, http or email,
> > the proposal for this identifier should justify this choise; i.e
> > 
> >         urn:email:[email-masked]  or
> >         urn:ftp:someplace:abc.efg
> >         urn:ftp://someplace/abcd.efg
> 
> Now this makes some sense to me.  I'm wondering if we want to
> make the statement stronger...
> 
> > Now this kind of 'clashes' with the needs to grandfather in various
> > schemes as their glyfh encoding might *NOT* be an unambigious character
> > index. For example if the indexes or local control identifiers are
> > collected over various contries; which each use their own (say latin)
> > charset, but the actual LCI is just the sequence of the character index
> > number _ITSELF_ into the various charsets. So encoding the glyf using
> > UTF8 it represents in one charset display mapping would most certainly
> > wrong for another one; and if the people interoperate you have broken the
> > LCI scheme. The reverse also happens; and on top of that normalizing in
> > UTF8 makes it even more fun.
> 
> The last portion of the last sentence has gone away and so the last
> sentence now reads:
> 
> "Therefore, the process of registering a namespace identifier
> shall include publication of a definition of which characters have
> a special meaning to that namespace".

Well this still does not quite solve it; but I think the underlying issue 
is about what is the 'real' thing, a sequene of sybols or a sequence of 
octeds.

> I don't see a case of glyph ambiguity in 
the URN character set > itself, however your following sentence:
> 
> > ++ Likewise if glyph ambiguity does not allow for UTF8 encoding
> > ++ the publication should outline the possible ambiguity and
> > ++ representations possible for display.
> 
> I like and am willing to add.
> 
> > ++ The URN is a sequence of glyphs taken from the <urn-set>. It is
> > ++ represented by an octet stream with the only the values of the
> > ++ indexes of the <urn-set> glyphs in UTF-8. A glyph or symbol encoded,
> > ++ entered, stored, displayed or conveyed which is not in this limited
> > ++ range, for examply with an UTF-8 encoding, is purely based on the
> > ++ mutual understanding of the publishing and utilizing party; but is
> > ++ not to be used to represent the URN.
> >
> > The above needs to be tackled anyway, somewhere; unless I missed the
> > place in the current draft which tells us which is really the authorative
> > representation (between machines :-) of the beast. (Ignoring
> > normalziaiton,etc).
> 
> I thought (probably incorrectly) that this had been closed going into
> San Jose.  The URN's canonical form (for transmission between
> machines) is the sequence of characters from <urn character set>.

Well it that is your understanding as well; then I am very happy; I'll 
wait and see the next version of the draft to see how this was worded.

> Now Martin and Keith can tell me I'm wrong, but I thought this was > closed.

Well I hope it is indeed closed with this.

> Other things:
> 
> If a namespace wants to be opaque and use base-64, that's fine, but
> I don't see where the syntax document must specify that.

Well this was more to stay in line with the UTF8 suggestion; because _IF_ 
you say that the cannonical for discussion is closed and it is the wire 
octed stream which counts; than the UTF8 and Base64 suggestions for 
encodings become exactly that; and thus needs to be specified in the 
documents which describe them.

Dw.

Date: Sat, 21 Dec 1996 21:51:06 +0100 (MET)
From: [email-masked]
To: Larry Masinter <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt
Reply-Path: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]

yes, you are quite right; but this was brought up before, and there
was some good reasoining as why to go UTF8 anyway.

Martin, could you re-elaborate ?

Dw.

http://ewse.ceo.org                         http://enrm.ceo.org
[email-masked]                  [email-masked]
+39 332 78 0014                                 +39 332 78 9549
                                            fax +39 332 78 9185

ISEI/ESBA;                     The Center For Earth Observation
Joint Research Centre of the European Communities, Ispra, Italy

On Fri, 20 Dec 1996, Larry Masinter wrote:

> I've come to understand that %XX encoding of UTF8 is particularly
> ugly, and that some variation of UTF7 (if not UTF7 itself) would be
> better for contexts where 7-bit-safe channels should be assumed.
> 
> 

Phone:  (617) 873-4398
Usmail: 150 CambridgePark Drive, Cambridge, MA, 02140
Date: Sat, 21 Dec 1996 13:31:58 -0500
To: Leslie Daigle <[email-masked]>
From: John Curran <[email-masked]>
Subject: Re: [URN] Checksums in URNs
Cc: "David W. Morris" <[email-masked]>, [email-masked]
Sender: [email-masked]
Reply-To: John Curran <[email-masked]>

At 15:37 12/20/96, Leslie Daigle wrote:
>...
>Unless someone (that could mean you, David Morris :-)  can come up with
>concrete answers to the questions I asked earlier (see below), I think
>we can sum up _consensus_ by saying:  there is obvious merit in having
>mechanisms to test the integrity of URNs.  We don't yet know what the
>best mechanism to handle that is (we don't even yet have any real-life
>experience with them), so we can't answer it now, and will leave it as
>a future problem.

A very reasonable position...  my own more critical viewpoint 
is that given the complete lack of existing experimentation in
deploying checksums in URx enviroments (read: absence of running 
code) and the multiple requirements one might have (single error
detection, multiple error detection, correction, etc.), I would
claim that we're far removed from the realm of standardization
and have entered the realm of creeping featurism.  

By all means,folks should explore using checksums (and this is
readily possible both on a namespace-specific basis and via meta
approaches), but none of this requires inclusion of checksums in
the underlying URN or UR* frameworks.  To look to mandating such
in the absence of running code is not how we try to do things in 
the IETF.

/John

To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt
From: Larry Masinter <[email-masked]>
Date: Fri, 20 Dec 1996 23:57:08 PST
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

I've come to understand that %XX encoding of UTF8 is particularly
ugly, and that some variation of UTF7 (if not UTF7 itself) would be
better for contexts where 7-bit-safe channels should be assumed.

Date: Fri, 20 Dec 1996 13:06:12 -0800 (PST)
From: Terry Allen <[email-masked]>
To: [email-masked]
Subject: Re: [URN] Checksums in URNs
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

Seems to me that checksums are metadata about the URN.  Certainly
for name spaces that don't include checksums in their names.

So checksums should go outside URNs, either in the manner Larry
suggested or in some more generalized way (like the checksums
you might want to use for other URIs and divers objects).

Happy Solstice.

    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: Fri, 20 Dec 1996 21:55:36 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: Ryan Moats <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

On Fri, 20 Dec 1996, Ryan Moats wrote:

> [email-masked] wrote:

> 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
> precence of an "%" character in a URN MUST be followed by two characters
> from the <hex> character set.

Very good. Wanted to suggest to mention %25 myself. Saying that
one has to use the %HH-encoding of the UTF-8 representation of "%"
is the same thing, but the first is a little more direct.

> >         3. suggested escape hatch for (grandfathered in) namespaces
> >            where the glyph representation is confirmed ambigious. (For
> >            example the $, #, pound and yen sign).
> 
> This is already taken care of by the <excluded> character set.  The only
> way to put a character from this set in a URN is to use "%" encoding.
> Otherwise, the character terminates the URN.
> 
> It dawns on me that you may be talking about what hex value to use
> for the "%" encoding.  My current position is that it is the
> UNICODE/10646 value via UTF-8.  

I also have difficulties grasping what Dirk exactly means. For me,
it could be one of two things:

(1) It's the problem that under some transfers, the # can change into
	a pound sign. If this is the thing, then we dealt with it
	on the "represented characters" side by using UTF-8 (where
	both # and pound have their well-defined positions) and
	on the "representing characters" side by not having it in
	<other>.

(2) It's the problem that e.g. the $ exists in several variants,
	in particular with one and two vertical bars, and that
	a namespace would, for some reason I currently ignore,
	need to distinguish between those two. Unicode/ISO 10646
	and therefore UTF-8 don't make such a distinction, as they
	encode characters, and not glyphs.
	If this is what Dirk is worrying about, I would like to
	answer as follows: The kinds of namespaces that we immagined
	to be mapped from the real world, such as ISBN, car numbers,
	account numbers, and so on, really won't use such subtleties
	of typography. It would be too easy to mix up the two repre-
	sentations for the people that use them.
	I think that such cases are so special that it is not necessary
	to mention them in detail. They are best lumped together
	with the cases where "characters represented" don't make
	sense.

> >         4. suggested escape hatch for namespaces where the identifiers
> >            have no meaningfull representation in the urn syntax (at
> > 	     least meaningfull in the sense that a UA could gain
> >	     something by showing it to the user) such as spaces which
> >	     have a purely binary object identifiers; base64 is the
> >	     _should_ wannabe.
> 
> I don't have a problem with this, so long as such information
> is included in the namespace registration documentation.

I always suggested such an escape hatch, but I would like to keep it
generic. For clarification, I propose to *add* after

   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.

a new paragraph saying

+ Namespaces that cannot be interpreted in terms of characters
+ may define their own mapping to syntactically
+ conforming NSSs. If a widespread and reliable digital form exists, they
+ may make use of octet encoding using the "%" character. Please note that
+ therefore, URNs can contain encoded octet sequences that are not valid
+ URN sequences. Such namespaces may also use other means for encoding
+ digital data, such as base64.

> >         6. Some extra requiments on the NSI if it is one of the URI
> >            prefixes. I can see valid reasons to do this; but also
> >            can see easy confusion with the UA interface; so if one
> >            proposes such a NSI idenfier she'd better address/defend
> >            it in the publication right away. Quick example:
> > 
> >            urn:email:[email-masked]
> >            urn:smtp:[email-masked]
> >            urn:nntp:some-message-id-as-above
> 
> Oog.  I'm gonna take a pass on this one also for now (I have to
> think about it some more)...

My thoughts (not finished yet):

- What about new URL schemes? Do we need a common registration?
- If we have a common registration, isn't there the danger that
	the urn: prefix will be dropped, for which finally
	agreement seems to have been found?

> > ...
> > Now this kind of 'clashes' with the needs to grandfather in various
> > schemes as their glyfh encoding might *NOT* be an unambigious character
> > index. For example if the indexes or local control identifiers are
> > collected over various contries; which each use their own (say latin)
> > charset, but the actual LCI is just the sequence of the character index
> > number _ITSELF_ into the various charsets. So encoding the glyf using
> > UTF8 it represents in one charset display mapping would most certainly
> > wrong for another one; and if the people interoperate you have broken the
> > LCI scheme. The reverse also happens; and on top of that normalizing in
> > UTF8 makes it even more fun.

If there is a namespace that encodes using different "charset"s
for different identifiers, then either the information about
each "charset" used is still available, somewhere in the identifier
or elsewhere, and the identifiers can be converted to UTF8 and
treated as everything else.
Otherwise, if the information about which "charset" is used in
each identifier is not available, or too difficult to get
(e.g. needing a connection to ask for it from some remote
site), the characters are lost, and there is no other solution
to treat this as if they never had been there. (i.e. use
base64 or such).

In this case, there is no need to speak about glyphs. If glyphs
are indeed an issue (e.g. a namespace indeed has to distinguish
between $ with one and with | and with ||), then if this is a
general problem for many of the characters/glyphs used, we can't
very well speak about characters anymore, and a special mapping
has to be designed. If it's only one or two glyphs, among many
where chararacters are well suited, the private zone might be
used, or some character might be substituted that is not otherwise
used in the namespace.

> I don't see a case of glyph ambiguity in the URN character set
> itself, however your following sentence:
> 
> > ++ Likewise if glyph ambiguity does not allow for UTF8 encoding
> > ++ the publication should outline the possible ambiguity and
> > ++ representations possible for display.
> 
> I like and am willing to add.

Ryan, does this sentence refer to the preceeding or the following
paragraph? I think the preceeding paragraph is not necessary.
URNs in general are displayed in their cannonical form.
We introduced UTF-8 so that we can construct nice interfaces
for the display of character-based URNs. It would be strange
to specify that in the context of a certain namespace, a $
has to be represented with ||. It would also be daring by
a namespace encoding icons to request or require that the icons
are displayed as such.
 
> > ++ The URN is a sequence of glyphs taken from the <urn-set>. It is
> > ++ represented by an octet stream with the only the values of the
> > ++ indexes of the <urn-set> glyphs in UTF-8. A glyph or symbol encoded,
> > ++ entered, stored, displayed or conveyed which is not in this limited
> > ++ range, for examply with an UTF-8 encoding, is purely based on the
> > ++ mutual understanding of the publishing and utilizing party; but is
> > ++ not to be used to represent the URN.
> >
> > The above needs to be tackled anyway, somewhere; unless I missed the
> > place in the current draft which tells us which is really the authorative
> > representation (between machines :-) of the beast. (Ignoring
> > normalziaiton,etc).
> 
> I thought (probably incorrectly) that this had been closed going into
> San Jose.  The URN's canonical form (for transmission between
> machines) is the sequence of characters from <urn character set>.
> Now Martin and Keith can tell me I'm wrong, but I thought this was
> closed.

Yes, it had been closed. It is represented by:

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.

Please note that this does not specify octet representation of the
canonical format. Octet representation may look differently if
the URN is in an EBCDIC file or an ASCII file or a UNicode file
(the later with every second octet being a NULL).

I don't think there is a need to reopen this. It's a fair
and safe, although not extremely efficient, compromize.

Regards,	Martin.

Date: Fri, 20 Dec 1996 15:48:11 -0500
From: [email-masked] (Stu Weibel)
To: [email-masked]
Subject: [URN] checksums
Sender: [email-masked]
Reply-To: [email-masked] (Stu Weibel)

Leslie is right... this thread is not critical to the success of URN
deployment and can be handled elsewhere.  Creeping featurism is the
bane of this group. Solve one problem at a time.

stu

Date: Fri, 20 Dec 1996 14:35:52 -0600
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: Daniel LaLiberte <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: structured NIDs [was Re: [URN] Pre-release of draft-ietf-...]
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

Daniel LaLiberte wrote:
> 
> Ryan Moats writes:
>  > [email-masked] wrote:
>  > > I only recently realized this when we where making an updated version
>  > > of a namespace; and we actually federated the namespace identification
>  > > itself for a little test; i.e.
>  > >
>  > >                 urn:v2.inet:some.where:somestring
>  >
>  > Ok, now we talk about the "." in the NID.  I don't have a strong opinion
>  > as to whether it should be included or not.  Anybody else what to
>  > comment on this?
> 
> Whether we do this or not, I don't consider it a silly question.
> It affects performance as well as human factor issues such as how
> organizations tend to arrange themselves (i.e. in hierarchies).
> 
> Structuring the NID is not strictly necessary because any
> substructure *could* be pushed off to the NSS.  But substructure in the
> NSS would not be as easily visible to clients and thus caching would
> be more difficult.
> 
> For example, if urn:inet:v2:some.where:somestring were handled one way
> and urn:inet:v8:some.where:somestring were handled another, then the
> V2 vs V8 is in the NSS.  But the NAPTR data for inet could specify a
> regex that matches on this part of the NSS and thus different
> resolvers could be specified, but it is more work for the client.

Hang on.  The NID cannot have ":" in it.  Therefore, the NID for
both of these cases is inet.  Now, if the inet namespace wants to
have substructure, that's fine.  However, the questions are:

(1) Should the NID have substrcuture?
(2) If yes, how do we do it?

I deleted the rest of the mail because it gets into implementation
(question 2) without discussing question 1.

Thinking about this some more, I'm wondering what structure in the
NID gives me.  The NID is used to (a) help find a namespace resolver
and (b) maybe help find NA information from the NSS.  Structure in
the NID would only be used to solve (a) or (b) which are already being
done without the strucutre.  Unless somebody has a (c), (d) or etc.
that NID structure gives me, why complicate the syntax?

Note: I'm punting on (2), because I'm leaning toward the answer to
(1) being "no".

Ryan

From: [email-masked] (Leslie Daigle)
Date: Fri, 20 Dec 1996 15:37:13 -0500
To: "David W. Morris" <[email-masked]>, Ryan Moats <[email-masked]>
Subject: Re: [URN] Checksums in URNs
Cc: "Ron Daniel Jr." <[email-masked]>, [email-masked]
Sender: [email-masked]
Reply-To: [email-masked] (Leslie Daigle)

Okay, I think this is losing focus...

The question is not simply whether having the ability to checksum URNs would be
a good thing or not -- there is much merit in the suggestion, because the
problems it tries to solve are very real.

However, there _is_ the question of whether or not it should be moved into
the general URN syntax/structure.  There are reasons to do this (it'll
be built in and usable by all schemes), and reasons not to (creeping 
featurism, trying to pick _one_ way to solve the problem for _all time_).

There seem to be more questions popping up -- how to handle white spaces,
what this is really intended to do, how it should be represented, etc.

There are alternative mechanisms -- the external wrapper/service, as Larry
suggested, or even incorporating it into individual namespaces -- or
coming up with a standardized way that new namespaces could _all_ adopt.

Unless someone (that could mean you, David Morris :-)  can come up with
concrete answers to the questions I asked earlier (see below), I think
we can sum up _consensus_ by saying:  there is obvious merit in having
mechanisms to test the integrity of URNs.  We don't yet know what the
best mechanism to handle that is (we don't even yet have any real-life
experience with them), so we can't answer it now, and will leave it as
a future problem.

Cheers!
Leslie.

[From my earlier message:]
  Things that need to be made clear:
  
          . whether this can be defined across _all_ URNs or is better hanlded
            by individual namespaces
  
          . is there _one_ checksumming standard that could be considered
            acceptable across _all_ URNs, now and forever, or else how
            do we identify which system was used for which URN?
  
          . how this would be handled in the rest of the URN resolution
            system (e.g., impacts on how NAPTR would handle URNs, etc)
  
          . how this would fit into the proposed syntax
  
  If somebody wants to propose concrete answers to these issues, we can
  see about getting consensus about moving on this...  

Specifically, rather than defining what "MUST" be done "by URNs", I'm
looking for some _concrete_ proposed adaptations to the drafts that would do 
what is wanted.

-- 

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

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

Date: Fri, 20 Dec 1996 13:44:00 -0700
To: "David W. Morris" <[email-masked]>
From: "Ron Daniel Jr." <[email-masked]>
Subject: Re: [URN] Checksums in URNs
Cc: Ryan Moats <[email-masked]>, [email-masked]
Sender: [email-masked]
Reply-To: "Ron Daniel Jr." <[email-masked]>

Thus spoke David W. Morris (at least at 11:54 AM 12/20/96 -0800)

>is some form of self validation a 
>necessary precondition for the long term utility and success of 
>URNs.  If the answer is yes, then the self-validation should be
>specified as part of the URN, even if only to say that a conforming
>URN implemenation must support ck:. If the answer is no, then the
>URN specification can ignore the issue and allow the perhaps never
>to be designed and specified other means to be used.

Actually, you are asking for something a bit stronger than
a self-validation ability. Lots of namespaces already provide
check-digit calculations of one form or another. However, their
calculations are not the same, so a user agent can't validate
the URNs. You are asking for the one-true-way to do check digits
in URNs, which would allow clients to do a sanity check on the
URN even if they were disconnected from the rest of the world.
While this would be nice, I am NOT convinced that it is
mandatory. I AM concerned about any attempts to say "this one
aspect of URNs must be immutable for all time". If protocols,
machines, filenames, resolution mechanisms, ... are all assumed
subject to change over time and therefore discouraged from
appearing in the URN, what makes us think that any arbitrary
check digit calculation will also be immutable? There is at
least one counter-example. The DUNS number system changed its
check digit calculation, and coming up with a new one that
would not invalidate the old numbers had to be fun. The
reasons they made that change, to fit more numbers into
their fixed-size identifier, are not so important to URNs but
my point is that we should avoid making requirements
for immutable procedures in a system that is expected to live
a long time in a mutable environment.

Regards,

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

From: Daniel LaLiberte <[email-masked]>
Date: Fri, 20 Dec 1996 14:13:41 -0600 (CST)
To: Ryan Moats <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: structured NIDs [was Re: [URN] Pre-release of draft-ietf-...]
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Ryan Moats writes:
 > [email-masked] wrote:
 > > I only recently realized this when we where making an updated version
 > > of a namespace; and we actually federated the namespace identification
 > > itself for a little test; i.e.
 > > 
 > >                 urn:v2.inet:some.where:somestring
 > 
 > Ok, now we talk about the "." in the NID.  I don't have a strong opinion
 > as to whether it should be included or not.  Anybody else what to
 > comment on this?

Whether we do this or not, I don't consider it a silly question.  
It affects performance as well as human factor issues such as how
organizations tend to arrange themselves (i.e. in hierarchies).

Structuring the NID is not strictly necessary because any
substructure *could* be pushed off to the NSS.  But substructure in the
NSS would not be as easily visible to clients and thus caching would
be more difficult.  

For example, if urn:inet:v2:some.where:somestring were handled one way
and urn:inet:v8:some.where:somestring were handled another, then the
V2 vs V8 is in the NSS.  But the NAPTR data for inet could specify a
regex that matches on this part of the NSS and thus different
resolvers could be specified, but it is more work for the client.

By the way, if the components of the structured NID were reversed and
separated by "/", then we would have something strongly resembling the
"path" scheme.  The reversal to reconstruct a DNS name (e.g. inet/v2
-> v2.inet.urn.net) could be done explicitly by clients rather than
rely on a sequence of regex substitutions and DNS lookups proportional
in length to the number of components.

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

Date: Fri, 20 Dec 1996 13:12:49 -0700
To: "David W. Morris" <[email-masked]>, Ryan Moats <[email-masked]>
From: "Ron Daniel Jr." <[email-masked]>
Subject: Re: [URN] Checksums in URNs
Cc: [email-masked]
Sender: [email-masked]
Reply-To: "Ron Daniel Jr." <[email-masked]>

Thus spoke David W. Morris (at least at 11:33 AM 12/20/96 -0800)

[on the subject of white space]
>the real world fact is that
>URNs will be 'typed' into plain text mail, printed, etc. For ease
>of handling, line breaks, etc. will creep in. Any verification scheme
>should, I think, allow for the possiblity.

I think this is a "user-interface" issue. When one system
sends a URN to another system, white space characters are
not allowed. If a user, OCR system, ... somehow comes up
with a bunch of whitespace characters when they try to
specify a URN to a user-agent, then it is that user-agent's
responsibility to make it legal or refuse it. We can and
should provide some "advice to imlpementors" that they
should expect to see illegal characters in URNs, especially
when a user is providing the URN, but that they MUST not send
an illegal URN, they SHOULD try obvious cleanups, and the
MAY try to be very smart indeed about how they make up a
legal URN from an illegal one.

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

Date: Fri, 20 Dec 1996 13:57:08 -0600
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: "David W. Morris" <[email-masked]>
Cc: "Ron Daniel Jr." <[email-masked]>, [email-masked]
Subject: Re: [URN] Checksums in URNs
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

David W. Morris wrote:
> 
> On Fri, 20 Dec 1996, Ryan Moats wrote:
> 
> [rest-deleted...]
>
> > BTW, just as a final note, the current URN syntax does not allow
> > arbitrary white space to be added in an unescaped form (just for
> > those inquiring minds)
> 
> And I am not proposing changing that ... but the real world fact is that
> URNs will be 'typed' into plain text mail, printed, etc. For ease
> of handling, line breaks, etc. will creep in. Any verification scheme
> should, I think, allow for the possiblity.

Any verification scheme "built into the URN itself" cannot handle that
possibility, because the unescaped white-space terminates the URN.

A verification scheme that can't handle the possibility is not
acceptable (I think we agree on this).

So, build the verification scheme into something that can handle
the white-space (a new meta-scheme).

Ryan

Date: Fri, 20 Dec 1996 11:54:07 -0800 (PST)
From: "David W. Morris" <[email-masked]>
To: "Ron Daniel Jr." <[email-masked]>
Cc: Ryan Moats <[email-masked]>, [email-masked]
Subject: Re: [URN] Checksums in URNs
Sender: [email-masked]
Reply-To: "David W. Morris" <[email-masked]>

On Fri, 20 Dec 1996, Ron Daniel Jr. wrote:

> I agree with Ryan. I am not in favor of adding more stuff
> to the URN syntax, especially when it can be accomplished by
> other means.

My base concern is only ... is some form of self validation a 
necessary precondition for the long term utility and success of 
URNs.  If the answer is yes, then the self-validation should be
specified as part of the URN, even if only to say that a conforming
URN implemenation must support ck:. If the answer is no, then the
URN specification can ignore the issue and allow the perhaps never
to be designed and specified other means to be used. If in practice,
URNs are perceived as as fragile as today's URLs, then the effort
to design URNs will have been wasted. One aspect of today's fragility
is typographic error of on entry.

Dave Morris

Date: Fri, 20 Dec 1996 13:48:50 -0600
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: [email-masked]
Subject: [URN] Syntax Draft Plans...
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

Folks-

There have been some good comments about the syntax draft and some
good stuff coming out of meshing it with the URL syntax, so I am
planning the following (i.e. you have been warned!).

There will be another pre-release of syntax-02 coming out on
12/26 ( Holidays, what are Holidays ;-} ).  The target is to
have -02 be sent to the i-d editors on 1/6/97.

This way folks (who don't have anything else to do between 12/25
and 1/1) can read the new version...

Ryan

Date: Fri, 20 Dec 1996 12:58:34 -0700
To: Ryan Moats <[email-masked]>, "David W. Morris" <[email-masked]>
From: "Ron Daniel Jr." <[email-masked]>
Subject: Re: [URN] Checksums in URNs
Cc: [email-masked]
Sender: [email-masked]
Reply-To: "Ron Daniel Jr." <[email-masked]>

I agree with Ryan. I am not in favor of adding more stuff
to the URN syntax, especially when it can be accomplished by
other means.

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

Date: Fri, 20 Dec 1996 11:33:26 -0800 (PST)
From: "David W. Morris" <[email-masked]>
To: Ryan Moats <[email-masked]>
Cc: "Ron Daniel Jr." <[email-masked]>, [email-masked]
Subject: Re: [URN] Checksums in URNs
Sender: [email-masked]
Reply-To: "David W. Morris" <[email-masked]>

On Fri, 20 Dec 1996, Ryan Moats wrote:

> Yes, but if it is encased in a meta-scheme, the URN syntax draft doesn't
> (and shouldn't care about it).  If it is embedded in the URN itself,
> then the ck: scheme is redundant.  Why invent the wheel twice?

Because ck: can apply to any URL but since it isn't part of the URL it
would be hard to require ... it would be an internet standard way to
validate things with no home to require its use.

> 
> As to the discussion of white space, etc. that's a different topic than
> what I'm going on about...
> 
> Ryan
> 
> BTW, just as a final note, the current URN syntax does not allow
> arbitrary white space to be added in an unescaped form (just for
> those inquiring minds)

And I am not proposing changing that ... but the real world fact is that
URNs will be 'typed' into plain text mail, printed, etc. For ease
of handling, line breaks, etc. will creep in. Any verification scheme
should, I think, allow for the possiblity.

Dave Morris

Date: Fri, 20 Dec 1996 13:25:51 -0600
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: "David W. Morris" <[email-masked]>
Cc: "Ron Daniel Jr." <[email-masked]>, [email-masked]
Subject: Re: [URN] Checksums in URNs
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

David W. Morris wrote:
> 
> On Fri, 20 Dec 1996, Ron Daniel Jr. wrote:
> 
> > My preference would be to NOT require checksums in all URNs.
> > I rather like Larry's suggestion of a wrapper like
> >   ck:the-checksum:the-uri
> 
> I like the clean elegance of the checksum wrapper as a general
> solution ... but I'm having a hard shaking the notion that having
> a checksum built in to the URN would vastly improve the reliability
> of URNs over time.

On the other hand, I don't see where it would help...

> My current feeling is that ck: is good and should be done as it can
> apply for URLs of all kinds....

No problem so far...

>AND URNs should have provision for
> a built in checksum which MUST be supported by all conforming UAs,
> Transfer Agents, etc. but MAY be used in any specific URN.

I have a problem with this, in that it adds optional structure to the
URN.  This optional structure make the URN syntax dirtier (IMHO)
and could create more headaches in resolving with the URL syntax (and 
I'm at my limit of various pain medications already...)...

> In either case, part of the design MUST consider how the feature will
> be used by humans ... I think that means that the syntax of ck: and
> a URN form if allowed needs to support linear white space insertion
> in the URL/URN at arbitrary points.

Yes, but if it is encased in a meta-scheme, the URN syntax draft doesn't
(and shouldn't care about it).  If it is embedded in the URN itself,
then the ck: scheme is redundant.  Why invent the wheel twice?

As to the discussion of white space, etc. that's a different topic than
what I'm going on about...

Ryan

BTW, just as a final note, the current URN syntax does not allow
arbitrary white space to be added in an unescaped form (just for
those inquiring minds)

Date: Fri, 20 Dec 1996 13:20:37 -0600
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: [email-masked]
Cc: [email-masked]
Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

[email-masked] wrote:
> 
> Just some comments on grandfathering and the % changes. The quick summary
> 
>         0. A plea to make the <urn-set> representation the real
>            thing; while still urging for the UA's to display/enter/...
>            then with effective UTF8 decoding.

I'll take a pass on this for the moment...

> 
>         1. suggested removal of the '%' sign from the list.
> 
>         2. suggested a utf-8 glyph encoding of '%' as a
>            octed for the char itself (%25 I think)

I think you may have missed my mail on URN/URL potential
incompatibilities.  The current text of the draft on the "%" issue 
is the following:

"...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.
 
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
precence 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."

This takes care of the above issues, as well as your "...%is..."
example below...

>         3. suggested escape hatch for (grandfathered in) namespaces
>            where the glyph representation is confirmed ambigious. (For
>            example the $, #, pound and yen sign).

This is already taken care of by the <excluded> character set.  The only
way to put a character from this set in a URN is to use "%" encoding.
Otherwise, the character terminates the URN.

It dawns on me that you may be talking about what hex value to use
for the "%" encoding.  My current position is that it is the
UNICODE/10646 value via UTF-8.  

>         4. suggested escape hatch for namespaces where the identifiers
>            have no meaningfull representation in the urn syntax (at
> 	     least meaningfull in the sense that a UA could gain
>	     something by showing it to the user) such as spaces which
>	     have a purely binary object identifiers; base64 is the
>	     _should_ wannabe.

I don't have a problem with this, so long as such information
is included in the namespace registration documentation.

>         5. Some very SILLY suggestion about leaving the '.' in the
>            NSS reserverd for future version or expansion.

I agree that I think it is silly.  I got confused here as to whether
you were talking about the NID or the NSS.  Reserving "." in the NSS
is the thing I think is silly. I'll talk about the NID later...

>         6. Some extra requiments on the NSI if it is one of the URI
>            prefixes. I can see valid reasons to do this; but also
>            can see easy confusion with the UA interface; so if one
>            proposes such a NSI idenfier she'd better address/defend
>            it in the publication right away. Quick example:
> 
>            urn:email:[email-masked]
>            urn:smtp:[email-masked]
>            urn:nntp:some-message-id-as-above

Oog.  I'm gonna take a pass on this one also for now (I have to
think about it some more)...

> -- This is slightly more restrictive that what is stated in RFC 1738 [3]
> -- (which allows the period "."). Further, the Namespace Identifier is
> -- case insensitive, so that "ISBN" and "isbn" refer to the same
> -- namespace.
> 
> I only recently realized this when we where making an updated version
> of a namespace; and we actually federated the namespace identification
> itself for a little test; i.e.
> 
>                 urn:v2.inet:some.where:somestring

Ok, now we talk about the "." in the NID.  I don't have a strong opinion
as to whether it should be included or not.  Anybody else what to
comment on this?

> -- To avoid confusion with the "urn:" identifier, the NID "urn" is
> -- reserved and MUST NOT be used.
> 
> After some confusion here; I would like to add something along the 
> lines of:
> 
> If a proposed namespace identifier is already in use as a protocol
> specifier in the URI space, such as for example ftp, http or email,
> the proposal for this identifier should justify this choise; i.e
> 
>         urn:email:[email-masked]  or
>         urn:ftp:someplace:abc.efg
>         urn:ftp://someplace/abcd.efg

Now this makes some sense to me.  I'm wondering if we want to
make the statement stronger...

> ...
> This means that a '%' followed by a non-hex encodes itself, but so
> 
>         urn:abc:jan%is%gek and

Not any more, see my discussion above.

> ...
> Now this kind of 'clashes' with the needs to grandfather in various
> schemes as their glyfh encoding might *NOT* be an unambigious character
> index. For example if the indexes or local control identifiers are
> collected over various contries; which each use their own (say latin)
> charset, but the actual LCI is just the sequence of the character index
> number _ITSELF_ into the various charsets. So encoding the glyf using
> UTF8 it represents in one charset display mapping would most certainly
> wrong for another one; and if the people interoperate you have broken the
> LCI scheme. The reverse also happens; and on top of that normalizing in
> UTF8 makes it even more fun.

The last portion of the last sentence has gone away and so the last
sentence now reads:

"Therefore, the process of registering a namespace identifier
shall include publication of a definition of which characters have
a special meaning to that namespace".

I don't see a case of glyph ambiguity in the URN character set
itself, however your following sentence:

> ++ Likewise if glyph ambiguity does not allow for UTF8 encoding
> ++ the publication should outline the possible ambiguity and
> ++ representations possible for display.

I like and am willing to add.

> ++ The URN is a sequence of glyphs taken from the <urn-set>. It is
> ++ represented by an octet stream with the only the values of the
> ++ indexes of the <urn-set> glyphs in UTF-8. A glyph or symbol encoded,
> ++ entered, stored, displayed or conveyed which is not in this limited
> ++ range, for examply with an UTF-8 encoding, is purely based on the
> ++ mutual understanding of the publishing and utilizing party; but is
> ++ not to be used to represent the URN.
>
> The above needs to be tackled anyway, somewhere; unless I missed the
> place in the current draft which tells us which is really the authorative
> representation (between machines :-) of the beast. (Ignoring
> normalziaiton,etc).

I thought (probably incorrectly) that this had been closed going into
San Jose.  The URN's canonical form (for transmission between
machines) is the sequence of characters from <urn character set>.
Now Martin and Keith can tell me I'm wrong, but I thought this was
closed.

Other things:

If a namespace wants to be opaque and use base-64, that's fine, but
I don't see where the syntax document must specify that.

Ryan

Date: Fri, 20 Dec 1996 19:52:28 +0100 (MET)
From: [email-masked]
To: Ryan Moats <[email-masked]>
Cc: [email-masked]
Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt
Reply-Path: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]

Just some comments on grandfathering and the % changes. The quick summary

        0. A plea to make the <urn-set> representation the real
	   thing; while still urging for the UA's to display/enter/...
           then with effective UTF8 decoding.

	1. suggested removal of the '%' sign from the list.

	2. suggested a utf-8 glyph encoding of '%' as a
           octed for the char itself (%25 I think)
     
        3. suggested escape hatch for (grandfathered in) namespaces
           where the glyph representation is confirmed ambigious. (For
	   example the $, #, pound and yen sign)

        4. suggested escape hatch for namespaces where the identifiers
           have no meaningfull representation in the urn syntax (at least
           meaningfull in the sense that a UA could gain something by
	   showing it to the user) such as spaces which have a purely
	   binary object identifiers; base64 is the _should_ wannabe.

	5. Some very SILLY suggestion about leaving the '.' in the
	   NSS reserverd for future version or expansion.

	6. Some extra requiments on the NSI if it is one of the URI
           prefixes. I can see valid reasons to do this; but also 
	   can see easy confusion with the UA interface; so if one
	   proposes such a NSI idenfier she'd better address/defend
	   it in the publication right away. Quick example:

		urn:email:[email-masked]
		urn:smtp:[email-masked]
		urn:nntp:some-message-id-as-above
		
	   Although one might think these are a bad idea; the syntax
	   and resolution allows for them; the do make a bit of sense
	   and I can image people with actually have brains dreaming
	   up persitant names for resources they already have avaible
    	   under a well know url. 

Have fun.

Dw.

-- URN Syntax
-- Filename: draft-ietf-urn-syntax-02.txt
--
-- 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 RFC 1738 [3]
-- (which allows the period "."). Further, the Namespace Identifier is
-- case insensitive, so that "ISBN" and "isbn" refer to the same
-- namespace.

I only recently realized this when we where making an updated version
of a namespace; and we actually federated the namespace identification
itself for a little test; i.e.

		urn:v2.inet:some.where:somestring

Which obviously works with the v2.inet.urn.net lookup. I am not sure
wether this is fluff functionality; and I feel that I am going down
a slipperly slope; but you 'might' want to reserve the dot somehow
for future expansion if you need an extra dimension; say because we do
not have the syntax right now; you could do something like

		urn:duns.2:gorbaglobinrealniceunicode

I.e. have an escape option. 
 
-- To avoid confusion with the "urn:" identifier, the NID "urn" is
-- reserved and MUST NOT be used.

After some confusion here; I would like to add something along the lines
of:

If a proposed namespace identifier is already in use as a protocol 
specifier in the URI space, such as for example ftp, http or email,
the proposal for this identifier should justify this choise; i.e

	urn:email:[email-masked]  or
	urn:ftp:someplace:abc.efg
	urn:ftp://someplace/abcd.efg

Because I can see people wanting to re-use some of the existing well
know protocol specifiers; but that would _really_ cause confusion
esspecially when the User agent allow you to type 'ibm' and really
turn it into http://www.ibm.com:80/home.html these days :-)

-- 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> ::= *<URN chars>
--
-- <URN chars> ::= <trans> | "%" <hex> <hex>
--
-- <trans> ::= <upper> | <lower> | <number> | <other>
--
-- <hex> ::= <number> | "A" | "B" | "C" | "D" | "E" | "F" |
-- "a" | "b" | "c" | "d" | "e" | "f"
--
-- <other> ::= "(" | ")" | "+" | "" | "," | "-" | "." | "/" |
-- ":" | "=" | "?" | "@" | "%"

This means that a '%' followed by a non-hex encodes itself, but so

	urn:abc:jan%is%gek and

is no problem. But than suppose you _want_ to replace the 'is' by
a 'ef' which looks like hex (though you did not intend it. So I would
propose to re-formulate it as:

++ <other> ::= "(" | ")" | "+" | "" | "," | "-" | "." | "/" |
++ ":" | "=" | "?" | "@"

And in the text

-- 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. The percentage sign _itself_ is encoded
++ as an octed index into its UTF-8 representation

-- Namespaces MAY designate one or more characters from the URN
-- character set as having special meaning for that namespace (An
-- example of this is the "%" character in the URN syntax itself). 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 and how to encode these characters if used in a literal
-- sense.

Now this kind of 'clashes' with the needs to grandfather in various
schemes as their glyfh encoding might *NOT* be an unambigious character
index. For example if the indexes or local control identifiers are
collected over various contries; which each use their own (say latin)
charset, but the actual LCI is just the sequence of the character index 
number _ITSELF_ into the various charsets. So encoding the glyf using 
UTF8 it represents in one charset display mapping would most certainly 
wrong for another one; and if the people interoperate you have broken the 
LCI scheme. The reverse also happens; and on top of that normalizing in 
UTF8 makes it even more fun.

So for this reason I suggest the follwing change of wording

-- Depending on the rules governing a namespace, valid identifiers in a
-- namespace might contain character indexes that are not members of the 
++ URN character set above or have a different glyph represenation in the 
++ above charset. (<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 index outside the URN character and/or 
++ with a different glyph interpretation. If the glyph and indexes 
++ representation is unambigious then it SHOULD be encoded 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. The percentage glyph _itself_ is encoded
++ as an octed index into the UTF-8 representation. 

As an aside; could someone more knowledgable than me add something about
normalization of the UTF-8 string; as this does aid the encoding when
a user is allowed to enter a URN from a keyword with other keys than
than those corresponding to the symbols of <urn-set>.

-- Namespaces whose object identifiers do not have a mapping to an 
-- information conveying representation SHOULD use a base64 encoding
-- of the binary encoded identifier.
 
-- Namespaces MAY designate one or more characters from the URN
-- character set as having special meaning for that namespace (An
-- example of this is the "%" character in the URN syntax itself). 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 and how to encode these characters if used in a literal
++ sense. Likewise if glyph ambiguity does not allow for UTF8 encoding
++ the publication should outline the possible ambiguity and 
++ representations possible for display. 

By the way; I do feel quite strong about glyph ambiguity and the
ability to encode arbritary strings. I would even be happier if
each name scheme essnetially defined _ITSELF_ what glyph encoding
it uses; and only suggest extremly strongly that UTF is the way
to go. But that the bottom line is that:

++ The URN is a sequence of glyphs taken from the <urn-set>. It is
++ represented by an octed stream with the only the values of the 
++ indexes of the <urn-set> glyphs in UTF-8. A glyph or symbol encoded,
++ entered, stored, displayed or conveyed which is not in this limited
++ range, for examply with an UTF-8 encoding, is purely based on the
++ mutual understanding of the publishing and utilizing party; but is
++ not to be used to represent the URN.

The above needs to be tackled anyway, somewhere; unless I missed the
place in the current draft which tells us which is really the authorative
representation (between machines :-) of the beast. (Ignoring 
normalziaiton,etc).

Well, Merry Chrismass,

Dw.

  

Date: Fri, 20 Dec 1996 10:16:10 -0800 (PST)
From: "David W. Morris" <[email-masked]>
To: "Ron Daniel Jr." <[email-masked]>
Cc: [email-masked]
Subject: Re: [URN] Checksums in URNs
Sender: [email-masked]
Reply-To: "David W. Morris" <[email-masked]>

On Fri, 20 Dec 1996, Ron Daniel Jr. wrote:

> My preference would be to NOT require checksums in all URNs. 
> I rather like Larry's suggestion of a wrapper like
>   ck:the-checksum:the-uri

I like the clean elegance of the checksum wrapper as a general
solution ... but I'm having a hard shaking the notion that having
a checksum built in to the URN would vastly improve the reliability
of URNs over time. 

My current feeling is that ck: is good and should be done as it can
apply for URLs of all kinds.  AND URNs should have provision for
a built in checksum which MUST be supported by all conforming UAs,
Transfer Agents, etc. but MAY be used in any specific URN.

In either case, part of the design MUST consider how the feature will
be used by humans ... I think that means that the syntax of ck: and 
a URN form if allowed needs to support linear white space insertion
in the URL/URN at arbitrary points.

Dave Morris

Date: Fri, 20 Dec 1996 18:41:13 +0100 (MET)
From: [email-masked]
To: "Ron Daniel Jr." <[email-masked]>
Cc: [email-masked]
Subject: Re: [URN] Checksums in URNs
Reply-Path: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked]

Although I can see the appeal of checksummed URN's; I would be
more interested implemeting them with a (commercial:-) type
of referall system; say the 'nice and easy' service peole 

	urn:nae:580064875

to just give an example of a 9-code protected string. This URN can
be N2N-ed by a nice-and-easy service (currently sitting on port
6080 of elect6.jrc.it) which will either give you the URN lodged
with it (through elect6.jrc.it:8080/nae.html) or an HTML page
explaining that you've got it wrong and the most likely 
alternative(s).

As URNs mature I do thing there is room for the 'friendly-name-
lodger' service and I do not know how many other people perfectly
willing to service you with nice namespaces which just have that
competive edge to your company/project. This is what is made
possible in the URN architecture (or at least in my private idea
of it) it; and this is what thus should be used to 'grandfather'
in such ideas.

Merry Chrismass to yee al by the way

Dw.

--
Live is fair to dutchmen; Sinterklaas comes round it on the fifth
http://ewse.ceo.org                           http://enrm.ceo.org
[email-masked]                    [email-masked]
+39 332 78 0014                                   +39 332 78 9549
                                              fax +39 332 78 9185

 ISEI/ESBA;                     The Center For Earth Observation
 Joint Research Centre of the European Communities, Ispra, Italy

On Fri, 20 Dec 1996, Ron Daniel Jr. wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> 
> Mime-Version: 1.0
> Content-Type: text/plain
> Content-Transfer-Encoding: 7bit
> 
> To: [email-masked]
> Date: Fri Dec 20 10:28:01 1996
> My preference would be to NOT require checksums in all URNs. 
> I rather like Larry's suggestion of a wrapper like
>   ck:the-checksum:the-uri
> 
> 
> 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: "Five Laws of Library Science" by S.R. Ranganathan     
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.2
> 
> iQB1AwUBMrrMoTOY2EydG1XFAQHdlgMA20ZcisvDDGG4yz4AJ7c4wMtiz4kwE1R5
> uzWotqHhTTgrkjuUPe0r38bxlFiyu5W+lgaHsSFbrnS+IpfMRclpgwmrW3sNclYc
> x/4+Yz8d0u/4qomFaMRJcyZMwQNKLyuY
> =7+Oc
> -----END PGP SIGNATURE-----
> 
> 

Date: Fri, 20 Dec 1996 10:18:36 -0700 (MST)
From: "Ron Daniel Jr." <[email-masked]>
To: [email-masked]
Subject: Re: [URN] Checksums in URNs
Sender: [email-masked]
Reply-To: "Ron Daniel Jr." <[email-masked]>

-----BEGIN PGP SIGNED MESSAGE-----

Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

To: [email-masked]
Date: Fri Dec 20 10:28:01 1996
My preference would be to NOT require checksums in all URNs. 
I rather like Larry's suggestion of a wrapper like
  ck:the-checksum:the-uri

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: "Five Laws of Library Science" by S.R. Ranganathan     

Date: Fri, 20 Dec 1996 08:32:08 -0600
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: "Martin J. Duerst" <[email-masked]>
Cc: Towsner <[email-masked]>, Larry Masinter <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Checksums in URNs
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

My turn to add my two cents worth...

Martin J. Duerst wrote:
> 
> On Thu, 19 Dec 1996, Towsner wrote:
> 
> > >Checksums and other kinds of decorations can be done outside the
> > >URL. Think of it as a metascheme:
> > >          ck:<checksum><url>
> > > e.g.     ck:A3Bd:http://www.parc.xerox.com/masinter
> >
> >       I like the idea of having the checksum be optional, as a
> > meta-scheme.
> 
> Same for me.

I'll make three...

> >I also think the checksum should be limited to alpha-numeric
> > characters, to avoid confusion.
> 
> What do you mean by "limited to alpha-numeric characters"? Can you be
> more precise.

How about just hex characters to keep it simple...

> >Perhaps this should be part of the URL
> > scheme as well.
> 
> If it is a metascheme, then it is a new URI scheme. It doesn't
> have to be discussed either in URL nor in URN syntax. It would
> go into a separate draft. It has to make sure, on its own,
> that it is compatible with the URL/URN syntax.

I agree with Martin, and if we use ck:<hex sequence> then we
are already compatible with the URL/URN character sets.  How to
generate the hex sequence is another headache altogether...

> Perhaps the URL syntax draft, where it speaks about URIs,
> could be generalized in the direction of metaschemes.
> From the syntax viewpoint, we already have two metaschemes
> (urn: and ck:), which can even be combined together,
> as ck:urn:namespace:NSS.

Martin is correct here as well.

Ryan

To: [email-masked]
Cc: "Ronald E. Daniel" <[email-masked]>, [email-masked]
Subject: Re: [URN] HTTP conventions draft
From: Toby Speight <[email-masked]>
Date: 20 Dec 1996 14:29:59 +0000
Lines: 49
Organization: ANSA - APM Ltd.
Sender: [email-masked]
Reply-To: Toby Speight <[email-masked]>

-----BEGIN PGP SIGNED MESSAGE-----

Dirkx> dirkx <URL:mailto:[email-masked]>

>>>>> In article <Pine.SOL.3.91.961219171347.13449F-100000@elect2>,
>>>>> Dirkx wrote:

Dirkx> On Wed, 20 Nov 1996, Ronald E. Daniel wrote:

Ron> If the client has requested the result be returned as text/html
Ron> or application/html, the result should be encoded as:

Ron> <UL>
Ron> <LI><A HREF="...url 1...">...url 1...</A>
Ron> <LI><A HREF="...url 2...">...url 2...</A>
Ron> etc.
Ron> </UL>

Ron> where the strings ...url n... are replaced by the n'th URL in the
Ron> list.

Dirkx> Given the fact that you can ask for a machine parsable list, the
Dirkx> above seems superfluous and tooo easy to get wrong. I would prefer
Dirkx> to just kill it; as it does little extra in (machine parsable)
Dirkx> functionality.

I think we should keep a recommendation that servers ought to be
prepared to return types other than a URI list (text/html and
text/plain, perhaps?) even if the format isn't specified.  IOW, we
ought to ensure that we can send something human-parsable, at least
until text/uri-list is ubiquitous.

I think Ron's suggestion is fine, if the word "should" is used in the
usual IETF strict sense of "not broken if it doesn't do this, and
shouldn't be relied upon, but ought to do it if there's no good reason
not to."



Date: Fri, 20 Dec 1996 14:13:25 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: Towsner <[email-masked]>
Cc: Larry Masinter <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Checksums in URNs
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

On Thu, 19 Dec 1996, Towsner wrote:

> >Checksums and other kinds of decorations can be done outside the
> >URL. Think of it as a metascheme:
> >          ck:<checksum><url>
> > e.g.     ck:A3Bd:http://www.parc.xerox.com/masinter
>=20
> =09I like the idea of having the checksum be optional, as a
> meta-scheme.

Same for me.

>I also think the checksum should be limited to alpha-numeric
> characters, to avoid confusion.

What do you mean by "limited to alpha-numeric characters"? Can you be
more precise.

>Perhaps this should be part of the URL
> scheme as well.

If it is a metascheme, then it is a new URI scheme. It doesn't
have to be discussed either in URL nor in URN syntax. It would
go into a separate draft. It has to make sure, on its own,
that it is compatible with the URL/URN syntax.

Perhaps the URL syntax draft, where it speaks about URIs,
could be generalized in the direction of metaschemes.
From=20the syntax viewpoint, we already have two metaschemes
(urn: and ck:), which can even be combined together,
as ck:urn:namespace:NSS.

Regards,=09Martin.

Date: Thu, 19 Dec 1996 20:41:24 -0500
To: Larry Masinter <[email-masked]>, [email-masked]
From: Towsner <[email-masked]>
Subject: Re: [URN] Checksums in URNs
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Towsner <[email-masked]>

>Checksums and other kinds of decorations can be done outside the
>URL. Think of it as a metascheme:
>          ck:<checksum><url>
> e.g.     ck:A3Bd:http://www.parc.xerox.com/masinter

	I like the idea of having the checksum be optional, as a
meta-scheme.  I also think the checksum should be limited to alpha-numeric
characters, to avoid confusion.  Perhaps this should be part of the URL
scheme as well.

--
<Insert witty signature here>
-Henry Towsner <[email-masked]>

To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Checksums in URNs
From: Larry Masinter <[email-masked]>
Date: Thu, 19 Dec 1996 15:07:59 PST
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

Checksums and other kinds of decorations can be done outside the
URL. Think of it as a metascheme:
          ck:<checksum><url>
 e.g.     ck:A3Bd:http://www.parc.xerox.com/masinter

Does anyone have a 2 character (or, perhaps a 4 character, 24-bit
base64) checksum scheme they'd propose?

To interpret a checksum URL, just strip off the ck & checksum.

Larry

From: [email-masked] (Leslie Daigle)
Date: Thu, 19 Dec 1996 17:43:17 -0500
To: marshall eubanks <[email-masked]>, [email-masked]
Subject: [URN] Checksums in URNs
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked] (Leslie Daigle)
[Was: Re: [URN] Re[2]: Article re San Jose IETF in Sunday San Francisco paper]

[Marshall Eubanks wrote:]
> > Maybe URN's should include a check-sum or the like to make sure that
> > it has been copied/typed correctly, much as crdit cards numbers, etc.,
> > do. This could even be in the URN label (as in, URN[XX]:yyyy, where
> > XX is a 2 character ascii code based on the yyyy field). The web
> > engine could then compare yyyy with XX and complain if they
> > don't match.
[...]
> A reasonable goal might be to be able to detect 2 character errors,
> and to correct one character errors.

In principle, being able to distinguish between wrong names and evaporated
resources seems like a good thing.  I haven't seen any comments (yet) that
suggest that it is felt to be out of scope.

We are now on the verge of finalizing the URN syntax, etc,  so we should
evaluate whether this seems like a solid, reasonably-implemented idea.

Things that need to be made clear:

	. whether this can be defined across _all_ URNs or is better hanlded
	  by individual namespaces

	. is there _one_ checksumming standard that could be considered
	  acceptable across _all_ URNs, now and forever, or else how
	  do we identify which system was used for which URN?

	. how this would be handled in the rest of the URN resolution
	  system (e.g., impacts on how NAPTR would handle URNs, etc)

	. how this would fit into the proposed syntax

If somebody wants to propose concrete answers to these issues, we can
see about getting consensus about moving on this...  

Leslie.

-- 

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

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

Date: Thu, 19 Dec 1996 17:21:59 +0100 (MET)
From: [email-masked]
To: "Ronald E. Daniel" <[email-masked]>
Cc: [email-masked]
Subject: Re: [URN] HTTP conventions draft
Sender: [email-masked]
Reply-To: [email-masked]

On Wed, 20 Nov 1996, Ronald E. Daniel wrote:

> I've changed the conventions draft to remove the integer from the
> text/uri-list media type. The new version is appended. I will
> send this to the ID editor later today.
> 
> INTERNET DRAFT                                                  Ron Daniel
> draft-ietf-urn-http-conventions-00.txt      Los Alamos National Laboratory
>                                                               13 Nov, 1996
> 
> 
>          Conventions for the Use of HTTP for URN Resolution
>
 ...
> If the client has requested the result be returned as text/html or
> application/html, the result should be encoded as:
> <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.
>
Given the fact that you can ask for a machine parsable list, the
above seems superfluous and tooo easy to get wrong. I would prefer
to just kill it; as it does little extra in (machine parsable)
functionality.

Just a minor one :-)

Dw.

Date: Thu, 19 Dec 1996 09:34:04 -0600
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: "Martin J. Duerst" <[email-masked]>
Cc: Leslie Daigle <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [URN] Potential inconsistency between URL and URN syntaxes...
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

Martin J. Duerst wrote:
> 
> We don't want a HTML parser or something similar to need separate code
> for parsing URLs and URNs. It should be able to deal with URNs as one
> URL scheme, syntactically. It looks like that is possible, but I have
> to admit that I am no regex expert.
> 

While I am not a regex expert either, there seem to me some obvious
issues here, which I have tried to address with comments on where
changes need to be made:

1. Can a URL parser handle the "urn:<NID>:" leader for URNs properly?
   Having looked at the "greedy" algorithm and the Regular Expression
   in the URL draft, I can say that the first part is sufficient to
   pick up the scheme as "urn:<NID>".  If we take the approach in
   comment 3 below, then the URL spec should note that (a) schemes
   may well have ":" in them or (b) a scheme beginning with "urn:"
   is treated as an opaque URL because it is really a URN (ITEM FOR 
   URL DRAFT).
2. The URN and URL character sets are not currently aligned well.
   ("Well" means that there are characters allowed for URLs that are
   not allowed for URNs).  There are currently (by my counting),
   two characters allowed in the URN char set that are not allowed in
   the URL char set: "\" and "%".  I don't have a problem with
   moving the "\" to the excluded set for URNs (ITEM FOR URN DRAFT)
   "%" is also part of the URN char set only to ensure that the
   definition for the end of a URN is clean.  It's sole purpose is to
   introduce an escape sequence for an octet (a literal "%" must be
   encoded as %25).  I am strengthening the language in the URN syntax
   draft with respect to the "%" issue. (ITEM FOR URN DRAFT)
3. There is no specification of structure for a URN NSS.  The only way
   to handle this through a URL parser is for the URL parser to declare
   the URN as an "opaque-URL" and do no processing on it.  This 
   specification (if done) must be done in the URL document (ITEM 
   FOR URL DRAFT).

If we do these things, I think we've cleaned up the problem.
I am currently moving the "\" character to the excluded region of 
the URN character set.

Ryan

Date: Thu, 19 Dec 1996 15:26:51 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: Leslie Daigle <[email-masked]>
Cc: Ryan Moats <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [URN] Potential inconsistency between URL and URN syntaxes...
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

On Wed, 18 Dec 1996, Leslie Daigle wrote:

> It looks like the following questions are on the table:
> 
> 	. should URN and URL syntaxes be consistent?

I guess we have to ask "to what extent should they be consistent".
Definitely, allowing something such as ">" in URNs, while they
are used to delimit URLs, would be a very bad idea. On the other
hand, the fact that the octets represented (with %HH in the canonical
form) in URNs are interpreted as UTF-8 should not at the moment
force URLs to suddenly convert to UTF-8 (quite difficult), but
should not on the other hand scare URLs away from making the
necessary preparations to get better i18n facilities and try
to move in the direction of UTF-8. (more on that later).

> 	. if yes, which should now change:
> 
> 		. URLs cannot, because of legacy support, although
> 	 	  there is the issue of "I18N"
> 
> 		. URNs "can", except that the existing syntax was
> 		  built for specific reasons to address issues that
> 		  have concerned URNs more than URLs (e.g., bringing
> 		  in other namespaces and addressing multiple language
> 		  issues).
> 
> 
> Is it "desirable" that URN syntax be compliant with URL syntax, or "required"?
> What _breaks_ if it is not?

We don't want a HTML parser or something similar to need separate code
for parsing URLs and URNs. It should be able to deal with URNs as one
URL scheme, syntactically. It looks like that is possible, but I have
to admit that I am no regex expert.

> [Ryan quotes from the URL draft:]
> > > 
> > >    Although this specification restricts its discussion to URLs, the
> > >    syntax defined is that of URI in general.  Any requirements placed on
> > >    the URL syntax also apply to the URI syntax.  This uniform syntax for
> > >    all resource identifiers allows a URN to be used in any data field
> > >    that might otherwise hold a URL.
> 
> This draft is for the _URL_ syntax, and this is the only paragraph that
> lays claim to all of URI syntaxes.
But it lays claims for all of the URL document, or at least a large part
of it.

Regards,	Martin.

Date: Thu, 19 Dec 1996 08:09:22 -0600
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: Michael Carroll <[email-masked]>
Cc: [email-masked]
Subject: Re: [URN] Potential inconsistency between URL and URN syntaxes...
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

Michael Carroll wrote:
> 
> It might be better for us to describe the current task as specifying
> *a* syntax for URNs, rather than *the* syntax for URNs.  This would
> clearly suggest the possibility that there will be other syntaxes
> later.  The other syntaxes may use characters from nonroman
> character sets; perhaps mappings will be specified from one syntax
> to another.

Wait a minute.  We've hashed this out already.  Nonroman character
sets are handled via UTF-8 and %encoding.  I really don't want to
re-open this.

Having multiple syntax definitions (IMHO) can be considered a
root of a lot of the current URL troubles.

Ryan

Date: Wed, 18 Dec 1996 22:09:35 -0800 (PST)
From: "Gregory J. Woodhouse" <[email-masked]>
To: [email-masked]
Subject: [URN] permanence
Sender: [email-masked]
Reply-To: "Gregory J. Woodhouse" <[email-masked]>

I've mostly kept silent on this matter because it seems rather late in the
game to discuss this kind of issue, but I have to agree that permanence is
best viewed as an implementation decision rather than a matter of policy.

Okay, that calls for some explanation. Ideally, I would like to think of
URNs as *abstract* names for resources, and I have to think that is what
they are intended to be. URLs encode specific information about which
servers store the information and wht specific requests are necessary to
retriewve the resource. URNs, on the other hand, encode no such
information, and this is the sense in which they are abstract. Of course,
permanence is a side effect of abstractness (and very much an intended
one!) By analogy, if the implementation of a class is modified, objects
which instantiate that class or its descendants need not be aware of the
change. Similarly, if a resource is moved, documents which reference it via
a URN need not be modified.

Okay, okay, that's all very obvious, and it may seem pointless say as much
here, but it seems that using permanence as the defining characteristic of
URNs has been the source of a lot of confusion.

---
[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: Wed, 18 Dec 1996 21:30:57 -0800 (PST)
From: "David W. Morris" <[email-masked]>
To: "Martin J. Duerst" <[email-masked]>
Cc: marshall eubanks <[email-masked]>, [email-masked]
Subject: Re: [URN] Re: Re[2]: Article re San Jose IETF in Sunday San Francisco paper
Sender: [email-masked]
Reply-To: "David W. Morris" <[email-masked]>

On Wed, 18 Dec 1996, Martin J. Duerst wrote:

> On Wed, 18 Dec 1996, marshall eubanks wrote:
> > know that it is typo free if it comes back as "not found." Credit
> > card numbers and the like include redundancy for exactly that reason.
> > A reasonable goal might be to be able to detect 2 character errors,
> > and to correct one character errors.
> 
> As far as I understand URNs (I was mainly involved in their i18n
> aspects), their most important property is permanence. This means
> that if you have an URN that is "not found", by the virtue of
> knowing it being an URN, you know that it's misspelled.

That is a circular argument .... permanence is a point of design here
not a point of policy. Hence, while the mechanism will allow a URN
to be resolved forever, it doesn't guarantee that it will be.  So 
I think the suggestion is quite useful. You really can't tell if it
is misspelled or the archives burned down. If you knew it was mispelled,
it might be worth attempting other means to figure out what was meant
while if it wasn't mispelled, then the resource is gone and one is out
of luck.  Having a URN checksum/crc/md5 to detect typos and an internal
self checking feature is redundancy but so what.  The internet protocols
are rampant with examples of redundancy between layers and I surely 
wouldn't expect a client to know how to validate every variation of
ISBN but it could be expected to validate a URN.

Dave Morris

Date:     Wed, 18 Dec 96 16:27:02 PST
From: "Michael Carroll" <[email-masked]>
To: [email-masked]
Subject:  Re: [URN] Potential inconsistency between URL and URN syntaxes...
Sender: [email-masked]
Reply-To: "Michael Carroll" <[email-masked]>

It might be better for us to describe the current task as specifying
*a* syntax for URNs, rather than *the* syntax for URNs.  This would
clearly suggest the possibility that there will be other syntaxes
later.  The other syntaxes may use characters from nonroman
character sets; perhaps mappings will be specified from one syntax
to another.

If we look at it this way, I think it's not even desirable that all
syntaxes for URNs comply with requirements on "the" (existing)
syntax for URLs.  It's just desirable that the first URN syntax
comply.  I don't know of anything that breaks if it doesn't.  I
agree "now is a logical time" to separate these things out.

Michael
--
  Michael Carroll
  Research Libraries Group
  [email-masked]

To:  [email-masked]

From: [email-masked] (Leslie Daigle)
Date: Wed, 18 Dec 1996 18:24:18 -0500
To: Ryan Moats <[email-masked]>, [email-masked]
Subject: Re: [URN] Potential inconsistency between URL and URN syntaxes...
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked] (Leslie Daigle)

It looks like the following questions are on the table:

	. should URN and URL syntaxes be consistent?
	
	. if yes, which should now change:

		. URLs cannot, because of legacy support, although
	 	  there is the issue of "I18N"

		. URNs "can", except that the existing syntax was
		  built for specific reasons to address issues that
		  have concerned URNs more than URLs (e.g., bringing
		  in other namespaces and addressing multiple language
		  issues).

Is it "desirable" that URN syntax be compliant with URL syntax, or "required"?
What _breaks_ if it is not?

[Ryan quotes from the URL draft:]
> > 
> >    Although this specification restricts its discussion to URLs, the
> >    syntax defined is that of URI in general.  Any requirements placed on
> >    the URL syntax also apply to the URI syntax.  This uniform syntax for
> >    all resource identifiers allows a URN to be used in any data field
> >    that might otherwise hold a URL.

This draft is for the _URL_ syntax, and this is the only paragraph that
lays claim to all of URI syntaxes.  It was written before there was a concrete
proposal for URNs.  I think the URL syntax RFC would be quite complete
_without_ this paragraph.

The URL syntax is going to face its own battles as the issues of 
character sets and languages are brought up -- it seems like now is a logical
time to separate out the evolution of these two things, _unless_ there
are some very concrete things that will break if they are not kept
consistent.

Cheers!
Leslie.

-- 

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

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

Date: Wed, 18 Dec 1996 19:21:06 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: Ryan Moats <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [URN] Potential inconsistency between URL and URN syntaxes...
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

On Wed, 18 Dec 1996, Ryan Moats wrote:

> Folks-
> 
> I was reminded this morning that there is a potential inconsistency
> between the URL and URN syntax specifications
> (draft-fielding-url-syntax-02.txt and draft-ietf-urn-syntax-01.txt).
> Because of this, I am cross-posting this to both lists, so I apologize
> to those folks that will see this multiple times (I know I will...)

I have noticed this inconsistency, too, and am glad Ryan brought it up.
 
> The inconsistency arises from the following:
> 
> In the URL syntax draft the following statement is made:
> 
> > 1.1. URL, URN, and URI
> > 
> >    URLs are a subset of Uniform Resource Identifiers (URI), which also
> >    includes the notion of Uniform Resource Names (URN).  A URN differs
> >    from a URL in that it identifies a resource in a location-independent
> >    fashion (see RFC 1737, [10]).  URNs are defined by a separate set of
> >    specifications.
> > 
> >    Although this specification restricts its discussion to URLs, the
> >    syntax defined is that of URI in general.  Any requirements placed on
> >    the URL syntax also apply to the URI syntax.  This uniform syntax for
> >    all resource identifiers allows a URN to be used in any data field
> >    that might otherwise hold a URL.
> 
> However, in the latest draft URN syntax spec (circulating on the urn
> mailing list), the syntax for a URN is
> 
> >    "urn:" <NID> ":" <NSS>
> 
> I don't beleive that the URN specification "can be used in any data
> field that might otherwise hold a URL" as it currently stands (If
> somebody thinks otherwise, please let me know).  Therefore, either the
> syntax specs need to be aligned or the statements about the URL
> specification refering to the URI syntax need to be modulated
> (neither of which are pleasant topics...).  My current preference
> is to modulate the URL syntax specification to support the URN syntax
> and move forward.

I think there is very much to be gained from URLs and URNs being
syntactically alligned. Currenty, it looks to me as if this is
the case; the "urn" part is a <scheme>, and everything after
that is scheme-specific. The greedy algorithm (Section 4.4)
and the exclusion of ":" in schemes assures that this parsing
will be done correctly.
The treatment of reserved characters could cause some problems,
however. To allow substitution of "%7E" by "~" (URL, 2.2/2.3.2)
while that character is not available on many keyboards is
problematic. Therefore, that aspect has to be reconsidered
anyway.
The URL draft also does not agree with the URN draft on i18n
issues. I18N in URLs is a large topic, and I hope to get the
time tomorrow to comment on its treatment in the URL draft.

In the context of this thread, it is at least required that
consequences in these differences are analysed/understood,
and that there is language in the URL draft (given it is kept
to be responsible for URIs in general) that the syntax
alignement does not include these issues. This most probably
should be done with a general statement explaining what
exactly is covered, and what not, by "uniform syntax".

Regards,	Martin.

Date: Wed, 18 Dec 1996 18:37:37 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: marshall eubanks <[email-masked]>
Cc: [email-masked]
Subject: [URN] Re: Re[2]: Article re San Jose IETF in Sunday San Francisco paper
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

On Wed, 18 Dec 1996, marshall eubanks wrote:

> > Maybe URN's should include a check-sum or the like to make sure that
> > it has been copied/typed correctly, much as crdit cards numbers, etc.,
> > do. This could even be in the URN label (as in, URN[XX]:yyyy, where
> > XX is a 2 character ascii code based on the yyyy field). The web
> > engine could then compare yyyy with XX and complain if they
> > don't match.
> 
> I was thinking here about the case where URN's could be very "cold."
> If I get a URL from someone today, and it's wrong, I can generally
> re-inquire, hunt around using search engines, etc. If I find a
> URN in (say) a 2 year old mail message, it might be very nice to
> know that it is typo free if it comes back as "not found." Credit
> card numbers and the like include redundancy for exactly that reason.
> A reasonable goal might be to be able to detect 2 character errors,
> and to correct one character errors.

As far as I understand URNs (I was mainly involved in their i18n
aspects), their most important property is permanence. This means
that if you have an URN that is "not found", by the virtue of
knowing it being an URN, you know that it's misspelled.

Another aspect of your proposal is that many namespaces, such as
ISBN, already contain check-sums.

Regards,	Martin.

Date: Wed, 18 Dec 1996 12:12:57 -0500
From: marshall eubanks <[email-masked]>
To: [email-masked], [email-masked]
Subject: [URN] Re[2]: Article re San Jose IETF in Sunday San Francisco paper
Sender: [email-masked]
Reply-To: marshall eubanks <[email-masked]>

I sent the following to the general IETF list, not the URN list,
by mistake. It concerns an idea I had after the problems that various
people had with a URL given in a mail message to the IETF :

> Maybe URN's should include a check-sum or the like to make sure that
> it has been copied/typed correctly, much as crdit cards numbers, etc.,
> do. This could even be in the URN label (as in, URN[XX]:yyyy, where
> XX is a 2 character ascii code based on the yyyy field). The web
> engine could then compare yyyy with XX and complain if they
> don't match.

I was thinking here about the case where URN's could be very "cold."
If I get a URL from someone today, and it's wrong, I can generally
re-inquire, hunt around using search engines, etc. If I find a
URN in (say) a 2 year old mail message, it might be very nice to
know that it is typo free if it comes back as "not found." Credit
card numbers and the like include redundancy for exactly that reason.
A reasonable goal might be to be able to detect 2 character errors,
and to correct one character errors.

                                     Regards
                                     Marshall Eubanks
                                     [email-masked]

From: Daniel LaLiberte <[email-masked]>
Date: Wed, 18 Dec 1996 09:59:50 -0600 (CST)
To: Ryan Moats <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: [URN] Potential inconsistency between URL and URN syntaxes...
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Ryan Moats writes:
 > However, in the latest draft URN syntax spec (circulating on the urn
 > mailing list), the syntax for a URN is
 > 
 > >    "urn:" <NID> ":" <NSS>
 > 
 > I don't beleive that the URN specification "can be used in any data
 > field that might otherwise hold a URL" as it currently stands (If
 > somebody thinks otherwise, please let me know).

I think otherwise.  I don't see anything wrong with this syntax -
consider that the scheme name for this whole class of URNs is called
"urn", and thus "urn:" preceeds the rest of the identifier.  

You were not specific about what the nature of the conflict is.

If "urn:" were optional (which is a subject still open for debate, I
presume), we may have a conflict.  The general URI syntax allows the
"<scheme name>:" prefix to be optional, and more of the prefix can be
left out, but then we might have a relative URI, which has different
semantics.  With no "urn:", the <NID> would actually function as the
scheme name since it indicates how to interpret the <NSS>.  But this
is true even with a required "urn:" prefix since we want URNs to be
independent of the resolution mechanism.

I'm not clear whether you believe URNs *should* be used in any data
field that might otherwise hold a URL, independent of whether they
in fact can.  I believe they should.

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

Date: Wed, 18 Dec 1996 09:11:15 -0600
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: [email-masked]
Cc: [email-masked]
Subject: [URN] Potential inconsistency between URL and URN syntaxes...
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

Folks-

I was reminded this morning that there is a potential inconsistency
between the URL and URN syntax specifications
(draft-fielding-url-syntax-02.txt and draft-ietf-urn-syntax-01.txt).
Because of this, I am cross-posting this to both lists, so I apologize
to those folks that will see this multiple times (I know I will...)

The inconsistency arises from the following:

In the URL syntax draft the following statement is made:

> 1.1. URL, URN, and URI
> 
>    URLs are a subset of Uniform Resource Identifiers (URI), which also
>    includes the notion of Uniform Resource Names (URN).  A URN differs
>    from a URL in that it identifies a resource in a location-independent
>    fashion (see RFC 1737, [10]).  URNs are defined by a separate set of
>    specifications.
> 
>    Although this specification restricts its discussion to URLs, the
>    syntax defined is that of URI in general.  Any requirements placed on
>    the URL syntax also apply to the URI syntax.  This uniform syntax for
>    all resource identifiers allows a URN to be used in any data field
>    that might otherwise hold a URL.

However, in the latest draft URN syntax spec (circulating on the urn
mailing list), the syntax for a URN is

>    "urn:" <NID> ":" <NSS>

I don't beleive that the URN specification "can be used in any data
field that might otherwise hold a URL" as it currently stands (If
somebody thinks otherwise, please let me know).  Therefore, either the
syntax specs need to be aligned or the statements about the URL
specification refering to the URI syntax need to be modulated
(neither of which are pleasant topics...).  My current preference
is to modulate the URL syntax specification to support the URN syntax
and move forward.

Ryan Moats
InterNIC Directory and Database Services

From: [email-masked] (Leslie Daigle)
Date: Mon, 16 Dec 1996 16:48:57 -0500
To: [email-masked]
Subject: [URN] DRAFT URN Meeting Minutes
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked] (Leslie Daigle)

Well, rather than tearing apart case insensivity for a while longer,
here's some more material to play with!  

These are the draft meeting minutes that Sally Hambridge put together
for us (thanks Sally!).  Overall, I think the meeting was quite successful,
in that we covered several drafts, made a plan for what to do next,
and seem to be making quite reasonable progress.

I would appreciate corrections/comments from people who attended the 
meeting -- I intend  to send the minutes in on Friday this week.

Additionally, comments on the content (whether or not you made it to
the meeting) are also welcomed.

Cheers!
Leslie.

==================

                Draft Minutes of the URN Working Group
                 37th IETF, San Jose, December 12, 1996

Group Co-Chairs: Leslie Daigle, [email-masked]
                 John Curran, [email-masked]

Minute-Meister:  Sally Hambridge,  Intel 

Leslie opened the meeting by reviewing the Charter and Milestones.  
Hot Spots in the milestones are: we lack a draft detailing 
N2L/N2R/etc resolution results.  We will probably use Ron Daniel's HTTP 
conventions draft as a start on this milestone.  We also need to 
submit a document describing one new namespace and a document 
which describes grandfathering in older naming schemes, as well 
as the Frameworks and Requirements draft.

Karen Sollins presented the open issues with the current 
Frameworks and Requirements document:

The document discusses the assumptions of longevity, delegation, 
and independence.  The requirements fall in 3 major areas:  
Evolution, Usability, and Security.  The framework looks like 
this:

URN:<NID><NSS>
   |
   |
Global NID registry
  |        |
  |        |
  |     Private URN resolution service
UDS server
  |
  |
Private URN resolution service

Karen includes a definition section which defines Local 
Resolution service - what transforms URNs into access to 
resources; Hints - information that helps to access the 
information; UDS - URN Resolution Service Discovery Service - how 
to find the right URN resolution service; HFN - Human friendly 
names.

The Security area will discuss access control on hints; server 
authenticity; Server distribution (a countermeasure on denial of 
service attacks) and Privacy - the users from resolution services 
and for publishers for their clients and publications lists.

Issues:  Encouragement of separation of URNs from semantics
 - Efficiency as a goal or a requirement is in several places 
(documents) which need to be aggregated.
- Whether there is a useful distinction to be made between long-
term and short-term hints
- Acceptance by potential providers of UDS services.

Karen asked what's missing from the list of issues:
Internationalization (i18n) should be covered one way or another.
Name space ID - needs to be in a document but probably not this 
document.

Ryan Moats presented the issues with the URN syntax ID:
URN: should this be optional.  Please see the later discussion on 
this for the consensus.  
NID syntax: Why not use numbers and "-".  No reason - Ryan will 
change the draft.  There was a suggestion for following the RFC 
for URLs on this, but it was pointed out that this document is 
currently undergoing a revision.  NID namespace will have case 
insensitivity and add %escaping.  The NSS may be case sensitive.
URN Character set adds/deletes: Add "%" to the allowed character 
set and add a list of characters NOT part of the set to the 
draft.
%escaping: Will be allowed for escaping of reserved characters in 
addition to characters outside the URN character set; and allow 
for %HH escaping to use either upper or lower case.
Where does a URN end? At the first non-URN character set 
character.
Equivalency: Are things the same when they point to the same 
resource?  (Equivalency of resources was deemed to be a 
rathole).    Leslie offered that a URN could point to a specific 
day's weather and another could refer to today's weather, and 
these were pointing to the same thing but were not equivalent.
ROUGH CONSENSUS was reached that ONLY lexical equivalency will be 
covered in the draft.
The namespace will have strict rules. 
For the Human readability - MUST/SHOULD the following text is 
being substituted:
  Any namespace (existing or newly-devised) that is proposed as a 
  URN-namespace 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

Ron Daniel discussed the NAPTR draft.
 - There will be verbiage to state that records with unknown 
flags must be ignored.
- The Pseudo-code has to go.
- "R" Flag for treating Regex as "Raw"
- Don't do "E" flag for encrypting Raw fields.
Flag field reserves 0-9 for experimentation.  The TFLag allows 
you to look for the same domain as I.  ROUGH CONSENSUS was to 
allow people to create new flags however they want, but that if 
you see a flag you don't recognize you ignore it.

There was a question of the references to other drafts, and John 
Curran said he would find out if the text RFC xxx could be 
written and if the RFC editor would insert the correct numbers.

This draft will be going as an Experimental RFC.  There was 
discussion about how the experimental status will effect DNS and 
the regex substitutions.  We need to be explicit.  We need to 
say how this doesn't overload DNS and how DNS security will help 
and where it won't.  Also, there will probably be more than one 
discover service in the future and we don't want this one to be 
"The Standard".  We need operational experience.  The requiring 
resolution problem is not part of this draft.  We will have one 
more revision on the mailing list, then this goes to 
Experimental.

HTTP Conventions: Ron took this one too.
- We need a simple resolver for testing, the goal is not 
Standards track.  The goal is to use the conventions on encoding 
on requests and responses on http:

GET /uri-res/<server>/<uri> HTTP 1.0

He will include % encoding, status codes, Accept: headers and 
other stuff from HTTP as appropriate.  This allows cgi scripts to 
get names from files or directories, although they look ugly.

Open Discussion:
URN:  There was a question of rough consensus on the problem of 
whether to require urn:.  The room seems to indicate that urn: 
should be required on any part of the urn that was shipped around 
the Internet.  Whether or not implementors would use urn: was 
left up to them for their own local products, but in transmission 
the urn: would be required.  The problem with urn: seems to be at 
the user interface and user services level.  Don't confuse human 
friendly names with internal representation.

Documents:
We need a URN dereferencing document to discuss the resolution 
service and the resolution system.  These need the syntax (which 
is close) and the system requirements needs the framework (which 
is also close.) 

Assign URN - needs everything! We need namespace requirements.  
We need to have one new namespace and we need to bring in 1 
existing namespace.  We need to pay some attention to potential 
lawsuit issue.  It is important for someone who has authority for 
the namespace to say how it works in URN.  The proposal is for 
these to be experimental.  Dun and Bradstreet is interested in 
working on this as soon as the syntax is ready.  Clifford Lynch 
said that the NISO bibliographic IDs could move en masse.

We can create a resolution system which can be used outside the 
URN space, but we need to make it work there first.

Charter directions:

* We need to get a grip on bringing in an existing namespace
* We need a new namespace scheme
* We need the Name space requirements document (to see whether 
DNS will or won't work)
* We need to bring all the requirements from all sources into one 
place
* We need to look at the process of creating new namespaces

-- 

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

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

Date: Mon, 16 Dec 1996 15:31:00 -0600
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: "Martin J. Duerst" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

Martin J. Duerst wrote:
> 
> On Mon, 16 Dec 1996 [email-masked] wrote:
> 
> > > >5. The NSS is case sensitive, while the NID, "urn:" tag and %escaping
> > > >are case insensitive.
> > >     Why is the NSS case sensitive?  Most people are used to URL's which
> > > are case insensitive.  There would be a lot of confusion with people
> > > ignoring caps, as well as allowing someone to take an NSS which is
> > > identicle to another except for capitalization.  (I think there was a
> > > similar issue recently with URL's and the three letter classification.)
> >
> > I disagree that all URLs are case insensitive.  Portions are, but then again,
> > some portions aren't.
> 
> See my example with a file name. In general, only the DNS part is
> case insensitive. User id may be, may be not, password certainly
> not, hierarchical part (filenames) certainly not, query part certainly
> not. This makes URLs case sensitive: If you don't know the details
> you better make sure you got it the right way, or it may point into
> the void.

This example works for me...

> > Going back into my email archives (not as thorough as Bunyip's, but easier
> > to get at, the syntax draft has always allowed individual namespaces to
> > declare themselves as having a case-insensitive NSS,
> 
> Is that mentionned specifically, or is it just due to the fact that
> NSSs can declare any two names to be functionally equivalent?

Yes.  In section 5, the quote is "Some namespaces may define additional
lexical equivalences, such as case-insensitivity of the NSS (or parts
thereof)."

Ryan

P.S. I forgot where I was for my previous message, so please ignore that
To: header.

Date: Mon, 16 Dec 1996 16:26:53 -0500
From: Lewis Girod <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt
Sender: [email-masked]
Reply-To: Lewis Girod <[email-masked]>

   From: [email-masked] (Leslie Daigle)
   Date: Mon, 16 Dec 1996 16:02:28 -0500

   There might be a better wording for this to suggest that the NSS is 
   expected to be transported and interpreted literally.

... and that each namespace defines any relevant notions of lexical
equivalence.  Using NAPTR, this equivalence function is implemented
within the regexps -- basically two different URNs generate the same
domain name to look up.  This may be used to express case
insensitivity, as well as more complex equivalence functions.

Also, since escaped characters are a syntax that applies to all NSS's,
we can specify the hex characters encoding escaped characters to be
case insensitive.

	- Lewis

Date: Mon, 16 Dec 1996 22:18:30 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

On Mon, 16 Dec 1996 [email-masked] wrote:

> > >5. The NSS is case sensitive, while the NID, "urn:" tag and %escaping
> > >are case insensitive.
> > 	Why is the NSS case sensitive?  Most people are used to URL's which
> > are case insensitive.  There would be a lot of confusion with people
> > ignoring caps, as well as allowing someone to take an NSS which is
> > identicle to another except for capitalization.  (I think there was a
> > similar issue recently with URL's and the three letter classification.)
> 
> I disagree that all URLs are case insensitive.  Portions are, but then again,
> some portions aren't. 

See my example with a file name. In general, only the DNS part is
case insensitive. User id may be, may be not, password certainly
not, hierarchical part (filenames) certainly not, query part certainly
not. This makes URLs case sensitive: If you don't know the details
you better make sure you got it the right way, or it may point into
the void.

> Going back into my email archives (not as thorough as Bunyip's, but easier
> to get at, the syntax draft has always allowed individual namespaces to
> declare themselves as having a case-insensitive NSS,

Is that mentionned specifically, or is it just due to the fact that
NSSs can declare any two names to be functionally equivalent?

>but that is not the
> default.  Further, there was some discussion that case-insensitivity would
> have strange effects in the international arena (Martin, maybe you
> can clarify this some more?)

First, we would have to make sure that case-insensitivity also applies
to accented characters, and to Greek, Cyrillic, and Armenian. Second,
the question of whether to extend insensitivity to things similar, but
not equivalent to case would come up (e.g. katakana and hiragana in
Japanese). This is an actual point of discussion for SGML :-(.
Third, casing can be different depending on language. The Turkish
dotless I is the famous example.

Regards,	Martin.

From: [email-masked] (Leslie Daigle)
Date: Mon, 16 Dec 1996 16:02:28 -0500
To: Towsner <[email-masked]>, Ryan Moats <[email-masked]>, [email-masked]
Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt
Sender: [email-masked]
Reply-To: [email-masked] (Leslie Daigle)

[Henry Towsner wrote:]
> 	Why is the NSS case sensitive?  Most people are used to URL's which
> are case insensitive.  There would be a lot of confusion with people
> ignoring caps, as well as allowing someone to take an NSS which is
> identicle to another except for capitalization.  (I think there was a
> similar issue recently with URL's and the three letter classification.)

Don't forget that we are trying to architect something that will not
preclude the incorporation of existing namespaces -- and many of those
 _are_ case sensitive.

Also, "case sensitivity" is poorly defined when it comes to non-7-bit
characters and non-English languages.

There might be a better wording for this to suggest that the NSS is 
expected to be transported and interpreted literally.

Leslie.

-- 

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

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

Date: Mon, 16 Dec 1996 12:45:26 -0800 (PST)
From: "Gregory J. Woodhouse" <[email-masked]>
To: Towsner <[email-masked]>
Cc: Ryan Moats <[email-masked]>, [email-masked]
Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt
Sender: [email-masked]
Reply-To: "Gregory J. Woodhouse" <[email-masked]>

The NSS should be case sensitive. Think about URLs. The following are not
equivalent:

http://wherever.org/Folder/
http://wherever.org/folder/

I don't think case sensitivity in the NSS wil be any gret surprise with
URNs. (Then again, I've never been much of a fan of case insensitivity,
anyway.)

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

From: [email-masked]
Date: Mon, 16 Dec 96 14:42 CST
To: [email-masked], [email-masked]
Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt
Sender: [email-masked]
Reply-To: [email-masked]

> >5. The NSS is case sensitive, while the NID, "urn:" tag and %escaping
> >are case insensitive.
> 	Why is the NSS case sensitive?  Most people are used to URL's which
> are case insensitive.  There would be a lot of confusion with people
> ignoring caps, as well as allowing someone to take an NSS which is
> identicle to another except for capitalization.  (I think there was a
> similar issue recently with URL's and the three letter classification.)

I disagree that all URLs are case insensitive.  Portions are, but then again,
some portions aren't. 

Going back into my email archives (not as thorough as Bunyip's, but easier
to get at, the syntax draft has always allowed individual namespaces to
declare themselves as having a case-insensitive NSS, but that is not the
default.  Further, there was some discussion that case-insensitivity would
have strange effects in the international arena (Martin, maybe you
can clarify this some more?)

Ryan

Date: Mon, 16 Dec 1996 21:31:43 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: Towsner <[email-masked]>
Cc: Ryan Moats <[email-masked]>, [email-masked]
Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

On Mon, 16 Dec 1996, Towsner wrote:

> >5. The NSS is case sensitive, while the NID, "urn:" tag and %escaping
> >are case insensitive.
> 	Why is the NSS case sensitive?  Most people are used to URL's which
> are case insensitive.

Looks like you are living on an MS-DOS box, or an IBM mainframe.
Otherwise, create two files, just differing in captitalization,
and try what you get with a file: URL. In case you file system
is capitalizationwise challenged, and you still have difficulties
believing me, I can set up two such files in our ftp directory :-).

Regards,	Martin.

Date: Mon, 16 Dec 1996 14:59:21 -0500
To: Ryan Moats <[email-masked]>, [email-masked]
From: Towsner <[email-masked]>
Subject: Re: [URN] Pre-release of draft-ietf-urn-syntax-02.txt
Sender: [email-masked]
Reply-To: Towsner <[email-masked]>

>5. The NSS is case sensitive, while the NID, "urn:" tag and %escaping
>are case insensitive.
	Why is the NSS case sensitive?  Most people are used to URL's which
are case insensitive.  There would be a lot of confusion with people
ignoring caps, as well as allowing someone to take an NSS which is
identicle to another except for capitalization.  (I think there was a
similar issue recently with URL's and the three letter classification.)

--
<Insert witty signature here>
-Henry Towsner <[email-masked]>

Date: Mon, 16 Dec 1996 09:41:17 -0600
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: [email-masked]
Subject: [URN] Pre-release of draft-ietf-urn-syntax-02.txt
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

This is a multi-part message in MIME format.

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

Folks-
 
Apologies for jumping any traditional post-IETF "quiet time", but I
would really like to try and move the syntax draft closer to draft
standard.  Attached is a pre-release of version -02.
 
We managed to reach rough consensus on the open issues raised during the
URN working group meeting, and so I've changed the syntax draft to
note these agreements. I'm now looking for rough consensus from those
folks on the mailing list that were not in San Jose.

Ryan

-----------Changes from the release draft are (in no particular order):
 
1. Various editing changes, and I've probably missed some, including
cleaning up the modified BNF grammar.
 
2. The tag "urn:" is now required.  There were several folks at San Jose
that said that the absence of this tag would break things, while there
was no one that said that the presence of this tag would break things. 
If someone has a situation were the presence will BREAK things (not just
be inconvient) let the mailing list know!
 
3. The NID now allows letters and numbers.
 
4. The equivalence section only talks about lexical equivalence. 
Functional equivalence is namespace specific and is outside the scope of
this document.
 
5. The NSS is case sensitive, while the NID, "urn:" tag and %escaping
are case insensitive.
 
6. "%" has been added to the URN character set.  An explicit list of
all octets not part of the URN character set has also been added (the
"excluded character set".  A URN ends with an octet that is part of
the excluded character set.
 
7. "%"escaping is now allowed for reserved characters as well as
characters not in the URN char set.
 
8. The two paragraphs in section 3 have been replaced with Leslie's
suggestion to the mailing list.

--------------4648506075BE
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                                      December 1996

                               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 5/19/97                                                 [Page 1]

INTERNET DRAFT                 URN Syntax                  December 1996

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 RFC 1738 [3]

Expires 5/19/97                                                 [Page 2]

INTERNET DRAFT                 URN Syntax                  December 1996

   (which allows the period "."). 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>         ::= *<URN chars>

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

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

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

   Namespaces MAY designate one or more characters from the URN
   character set as having special meaning for that namespace (An
   example of this is the "%" character in the URN syntax itself).  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 and how to encode these characters if used in a literal
   sense.

Expires 5/19/97                                                 [Page 3]

INTERNET DRAFT                 URN Syntax                  December 1996

2.3 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
   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 says that two URNs are
not equivalent if the procedure above says they are equivalent.

Expires 5/19/97                                                 [Page 4]

INTERNET DRAFT                 URN Syntax                  December 1996

6. Functional Equivalence in URNs

   Resolvers determine functional equivalence based on specific rules
   for the namespace.  Therefore, 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, isbn:1-23485-8-29 are lexically equiv.
     urn:isbn:1-23485-8-29, ISBN:1-23485-8-29 are lexically equiv.
     urn:isbn:1-23485-8-29, isbn:123485829 are not lexically equiv.
        but may be functionally equivalent.

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.

10. References

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

         [1]         L. L. Daigle, P. Faltstrom, R. Iannella.  "A Frame-
                     work for the Assignment and Resolution of Uniform
                     Resource Names," Internet Draft (work in progress).
                     June 1996.

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

Expires 5/19/97                                                 [Page 5]

INTERNET DRAFT                 URN Syntax                  December 1996

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

11. Editor's address

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

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

                 This Internet Draft expires May 19, 1997.

Expires 5/19/97                                                 [Page 6]

--------------4648506075BE--

From: [email-masked] (Leslie Daigle)
Date: Fri, 13 Dec 1996 01:24:39 -0500
To: [email-masked]
Subject: [URN] URN WG Meeting -- summary
Sender: [email-masked]
Reply-To: [email-masked] (Leslie Daigle)

There was a URN WG meeting today (Dec 12/96) at the San Jose IETF.  A brief
summary of that session is attached -- minutes will follow in the next
few days.

....

The URN WG session included a discussion of the 4 current Internet drafts
that we have (in generic terms, URN Discovery System Requirements & Framework,
URN Syntax, NAPTR, and HTTP Conventions for URN Resolution).  A few issues 
were identified with each document, and consensus was felt on most of them.
Therefore, URN Syntax, NAPTR and HTTP Conventions will go through one more quick
editing phase before being circulated on the mailing list and (barring further
issues) submitted for consideration as RFCs.  The System Requirements document
is younger and will be restructured before calling for discussion on particular
items.    Volunteers were sought and obtained for tackling the URN Namespace 
Requirements document, and also proposed namespaces for grandfathering.  To 
everyone's amazement, we accomplished this with the minimum of discussion and 
were done in 1 1/2 hours.  Hurrah!

Leslie.

-- 

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

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

Date: Fri, 06 Dec 1996 10:48:27 -0700
To: [email-masked]
From: Ron Daniel <[email-masked]>
Subject: [URN] comments on Sollins' requirements draft
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Hi all,

Some notes w.r.t. Karen Sollins' recent draft on URN Resolution Requirements
and Framework. This is a little long, but maybe you can read it on the
flight to San Jose. For those who have not yet learned how to sleep on
flights, this should cure you of *that* problem. :-)

====
 Notes on Conformance of the NAPTR Proposal to URN Resolution Requirements

Karen Sollins has recently issued the first draft of a requirements document
for URN Resolution Services. To provide feedback to her for subsequent
versions of that draft, I have tried to document how the NAPTR resolution
proposal does or does not meet those requirements. I'll confess to being a
little ...difficult...  :-) and deliberately taking advantage of what I
perceived to be ambiguities in the requirements. This accounts for the
"NAPTR is the greatest thing in the world" tone of much of my responses.
The point is to try to push on the requirements as hard as possible to
see where they might be weaker than desired. Where I have knowingly
done so I have made an attempt at honesty by including a notes section
that explains what I think is the real intent of the requirement and how
NAPTR would or would not meet it. The notes section may also contain critiques
of the requirement in general.

General Comments:
=================

I think Karen has done something good by noting that we have resolver
discovery services (her UDS acronym) as opposed to resolvers. I would like
to see the requirements made more explicit on which sort of service they
apply to.

The draft collects the requirements into summaries at the end of each
section. That was found very useful and my comments key off of the summaries.
I have added some numbers on the requirements to make it easier to refer
to particular ones. I would like to see the draft use a numbering scheme.
I found it confusing on pg. 6 where one paragraph starts off "Lastly..."
and the next paragraph starts off "Second, ...".

Requirements on Evolution (sec. 3.1)

(3.1.1.a) Support for a growing set of URN schemes
==================================================
The NAPTR proposal supports growth in the number of URN schemes (namespaces).
New namespaces, X, may be added to X.urn.net and rules for their resolution
established.

(3.1.1.b) Support for new local URN resolution schemes
======================================================
The NAPTR proposal directly supports the evolution of URN resolution
schemes through the "services" field in the NAPTR record. Multiple
NAPTR records may be associated with a namespace to handle the period
of transition from one resolution protocol to another.

Notes:
I was unclear on the use of the term "local" in the summary statement of
the requirement. It did not appear in the narrative explanation of the
requirement.

The requirement is ambiguous. I can, I think, reasonably interpret it as
I did in the answer above. However, I believe that Karen's intent was that
there be an evolutionary path away from the NAPTR UDS approach itself, not
just the resolver protocols "discovered" by the NAPTR approach.

Assuming that was Karen's intent, I still think NAPTR meets the requirement.
My intent is that NAPTR resolution be used as a fallback approach when
a client does not have a specific handler for a namespace or URL protocol.
This allows alternate resolution mechanisms to be used on a namespace
by namespace basis. When a replacement UDS for NAPTR arises, there is no
difficulty in making it the resolver of last resort instead of NAPTR, and
in configuring clients so they only use NAPTR for namespaces not yet
serviced by the new UDS.

(3.1.1.c) Support for new authentication schemes:
=================================================

The authentication schemes supported by the individual resolution protocols
are outside the bounds of the NAPTR spec. The NAPTR UDS itself can utilize
the recent DNSSEC work to build authentication mechanisms when desired.
Any authentication needs not addressable through the DNSSEC framework can
be addressed by defining a new DNS resource record, or by using a special
convention on existing records such as TXT.

Notes:
The narrative for this requirement was not especially helpful. While the
previous two requirements had narratives that could be shortened, this one
needs some more explanation.

(3.1.1.d) Support for alternative UDS schemes active simultaneously
===================================================================

The notes for 3.1.1.b explain how NAPTR does not preclude alternative
UDS schemes and shows one way in which a client can use multiple UDS
schemes at the same time.

(3.1.2) Support and encourage the evolution toward the separation of
        global identification from short-lived, locally useful, or human
        friendly semantics
========================================================================

The NAPTR proposal supports the resolution of identifiers from
namespaces without the visible inclusion of resolution-system-specific
hints such as domain names.

Notes:
"Support" is OK, but the "and encourage" is a bit much.

Terry Allen has already commented on how this requirements document goes
well beyond the URN Requirements document in terms of deprecating human-
friendly names. I agree with he and Stu - we should take no position on
the friendliness of names. If they can be made unique, persistent, and
location-independent, that should be good enough for us.

The narrative never makes a clear statement of the requirement. It only
appears in the summary.

(3.1.3) To support the development and deployment of pricing models to
        manage human behavior with respect to limited resources.
======================================================================
The NAPTR proposal allows fee-for-resolution systems to be deployed
using the access controls on resolvers. The details of such controls
are outside the bounds of the NAPTR spec. New namespces will almost
certainly incurr the $50/yr. domain name registration fee.

Notes:
This requirement is *far* too strong. Prices are not the only way to
control user behavior, assuming it needs to be controlled. This
requirement should say nothing stronger than resolvers not precluding
the possibility of payment being one of many possible controls on access
to resolution info.

3.2 Usability and Feature Set Requirements
3.2.1 (The publisher)

(3.2.1.a) URN to hint resolution must be correct and efficient
==============================================================
The NAPTR proposal supports the efficient location of resolvers
because of the highly caching nature of DNS. Correctness of that
information is provided by the normal operation of DNS. In cases
demanding unusually high guarrantees of correctness, the recent
DNSSEC work can be used to provide signatures on the NAPTR responses.

Efficiency of the resolvers themselves is outside the bounds of the
NAPTR spec, but the NAPTR spec does help in making efficient resolution
possible since it allows reslovers to be replicated through the use of
the SRV record.

Notes:
We have no definition of "efficient" and "inefficient" so it is
impossible to evaluate conformance to this requirement on an
objective basis. I'll engage in subjective arguments with the
best of 'em. You need an objective criteria to which you can point
and say "put up or shut up". 

(3.2.1.b) Publishers must be able to select among URN resolution services
          to locate their resources
=========================================================================
NAPTR directly supports this requirement through the use of the
"services" field and multiple NAPTR records.

Notes:
The narrative goes beyond the requirement summary and says that the
selection must be easy. How do we quantify that? The narrative also
imposes a requirement not in the summary, that changing resolution
services SHOULD NOT be expensive for the publisher. What is and is
not expensive? (Adding a new NAPTR record is not, in itself, an
expensive operation. What kind of fees might be imposed are impossible
for the spec to address).

(3.2.1.c) Publishers must be able to arrange for multiple access points
          for their location information.
=======================================================================
The NAPTR proposal supports multiple resolvers through the SRV record.

Notes:
The narrative and the summary are quite different. The summary says
"location information" while the narrative talks about "resources".
The narrative also says services SHOULD be prepared to tailor
responses based on the entity making the query and uses local
caches as an example.

The NAPTR proposal can accomodate these as well. Multiple locations
for resources is handled by the resolvers, but the details are
outside the bounds of the NAPTR spec. Tailored responses are also
a resolver problem, but can be handled using existing technology.

(3.2.1.d) Publishers must be able to provide for both long-lived
          and short-lived hints
================================================================
The NAPTR proposal allows for hint lifetime to be communicated
using DNS TTLs, or resolution-method-specific lifetime information.
(e.g. HTTP Expires: headers).

Notes:
The requirement seems to assume that a distinction must be drawn
between short-term and long-term hints. I do not see this as being
necessary. Is it not more important that publishers be able to
communicate the expected lifetime of a hint and we not impose some
artificial short/long distinction? Why not short/medium/long or
really-really-really short//////etc.

(3.2.1.e) It must be relatively easy for publishers to install and
          observer [sic] their hint information and any security
          constraints they need for their hints.
==================================================================

The NAPTR proposal meets this requirement. (well, I blush a *little*
when I say that, but I digress). Hint information held on resolvers
is outside the bounds of the NAPTR proposal, but we expect that the
hint information on resolvers will be held in databases that can be
maintained using normal practice. Access to those databases will be
through particular resolution protocols. Maintaining and monitoring
the security imposed by those resolution protocols is outside the
bounds of the NAPTR spec, and outside the bounds of the resolution
protocol specs as well.

The hint information within the bounds of the NAPTR spec are the
NAPTR resource records used to find resolvers. That information is
relatively small and is expected to not change frequently. Editing
zone files is not the job of the publisher, but of the managment,
so we will get to that part of the requirement later I'm sure.
Monitoring the correct provision of information can be easily
achieved, either through the use of nslookup or through the use
of ultra-friendly front ends around nslookup. (Recent work on
dynamic update will make the construction of ultra-friendly
front ends possible so direct zone file editing can be avoided).

Notes:
"relatively easy" is not quantifiable. Therefore, I don't blush
*too* much when I say that editing a zone file meets the requirement.

Isn't installation of hint info a requirement for the resolver managers,
not the publishers? publishers should be able to provide the necessary
info about new resources to the management, but they don't need to install
the hints themselves.

(3.2.2) Client requirements
Generic note - it took awhile for me to figure out that "client" meant
"user-agent", not "user". A change in terminology might be nice.

(3.2.2.a) The interface to the UDS must be simple, effective, and efficient.
============================================================================
The current NAPTR library has a simple, effective, and efficient interface.

Notes:
(OK, OK, proof by assertion is not a recognized logical technique. :-)
The API for out NAPTR library is pretty simple, init_resolution() and
get_next_resolver(). However, that API is outside the bounds of the NAPTR
spec. Any number of APIs could be developed that provide access to the
information from the NAPTR records. As I have been told repeatedly in
other contexts, the IETF rarely standardizes APIs. In this case I think
that is certianly the right policy, because I don't think we know enough
about the space of possible UDS systems to develop an API that will work
with all of them in a useful fashion. If we are not going to standardize
an API, I don't think we should be setting requirements on them.

(3.2.2.b) The client and client applications must be able to understand
          the information stored in and provided by the UDS, in order to
          be able to make informed choices.
========================================================================

The NAPTR proposal supports this requirement, since the results coming
back clearly indicate the services offered by a resolver and the protocol
necessary to communicate with the resolver.

Notes:
Shouldn't this really be a requirement on the resolvers rather than the
UDS? The HTTP Conventions approach would still meet it since results
are tagged with media types.

The last paragraph in the section on client requirements does not state
any requirements and might be moved to the assumptions section.

(3.2.2.c)
I would add a requirement that the info returned from the UDS to the client
(and the resolver to the client) must be capable of evolving over time without
the wholesale replacement of the UDS or resolution protocol.

(3.2.3) Management requirements
(3.2.3.a) The managment of hints must be as unobtrusive as possible,
          avoiding using too many network resources.
=====================================================================
Managing hints in NAPTR records is local to the zone containing that
record and is therefore unobtrusive.

Notes:
this seems kind of vague

(3.2.3.b) A pricing scheme may be necessary to provide not only cost
          recovery, but also social incentives and disincentives to
          encourage certain sorts of behavior deemed necessary to meet
          other requirements.
======================================================================

I've already addressed this in 3.1.3, haven't I?

Notes:
This is not a well-stated requirement. How about "resolution service
providers may use pricing schemes or other means of access control"?
I still think you are pushing too hard for pricing. It is a policy
issue, and the technical issues for UDS requirments are not to
preclude it.

(3.2.3.c) The configuration and verification of configuration of
          individual UDS servers must be simple enough not to
          discourage configuration and verification.
================================================================
It is possible to configure and verify NAPTR resource record information.

Notes:
How can I evaluate conformance to this requirement? My friends and I
can write NAPTR records and we can use our debug client to make sure
we get to the machine we think we are going to get to. Is that good
enough?

The last sentence of the narrative for this requirement imposes another
requirement - one that I urge you to remove. The sentance says: "[...]
encouraging volunteer participants REQUIRES that, as with the DNS, such
volunteers can feel confident about the service they are providing and
its benefit to both themselves and the rest of the community". How can
we evaluate conformance to such a requirement?

(3.3) Security and Privacy requirements

Oh boy. While there are other parts of the draft I don't like, I find
chunks of this section unacceptable. The requirements in this section
have the implicit effect of mandating a security policy across all URN
resolvers and UDS'. This policy will be too strong for some sites and
too weak for others. My most vociferous objection is to the last
sentence of the first paragraph: "Therefore we believe that the benefit
of providing integrity guarantees beyond those provided by the servers
themselves does not outweight the cost".

     You     can't     make      that      decision    for     me!

There are people at my site who are *very*
interested in integrity guarantees. I know because I have talked to them.
Whether they will remain interested
once they see the true cost is for *them* to decide. This requirements
document has no business requiring or precluding any security measures.
What it must do is operate under the assumption that there is some site
out there with NO security, and that vicious hackers have totally had
their way with that site. It must then be possible for sites that wish
to be totally paranoid about security to resolve a URN to the resource
in such a fashion that they can
   1) Be assured that it has not been compromised
or 2) Be able to determine that at least one of the steps in the
      resolution process can not be guranteed to be safe, and that
      any use of the resource is at their own risk.
That is all that can be done. Any attempt to mandate that all sites obey
some minimal level of security is flawed. Its an instance of the
"everyone is my friend" assumption.

This implicit establishment of the security policy that must be obeyed
by URN resolvers shows up in several other places. There are many
sentences where you say that something "must" exist which I would
like to change to saying "must be capable of supporting". For example
you say that "There needs to be an authoritative version of each hint,
and it must support change control limited only to those principals
with the right to modify it". I would prefer a different wording:
"Each resolution hint shall have an authoritative instance. It
must be possible to restrict changes to the authoritative hint
according to the security policy of the organization issuing the hint.
Propagation of changes to the authoritative version to any sites mirroring
it must be capable of being carried out in a fashion consistent with
the security policy governing the operation of the mirroring service."
(Actually, I would prefer something less awkward, but I digress. :-)

Its not that the former is hard to achieve, requiring root access to edit
a zone file meets the letter of the requirement. The problem is that it
precludes certain modes of operation. You and I may think that those modes
of operation are only for idiots, but we are not the ones making the
cost/benefit calculations.

I also disagree with some of your threat analysis. For example, you
are concerned about packet sniffers violating user's privacy and state
that it can be "combatted by anonymizing queries through a trusted,
fairly local gateway, although it involves an extra step and another
potential bottleneck". This becomes the requirement "Client privacy
is threatened by packet sniffing and server logging. It is desirable to
reduce these threats as much as possible".
The most likely scenario for snooping involves an
employer monitoring employee's traffic for appropriate use. So, the
people most likely to run the "anonymizing gateway" are the ones most
likely to be analyzing the requests. (I can point to at least one example
of an organization that monitors HTTP requests and does random sampling
of incoming GIFs for obvious reasons). Your requirement stating that it
is desirable to reduce such threats takes a position counter to the U.S.
legal precedent that employers have the right to do such monitoring.
That is one reason I keep harping on not mandating a security policy.
Whose side should we take on such an issue?

Anyway, since this message is already so long, and since I disagree so
strongly with the security requirements, I'm going to stop here. We can
iterate on the requirements a few times.

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

Date: Wed, 04 Dec 1996 12:00:58 -0700
To: [email-masked]
From: Ron Daniel <[email-masked]>
Subject: [URN] FPIs as a URN Namespace
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Hi,

At the Montreal BOF, I suggested FPIs (ISO Formal Public Identifiers)
as one of the namespaces that would be of interest for grandfathering
into the URN world. Recently I've started working on just how to
accomplish such a feat. Although I am not ready to issue an internet
draft of the subject, people may want to take a look at some notes
I've put together on the topic. They are at
  http://www.acl.lanl.gov/URN/FPI-URN.html
If time allows we may discuss this at the WG meeting next week.

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

From: [email-masked]
To: Ron Daniel <[email-masked]>
Cc: [email-masked]
Subject: Re: [URN] some more NAPTR edits
Date: Tue, 03 Dec 1996 23:25:51 +0100
Sender: [email-masked]
Reply-To: [email-masked]

Ron,
I think encrypted NAPTR records are a Bad Idea.
The reason is that I can't figure out where to put the information
about which key to use.

You may have to specify that the key is identified by the replacement
field, with the raw data in the regexp field, in which case the semantics
is different from "R", and you might as well make E exclusive with R.
or something else......key handling is the bane of encryption systems.

                  Harald A

From: [email-masked] (Leslie Daigle)
Date: Tue, 3 Dec 1996 17:43:46 -0500
To: [email-masked]
Subject: Re: [URN] Getting ready for next week's meeting...
Sender: [email-masked]
Reply-To: [email-masked] (Leslie Daigle)

Thanks to Ron for being eagle-eyed and catching the error -- he has been
involved in many of the drafts, but not all of them!

> 	. URN Framework and Requirements [Ron 15]

This should, of course, be

 	. URN Framework and Requirements [Karen 15]

Leslie.

-- 

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

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

From: [email-masked] (Leslie Daigle)
Date: Tue, 3 Dec 1996 16:56:24 -0500
To: [email-masked]
Subject: [URN] Getting ready for next week's meeting...
Sender: [email-masked]
Reply-To: [email-masked] (Leslie Daigle)

As some of the draft-editors have been asking about length of timeslots
on the agenda for next week's meeting, it seems a good time to propose
a refined view of that agenda and a Plan.

The refined view (with time assignments) is attached.  The basic plan is
to give everybody air time to discuss issues with individual drafts. 

Of course, since all attendees WILL have read the drafts (:-) I am
asking that draft-editors focus on preparing themselves for _issues_, and
not use their valuable time for reviewing material that should already
be familiar.

What I propose, then, is that each draft-editor arrive prepared with:

	. a _very_ brief overview of the draft 
	. a list of known issues with the draft
	. a list of proposed solutions to those issues (if any)
	. a sense of humour

What I think we can walk away from the meeting with is:

	. some proposed solutions to issues
	. a (hopefully finite) list of issues that remain to be addressed
	  with each draft
	. a plan for addressing the remainder of our chartered work
	  (i.e., documents, volunteers :-)

In order to make this all work smoothly, I suggest that, if you have
issues-as-yet-unaired with a particular draft, rather than harbouring them
until next week's meeting and springing them on unsuspecting editors, how
about at least listing them now?  (on the mailing list, or to the editors
directly).  There isn't a lot of time at the meeting, so if we can use
it for solid discussion instead of trying to reach understanding over
terminolory in describing issues, that would be great.

For starters, let me know if there are any comments on the proposed agenda...

Cheers!
Leslie.

----------------------------------------
IETF URN Working Group
----------------------------------------

Agenda for Thursday, December 12, 1996 (9h00-11h30), San Jose, California.

Status review:  [10 minutes]
	. Status of documents
	. Progress on WG milestones

Discussion of document-specific issues: [90 minutes]
	. URN Framework and Requirements [Ron 15]
	. URN Syntax [Ryan 15]
	. NAPTR proposal [Ron and/or Michael 15]
	. HTTP conventions [Ron 15]
	. General issues across drafts/flex time [30]

Where to go from here: [30 minutes] 
	. other issues
	. addressing remaining documents

-- 

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

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

Date: Sun, 1 Dec 1996 08:31:01 -0800 (PST)
From: Terry Allen <[email-masked]>
To: [email-masked]
Subject: [URN] Compliance in Framework draft
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

This message is about compliance requirements as stated in the
framework draft.

I think compliance requirements, clearly stated, are a good thing.
Compliance is mentioned several times, most notably in the two
sections excerpted below (it would be good to have a distinct section
specifically on compliance):

| Abstract:
| 
| This document addresses the issues of the discovery of local URN
| resolution services that in turn will directly translate URNs into
| URLs and URCs.  The document falls into three major parts, the
| assumptions underlying the work, the requirements in order to be a
| viable URN-resolution-service discovery service or UDS, and a
| framework for designing UDSs.  The requirements fall into three major
| areas: evolvability, usability, and security and privacy.  A UDS that
| is compliant with the framework will not necessarily be compliant with
| the requirements.  Compliance with the requirements will need to be
| validated separately.
 [ ... ]

| 4. The Framework
| 
| With these assumptions and requirements in mind, one can conclude with a
| general framework within which UDS designs will fall.  As stated
| earlier, although this framework is put forth as a suggested guide for
| UDS designers, compliance with it will in no way guarantee compliance
| with the requirements.  Such an evaluation must be performed separately.
| It is also understood that there may be UDS services that do not meet
| the requirements in clearly identified ways.  This may be true
| especially with early plans and experiments.  For example, although a
| careful threat analysis may have been done to understand security
| requirements, not all those security requirements may be addressed, in
| order to use existing facilities to allow for early deployment for
| experimentation purposes.  All such lack of compliance should be clearly
| documented.

It emerges from these sections that those offering UDSs should
document lack of compliance with the requirements, which I take to
be the bulletted items listed in extract form at the end of this
message.  Let's think about the requirements in the light of this 
compliance requirement.

How is a vendor to make meaningful comment on the following
(a short selection):

|    * To support the development and deployment of pricing models to
|      manage human behavior with respect to limited resources.

|       e) It must be relatively easy for publishers to install and
|          observer their hint information and any security constraints
|          they need for their hints.     

|       a) The management of hints must be as unobtrusive as possible,
|          avoiding using too many network resources;         

|    * Broad availability of servers will reduce the thread to denial
|      of service;       

Can I as a client or user expect to obtain useful information wrt
those points from a vendor's documentation?  I'd expect no more
than "yeah, we can do that" and "sure, our system is relatively
easy and unobtrusive".

When you think of it this way, does it not appear that many of
the requirements are desiderata for a well functioning Internet
in general, and need not be listed among the requirements for
UDSs specifically?

EXCERPTED LIST OF REQUIREMENTS 

| 3. Requirements
 [ ... ]

| 3.1 Evolution
 [ ... ]
| In summary, the requirements in the area of evolvability are:
| 
|    * To support evolution of mechanisms, specifically for
|       a) a growing set of URN schemes;
|       b) new local URN resolution schemes;
|       c) new authentication schemes;
|       d) alternative UDS schemes active simultaneously;
|    * To support and encourage the evolution toward the separation of
|      global identification from short-lived, locally useful, or human
|      friendly semantics;
|    * To support the development and deployment of pricing models to
|      manage human behavior with respect to limited resources.
| 
| 3.2 Usability and Feature Set Requirements
 [ ... ]
| To summarize, the usability requirements fall into three areas based on
| participation in hint management and discovery:
| 
|    * The publisher
|       a) URN to hint resolution must be correct and efficient;
|       b) Publishers must be able to select among URN resolution
|          services to locate their resources;
|       c) Publishers must be able to arrange for multiple access points
|          for their location information;
|       d) Publishers must be able to provide for both long-lived and
|          short-lived hints;
|       e) It must be relatively easy for publishers to install and
|          observer their hint information and any security constraints
|          they need for their hints.
|    * The client
|       a) The interface to the UDS must be simple, effective, and
|          efficient;
|       b) The client and client applications must be able to understand
|          the information stored in and provided by the UDS, in order
|          to be able to make informed choices.
|    * The management
|       a) The management of hints must be as unobtrusive as possible,
|          avoiding using too many network resources;
|       b) A pricing scheme may be necessary to provide not only cost
|          recovery, but also social incentives and disincentives to
|          encourage certain sorts of behavior deemed necessary to meet
|          other requirements;
|       c) The configuration and verification of configuration of
|          individual UDS servers must be simple enough not to
|          discourage configuration and verification.
| 
| 3.3 Security and Privacy Requirements
 [ ... ]
| trusts it not to be compromised.  We can turn each of these into a
| security goal.
| 
| * ACCESS CONTROL ON HINTS: There needs to be an authoritative version of
|   each hint, and it must support change control limited only to those
|   principals with the right to modify it.  The choice of who those
|   principals are or whether they are unlimited must be made by the
|   publisher of a hint. 
| 
| * SERVER AUTHENTICITY: Servers and clients must be able to learn the
|   identity of the servers with which they communicate.  This will be a
|   matter of degree and it is possible that there will be more
|   trustworthy, but less accessible servers, supported by a larger
|   cluster of less authenticatable servers that are more widely
|   available.  In the worst case, if the client receives what appears to
|   be invalid information, the client should assume that the hint may be
|   inaccurate and confirmation of the data should be sought from more
|   reliable but less accessible data.
| 
| * SERVER DISTRIBUTION: Broad availability will provide resistance to
|   denial of service.  It is only to the extent that the services are
|   available that they provide any degree of trustworthiness.  In
|   addition, the distribution of services will reduce to vulnerability
|   of the whole community, by reducing the trust put in any single
|   server.  This must be mitigated by the fact that to the extent trust
|   is based on a linked set of servers, if any one fails, the whole
|   chain of trust fails; the more elements there are in such a chain,
|   the more vulnerable it may become.
 [ ... ]
| In summary, security and privacy requirements can be identified as some
| degree of protection from threats:
| 
|    * It must be possible to create authoritative versions of a hint
|      with access to modification privileges controlled;
|    * It must be possible to determine the identity of servers or avoid
|      contact with unauthenticated servers;
|    * Broad availability of servers will reduce the thread to denial
|      of service;
|    * Client privacy is threatened by packet sniffing and server
|      logging.  It is desirable to reduce these threats as much as
|      possible;
|    * It should be feasible for publishers to keep private certain
|      information such as an overall picture of the resources they are
|      publishing and the identity of their clients;
|    * Publishers should be able to restrict access to the resolution of
|      the URNs for the resources they publish, if they wish.

Regards,