Re: date in URN

Karen Sollins:
| There are several different things we need to be able to do.  Human
| friendly names need to be short, nmemonic, probably limited in scope,
| reusable, etc.  You and I both may have things we like to call
| "my-address-book".  They identify different objects in different human
| friendly naming contexts, but they have the same name at one level of
| abstraction.  Somewhere below that level of abstraction we have a need
| in the global net for globally unique identifiers.  I believe that
| we've perpetuated a slight mistake in the URI WG by calling these
| things URNs ("names") because too people assume that a name has to be
| human friendly.  These things should be as human unfriendly as we can
| get away with, to discourage their direct use by humans.  They are
| serving a different purpose at a different level of abstraction than
| human friendly names.

This contradicts RFC 1737; was that what you meant?

   o Human transcribability: For URNs to be easily transcribable by
     humans without error, they should be short, use a minimum of
     special characters, and be case insensitive. (There is no strong
     requirement that it be easy for a human to generate or interpret a
     URN; explicit human-accessible semantics of the names is not a
     requirement.)  For this reason, URN comparison is insensitive to
     case, and probably white space and some punctuation marks.

URNS that are deliberately unfriendly will generate higher rates
of error in transcription.  (And it seems to me that case might actually 
help reduce error.)

I would be happy to trash this clause, too; uniqueness, legacy,
and comparison are the points in RFC 1737 I see as most important.


Terry Allen  (   O'Reilly & Associates, Inc.
Editor, Digital Media Group    101 Morris St.
			       Sebastopol, Calif., 95472

A Davenport Group sponsor.  For information on the Davenport 
  Group see

Received on Friday, 23 June 1995 18:32:29 UTC