Subject: Re: [URN] some comments
From: Ron Daniel <[email-masked]>
To: "Karen R. Sollins" <[email-masked]>, [email-masked]
Date: Thu, 31 Oct 1996 17:33:19 -0700

Thus spoke Karen R. Sollins (at least at 07:02 PM 10/29/96 -0500)

>Now, my one other comment relates to an earlier topic - security.  I
>am in complete agreement with Ron (and whoever else) who said that
>security (and let's make sure we include integrity of the information
>in "security") that no one (user or publisher) should be required to
>support security and integrity.  But...if the infrastructure
>supporting URN resolution (which IS the topic of discussion for this
>WG) is to be able to provide security and integrity for anyone, there
>may be some requirements it will place on its clients (users and
>publishers).  I would like to be confident that we are all in
>agreement about the following: in the case where there are security
>measures that must be in place within the infrastructure in order to
>provide security (at some agreed upon level) to those who want it,
>even if that imposes some security requirements on those who don't
>want it, that the choice of having the security mechanisms in place
>will take precedence over not have the mechanisms.  Of course, within
>that constraint, wherever security isolation can be provided, security
>mechanisms should NOT be required.

To paraphrase:
  1) Karen agrees that we should not *require* users or publishers to
     support security
but
  2) If the resolution infrastructure is such that no-one can enjoy a
     high level of security unless some requirements are placed on all
     participants of the system
then
  3) We should go for requiring modest levels of security on all participants
     rather than precluding people from operating as securely as they want.

I totally support the goal of allowing people to have high security if
they want it. That is why I am in total, adamant, and unequivocal
opposition to the assumption in part 2 - that there might be a URN
resolution system with such poor isolation between security domains.

I work at a place that is willing to spend lavishly on securing
our information. Call us cowards, but we are unwilling to rely on the good
will of millions of people around the world and the correct configuration
of their machines. We are not alone in this fear. Consider Cogswell Cogs
and Spacely Sprockets. Should either be willing to rely on the good behavior
of their mortal competitor?

A URN resolution system that can only achieve high levels of security for
some sites and the parties to their security policy by assuming *any*
security at sites outside that policy is broken. It is unprotected
against insider attacks, because it makes everyone in the world an insider.
You can't assume that all the systems around the world are participating in
some friendly alliance. You have to assume that those people may be out
to get you.

Let's take the case of client software and integrity checking. Lets assume
I am ParanoidPublishers, Inc. who will, with probability 99.9%, only give
out the URLs for my
publications to clients who can validate my signature on the URLs. That's
my policy. SubversiveClients, Ltd. puts out a browser that says to me
"sure, I do signature validation, you betcha". Should I believe them?
I should send them a test and say, "Great, then you won't mind looking
at these 10 URLs, each with a different signature, trying to validate
them all, and then contacting the resolver that is at the only
URL signed with my real key. BTW, all the other URLs set off an automated
counter-attack". At the "real" resolver, the probability of the client
lying to you is now 1 in 10. Repeat the process to make the probability 1
in 100, then 1 in 1000.

Happy Halloween,

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: "Ryan Moats" <[email-masked]>
To: "Gregory J. Woodhouse" <[email-masked]>, "Martin J Duerst" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Thu, 31 Oct 96 14:56:43 
Priority: Normal
Subject: [URN] UTF-8/ASCII (was: New Syntax Draft)
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Thu, 31 Oct 1996 05:54:38 -0800 (PST), Gregory J. Woodhouse wrote:

>On Thu, 31 Oct 1996, Martin J Duerst wrote:
>
>> Gregory Woodhouse wrote:
>> 
>> This difference is always absolutely clear! A string that only contains
>> bytes with the high bit '0' (7-bit bytes) is ASCII. As soon as a high
>> bit is set to '1', it's not ASCII anymore. It may be UTF-8, or may not.
>>
>I understand this point, but I'm not talking about UTF-8 itself, but UTF-8
>encoded into ASCII.

At the risk of being obvious, any UTF-8 encoded to ASCII (according to
the syntax doc) is going to have a leading octet encoded as something
in the %80-%FF range.  Anything in the %00-%7F range is an unsafe
(based on one definition or another) ASCII character.

However, I think this is somewhat moot (I think this argues for removing
the UTF-8 decoding requirement.)

Ryan

Date: Thu, 31 Oct 1996 12:51:48 -0800 (PST)
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Names and Locations (was [URN] some comments)
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

|  > > You made the curious statement that URNs identify resources while URLs
|  > > identify locations.  I'm not sure whether that was a slip, but to my
|  > > mind, a URL *IS* a location that identifies a resource.  Now you also
|  > URLs identify a particular location for a resource.
| OK, what is a location?  Is it the bits on the disk that "has" the
| resouce?  (The disk might be shared by many servers, so the resource
| has a different "location" for each server.) Is it the server running
| at a particular IP address and port, that may share many disks with
| other servers?  (The server may be a virtual server that runs on many
| machines, and the particular IP address is irrelevant.)  Is it the
| domain name of the server, together with the path within the server?
| That's getting closer to the abstraction that URLs provide.  Is the
| location, in fact, the URL itself?

No, the URL is neither the location nor the resource, but the
name of a location, or a name of a location that may be resolved
on the fly.  The location is not the resource; the name of the
location is not the name of the resource.

| Consider caches.  The resolution of a URL via a cache proxy may find
| the resource in the cache rather than in some remote server.  What is
| "the location" of the resource in that case?

What is "the resource"?  Any copy of what you got back from resolution?
then its location is both in the cache and on the remote server.
Is it "the copy I got back from resolution"?  then its location
is in the cache.

| Here is an example of how what is thought of as a location really
| turns out to *be* a name (as in persistent location).  Take a normal
| http URL such as http://www.ncsa.uiuc.edu/.  Instead of using normal
| HTTP to resolve the URL, or to look it up in a cache, let's set up a
| NAPTR-based "http" naming authority.  Under that branch of the name
| space, we could ask the appropriate DNS server to look up
| 'www.ncsa.uiuc.edu' to find out where a server is currently located
| and what "resolution protocols" are currently supported.

That is a coincidence of naming:  you made the name of the resource
(qua URN) be the same as the name of its location.  But 
   urn:http://www.ncsa.uiuc.edu/ 
and 
   url:http://www.ncsa.uiuc.edu/
name two different things.

| We don't need to create a new kind of identifier to make a URL into a
| persistent location.  

Which is not what you did in the example just given.  You created
a new name space and rules for using it that by design produce
a name that looks like a URL which, when resolved, will give the
same result.

| To summarize, both URLs and URNs have the following abstract
| resolution process in common:
| 1. Do some client-specific processing of the URI - maybe end there.
| 2. Look at the scheme name of the URI.  If it says "URN:" drop it and repeat.

No, you have to branch into your "find URN" subprocess.  

| 3. Look up the scheme in local table to find out what process should

The local table will be different for URLs and URNs, will it not?  

|    be invoked.  E.g. news URIs may use NNTP, http URIs may use HTTP,
|    cid URIs may use NAPTR-protocol.
| 4. Invoke the process identified by step 3. 
| 5. If error results, exit.
| 6. If redirected to another URI, repeat whole process with that URI.
| 
| An alternative to steps 2 and 3 would use more than just the scheme
| name to determine what process to invoke.  There are several other
| varients possible in the whole process, and each client or each user
| might do things differently.
| 
| I hope I've made my postion very clear regarding names, locations, and
| the resolution process.

That you see no difference between objects and their locations?

(apologies for the "ig" subject line in a previous post)

    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

From: "Ryan Moats" <[email-masked]>
To: "Gregory J. Woodhouse" <[email-masked]>, "Martin J Duerst" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Thu, 31 Oct 96 14:52:22 
Priority: Normal
Subject: [URN] More on UTF-8 Decoding (was: New syntax draft)
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Thu, 31 Oct 1996 14:38:57 +0100 (MET), Martin J Duerst wrote:

>Gregory Woodhouse wrote:
>
>>I'm also concerned because decoding requires knowledge that the string
>>being decoded is UTF-8.
>
>Not exactly. It is very rare that a string that is not UTF-8 looks
>like an UTF-8 string.
>
>>I said before that I wasn't terribly excited about
>>using RFC 1522 style encodings,
>
>Me neither! "charset" is okay for long mails, and RFC 1522 was unavoidable
>at the time it was created, but now we have better solutions.
>

I think this is a good argument for taking UTF-8 decoding out
of the syntax document.  Any reasons to leave it in?

Ryan

From: "Ryan Moats" <[email-masked]>
To: "Gregory J. Woodhouse" <[email-masked]>, "Martin J Duerst" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Thu, 31 Oct 96 14:49:42 
Priority: Normal
Subject: [URN] What is %encoding (was: New syntax draft)
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Thu, 31 Oct 1996 05:15:43 -0800 (PST), Gregory J. Woodhouse wrote:

>By %encoding I assume you mean hex encoding of non-ASCII or non-safe bytes.
>Is there an official name for this encoding scheme? I've seen it called URL
>encoding, but that hardly seems satisfactory.

%encoding refers to %HH encoding of octets.  I do make this point in section 1.2.
As to the name, I've had it referred to as "%encoding" in several pieces of mail to me,
so that is what I'm using.  If somebody has a better name that is acceptable to
folks, I'll be happy to change it.

Ryan

From: "Ryan Moats" <[email-masked]>
To: "Martin J Duerst" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Thu, 31 Oct 96 14:29:20 
Priority: Normal
Subject: Re: [URN] New syntax draft (was: no subject)
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Thu, 31 Oct 1996 11:58:35 +0100 (MET), Martin J Duerst wrote:

>>   It should be noted that certain characters in the Namespace Specific
>>   String syntax may have special meaning in certain namespaces.
>>   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.
>
>Can they be encoded with %HH? Or should we specifically request some
>other mechanism in order to not confuse different things, and let
>programs that deal with URNs in general change from %HH to 8-bit
>and back?

Well, I don't have a current opinion one way or the other.  Thinking about
it some more, I don't see how we can avoid %HH encoding, so why not
just say that encoding must be specified if %HH isn't used.

Ryan

From: "Ryan Moats" <[email-masked]>
To: "Martin J Duerst" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Thu, 31 Oct 96 14:27:15 
Priority: Normal
Subject: [URN] UTF-8 Decoding (was New syntax draft)
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

I've found some time to answer this (at least in part...)

On Thu, 31 Oct 1996 11:58:35 +0100 (MET), Martin J Duerst wrote:

>>   URN resolvers MUST be capable of accepting URNs that have been
>>   %encoded for either 8-bit clean or 7-bit transports.  %encoding is
>>   removed first, then UTF-8 decoding is performed.  URN resolvers MUST
>>   return identical results from ANY legally encoded form of the URN.
>
>I wonder about UTF-8 decoding. It somehow implies that resolvers
>work with Unicode internally, which would be fine, but is not
>necessary. For database lookup and equality checks, staying with
>UTF-8 will also be okay. For things such as regular expressions,
>some additional definitions are necessary as to what the regular
>expressions are working on (i.e. characters or octets), but still
>it could work in UTF-8.
>
>Also, what does UTF-8 decoding mean for an NSS that is not UTF-8?

That is an interesting point.  Let me go back and think about it.  Maybe
we can remove this requirement.  We talk about equivalency at the UTF-8 level
later so maybe we can remove the reference to UTF-8 decoding here...

Ryan

Date: Thu, 31 Oct 1996 13:21:59 -0700
To: Daniel LaLiberte <[email-masked]>, Larry Masinter <[email-masked]>
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] HTTP resolution protocol
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke Daniel LaLiberte (at least at 03:30 PM 10/30/96 -0600)
>Larry Masinter writes:
> > I think some people would say that
> > 
> >     GET <service>/<uri>  HTTP/1.0
> > 
> > is not valid HTTP.
>
>I was wondering about that.  Maybe Ron meant:
>
>  GET /<service>/<uri>  HTTP/1.0

My mistake, I should have had the initial "/".

> > New services need new methods.

I have had some off-list mail about defining new HTTP methods
for the various resolution service requests (N2C is the most
frequent suggestion, but any of them could be handled this way).

The draft did not clearly state my goal for the http resolution protocol,
which was to have something that could be very easily deployed for
initial tests. Backward compatability with existing servers was a goal.
I wanted something where people could either add a script to their
cgi-bin directory or even just create a new directory and plop files into it.

It may be that the rest of the list thinks such a goal is inappropriate.
Certainly there is the potential for conflict if a site already had
"N2L" in its URLs.  (Although an AltaVista search for url:N2L didn't
find anything).

A possible compromise position is:

1) N2R is encoded as GET uri, not GET /N2R/uri
2) new HTTP methods are defined for other resolution service requests,
   so we would issue requests like
      N2C  uri  HTTP/1.x
   (versioning of the HTTP protocol may be an issue here).
3) N2L is treated as a special case because of its importance
   and is still encoded as GET /N2L/uri  HTTP/1.0   (or 1.1)

Opinions?
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: Thu, 31 Oct 1996 13:22:00 -0700
To: Terry Allen <[email-masked]>, [email-masked]
From: Ron Daniel <[email-masked]>
Subject: [URN] Re: ig
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke Terry Allen (at least at 11:52 AM 10/31/96 -0800)

>That's good, but I can't find any way to use Accept: to limit
>the absolute number of resources that the client is willing
>to receive.  Have I missed it?

No, Accept: was intended to be used for returning one and only one
version of a resource. N2Rs is rather strange for HTTP, so none of
its headers are going to be intended for such a context. (But they
accomodate it easily, 200 OK is still 200 OK).

>An image library might have scads of GIFs of the same object:
>the Parthenon in 1932, the P in 1964, the P at sunrise, the P
>under moonlight ... but it will be difficult to know in advance
>how to twiddle the Accept: information so as not to be inundated
>by Parthenons in response.

They may have lots of images of the same object, but I doubt that
those images will have identical URNs.

More likely is where we have something like a Kodak PhotoCD with
the same image at different resolutions. N2Rs would return a
multipart with all those different resolutions.

>  Or maybe that's okay and users should
>be warned that they may get more than the bargained for when they
>use N2Rs?

That's my attitude, but then I tend toward the "let them shoot their
foot off" approach.

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: Thu, 31 Oct 1996 13:51:04 -0600 (CST)
From: Daniel LaLiberte <[email-masked]>
To: [email-masked] (Leslie Daigle)
Cc: [email-masked]
Subject: Re: Names and Locations (was [URN] some comments)
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Leslie Daigle writes:
 > > In general, each scheme, whether for a URL or URN, should be
 > > associated with some resolution protocol.  
 > 
 > I'm not sure I'm clear on what you're getting at here, and even if
 > we do agree, I think there is some potential for the above to be a
 > bit misleading.

I'll try to be more clear below.  If URLs and URNs are to be in the
same name space of URI schemes, then we need to talk about them as the
same kind of thing.  This is not only possible, it is correct.

BTW, emphasis in the following is not shouting.  I'm very calm, now.

 > The point of the indirection in the URN naming is to abstract the
 > (final) resolution protocol so that no name space is specifically
 > associated with, say, HTTP, or Whois++.  THe idea is that any URN
 > can be resolved using different protocols -- at one time, or at
 > different stages in its lifetime -- and this is a separate process
 > from determining the URN identifier string.

This illustrates why I think the term "resolution protocol" is
confusing.  I mean something different than you and others do - and
you qualified it parenthetically by saying "the (final) resolution
protocol".  More below.

 > However, there is a general mechanism for handling URNs to the
 > extent of extracting Naming Authority, etc etc etc, which is
 > standard across the URNs we define here.

My point is that this mechanism for looking up the naming authority
etc, as defined by the NAPTR spec (or other such specs), is only
*part* of the WHOLE RESOLUTION PROCESS.  (Calling it a "resolution
process" may avoid the "protocol" issue, but it is not that simple, as
I argued in previous mail.)  The first part of the whole resolution
process involves how you talk to DNS servers to lookup the naming
authority etc.  Note: HOW YOU TALK TO DNS IN THIS PARTICULAR WAY *IS*
A PROTOCOL.  If you like, it is a protocol layered on top of the raw
DNS protocol.  Note also that it is this lookup process that makes
URNs into locations; You LOOK UP URNs starting AT A PARTICULAR
LOCATION which is the root of the name space (urn.net or wherever).
(Actually, just as for URLs, you can lookup up the very same URNs
in different ways - see below.)

Another part of the process is using the result of the first part,
specifically the list of what is being called "resolution protocols".
The client may then select one of these "resolution protocols" to
continue with the resolution process.  But note that this is not
necessarily the end of the whole process.  A resolution service might
return an indirection to yet another URI, so the resolution process
continues until you have what you want, whether that is the resource
originally identified or some information about it, or you get an
error.

There may be other parts of the resolution process that are used 
*before* looking up naming authorities, such as trying to resolve
the whole identifier from a local cache, or from a more global cache.
It may not be necessary to do some of the above steps in the resolution
process depending on what is found elsewhere via other protocols.

Many protocols are involved in this whole resolution process, and to
say that only some are the "resolution protocols" obscures the truth
and so is misleading.

 > > You made the curious statement that URNs identify resources while URLs
 > > identify locations.  I'm not sure whether that was a slip, but to my
 > > mind, a URL *IS* a location that identifies a resource.  Now you also
 > 
 > URLs identify a particular location for a resource.

OK, what is a location?  Is it the bits on the disk that "has" the
resouce?  (The disk might be shared by many servers, so the resource
has a different "location" for each server.) Is it the server running
at a particular IP address and port, that may share many disks with
other servers?  (The server may be a virtual server that runs on many
machines, and the particular IP address is irrelevant.)  Is it the
domain name of the server, together with the path within the server?
That's getting closer to the abstraction that URLs provide.  Is the
location, in fact, the URL itself?

Consider caches.  The resolution of a URL via a cache proxy may find
the resource in the cache rather than in some remote server.  What is
"the location" of the resource in that case?

Here is an example of how what is thought of as a location really
turns out to *be* a name (as in persistent location).  Take a normal
http URL such as http://www.ncsa.uiuc.edu/.  Instead of using normal
HTTP to resolve the URL, or to look it up in a cache, let's set up a
NAPTR-based "http" naming authority.  Under that branch of the name
space, we could ask the appropriate DNS server to look up
'www.ncsa.uiuc.edu' to find out where a server is currently located
and what "resolution protocols" are currently supported.

We don't need to create a new kind of identifier to make a URL into a
persistent location.  We *do* need new persistent services, such as
the NAPTR records in DNS.

How a URL is processed determines where the resource is really found,
and the very same URL could be processed many different ways and the
resource found many different places.

And besides all that, a URL can be used to find other things
associated with the resource, by completely different means, such as
annotations or censorship ratings.  The URL identifies all those
things too, depending on how the URL is processed.

The tight binding between http URLs and the HTTP protocol is an
illusion created by frequent reinforcement and a transparent
resolution process.  (Similarly, many people feel they "visit" a web
page, rather than bring a copy of the page back to their browser.)

To summarize, both URLs and URNs have the following abstract
resolution process in common:

1. Do some client-specific processing of the URI - maybe end there.
2. Look at the scheme name of the URI.  If it says "URN:" drop it and repeat.
3. Look up the scheme in local table to find out what process should
   be invoked.  E.g. news URIs may use NNTP, http URIs may use HTTP,
   cid URIs may use NAPTR-protocol.
4. Invoke the process identified by step 3. 
5. If error results, exit.
6. If redirected to another URI, repeat whole process with that URI.

An alternative to steps 2 and 3 would use more than just the scheme
name to determine what process to invoke.  There are several other
varients possible in the whole process, and each client or each user
might do things differently.

I hope I've made my postion very clear regarding names, locations, and
the resolution process.

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

Date: Thu, 31 Oct 1996 11:52:21 -0800 (PST)
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: [URN] ig
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

Ron writes:
| >| 3.4  N2Rs (URN to Resources):
| >| This resolution service returns multiple instances of a resource,
| >| for example, GIF and JPEG versions of an image. The judgment about
| >| the resources being "the same" resides with the naming authority that
| >| issued the URN.
| >
| >All the instances that suit the Accept info the client has sent?
| >Does that leave us with nothing between asking for one instance
| >(N2R) and all (N2Rs), or is there some way to quality the request
| >so that one receives no more than, say, 13 instances?  (Happy
| >Halloween!)
| 
| I will add some words to the effect that the resolver MAY restrict
| the resources returned to those that match the Accept: header.

That's good, but I can't find any way to use Accept: to limit
the absolute number of resources that the client is willing
to receive.  Have I missed it?  Is this perhaps an issue for HTTP and 
not this group?

An image library might have scads of GIFs of the same object:
the Parthenon in 1932, the P in 1964, the P at sunrise, the P
under moonlight ... but it will be difficult to know in advance
how to twiddle the Accept: information so as not to be inundated
by Parthenons in response.  Or maybe that's okay and users should
be warned that they may get more than the bargained for when they
use N2Rs?

Regards,

Date: Thu, 31 Oct 1996 12:48:25 -0700
To: "Gregory J. Woodhouse" <[email-masked]>, Fisher Mark <[email-masked]>
From: Ron Daniel <[email-masked]>
Subject: RE: [URN] HTTP resolution protocol
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke Gregory J. Woodhouse (at least at 11:10 AM 10/31/96 -0800)

>It seems to me that we should follow the same model as other requests and
>use the status code to indicate a(n) (un)successful resolution and then use
>the entity-body to provide either explanatory text or hyperlinks for old
>browsers.

For the most part, this is what I intended. I need to be more explicit on
the Status codes that can be returned from successful or unsuccessful
resolution attempts.

One place where we seem to differ slightly is on the entity-body.
I certainly think that it should be used most of the time. The one place
where I think we should make an exception is the N2L request. If the
new URL is returned in the Location: header, clients will automatically
fetch the resource. If it is returned in the body, we get into the "click
twice to access" model, which is a real pain in the rear.

I will try to be more explicit on the various Status codes that should
be returned.

>Status 303 See Other seems a natural for our purposes--at least
>N2L resoulution.

Agreed, but it doesn't appear in my copy of RFC 1945 - the HTTP/1.0
spec. It is in the 1.1 spec, which is why I said it should be returned
there.

>For N2R resolution it would seem desirable to return the
>entire resource in the entity-body,

That is my intent, but I suppose I can try to tighten up my wording.
"standard HTTP mechanisms" was used to cover all the Content-type,
Status, ... material.

> and for N2Rs, I'd like to see a
>multipart/mixed or multipart/alternative entity containing each resource.

Right. Here again I should be more precise. I said "multipart", I think
"multipart/alternative" is probably the way to go.

>Here, I'm a little unsure as to the best status code. One possibility is
>200 OK for N2R, but I don't know about N2Rs.

I think that as long as at least one version of a resource can be returned,
200 OK is the way to go for both N2R and N2Rs.  There is the case to consider
where we ask N2Rs but only one resource can be returned. Do we need
to wrap it in a multipart even though there is only one part? I think not
but don't have strong feelings on the subject.

>Another question I have is
>whether there should be any indication tht the content was returned as a
>result of URN resolution. If so, a new status code may be necessary. 

Is there any need to make such a distinction?
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: Thu, 31 Oct 1996 12:48:26 -0700
To: Fisher Mark <[email-masked]>
From: Ron Daniel <[email-masked]>
Subject: RE: [URN] HTTP resolution protocol
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke Fisher Mark (at least at 01:44 PM 10/31/96 EST)
[...]
Mark asks "why text/plain instead of text/html or a new media type"?

No really good reason, I'm afraid.

How about:
   1) We define text/uri-list as a new media type?
   2) We allow the Accept: header to be used to pick between returning
      the result as text/html or text/uri-list.

I think that the primary use of the lists will be for automated processing,
thus the new media type allows us to launch those content handlers easily.
Clients that don't support text/uri-list have a fallback that will allow
humans to pick URI if necessary. New clients of the agent variety should
use text/uri-list.

Sound OK to you? If so I will add it to the draft, and also a note that
recommends when HTML is returned that the items look like
<UL>
<LI><A HREF="...new URI...">...new URI</A>
<LI>...
</UL>
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: Thu, 31 Oct 1996 12:21:04 -0700
To: Terry Allen <[email-masked]>, [email-masked]
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] HTTP resolution protocol
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke Terry Allen (at least at 10:37 AM 10/31/96 -0800)
>A few comments, mostly re coordination with the Framework document:
>
>| 3.1  N2L (URN to URL):
>| The request is encoded as above. The URL MUST be returned in a Location:
>| header for the convienience of the most common case of wanting the resource.
>| A 30X status line SHOULD be returned. HTTP/1.1 clients should be sent the
>| 303 status code. HTTP/1.0 clients should be sent the 302 (Moved temporarily)
>| status code unless the resolver has particular resons for using 301
>| (moved permanently) or 304 (not modified) codes.
>
>It would be nice to have a brief explanation of why these are
>the right responses, perhaps recapping what will be in the
>Framework document.

No commitments on this one, but I will see what we can do.

>|                Simple format for returning multiple URLs
>| 
>| [Do we need to have a continuation character for *very* long lines? 
>|  I tend to think not.]
>
>Might be useful; there will be a significant proportion of long lines.

Right, but that does not mean that the long lines have to be broken.
I am unaware of any line length limitation for text/plain bodies.
If we don't break the lines, things are simpler.

>| 3.4  N2Rs (URN to Resources):
>| This resolution service returns multiple instances of a resource,
>| for example, GIF and JPEG versions of an image. The judgment about
>| the resources being "the same" resides with the naming authority that
>| issued the URN.
>
>All the instances that suit the Accept info the client has sent?
>Does that leave us with nothing between asking for one instance
>(N2R) and all (N2Rs), or is there some way to quality the request
>so that one receives no more than, say, 13 instances?  (Happy
>Halloween!)

I will add some words to the effect that the resolver MAY restrict
the resources returned to those that match the Accept: header.

>| 3.6  N2Ns (URN to URNs):
>| ------------------------
>| 
>| While URNs are supposed to identify one and only one resource, that
>| does not mean that a resource may have one and only one URN. For
>| example, consider a resource that has something like
>| "current-weather-map" for one URN and "weather-map-for-datetime-x" for
>| another URN. The N2Ns service request lets us obtain lists of URNs that
>| are believed equivalent at the time of the request. As the weathermap
>
>The example implies, "lists of URNs that are believed to name equivalent
>resources at the time of the request", which agrees with the language
>in the next para.

Right. I will change the wording to be more precise.

>| 3.8  L2Ls (URL to URLs):
>| ------------------------
>| 
>| The request is encoded as described above. The result is a list of
>| all the URLs that the resolver knows are associated with the resource
>| located by the given URL. It is returned in a text/plain body encoded
>| as described above.
>
>"Associated" is awfully broad.  The Framework document will clear up
>what associations are intended, right?

Using "associations" was a mistake on my part. The intent here is that
we return the locations of equivalent resources, analogous to the N2Ns
request.
 
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: Thu, 31 Oct 1996 11:10:52 -0800 (PST)
From: "Gregory J. Woodhouse" <[email-masked]>
To: Fisher Mark <[email-masked]>
Cc: Ron Daniel <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [URN] HTTP resolution protocol
Sender: [email-masked]
Reply-To: "Gregory J. Woodhouse" <[email-masked]>

It seems to me that we should follow the same model as other requests and
use the status code to indicate a(n) (un)successful resolution and then use
the entity-body to provide either explanatory text or hyperlinks for old
browsers. Status 303 See Other seems a natural for our purposes--at least
N2L resoulution. For N2R resolution it would seem desirable to return the
entire resource in the entity-body, and for N2Rs, I'd like to see a
multipart/mixed or multipart/alternative entity containing each resource.
Here, I'm a little unsure as to the best status code. One possibility is
200 OK for N2R, but I don't know about N2Rs. Another question I have is
whether there should be any indication tht the content was returned as a
result of URN resolution. If so, a new status code may be necessary. 

---
Gregory Woodhouse     [email-masked]
home page:            http://www.wnetc.com/
resource page:        http://www.wnetc.com/resource/

From: Fisher Mark <[email-masked]>
To: Ron Daniel <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [URN] HTTP resolution protocol
Date: Thu, 31 Oct 96 13:44:00 EST
Encoding: 32 TEXT
Sender: [email-masked]
Reply-To: Fisher Mark <[email-masked]>

In sections 3.2 ("N2Ls (URN to URLs)"), 3.6  ("N2Ns (URN to URNs)"), 3.7 
 ("L2Ns (URL to URNs)"), and 3.8  ("L2Ls (URL to URLs)"), the entity body 
returned is of Internet Media Type type text/plain, and therefore is not 
directly usable by the current crop of UAs, but the other resolution 
services return responses or entity bodies that are directly usable.  Why 
was text/plain chosen instead of a simple HTML list?  As an example (drawn 
from draft-daniel-http-00.txt section 3.2):

<HTML>
<HEAD><TITLE>N2Ls Resolution of <URN:cid:[email-masked]></TITLE></HEAD>
<BODY>
<H1>N2Ls Resolution of <URN:cid:[email-masked]></H1>
<UL>
<LI><A 
HREF="http://www.huh.org/cid/foo.html">http://www.huh.org/cid/foo.html</A></  
LI>
<LI><A 
HREF="http://www.huh.org/cid/foo.pdf">http://www.huh.org/cid/foo.pdf</A></LI>
<LI><AHREF="ftp://ftp.foo.org/cid/foo.txt">ftp://ftp.foo.org/cid/foo.txt</A>  
</LI></UL>
</BODY>
</HTML>

Since we already have the tools to deal with HTML, why resort to text/plain? 
 Or, like in section 3.5  ("N2C (URN to URC)"), why not assign an Internet 
Media Type to the response, so that UAs can know that the response is not 
just some random message?
======================================================================
Mark Leighton Fisher                   Thomson Consumer Electronics
[email-masked]                   Indianapolis, IN

Date: Thu, 31 Oct 1996 10:37:00 -0800 (PST)
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [URN] HTTP resolution protocol
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

A few comments, mostly re coordination with the Framework document:

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

It would be nice to have a brief explanation of why these are
the right responses, perhaps recapping what will be in the
Framework document.

|                               Figure 1
|                Simple format for returning multiple URLs
| 
| [Do we need to have a continuation character for *very* long lines? 
|  I tend to think not.]

Might be useful; there will be a significant proportion of long lines.

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

All the instances that suit the Accept info the client has sent?
Does that leave us with nothing between asking for one instance
(N2R) and all (N2Rs), or is there some way to quality the request
so that one receives no more than, say, 13 instances?  (Happy
Halloween!)

| 3.6  N2Ns (URN to URNs):
| ------------------------
| 
| While URNs are supposed to identify one and only one resource, that
| does not mean that a resource may have one and only one URN. For
| example, consider a resource that has something like
| "current-weather-map" for one URN and "weather-map-for-datetime-x" for
| another URN. The N2Ns service request lets us obtain lists of URNs that
| are believed equivalent at the time of the request. As the weathermap

The example implies, "lists of URNs that are believed to name equivalent
resources at the time of the request", which agrees with the language
in the next para.

| example shows, some of the equivalances will be transitory, so the
| result should not be cached.

| The request is encoded as above. The result is a list of all the
| URNs, known to the resolver, which identify the same resource as the
| input URN. The result shall be encoded as for the N2Ls request
| above. The original URN may appear in the list of returned URNs.

| 3.8  L2Ls (URL to URLs):
| ------------------------
| 
| The request is encoded as described above. The result is a list of
| all the URLs that the resolver knows are associated with the resource
| located by the given URL. It is returned in a text/plain body encoded
| as described above.

"Associated" is awfully broad.  The Framework document will clear up
what associations are intended, right?

Regards,

    Terry Allen    Fujitsu Software Corp.    [email-masked]
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

To: IETF-Announce:;
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-syntax-00.txt
Date: Thu, 31 Oct 1996 10:01:29 -0500
Sender: [email-masked]
Reply-To: [email-masked]

--NextPart

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

       Title     : URN Syntax                                              
       Author(s) : R. Moats
       Filename  : draft-ietf-urn-syntax-00.txt
       Pages     : 5
       Date      : 10/30/1996

Uniform Resource Names (URNs) are intended to serve as persistent resource 
identifiers. This document presents the syntax for URNs.  Support for 
existing legacy namespaces is discussed. URN transmission encoding 
requirements are presented.  Finally, there is a discussion of URN 
equivalence and how to determine it.                                       

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

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Date: Thu, 31 Oct 1996 05:54:38 -0800 (PST)
From: "Gregory J. Woodhouse" <[email-masked]>
To: Martin J Duerst <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [URN] New syntax draft (was: no subject)
Sender: [email-masked]
Reply-To: "Gregory J. Woodhouse" <[email-masked]>

On Thu, 31 Oct 1996, Martin J Duerst wrote:

> Gregory Woodhouse wrote:
> 
> This difference is always absolutely clear! A string that only contains
> bytes with the high bit '0' (7-bit bytes) is ASCII. As soon as a high
> bit is set to '1', it's not ASCII anymore. It may be UTF-8, or may not.
>
I understand this point, but I'm not talking about UTF-8 itself, but UTF-8
encoded into ASCII.
 
---
Gregory Woodhouse     [email-masked]
home page:            http://www.wnetc.com/
resource page:        http://www.wnetc.com/resource/

Subject: Re: [URN] New syntax draft (was: no subject)
To: [email-masked] (Gregory J. Woodhouse)
Date: Thu, 31 Oct 1996 14:38:57 +0100 (MET)
Cc: [email-masked], [email-masked]
Content-Length: 2937
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Gregory Woodhouse wrote:

>I'm also concerned because decoding requires knowledge that the string
>being decoded is UTF-8.

Not exactly. It is very rare that a string that is not UTF-8 looks
like an UTF-8 string.

>I said before that I wasn't terribly excited about
>using RFC 1522 style encodings,

Me neither! "charset" is okay for long mails, and RFC 1522 was unavoidable
at the time it was created, but now we have better solutions.

>but it seems essential in this case because
>otherwise the UA has no way of knowing (except by guessing) that the string
>is encoded UTF-8 and not just an ASCII string.

This difference is always absolutely clear! A string that only contains
bytes with the high bit '0' (7-bit bytes) is ASCII. As soon as a high
bit is set to '1', it's not ASCII anymore. It may be UTF-8, or may not.

>It is conceivable that some
>URN schemes will allow the sequences like %20%1E or whatever, so this could
>be a real problem.

Well, %20 is a space, which is ASCII, but should be escaped.
%1E is a control character (record separator), never appears in UTF-8,
and strictly speaking is also not part of ASCII.

>Another thought: What if someone wants to come along an
>do %hhhh style encoding of UTF-16? Will this be mistaken for encoded UTF-8?

Well, anybody can come along and propose new weird syntax rules for
URNs. Hopefully, nobody will listen to him/her. And these rules
won't comply with the official URN syntax we are working on here.

Actually, I don't think that anybody will get the idea of using UTF-16
when UTF-8 is proposed. It's Unicode/ISO 10646 in both cases, the transform
is easy, and people dealing with Unicode and stuff know that things such
as URNs, with ASCII backwards compatibility requirements, are best
handled using UTF-8.

The things we have to worry about more are people that come along
and say they want to use something else than Unicode/ISO 10646,
or at least want to be able to use something else, because for
some reasons, they are against Unicode, or they think it should
just be one of many encodings.
Also, what we have to worry about are cases where it's difficult
to know what native character encoding is used, so that it is
difficult to convert to Unicode and UTF-8 even if you wanted.
ftp is a typical case of this.

Anyway, even the two cases above are well handled in the draft.
We tell them that if they really need to, they can use something
else than UTF-8. Maybe we should tell them a little bit clearer
that if they do that, they are not supposed to get any much
of support by general tools, i.e. their URNs will just show
up as %HH%HH..., and the users will have to type them in like
this, and accidentally, some of it may be interpreted as UTF-8
and be displayed as such, but they cannot have their users
type native characters into a browser and expect that the
browser does the right thing (because it would in this case
convert to UTF-8).

Regards,	Martin.

Date: Thu, 31 Oct 1996 05:15:43 -0800 (PST)
From: "Gregory J. Woodhouse" <[email-masked]>
To: Martin J Duerst <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [URN] New syntax draft (was: no subject)
Sender: [email-masked]
Reply-To: "Gregory J. Woodhouse" <[email-masked]>

By %encoding I assume you mean hex encoding of non-ASCII or non-safe bytes.
Is there an official name for this encoding scheme? I've seen it called URL
encoding, but that hardly seems satisfactory.

I'm also concerned because decoding requires knowledge that the string
being decoded is UTF-8. I said before that I wasn't terribly excited about
using RFC 1522 style encodings, but it seems essential in this case because
otherwise the UA has no way of knowing (except by guessing) that the string
is encoded UTF-8 and not just an ASCII string. It is conceivable that some
URN schemes will allow the sequences like %20%1E or whatever, so this could
be a real problem. Another thought: What if someone wants to come along an
do %hhhh style encoding of UTF-16? Will this be mistaken for encoded UTF-8?

---
Gregory Woodhouse     [email-masked]
home page:            http://www.wnetc.com/
resource page:        http://www.wnetc.com/resource/

Date: Thu, 31 Oct 1996 05:00:28 -0800 (PST)
From: "Gregory J. Woodhouse" <[email-masked]>
To: Daniel LaLiberte <[email-masked]>
Cc: Ron Daniel <[email-masked]>, [email-masked]
Subject: Re: [URN] HTTP resolution protocol
Sender: [email-masked]
Reply-To: "Gregory J. Woodhouse" <[email-masked]>

On Wed, 30 Oct 1996, Daniel LaLiberte wrote:

> (Why are people putting [URN] in the title if the recipients are
> all on the urn-ietf list?  Just curious.)
>

It's a feature of Majordomo and other listservers to allow a specific
string to be prepended to a message subject if it's not already present. I
find this feature very useful and have always used it wne running lists.
For example, I now run an average of 100-300 messages in my in box. When I
want to look at messages from this list I select all messages with "[URN]"
in the subject and narrow my display to include only those messages. This
is with Pine 3.95 which is fairly sophisticated in this regard. Other
mailers are more limited but do allow sorting. This way, if there is a
common prefix to all the messages they show up together after a sort.

(I realize mail processing and UA characerisics has nothing to do with
URNs.  I left the list on the recipient list in case more people were
wondereing about the prefixes, but if you want to discuss this further we
might want to take it off list.) 
 
---
Gregory Woodhouse     [email-masked]
home page:            http://www.wnetc.com/
resource page:        http://www.wnetc.com/resource/

Subject: Re: [URN] New syntax draft (was: no subject)
To: [email-masked]
Date: Thu, 31 Oct 1996 11:58:35 +0100 (MET)
Cc: [email-masked], [email-masked]
Content-Length: 2081
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

>Internet-Draft                                                Ryan Moats
>draft-ietf-urn-syntax-00.txt                                        AT&T
>Expires in six months                                       October 1996

>1.2 Namespace Specific String Syntax
>
>   Depending on the rules governing a namespace, valid identifiers in a
>   namespace might contain characters that are reserved characters in
>   URI syntax or non-printable ASCII characters.  To accommodate the
>   largest set of valid identifiers, the NSS portion of a URN shall use
>   UTF-8 representation of ISO 10646 as its character set.  Namespaces
>   that do not currently use ISO 10646/UTF-8 are encouraged to migrate
>   to it.

Very well put!

>   URN resolvers MUST be capable of accepting URNs that have been
>   %encoded for either 8-bit clean or 7-bit transports.  %encoding is
>   removed first, then UTF-8 decoding is performed.  URN resolvers MUST
>   return identical results from ANY legally encoded form of the URN.

I wonder about UTF-8 decoding. It somehow implies that resolvers
work with Unicode internally, which would be fine, but is not
necessary. For database lookup and equality checks, staying with
UTF-8 will also be okay. For things such as regular expressions,
some additional definitions are necessary as to what the regular
expressions are working on (i.e. characters or octets), but still
it could work in UTF-8.

Also, what does UTF-8 decoding mean for an NSS that is not UTF-8?

>   It should be noted that certain characters in the Namespace Specific
>   String syntax may have special meaning in certain namespaces.
>   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.

Can they be encoded with %HH? Or should we specifically request some
other mechanism in order to not confuse different things, and let
programs that deal with URNs in general change from %HH to 8-bit
and back?

Regards,	Martin.

Subject: Re: [URN] HTTP resolution protocol
To: [email-masked]
Date: Thu, 31 Oct 1996 11:25:43 +0100 (MET)
Cc: [email-masked], [email-masked]
Content-Length: 304
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Daniel LaLiberte wrote:

>(Why are people putting [URN] in the title if the recipients are
>all on the urn-ietf list?  Just curious.)

Because most people are on more than one mailing list, and it
is convenient to know from which list the mails come just
from looking at the subjects.

Regards,	Martin.

From: [email-masked] (Leslie Daigle)
Date: Thu, 31 Oct 1996 04:07:22 -0500
To: Daniel LaLiberte <[email-masked]>, "Karen R. Sollins" <[email-masked]>
Subject: Re: Names and Locations (was [URN] some comments)
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked] (Leslie Daigle)

Dan, forgive me for using your message as an opportunity to write down
some basic definitions to make sure we ae all on the same page here...

[Dan LaLiberte wrote:]

> I agree.  But "a URN syntax" seems to imply that there must be just
> one syntax for all URNs.  Did you mean that?

>From the perspective of the work this group is doing, we neeed _a_ URN
syntax.  Because we are attempting to accommodate a broad range of name
spaces, the syntax is designed to be flexible -- ony specifying those things
that must be in order to be able to write software that handles URNs.
(E.g., acceptable character sets, how to handle escaping characters where
necessary, etc).    The URN syntax does not, however, have anything to say
about what structure a particular namespace wishes to use in the NSS
(i.e., namespace specific (opaque) string).

I think Karen's point was that this syntax should be defined
from the perspective of what we're trying to do with URNs, and not from the
technological  limitations or strengths of a particular implementation of
the architecture.

> We should state that name space identifiers and URI schemes are in the
> same name space.  Call them all the same thing: "URI Schemes".

Perhaps a convenient (and maybe even necessary) approach, but it should be
kept in mind that a URN name space is not the same thing as a URL protocol
(see below) -- so this starts to be a collection of apples and oranges.

> In general, each scheme, whether for a URL or URN, should be
> associated with some resolution protocol.  

I'm not sure I'm clear on what you're getting at here, and even if we do agree,
I think there is some potential for the above to be a bit misleading.

The point of the indirection in the URN naming is to abstract the (final) 
resolution protocol so that no name space is specifically associated with, say, 
HTTP, or Whois++.  THe idea is that any URN can be resolved using different 
protocols  -- at one time, or at different stages in its lifetime -- and this 
is a separate process from determining the URN identifier string.

However, there is a general mechanism for handling URNs to the extent of
extracting Naming Authority, etc etc etc, which is standard across the URNs
we define here.  

What _is_ associated with each name space is the particular means of extracting 
the necessary namespace ID to look up the naming authority (i.e., perhaps from
the NSS, perhaps just based on the namespace, etc).  So, CID URNs might
have a mapping that describes how to pull a DNS name out of the string; 
LesliesNamespace might have a mapping based on the phase of the moon.  All
LesliesNamespace URNs will require the use of this mapping in order to find
the Naming Authority, which will lead to a server speaking any of seaveral
possible protocols for the final resolution.

> You made the curious statement that URNs identify resources while URLs
> identify locations.  I'm not sure whether that was a slip, but to my
> mind, a URL *IS* a location that identifies a resource.  Now you also

URLs identify a particular location for a resource.  Mechanisms for migrating
that resource without changing the URL are based on aliasing techniques that
are external to the URL. It is therefore usually a problem when a particular
resource is moved to another location.

URNs identify a resource, independently of its location.  The indirection
mechanisms permit that a single resource may be in several locations at
once, or may migrate, without changing the URN.  This is handled within the
URN support framework, and is therefore consistent across URNs.  The idea
is that, in general, it should not be a problem if a resource is moved.

So, the URN identifies the resource; a URL identifies a location which is an
instance of a resource, nd these are qualitatively  different things (yes, I
am feeling brave this morning!).

Leslie.

-- 

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

  "The light at the end of the tunnel             Leslie Daigle
     is often the blindingly obvious..."          Vice President, Research
                                                  Bunyip Information Systems
                      -- ThinkingCat              (514) 875-8611
                                                  [email-masked]
----------------------------------------------------------------------------

Date: Wed, 30 Oct 1996 15:30:33 -0600 (CST)
From: Daniel LaLiberte <[email-masked]>
To: Larry Masinter <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [URN] HTTP resolution protocol
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Larry Masinter writes:
 > Ron,
 > 
 > I think some people would say that
 > 
 >     GET <service>/<uri>  HTTP/1.0
 > 
 > is not valid HTTP.

I was wondering about that.  Maybe Ron meant:

  GET /<service>/<uri>  HTTP/1.0

 > New services need new methods.

Well... http is a "service".  Should it be a "method"? 

dan

Date: Wed, 30 Oct 1996 15:21:08 -0600 (CST)
From: Daniel LaLiberte <[email-masked]>
To: "Karen R. Sollins" <[email-masked]>
Cc: [email-masked]
Subject: Names and Locations (was [URN] some comments)
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Karen R. Sollins writes:
 > 1) There were a couple of almost parenthetical comments about the
 > NAPTR proposal that made me worry.  It is important that we all agree
 > that a URN syntax is independent of the NAPTR or any other URN
 > resolution proposal.

I agree.  But "a URN syntax" seems to imply that there must be just
one syntax for all URNs.  Did you mean that?

 > 2) About "urn:", I don't know whether I come from the other
 > "religious" viewpoint, but unless we have additional requirements and
 > mechanisms in place, I think it would be a really bad idea to make the
 > "urn:" optional.  Let's look at a few points here:
 > 
 > a) I don't believe that there is anything in the URL or URN
 > requirements documents (or any other RFCs) that states that prefixes
 > for URNs (without the "urn:") and URLs cannot be the same.

We should state that name space identifiers and URI schemes are in the
same name space.  Call them all the same thing: "URI Schemes".

One way to avoid this is to make sure that the context for resolution
is always clear.  So when giving a URL in an HTML document you could
use HTTP="scheme:opaque-string", and when giving a URN you could use a
different tag, e.g.  URN="nsi:opaque-string".  This idea tends to pop
up occasionally, but I think it not useful.

 > b) Given a random string (say foo://opaque_string) in some specific
 > situation, something needs to decide what it means and what to do with
 > it.  If the string is a URN it identifies a resource, while, if it is
 > a URL it identifies a location (in other words, it identifies an
 > abstraction from the perspective of a transport protocol, in fact, the
 > "foo" transport protocol).  So, now, without any specification of
 > urn-hood or url-hood, who makes a decision and how?

In general, each scheme, whether for a URL or URN, should be
associated with some resolution protocol.  

You made the curious statement that URNs identify resources while URLs
identify locations.  I'm not sure whether that was a slip, but to my
mind, a URL *IS* a location that identifies a resource.  Now you also
qualified it by saying that locations are associated with transport
protocols.  I think maybe therein lies the rub for this name-location
friction.  

The term "transport protocol" means, to me, a set of descriptions,
rules, policies, etc for how data is transferred between two or more
points.  In contrast, the term "resolution protocol" is about how some
identifier is resolved into something else, not necessarily the final
"resource". (You didn't use "resolution protocol", but others have.)
But consider HTTP.  It is a resolution protocol in that http URLs are
resolved into something else (sometimes the resource is returned,
sometimes just data about it).  The fact that something is returned as
a result of the resolution process means that HTTP must deal with
transport too.  In fact, to make a resolution request, the request
itself must be transported from the client to the server.  A transport
that is merely one-way, and doesn't involve a request could be
considered to have a pure transport protocol.  But most real transport
protocols involve something like a request to send something followed
by acknowledgment, refusal, etc.

While I am at it, the term "protocol" seems to have gotten a
too-specific meaning in the internet community.  The general meaning
of the term is rules for how things talk to each other.  If the things
that are talking are distributed across a network, this is very
important to internet people, to the point that "protocol" means just
over the network.  But with the advent of distributed object
technologies, it should become increasingly clear that, from a
high-level perspective, it is irrelevant (except for performance,
security and the like) whether communicating objects are co-located in
the same process or distributed.  "Applications" can execute within a
single machine or be smeared across several.  Sure there are protocols
that are only really needed over the network, such as IP, but I bet
someone somewhere is using IP within a process to "simulate" the
network.

Back to names.

 > c) Consider how one might build applications, with respect to URNs
 > (it's too late for URLs to solve this problem).  Suppose five new
 > kinds of URNs are defined and five new kinds of URLs are defined.  The
 > application starts seeing strings with these ten new prefixes.  Now
 > the applications must have some mechanism for dealing with all these
 > new things.  So, assume it makes some decision, perhaps to send all
 > unidentifiable strings to a proxy for URNs.

What is wrong with sending each identifier to a possibly different
proxy that is intended to resolve it?  How does a client know which
identifiers go to which proxy?  Ah ha!  We need a downloadable global
resolution mapping table for all globally defined URI schemes.  The
client would use this table to look up the appropriate resolution
mechanism.  Local versions of the table could exist to, for example,
map local identifiers to a faster private server.

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

To: [email-masked]
Cc: [email-masked]
Subject: Re: [URN] HTTP resolution protocol
From: Larry Masinter <[email-masked]>
Date: Wed, 30 Oct 1996 12:54:12 PST
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

Ron,

I think some people would say that

    GET <service>/<uri>  HTTP/1.0

is not valid HTTP. In fact, I think there are a number of current
products that offer (on the same port) both regular and proxy HTTP
support would be confused by something that half looks like a URL but
isn't really.

New services need new methods.

Larry

Date: Wed, 30 Oct 1996 14:15:51 -0600 (CST)
From: Daniel LaLiberte <[email-masked]>
To: Ron Daniel <[email-masked]>
Cc: [email-masked]
Subject: [URN] HTTP resolution protocol
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

(Why are people putting [URN] in the title if the recipients are
all on the urn-ietf list?  Just curious.)

Ron Daniel writes:

 >          Conventions for the Use of HTTP for URN Resolution

Perhaps the whole document could be more specific on the fact that
this is a particular kind of URN resolution, not the only way that
HTTP might in fact be used (simultaneously) for URN resolution.
For example, path URNs can be mapped directly to http URLs, which
the client resolves normally via HTTP, using whatever services are
supported via HTTP.  (Additional http services might be metadata
requests, for example.)

 > Abstract:
 > =========
 > 
 > One of the main purposes of the work on URNs is to allow resources
 > to be replicated onto multiple sites.

I disagree with this.  Replication should be considered orthogonal to
naming and name resolution.  Names are not required to offer just as
much transparency in the replication process and resolution via
replicas.  An identifier (whether a "name" or "location") for a
resource can be associated with many other identifiers of replicas, or
alternatively, an identifier can be associated with many other
services that *have* replicas of the resource.

The main purpose of URNs is to provide an additional level indirection
via a relatively long lived resolution service (e.g. DNS).  Providing
replica identifiers at the same time as providing this indirection
seems like a reasonable thing to do (and it is) but it is the
indirection which is the main purpose of names.

You also have described several other services that the server would
provide, so why focus on replication in the Abstract?

 > Obtaining a copy of such a
 > replicated resource procedes by contacting a "resolver" that knows the
 > locations of the replicated resource.

An HTTP server could know the locations of a replicated resource
identified by either an http URL or a URN.

 > 2.0 General Approach:
 > =====================
 > 
 > The general approach used to encode resolution service requests in HTTP
 > is quite simple: 
 > 
 >     GET <service>/<uri>  HTTP/1.0
 > 
 > For example, if we have the URN "cid:[email-masked]" and want a URL,
 > we would send the request:
 > 
 >     GET N2L/cid:[email-masked] HTTP/1.0

What you propose works, but consider why not do:

  N2L cid:[email-masked] HTTP/1.0

The "N2L/" prefix on the URI defines a name space within the server -
the server might be used for other things simultaneously.  Doing a GET
request on this URI means (in current HTTP) that the result should be
cachable, and as far as the client is concerned it looks like
"N2L/whatever" is the identifier for a resource itself.  The full URL
for this resource is "http://wherever/N2L/whatever".  Could we then
request "N2L/N2L/whatever"?

With a new "N2L" method, things would be different.  Whether the
result is cachable is not certain.  Most servers cannot (yet) be
configured to handle new methods.  But otherwise, it might make more
sense to keep the N2L service request out of the identifier of the
real resource (the <whatever>).  Folding the service (or method) request
into an identifier is not a sin - in fact, I have suggested more of
the same.  I just want to point out that that is what you are doing.

 > One caveat should be kept in mind. The "urn:" prefix is still the
 > subject of controversy, so some URN documents advocate treating it
 > as optional. HTTP resolvers MUST return identical results for URIs
 > that do and do not contain the "urn:" prefix.

Wouldn't it be simpler just to require that the "urn:" should be
removed before submitting the request?

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

Date: Wed, 30 Oct 1996 12:58:47 -0600 (CST)
From: Daniel LaLiberte <[email-masked]>
To: Larry Masinter <[email-masked]>
Cc: [email-masked]
Subject: Re: [URN] What is equivalence?
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Larry Masinter writes:
 > Do the namespaces 'define' equivalence, or do they 'implement' it?
 > 
 > That is, would you want to assert that if
 >    isbn:0-13-443672-5 and isbn:013443672-5 
 > are ever to be treated the 'same', then they must always be treated
 > the 'same'? Otherwise, a client which has 'knowledge about the
 > namespace' might find that knowledge out of date.

I don't recall if anyone mentioned the idea of a client
getting and caching general rules (e.g. regular expressions) for how
to transform an identifier into a canonical, preferred form.
Testing equivalence would then involve transforming all identifiers
to cannonical form, and then comparing.

One resolution service might be to answer a request for the canonical
form of an identifier, perhaps along with the rule used to do the
transformation.

 > On the other hand, you might want to allow 
 >     duns:ibm to be the same as duns:international-business-machines
 > but are you willing to allow that equivalence to be cached in clients
 > or wired into them?

I gather the idea here is that "duns:ibm" is a prefix for a whole class
of identifiers.

Mapping 'duns:ibm' to 'duns:international-business-machines' (or vise
versa) goes beyond a few general transformation rules to lots of
specific cases (one for every company name with an acronym), but
clients could and should certainly cache as many such specific
rules as are useful, and still valid.

But there is another notion of equivalence that should be considered:
the equivalence of any two identifiers may be specified by a naming
authority (or an associated resolution service).  The identifiers may
be in completely different name spaces, so some agreement must exist
and be certifiable.  This equivalence of two identifiers that applies
to only these specific identifiers is a special case of the general
transformation rule.

In all cases, the identifier space (or some subauthority within it)
specifies how equivalence is determined, either as a very general rule
or as lots of specific rules.  A few very general rules with very long
life times may be wired into clients.

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

Date: Wed, 30 Oct 1996 11:59:25 -0700
To: [email-masked]
From: Ron Daniel <[email-masked]>
Subject: [URN] HTTP resolution protocol
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Hi again,

A rough draft of the HTTP resolution protocol is appended. This sets
the conventions on how URN resolution service requests and responses
should be encoded in HTTP requests and responses. It is the draft
that specifies the meaning of the "http" resolution protocol that
is mentioned in the NAPTR draft.

====

INTERNET DRAFT                                                  Ron Daniel
draft-daniel-http-00.txt                    Los Alamos National Laboratory
                                                              30 Oct, 1996

         Conventions for the Use of HTTP for URN Resolution

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

    This document is an Internet-Draft.  Internet-Drafts are working
    documents of the Internet Engineering Task Force (IETF), its
    areas, and its working groups.  Note that other groups may also
    distribute working documents as Internet-Drafts.
  
    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other
    documents at any time.  It is inappropriate to use Internet-
    Drafts as reference material or to cite them other than as
    ``work in progress.''
  
    To learn the current status of any Internet-Draft, please check
    the ``1id-abstracts.txt'' listing contained in the Internet-
    Drafts Shadow Directories on ftp.is.co.za (Africa),
    nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
    ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).

    This draft expires 25 Feb., 1997.

Abstract:
=========

One of the main purposes of the work on URNs is to allow resources
to be replicated onto multiple sites. Obtaining a copy of such a
replicated resource procedes by contacting a "resolver" that knows the
locations of the replicated resource. The resolver can then return one
or more of those locations, and the client can use them to fetch the
resource. 

The framework being developed in the URN-WG allows different resolution
systems. This means that the resolvers may speak different protocols,
and that there may be different ways of locating a resolver.

This draft establishes conventions for encoding URN resolution requests
and responses in HTTP 1.0 (and 1.1) requests and responses. HTTP
provides a quick and easy way to begin resolving URNs. We expect that
conventions for using more capable protocols to talk with URN resolvers
will also be defined.

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

The NAPTR draft[1] describes a way of using DNS to locate resolvers for
URIs.  That draft provides places to specify the "resolution protocol"
spoken by the resolver, as well as the "resolution services" it offers.
As of this writing, the "resolution protocols" allowed by the NAPTR draft
are HTTP, RCDS, HDL, and RWHOIS. (That list is expected to grow over time).
The NAPTR draft also lists a variety of resolution services, such
as N2L (given a URN, return a URL); N2R (Given a URN, return the named
resource), etc. This draft specifies the conventions to follow to
encode resolution service requests in the HTTP protocol, allowing
widely available HTTP daemons to serve as URN resolvers.

The reader is assumed to be familiar with the HTTP/1.0 [2] and 1.1 [3]
specifications.

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

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

    GET <service>/<uri>  HTTP/1.0

For example, if we have the URN "cid:[email-masked]" and want a URL,
we would send the request:

    GET N2L/cid:[email-masked] HTTP/1.0

Because of the character set limitations on URIs, we might wish to
encode the '@' character as its hex equivalent, thus the request would be

    GET N2L/cid:foo%40huh.com HTTP/1.0

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

    GET N2L/cid:foo%40huh.com HTTP/1.1
    Host: <whatever host we are sending the request to>

Handling these requests on the server side is easy to implement in a
number of ways. The N2L request could be handled by a CGI script that
took the incoming URN, looked it up in a database, and returned the URL
as an HTTP redirect. Service requests like N2R or N2C could be set up
so that the daemon answered the request by returning files out of N2R/
and N2C/ directories, or they could be handled by a script.

One caveat should be kept in mind. The "urn:" prefix is still the
subject of controversy, so some URN documents advocate treating it
as optional. HTTP resolvers MUST return identical results for URIs
that do and do not contain the "urn:" prefix. For example, the two
request below must return identical results:
    GET N2L/cid:foo%40huh.com HTTP/1.0
    GET N2L/urn:cid:foo%40huh.com HTTP/1.0

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

This section goes through the various resolution services established
in the URN Framework draft [4] and states how to encode each of them,
how the results should be returned, and what error codes are most likely
to arise [actually, error handling does not appear in this first draft].

Unless stated otherwise, the HTTP requests are formed according to
the examples above, either for HTTP/1.0 or HTTP/1.1.

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

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

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

The request is encoded as above. The result is a list of 0 or
more URLs.  These should be returned in a text/plain document
that first lists the number of URLs in the result, then lists
the URLs, one per line. The URLs should be encoded according to
the URI specification [5]. Comments may be placed in the returned
file by starting a line with the '#' character. The URN for the
request SHOULD be placed in a comment line that begins "# urn:".
An example of such a result is shown below in figure 1.

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

                              Figure 1
               Simple format for returning multiple URLs

[Do we need to have a continuation character for *very* long lines? 
 I tend to think not.]

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

The request is encoded as above. The resource is returned using
standard HTTP mechanisms. The request may be modified using the
Accept: header as in normal HTTP.

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

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

The request is encoded as above. The result is returned in a MIME
multipart message. 

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

The request is encoded as above. The result will have its own
Internet Media Type, and should be handled as if returning 
any other instance of that type. [Do we need to do anything
special with some of the extra headers?] 

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

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

The request is encoded as above. The result is a list of all the
URNs, known to the resolver, which identify the same resource as the
input URN. The result shall be encoded as for the N2Ls request
above. The original URN may appear in the list of returned URNs.

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

The request is encoded as above. The result is returned as a
text/plain body containing a list of URNs as described earlier.

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

The request is encoded as described above. The result is a list of
all the URLs that the resolver knows are associated with the resource
located by the given URL. It is returned in a text/plain body encoded
as described above.

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

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

Implementation Notes:
=====================

This section gives an example of how to configure a web server to
respond to the N2L resolution request. It is not intended to specify
standard behavior, it is provided here merely as a courtesy for
implementors.

First, we assume the presence of a CGI script, n2l.pl, that processes
the provided URN, converting it into a canonical format. It would remove
any "urn:" prefix,  decode any %encoded special characters, normalize
case-insensitive parts of the URN to lower case, etc. It would then use
the normalized URN as the key for a search in a database, which we assume
returns the URL as a string. A sample of our implementation of that script
is provided as Appendix A. We will further assume that the n2l.pl script
is in the cgi-bin directory of the web server.

The easiest way to invoke the n2l.pl script in response to N2L requests
is to set up a Redirect directive in the srm.conf file. (This works for
servers based on the original NCSA HTTP daemon, such as Apache.) The
relevant Redirect directives might look like:

Redirect /N2L http://urn.acl.lanl.gov/cgi-bin/n2l.pl
Redirect /L2N http://urn.acl.lanl.gov/cgi-bin/l2n.pl

Appendix A:  n2l.pl script
==========================

This is a simple perl script for the N2L resolution service. It
assumes the presence of a DBM database to store the URN to URL
mappings.

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

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

    $urn = $ENV{'PATH_INFO'} ;
    if(length($urn)<3)
    {
        $error=1;
    }

    if(!$error)
    {
        $urn =~s/^(\/)(urn:)?(.*)/$3/i;
        # Additional canonicalization should be performed here

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

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

    exit;

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

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

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

[3] HTTP 1.1 draft

[4] URN Framework draft

[5] RFC 1630

Security Considerations
=======================
  Resolution requests may be of interest to traffic analysts. Resolution
  responses might be the target of spoofing, especially once electronic
  commerce takes hold and users would pay the server of a resource. The
  requests and responses used in this draft are amenable to encoding and
  signing in the manner of any other HTTP traffic.

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

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

    This draft expires 5 May, 1997.

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, 30 Oct 1996 10:57:27 -0700
To: [email-masked]
From: Ron Daniel <[email-masked]>
Subject: [URN] current version of NPATR draft
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Hi all,

Some personal things have come up that have eaten most of my time,
thus my relative quiet on the list.  The WG charter calls for the
NAPTR draft to be submitted this month. Earlier versions have been
submitted, but here is the one that incorporates a lot of the feedback
we have had up to now.  I'm sending this to the ID editor today.

This draft does not yet address the issue of how regexps might deal with
international character sets, partly because we haven't finalized that
but mostly because of lack of time to look into solutions to that problem.

------

INTERNET DRAFT                                                  Ron Daniel
draft-ietf-urn-naptr-00.txt                 Los Alamos National Laboratory
                                                          Michael Mealling
                                                   Network Solutions, Inc.
                                                             30 Oct., 1996

                Resolution of Uniform Resource Identifiers
                       using the Domain Name System

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

    This document is an Internet-Draft.  Internet-Drafts are working
    documents of the Internet Engineering Task Force (IETF), its
    areas, and its working groups.  Note that other groups may also
    distribute working documents as Internet-Drafts.
  
    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other
    documents at any time.  It is inappropriate to use Internet-
    Drafts as reference material or to cite them other than as
    ``work in progress.''
  
    To learn the current status of any Internet-Draft, please check
    the ``1id-abstracts.txt'' listing contained in the Internet-
    Drafts Shadow Directories on ftp.is.co.za (Africa),
    nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
    ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).

    This draft expires 05 May, 1997.

Abstract:
=========

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

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

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

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

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

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

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

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

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

Locating a resolver through the rewrite procedure may take multiple
steps, but the beginning is always the same. Every URI has a
colon-delimited prefix.  NAPTR resolution begins by taking this prefix,
appending the well-known suffix ".urn.net", and querying the DNS for NAPTR
records at that domain name.  Based on the results of this query, zero
or more additional DNS queries may be needed to locate resolvers for the
URI. The details of the conversation between the client and the resolver
thus located are outside the bounds of this draft.
Three brief examples of this procedure are given in the next section.

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

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

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

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

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

The key fields in the NAPTR RR are order, preference, service, flags,
regexp, and replacement:
* The order field specifies the order in which records MUST be processed
  when multiple NAPTR records are returned in response to a single query.
  A naming authority may have delegated a portion of its namespace to
  another agency. Evaluating the NAPTR records in the correct order is
  necessary for delegation to work properly.
* The preference field specifies the order in which records SHOULD
  be processed when multiple NAPTR records have the same value of "order".
  This field lets a service provider specify the order in which resolvers
  are contacted, so that more capable machines are contacted in preference
  to less capable ones.
* The service field specifies the resolution protocol and resolution
  service(s) that will be available if the rewrite specified by the
  regexp or replacement fields is applied. Resolution protocols are
  the protocols used to talk with a resolver. They will be specified in
  other documents. Resolution services are operations such as
  N2R (URN to Resource), N2L (URN to URL), N2C (URN to URC), etc.
  These are discussed in the URN Framework document[2], and their behavior
  in a particular resolution protocol will be given in the specification for
  that protocol.
* The flags field contains modifiers that affect what happens in the
  next DNS lookup, typically for optimizing the process.
* The regexp field is one of two fields used for the rewrite rules, and is
  the core concept of the NAPTR record. The regexp field is a String
  containing a sed-like substitution expression. (The actual grammar for
  the substitution expressions is given later in this draft). The
  substitution expression is applied to the original URN to determine the
  next domain name to be queried. The regexp field should be used when the
  domain name to be generated is conditional on information in the URI. If
  the next domain name is always known, which is anticipated to be a common
  occurrence, the replacement field should be used instead.
* The replacement field is the other field that may be used for the rewrite
  rule. It is an optimization of the rewrite process for the case where the
  next domain name is fixed instead of being conditional on the content of
  the URI. The replacement field is a domain name (subject to compression if
  a DNS sender knows that a given recipient is able to decompress names in
  this RR type's RDATA field). If the rewrite is more complex than a simple
  substitution of a domain name, the replacement field should be set to . and
  the regexp field used. 

Note that the client applies all the substitutions and performs all
lookups - this is not handled in DNS servers. Note also that there is no
reason to provide values in both the replacement and regexp field. Only
one should be specified. If a value is specified in both, the replacement
name MUST be used and the regexp string MUST be ignored. It is the belief
of the developers of this document that regexps should rarely be used. The
replacement field seems adequate for the vast majority of situations. Regexps
are only necessary when portions of a namespace are to be delegated to
different resolvers.

Example 1
---------

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

                 urn:duns:002372413:annual-report-1997

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

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

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

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

Since our example RR specified the "s" flag, it was terminal. Our
next action is to lookup SRV RRs for _rcds._udp.isi.dandb.com, which
will tell us hosts that can provide the necessary resolution service. 
That lookup might return:

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

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

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

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

Example 2 
---------

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

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

*.gatech.edu IN NAPTR
;;       order pref flags service           regexp  replacement
  IN NAPTR 100  50  "s"  "z3950+N2L+N2C"    ""   _z3950._tcp.gatech.edu.
  IN NAPTR 100  50  "s"  "rcds+N2C"          ""   _rcds._udp.gatech.edu.
  IN NAPTR 100  50  "s"  "http+N2L+N2C+N2R"  ""   _http._tcp.gatech.edu.

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

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

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

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

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

Example 3
---------

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

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

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

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

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

This expression returns everything after the first double slash and
before the next slash or colon. Backslashes are needed to escape the
forward slash since the forward slash character is what separates the
components of the substitution expression. (Recall from the previous
example that in the zone file, this pattern actually needs to be
entered as "/.*\\/\\/([^\\/:]+)/\\1/i").  Applying this pattern to the
URL extracts "www.foo.com". Looking up NAPTR records for that might
return:

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

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

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

The format of the NAPTR RR is given below. The DNS type code for
NAPTR is 104 [this is being changed, we believe it will be assigned 35].

    Domain TTL Class Order Preference Flags Service Regexp Replacement 

where:

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

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

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

       At this time only three flags, "S", "A", and "P", are defined. "S"
       means that the next lookup should be for SRV records instead of NAPTR
       records. "A" means that the next lookup should be for A records. The
       "P" flag says that the remainder of the resolution shall be carried
       out in a Protocol-specific fashion, and we should not do any more
       DNS queries.
       
       The remaining alphabetic flags are reserved. The numeric flags may be
       used for local experimentation. The S, A, and P flags are all mutually
       exclusive, and resolution libraries MAY signal an error if more
       than one is given. (Experimental code and code for assiting in the
       creation of NAPTRs would be more likely to signal such an error than
       a client such as a browser). We anticipate that multiple flags will
       be allowed in the future, so implementors MUST NOT assume that the
       flags field can only contain 0 or 1 characters. 

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

           service_field = [ [protocol] *("+" rs)]
           protocol      = "rcds" / "http" / "hdl" / "rwhois"
           rs            = "N2L" / "N2Ls" / "N2R" / "N2Rs" / "N2C"
                         / "N2Ns" / "L2R" / "L2Ns" / "L2Ls" / "L2C"

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

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

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

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

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

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

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

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

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

  subst_expr   = "/"   ere  "/"  repl  "/"  *flags
  ere          = POSIX Extended Regular Expression (see [9], section 2.8.4)
  repl         = dns_str /  backref / repl dns_str  / repl backref
  dns_str      = ...... which RFC can I cite for this? 1035 seems obsolete .....
  backref      = "\" 1POS_DIGIT
  flags        = "i" 
  DNS_CHAR     = "_" / "0" / "1" / ... / "9" / "a" / ... / "z"
  POS_DIGIT    = "1" / "2" / ... / "9"  ; 0 is not an allowed backref value

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

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

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

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

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

The URN-WG is discussing the use of international characters in URNs.
The regexp package used may need to be changed from POSIX to one with
the ability to handle UNICODE characters.

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

Usage
=====

Pseudocode for a client routine using NAPTRs is given below:

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

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

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

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

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

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

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

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

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

The authors would like to thank Keith Moore for all his consultations
during the development of this draft. We would also like to thank Paul
Vixie for his assistance in debugging our implementation, and his answers
on our questions.

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

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

[2] draft-daigle-urn-framework-00.txt "A Uniform Resource Naming
    Framework", Leslie Daigle and Patrik Faltstrom, June, 1996.

[3] draft-gulbrandsen-dns-rr-srvcs-03.txt  " A DNS RR for specifying the
    location of services (DNS SRV)",  Arnt Gulbrandsen and Paul Vixie,
    March 1996.

[4] Paul Vixie, personal communication.

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

[6] Keith Moore, personal communication.

[7] Keith Moore, "Resource Cataloging and Distribution Service", ???
    (insert as [4], renumber the others?)

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

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

[10] ... rwhois spec ...
[11] ... encoding resolution service requests in HTTP...

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

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

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

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

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

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

    This draft expires 05 May, 1997.

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, 30 Oct 1996 08:15:18 -0600
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: [email-masked]
Cc: [email-masked]
Subject: [URN] (no subject)
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

Internet-Draft                                                Ryan Moats
draft-ietf-urn-syntax-00.txt                                        AT&T
Expires in six months                                       October 1996

                               URN Syntax
                 Filename: draft-ietf-urn-syntax-00.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

   This document presents the syntax for Uniform Resource Names (URNs).
   More information on the purpose of URNs is available from [1].  NEED
   TO ADD ABSTRACT!!!!

1. 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 "urn:" sequence is currently optional,
   as no closure on its definite presence or absence has been reached.
   The Namespace ID is used to determine the _syntactic_ interpretation
   of the Namespace Specific String (as discussed in [1]).

   RFC 1737 [2] suggests additional requirements on URN encoding, which

Expires 4/97                                                    [Page 1]

INTERNET DRAFT                 URN Syntax                   October 1996

   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.

1.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>         ::= <letter> [ <let-hyp> ]

   <let-hyp>     ::= <letter> | "-"

   <letter>      ::= any one of the 52 alphabetic characters A through Z
                     in upper case and a through z in lower case

   This is slightly more restrictive that what is stated in RFC 1738 [4]
   (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 optional "urn:" identifier, the NID "urn"
   is reserved and may not be used.

1.2 Namespace Specific String Syntax

   Depending on the rules governing a namespace, valid identifiers in a
   namespace might contain characters that are reserved characters in
   URI syntax or non-printable ASCII characters.  To accommodate the
   largest set of valid identifiers, the NSS portion of a URN shall use
   UTF-8 representation of ISO 10646 as its character set.  Namespaces
   that do not currently use ISO 10646/UTF-8 are encouraged to migrate
   to it.

   Clients MUST be capable of %encoding the UTF-8 formatted NSS.
   %encoding, (as discussed in [3]) uses a percent sign "%" immediately
   followed by two hexadecimal digits (0-9, A-F) giving the binary code
   for that octet. The rules for %encoding presented in [3] apply with
   the following exceptions:

      1. [3] states that occurrence of the '/' character in URIs must
      denote hierarchy, so that partial forms of a URI are possible.
      This restriction is unenforceable, and relative URLs do not have a
      scheme prefix, so we allow URNs to contain unescaped occurrences

Expires 4/97                                                    [Page 2]

INTERNET DRAFT                 URN Syntax                   October 1996

      of the '/' character that do not denote hierarchy.

      2. As an optimization when the transport between systems is known
      to be 8-bit-clean, clients MAY omit the %encoding on 8-bit
      characters but MUST still %encode the reserved characters below.

   For historic reasons, the characters "#" (%23), "?" (%3F), "%" (%25),
   "*" (%2A), "!" (%21), "<" (%3C), ">" (%3E), and '"' (%22), are
   reserved and must be %encoded.  Thus client implementers should
   accept URNs from users in an unencoded form but must encode them
   before sending them to a resolver.

   URN resolvers MUST be capable of accepting URNs that have been
   %encoded for either 8-bit clean or 7-bit transports.  %encoding is
   removed first, then UTF-8 decoding is performed.  URN resolvers MUST
   return identical results from ANY legally encoded form of the URN.

   It should be noted that certain characters in the Namespace Specific
   String syntax may have special meaning in certain namespaces.
   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.

2. Support of existing legacy naming systems

   To allow for support existing legacy naming systems (as required by
   [2]), the Namespace Specific String shall be considered an "opaque
   string" in the sense of structure except as mentioned in Section 1.

   In addition, URN servers should be prepared to accept URNs that do
   not use ISO 10646/UTF-8 for those namespaces that currently use a
   different encoding.  Note that this is not a general requirement on
   all resolvers, only resolvers that handle a namespace that is known
   not to use ISO 10646/UTF-8.

3. URN encoding for transmission

   Because the NSS of a URN is considered a series of octets of data,
   encoding URNs for transport is the responsibility of the transport
   mechanism and is not discussed here.  Any mechanism that can handle
   arbitrary 8-bit data will successfully transport a URN.

4. Equivalence in URNs

URNs are considered equivalent if they return the same result.  For
various purposes, such as caching, a test is necessary to determine
equivalence without actually resolving the URNs and fetching/comparing

Expires 4/97                                                    [Page 3]

INTERNET DRAFT                 URN Syntax                   October 1996

the underlying resources.  "Lexical equivalence" is a stricter condition
that the equivalence described above (functional equivalence).

4.1 Lexical Equivalence

   Lexical equivalence may be determined by comparing two URNs without
   making any network accesses. Two URNs are lexically equivalent if
   they are octet-by-octet equal after the following preprocessing

           1. remove any %encoding that might be present
           2. drop any preceding "urn:" token
           3. normalize the case of the NID

   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.

4.2 Functional Equivalence

   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.

4.3 Examples

   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.

5. Security considerations

   Because of the number of potential namespaces, it must be restated
   that certain of the characters in the Namespace Specific String may
   have special meaning to certain namespace resolvers.  The process of
   registering a namespace identifier shall therefore 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 4/97                                                    [Page 4]

INTERNET DRAFT                 URN Syntax                   October 1996

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

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

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

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

8. Author'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 April 1, 1997.

Expires 4/97                                                    [Page 5]

Subject: Re: [URN] some comments
To: [email-masked]
Date: Wed, 30 Oct 1996 10:57:53 +0100 (MET)
Cc: [email-masked]
Content-Length: 5899
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Karen Solins wrote:

>Not being a big fan of character set wars, I've sat by the sidelines
>for a while.

Well, we didn't have a war of any kind, did we? Character set
issues have to be discussed like other things, but why
is nobody speaking about a "security war", or so :-?.

>1) There were a couple of almost parenthetical comments about the
>NAPTR proposal that made me worry.  It is important that we all agree
>that a URN syntax is independent of the NAPTR or any other URN
>resolution proposal.  If we find that there are decisions that we all
>agree are important for URN syntax, for which we find that the NAPTR
>proposal is ill-equipped to deal (e.g. the relationship between
>character sets and regular expressions) then we should NOT remove
>those from the syntax document, but rather modify the NAPTR proposal.

In terms of relations between regural expressions and character sets,
I guess things can work together even with UTF-8. But it is important
to say on which representation the regular expressions should work:
- On the %HH Representation (and exactly what is escaped, and what not).
- On the 8-bit octet representation (needs an 8-bit proof implementation).
- On the characters themselves (needs some additional conventions).
Regular expressions for one of these representations can be transformed
(even mechanically) to another one, usually with some expansion,
of course.

>2) About "urn:"

>c) Consider how one might build applications, with respect to URNs
>(it's too late for URLs to solve this problem).  Suppose five new
>kinds of URNs are defined and five new kinds of URLs are defined.  The
>application starts seeing strings with these ten new prefixes.  Now
>the applications must have some mechanism for dealing with all these
>new things.  So, assume it makes some decision, perhaps to send all
>unidentifiable strings to a proxy for URNs.  This is something that
>acts a front end for URN resolution.  For some large number of the
>requests, the resolution will fail because truthfully, they were URLs.
>Things could just as well have gone the other way if it was assumed
>that the new strings are all URLs.  Some decision must be made one way
>or the other.  The other alternative to the proxy is that the
>application or some additional level of proxying does the
>demultiplexing and is kept up to date with new kinds of URNs and
>URLs.  If the answer is that the application must do it, then new
>versions of every application using URNs must be distributed.  If the
>answer is that there is a second level of proxying, we have now made
>it take even longer to get an answer, by including another network
>transit to the time to respond.

While being one of the experts on internationalization (in this list,
at least), I am still having problems with the difference between
URLs and URNs. The above helped quite a bit, but I still wonder:
Aren't URLs just in some way a subcategory of URNs? If I send an
URL to a resolver, should it not just resolve to itself (instead
of producing an error)? Of course, if the client iterates on this
answer, an endless loop would result. But the resolver could
have returned alternatives, which might be exploited.
Couldn't some implementation send everything they get in terms
of URL/URN to a resolver? Couldn't we start doing resolution
on what up to now were plain URLs, i.e. that an older browser
just goes directly (well, with DNS lookup and stuff, anyway)
to a single location when seeing a http: URL, but a newer
browser would contact a resolver first? Is it necessary
to distinguish these two behaviours by urn:http:... and
http:..., or mabye urnhttp:... and http:...?
One reason for asking such questions is that I know that
everybody here (except me:-) knows the conceptual and
technical differences between URLs and URNs, but actual
implementern will know less, resource creators even less,
and plain users even less.

>3) About those character set discussions, perhaps we should step back
>a little.  If I'm understanding the issues (and I certainly don't
>claim to be an expert on character set issues), it seems to me that
>the bottom line issue is that the thing to be avoided is false
>positives when looking at equality or equivalence of URNs.  The
>problem arises when something concludes that two URNs, once
>transcoded, transliterated, or whatever, are identifying the same
>resource, when they were intended to identify different ones.  False
>negatives in this situation may cause additional work, additional
>network traffic, and/or additional cost in other dimensions, but not
>incorrect behavior.  It is the incorrect behavior that must take the
>front seat.  With that in place, clearly the more effective we can be
>at avoiding false negatives the nicer it is, but that must be
>secondary.
>
>It seems to me if one keeps this in mind, some of the concerns that
>were brought up may fall into place a little more easily.  Such
>questions as two encodings for "A grave" take a backseat to making
>sure that the two encodings do not to get mapped into one, when in
>some namespace they are considered distinct, thus allowing for
>differentiation among resources.

Having thought again about some earlier comments I have made, and
also about some comments of Larry in a different list, I think
this is a very valid point. Even if we would specify that
A-Grave and A followed by combining-grave are equivalent,
it would be difficult that not suddenly somebody creates
e.g. two different files on an ftp server, only differing
in this aspect, because his/her file system doesn't know
about the way we have defined equivalence.

Nevertheless, I think we should not completely ignore this
problem, make an active and concious decision about it,
give some guidelines for implementors about how to proceed,
and put in some recommendation and/or warnings in the
relevant document(s).

Regards,	Martin.

Date: Tue, 29 Oct 1996 17:01:25 -0800 (PST)
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [URN] some comments
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

Karen writes:
| Not being a big fan of character set wars, I've sat by the sidelines

I hope we haven't been warring.  I just caught up on FTPEXT (where,
incidentally, Unicode is also an issue), and *that's* war.

| 1) There were a couple of almost parenthetical comments about the
| NAPTR proposal that made me worry.  It is important that we all agree
| that a URN syntax is independent of the NAPTR or any other URN
| resolution proposal. 

Absolutely.  And, skipping the discussion of "urn:", I believe
this is relevant to your last point:
 
| Now, my one other comment relates to an earlier topic - security.  I
| am in complete agreement with Ron (and whoever else) who said that
| security (and let's make sure we include integrity of the information
| in "security") that no one (user or publisher) should be required to
| support security and integrity.  But...if the infrastructure
| supporting URN resolution (which IS the topic of discussion for this
| WG) is to be able to provide security and integrity for anyone, there
| may be some requirements it will place on its clients (users and
| publishers).  I would like to be confident that we are all in
| agreement about the following: in the case where there are security
| measures that must be in place within the infrastructure in order to
| provide security (at some agreed upon level) to those who want it,
| even if that imposes some security requirements on those who don't
| want it, that the choice of having the security mechanisms in place
| will take precedence over not have the mechanisms.  Of course, within
| that constraint, wherever security isolation can be provided, security
| mechanisms should NOT be required.

You phrase this as a general matter, and we clearly cannot pretend
to govern all resolutions methods.  As a trivial example, one method
of URN resolution is the publication of physical books containing
URNs and other information.  Some URNs may be resolvable only by
such non-Internet means.  Suppose the government were to insist that
copies of such books that are sold to the government must be printed on 
tamper-resistant paper (someone wanting security).  Is that something 
this group should concern itself with?

I don't think so, I don't think that one can speak of *the* 
"infrastructure supporting URN resolution," and so I don't agree
with your very general statement.  Can you sharpen it up some?

Regards,
    Terry Allen    Fujitsu Software Corp.    [email-masked]
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

Date: Tue, 29 Oct 1996 19:02:31 -0500
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Subject: [URN] some comments
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

Not being a big fan of character set wars, I've sat by the sidelines
for a while.  I just reread all the messages to this list for the last
couple of weeks, trying to pick out places where there may be deeper
issues.  So, I have here a small list of somewhat disconnected
comments and questions.  For some of you this may not get to the heart
of the problems - my apologies.

Most of the discussion has centered around the URN syntex draft
written by Ryan Moats, so I will comment on that subject first.

1) There were a couple of almost parenthetical comments about the
NAPTR proposal that made me worry.  It is important that we all agree
that a URN syntax is independent of the NAPTR or any other URN
resolution proposal.  If we find that there are decisions that we all
agree are important for URN syntax, for which we find that the NAPTR
proposal is ill-equipped to deal (e.g. the relationship between
character sets and regular expressions) then we should NOT remove
those from the syntax document, but rather modify the NAPTR proposal.

2) About "urn:", I don't know whether I come from the other
"religious" viewpoint, but unless we have additional requirements and
mechanisms in place, I think it would be a really bad idea to make the
"urn:" optional.  Let's look at a few points here:

a) I don't believe that there is anything in the URL or URN
requirements documents (or any other RFCs) that states that prefixes
for URNs (without the "urn:") and URLs cannot be the same.

b) Given a random string (say foo://opaque_string) in some specific
situation, something needs to decide what it means and what to do with
it.  If the string is a URN it identifies a resource, while, if it is
a URL it identifies a location (in other words, it identifies an
abstraction from the perspective of a transport protocol, in fact, the
"foo" transport protocol).  So, now, without any specification of
urn-hood or url-hood, who makes a decision and how?

c) Consider how one might build applications, with respect to URNs
(it's too late for URLs to solve this problem).  Suppose five new
kinds of URNs are defined and five new kinds of URLs are defined.  The
application starts seeing strings with these ten new prefixes.  Now
the applications must have some mechanism for dealing with all these
new things.  So, assume it makes some decision, perhaps to send all
unidentifiable strings to a proxy for URNs.  This is something that
acts a front end for URN resolution.  For some large number of the
requests, the resolution will fail because truthfully, they were URLs.
Things could just as well have gone the other way if it was assumed
that the new strings are all URLs.  Some decision must be made one way
or the other.  The other alternative to the proxy is that the
application or some additional level of proxying does the
demultiplexing and is kept up to date with new kinds of URNs and
URLs.  If the answer is that the application must do it, then new
versions of every application using URNs must be distributed.  If the
answer is that there is a second level of proxying, we have now made
it take even longer to get an answer, by including another network
transit to the time to respond.

So, although I don't believe it is absolutely necessary, I do believe
that, first, if we don't require the "urn:" prefix we MUST document in
an RFC that URN and URL prefixes come from the same namespace and do
not overlap, and, second, if we do that, we understand that we are
potentially increasing the work to achieve new URN and URL resolution
activities.

3) About those character set discussions, perhaps we should step back
a little.  If I'm understanding the issues (and I certainly don't
claim to be an expert on character set issues), it seems to me that
the bottom line issue is that the thing to be avoided is false
positives when looking at equality or equivalence of URNs.  The
problem arises when something concludes that two URNs, once
transcoded, transliterated, or whatever, are identifying the same
resource, when they were intended to identify different ones.  False
negatives in this situation may cause additional work, additional
network traffic, and/or additional cost in other dimensions, but not
incorrect behavior.  It is the incorrect behavior that must take the
front seat.  With that in place, clearly the more effective we can be
at avoiding false negatives the nicer it is, but that must be
secondary.

It seems to me if one keeps this in mind, some of the concerns that
were brought up may fall into place a little more easily.  Such
questions as two encodings for "A grave" take a backseat to making
sure that the two encodings do not to get mapped into one, when in
some namespace they are considered distinct, thus allowing for
differentiation among resources.

***

Now, my one other comment relates to an earlier topic - security.  I
am in complete agreement with Ron (and whoever else) who said that
security (and let's make sure we include integrity of the information
in "security") that no one (user or publisher) should be required to
support security and integrity.  But...if the infrastructure
supporting URN resolution (which IS the topic of discussion for this
WG) is to be able to provide security and integrity for anyone, there
may be some requirements it will place on its clients (users and
publishers).  I would like to be confident that we are all in
agreement about the following: in the case where there are security
measures that must be in place within the infrastructure in order to
provide security (at some agreed upon level) to those who want it,
even if that imposes some security requirements on those who don't
want it, that the choice of having the security mechanisms in place
will take precedence over not have the mechanisms.  Of course, within
that constraint, wherever security isolation can be provided, security
mechanisms should NOT be required.

			Cheers,
			Karen

___________________________________________________________________
Karen R. Sollins				[email-masked]
Research Scientist				Phone: 617/253-6006
M.I.T. Laboratory for Computer Science		Fax:   617/253-2673
545 Technology Square
Cambridge, MA 02139

From: "Ryan Moats" <[email-masked]>
To: "Martin J Duerst" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Sun, 27 Oct 96 18:10:51 
Priority: Normal
Subject: Re: [URN] URN Syntax thoughts
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Fri, 25 Oct 1996 21:31:30 +0100 (MET), Martin J Duerst wrote:

>Larry Masenter wrote:
>
>>> Is it so much different to back away from the 10646/UTF-8 statement in 
>>> the syntax document and say "As part of the registration procedure, the
>>> character set/encoding used by a namespace shall be documented, or some
>>> such words to that effect."
>>
>>This is completely inadequate: the user and client need to be able to
>>translate the thing that the user sees on the cereal boxtop (sequence
>>of glyphs) into what gets transmitted over the network (sequence of
>>octets) in an unambiguous way. The translation method can't vary
>>depending on the the first part of what's translated.
>
>I definitely agree that we should not let things float too much.
>In may view, it should run down to the following statements:
>
>- If you create something new, and deal with characters, use UTF-8.
>- If you have something old, try to move towards UTF-8.
>- If you don't do UTF-8, be aware that support is not guaranteed
>	(i.e. you will have to print %HH on your cardboard box,...).
>	[So this means that the translation method doesn't vary.
>	 It's just not there in some cases :-).]
>- If you use an octet sequence that is not UTF-8, we won't consider
>	that an outright error.
>

I need to think about this some more, but I think I can live with this.  My
concern about the UTF-8 discussion was not just that I wasn't seeing
any closure, I wasn't seeing any direction of closure (and the discussion
seem to be growing in scope) which is why I started the new thread...

Date: Fri, 25 Oct 1996 14:34:58 -0700 (PDT)
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] URN Syntax thoughts
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>
Ron:

| >I'm not seeing any closure on the UTF-8 issue,
| 
| I'm willing to give this issue some more time. I have not seen any

as am I.

| strong opposition to using UTF-8. What I think is the outstanding
| question on the use of UTF-8 is something like "what about namespaces
| that want to provide octets that are not UTF-8?"
| 
| My answer: Tough. If people want to ship around binary data as their
| names, then they can encode it in a fashion similar to the data:
| URL scheme where they have 2 choices:
|   1) Base64  (which uses only safe characters)
|   2) %encoding (which uses only safe characters)

Suppose they don't, though?  What is the effect of saying "tough"?
What happens to people who contumaciously people promulgate URNs that 
(perhaps only in part) are not encoded in UTF-8 (and, perhaps, are not 
even in Unicode).  Or who do this because their software is buggy
or because their employers made them do it (think Dilbert)?
What will break?

The intuition of Joe Namespace is likely to be that he can construct
a URN for his unique name (XXXXXX, not in UTF-8) by prefixing those
hierarchical name space division markers he usually takes for
granted (A/B/C/XXXXXX), prefixing the NIS for his top-level
name space (sludge:A/B/C/XXXXXX), and depending on his religion
(though we really should not use the term "religious issue" in
a formal document ...), prefixing "urn:".  Leaving aside the
question of whether A/B/C is in UTF-8, is it plausible to believe
that Joe Namespace will accept a regime in which his unique name
is XXXXXX but appears in a URN as XYZXYZ (UTF-8 encoded)?

I'm inclined to think that urn:sludge:A/B/C/XXXXXX should be
allowed because it seems like common sense (to me, at the moment,
still), and will occur (because it seems like common sense to
Joe Namespace, or his employer, or because Joe lacks a tool that does
UTF-8 conversion).

What arguments are there that urn:sludge:A/B/C/XXXXXX cannot be
resolved if urn:sludge:A/B/C/XYZXYZ can be?  (as distinct from
arguments that XYZXYZ can be resolved faster or more efficiently
than XXXXXX.)  And what of the two subcases:  A/B/C/ is UTF-8
or is not?

Regards,
    Terry Allen    Fujitsu Software Corp.    [email-masked]
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

Subject: Re: [URN] URN Syntax thoughts
To: [email-masked]
Date: Fri, 25 Oct 1996 21:31:30 +0100 (MET)
Cc: [email-masked], [email-masked]
Content-Length: 3112
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Larry Masenter wrote:

>> Is it so much different to back away from the 10646/UTF-8 statement in 
>> the syntax document and say "As part of the registration procedure, the
>> character set/encoding used by a namespace shall be documented, or some
>> such words to that effect."
>
>This is completely inadequate: the user and client need to be able to
>translate the thing that the user sees on the cereal boxtop (sequence
>of glyphs) into what gets transmitted over the network (sequence of
>octets) in an unambiguous way. The translation method can't vary
>depending on the the first part of what's translated.

I definitely agree that we should not let things float too much.
In may view, it should run down to the following statements:

- If you create something new, and deal with characters, use UTF-8.
- If you have something old, try to move towards UTF-8.
- If you don't do UTF-8, be aware that support is not guaranteed
	(i.e. you will have to print %HH on your cardboard box,...).
	[So this means that the translation method doesn't vary.
	 It's just not there in some cases :-).]
- If you use an octet sequence that is not UTF-8, we won't consider
	that an outright error.

I repeat the main reasons for why I think this amount of flexibility
is necessary. First, there are cases where you don't know what
encoding is used. You could treat that like the data URL, but
in some cases, this would mean that you would have to split
functionality that now comes together. FTP is a typical example.
It is very difficult to specify that servers that don't know
the encodings of their filenames should use a data-like scheme,
and those that know the encoding can use UTF-8. It is much
more encouraging to say: If you know, convert to UTF-8; if you
don't know, use raw octets. This gives a very smooth transition.

The other reason for flexibility is political. Some people are,
for some sometimes rather strange reasons, heavily against
Unicode. It's much easier to deal with them if we don't
"force everybody to use Unicode". Still, we want things to
go in that direction, so simplify things, and so just saying
"the namespaces take care" is of no use.

A minor, but maybe serious, problem in this approach is the
following: Assume at some point (either at entry or at some
server) some general UTF-8 URN normalization/canonicalization
is done. It's easy to say that no such thing should be done
on octet sequences that are not legal UTF-8. But there is
a slight possiblity that some arbitrary octet sequence is
UTF-8 (and not pure ASCII). Here are the probabilities,
derived mostly by simulation:
Length of sequence	approximate probability
1			0
2			1/32
3			1/28
4			1/35
5			1/48
6			1/70
7			1/107
8			1/175
9			1/287
10			1/465
15			1/6450
20			1/100000

Of course, the probabilities of octet sequences that would
be affected by normalization is much much lower, esp. if this
normalization is restricted to cases of the A-grave type.
It might be possible to construct a RISK case out of this :-(.

Still, I think a little bit of flexibility for backwards
compatibility is desirable.

Regards,	Martin.

Subject: Re: [URN] Unicode for NSS query
To: [email-masked] (Larry Masinter)
Date: Fri, 25 Oct 1996 20:27:11 +0100 (MET)
Cc: [email-masked]
Content-Length: 2336
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Larry Masenter wrote:

>The way that i think of this is that the constraints:
>
>1 'has a unique sequence of octets that can be unambiguously interpreted by a
>  system'
>
>2 'has a unique sequence of glyphs that can be unambiguously displayed
>  and subsequently entered by a user'
>  
>cannot be mutually satisfied. The simplest way to think about this is
>to have two kinds of representations of URNs: as a canonical sequence
>of octets, and as a user-entered string. Every URN has a single
>canonical representation, and the user entry method must map it to the
>canonical representation. No embedded URN-as-protocol-element should
>require canonicalization. The protocol for 'canonicalizing' a name may
>not be the same as the protocol for 'resolving' a name or asking for
>information about it.

Larry, I have some difficulties understanding you. By user-entered
string, do you mean the stuff on the cardboard box, and maybe the
pixels on the screen that the user sees when typing it in? Or do
you mean some kind of represenation that is moved around inside
the computer?

And why do you think that the two cannot be mutually satisfied?
It works for ASCII, anyway. For some other scripts, it is a little
bit more difficult, but some of these problems are similar to
what we have currently when somebody confuses "O" and "0" or
"l" and "1" and "I", and others, such as the A-grave case,
could be defined by normalization, which would also be required
for deriving your "canonical representation".

The problem of embedding is of course a tough one. One way to
interpret your statement is that it means that e.g. in an HTML
document, URL/Ns would only appear in the %HH notation (because
arbitrary octets would not usually pass the SGML parser).
This would indeed be rather restricting. I could easily immagine
that a Japanese document author constructs a document encoded
in SJIS, and just writes down a Japanese URL/N from the cardbord
box as is. It would technically be no problem for the browser
to take this URL/N, interpret it as SJIS, convert it to UTF-8,
maybe normalize it, and then pass it to some resolving mechanism.

If you see some problems with this, please tell me. If you don't
want to call the visible (e.g. in SJIS) form an URL/N, I can
accept that, but users will soon call it that way anyway.

Regards,	Martin.

Date: Fri, 25 Oct 1996 10:38:45 -0600
To: [email-masked], "URN mailing list" <[email-masked]>
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] URN Syntax thoughts
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke [email-masked] (at least at 08:15 AM 10/25/96)

>I'm not seeing any closure on the UTF-8 issue,

I'm willing to give this issue some more time. I have not seen any
strong opposition to using UTF-8. What I think is the outstanding
question on the use of UTF-8 is something like "what about namespaces
that want to provide octets that are not UTF-8?"

My answer: Tough. If people want to ship around binary data as their
names, then they can encode it in a fashion similar to the data:
URL scheme where they have 2 choices:
  1) Base64  (which uses only safe characters)
  2) %encoding (which uses only safe characters)

I say we go with UTF-8 as the interpretation of any 8-bit characters.

Comments?
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"

To: [email-masked]
Cc: [email-masked]
Subject: Re: [URN] URN Syntax thoughts
From: Larry Masinter <[email-masked]>
Date: Fri, 25 Oct 1996 09:09:02 PDT
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

> Is it so much different to back away from the 10646/UTF-8 statement in 
> the syntax document and say "As part of the registration procedure, the
> character set/encoding used by a namespace shall be documented, or some
> such words to that effect."

This is completely inadequate: the user and client need to be able to
translate the thing that the user sees on the cereal boxtop (sequence
of glyphs) into what gets transmitted over the network (sequence of
octets) in an unambiguous way. The translation method can't vary
depending on the the first part of what's translated.

Larry

From: [email-masked]
Original-From: "Ryan Moats" <[email-masked]>
To: "URN mailing list" <[email-masked]>
Date: Fri, 25 Oct 96 08:15:06 
Priority: Normal
Subject: [URN] URN Syntax thoughts
Sender: [email-masked]
Reply-To: [email-masked]

Folks-

I'm not seeing any closure on the UTF-8 issue, and having seen some of the
comments on allowing namespaces (either existing or new?) to use alternate
things by including that information in their registration document, I see the 
situation that a URN resolver will have to know about schemes documented
in many different documents.

Is it so much different to back away from the 10646/UTF-8 statement in 
the syntax document and say "As part of the registration procedure, the
character set/encoding used by a namespace shall be documented, or some
such words to that effect."  This really slams the lexical equivalence discussion
at the client down to "remove %encoding and do octet by octet comparison to
determine if the NSS is equivalent. If the NSSs are equivalent and the NIDs
are equivalent (case insensitivity here), the URNs are deemed equivalent".
It doesn't (in my mind) change the lexical equivalence discussion at the server
and I think it simplifies the issue.  We can put in a statement like "new
namespaces SHOULD use 10646/UTF-8" somewhere.

I know that somebody mentioned this (I can't find the mail right now...)
I'm just asking the question over again (with a new subject thread so I can
keep it seperate from the other discussions).

Ryan

To: [email-masked]
Cc: [email-masked]
Subject: Re: [URN] Unicode for NSS query
From: Larry Masinter <[email-masked]>
Date: Thu, 24 Oct 1996 18:22:27 PDT
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

The way that i think of this is that the constraints:

1 'has a unique sequence of octets that can be unambiguously interpreted by a
  system'

2 'has a unique sequence of glyphs that can be unambiguously displayed
  and subsequently entered by a user'
  
cannot be mutually satisfied. The simplest way to think about this is
to have two kinds of representations of URNs: as a canonical sequence
of octets, and as a user-entered string. Every URN has a single
canonical representation, and the user entry method must map it to the
canonical representation. No embedded URN-as-protocol-element should
require canonicalization. The protocol for 'canonicalizing' a name may
not be the same as the protocol for 'resolving' a name or asking for
information about it.

Date: Thu, 24 Oct 1996 15:45:06 -0700
From: "Frederick G.M. Roeber" <[email-masked]>
Organization: Netscape
To: [email-masked]
Subject: [URN] Couple points about the draft..
Sender: [email-masked]
Reply-To: "Frederick G.M. Roeber" <[email-masked]>

1) Under "NAPTR RR Format," under "Flags," second paragraph:

"The S and A flags are mutually exclusive, and resolution libraries
SHOULD signal an error so that bad NAPTRs can be quickly detected."

I disagree with that SHOULD.  It's fine for experimental code, but not
for something I ship to customers: they're not going to expect or like
receiving error messages for someone else's mistakes.

I think it should be something more like,

"The S and A flags are mutually exclusive, [and clients should cope]. 
Clients MAY point out this error so that bad NAPTRs might be quickly
detected."

2) Without yet throwing my ante into the "`urn:' being optional"
discussion, I'd like to point out an unclear statement:  Under "Notes:,"
the first note: "The `urn:' prefix is a matter of religious
controversy.  Client code should handle...."

Is that "should" a SHOULD?

Ron pointed out privately that if the prefix is indeed optional, then
the "should" has to be a MUST.

-- 
Frederick G.M. Roeber
Physicist in Residence, Netscape Communications Corporation

Subject: Re: [URN] Unicode for NSS query
To: [email-masked]
Date: Thu, 24 Oct 1996 23:02:13 +0100 (MET)
Cc: [email-masked]
Content-Length: 5224
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Ryan wrote:
>
>On Thu, 24 Oct 1996 21:47:41 +0100 (MET), Martin J Duerst wrote:
>
>>>
>>>On Thu, 24 Oct 1996, Martin J Duerst wrote:
>>>
>>>> 
>>>> I have suggested that we might be required to thing in terms of
>>>> both characters and octets. For some things, similar to a data:
>>>> URL, thinking in characters might be artificial. For some
>>>> other things, such as URLs, thinking in octets may to some
>>>> extent be necessary because of backwards compatibility issues
>>>> (assume an URL scheme is extended and decides to use some
>>>> weird RFC 1522-like method for encoding characters, and this
>>>> would have to be grandfathered).
>>>>
>>>
>>>I have thought about the same thing, and I admit that I am not altogether
>>>enthusiastic about RFC 1522 style encoding of URNs, but it may be forced
>>>upon us. 
>>
>>Well, I didn't mean that this is currently the case. The ftp
>>i18n extensions, for example, are happily going in the direction
>>of UTF-8 and would very well fit together with our proposal.
>>
>>But I have made the experience that trying to specify UNicode only
>>can meet quite some resistance. Some people, for whatever reasons,
>>are strongly anti-unicode. If you specify something like
>>"urns use Unicode and nothing else", they may start to complain.
>>If you say "urns should use Unicode, and clients should interpret
>>urns as Unicode if possible, but if really necessary, an NSS
>>can use something else" then it's difficult to oppose, even
>>if maybe in actual practice, there will not be a single NSS
>>that ever specifies something else than Unicode.
>
>Huh?  My "knee-jerk" reaction is that by saying that client should convert from
>an NSS that isn't in Unicode(10646)/UTF-8 shall be converted before
>being sent to the URN resolver handles this nicely.  I include in this statement
>the act of entering a NSS at an interface in some other encoding (ASCII, etc.)

Yes, but sometimes you would just not know what charset the
stuff is in. Note that there are two things:

- The user types in an urn into an application that locally
	uses some other encoding, which then gets converted
	to UTF-8 at the moment the application knows this is
	an URN.
- There is an NSS that for some reasons, and maybe for some
	of its namespace only, doesn't have a clue about what
	characters it's dealing with, or explicitly wants
	to have the relation between characters and octet
	values different that UTF-8 for some reason whatsoever.
It is the later that I am speaking about, not the former.

>>NSSs or URL shemes (I still have problems distingushing them)
>>themselves might also do the same thing, namely saying that
>>in general, character semantics should be ISO 10646/UTF-8, but
>>that other things would be tolerated for backwards compatibility.
>>This is exactly the case for ftp, where a lot of 8-bit filenames
>>are already existing and in use, although not UTF-8.
>
>I'm not sure I'm comfortable with this.  My view is that the documentation of the NID
>would specify this as an exception to the syntax document and the syntax document
>says "here's the syntax, but exceptions are allowed for namespaces that document 
>there exceptions elsewhere?  Seems awfully kludgy to me...

Yes, in some sense it is. But this is reality, which is not always
simple and logic.
Take ftp as an example. Although not officially standardised,
a lot of ftp hosts have files with 8-bit octets in their names.
Although you can make some guesses about what characters these
octets stand for, you are really not sure. Even on the same
server, or in the same URL, different files, or different parts,
may have different encodings, because the encodings reflect the
settings of the users that created these filenames.
And it is impossible to force upon all existing ftp servers
that they suddenly know what characters their filenames
represent if up to now URLs have been octets and nothing else.

The only thing we can hope for, and which we are working for
in the ftp-wg, is a gradual transition towards UTF-8.

>>It is also important because not every arbitrary sequence of
>>8-bit octets is an UTF-8 sequence. What should browsers, resolvers,
>>and all the other components of our URN arichitecture do with
>>these?
>
>I expect that anything that tries to resolve a sequence of 8-bit octets that aren't a
>UTF-8 sequence should fail, unless the namespace has provided information otherwise.

That might be a solution, unless there are resolvers that do resolution
without knowing much about specific namespaces. But for existing
URL schemes, the assumption would have to be that they implicitly
specify otherwise.

>I see this as related to the above issue:  The two basic choices are:
>
>(1) Allow things other than UTF-8 (and force the exceptions to be documented as
>part of namespace registration).  The resolvers then have to use the namespace
>specific information (including exceptions).  (2) Do not allow other than UTF-8 and
>reject the arbitrary 8-bit octet sequence as unresolvable if it is unresolvable.
>
>The first is cleaner from the point of view of the end-users, the second from the point
>of view of internal clenliness.

The second, at any rate, is not very practical.

Regards,	Martin.

From: [email-masked]
Original-From: "Ryan Moats" <[email-masked]>
To: "Martin J Duerst" <[email-masked]>
Cc: "URN mailing list" <[email-masked]>
Date: Thu, 24 Oct 96 15:46:15 
Priority: Normal
Subject: Re: [URN] Unicode for NSS query
Sender: [email-masked]
Reply-To: [email-masked]

On Thu, 24 Oct 1996 21:47:41 +0100 (MET), Martin J Duerst wrote:

>>
>>On Thu, 24 Oct 1996, Martin J Duerst wrote:
>>
>>> 
>>> I have suggested that we might be required to thing in terms of
>>> both characters and octets. For some things, similar to a data:
>>> URL, thinking in characters might be artificial. For some
>>> other things, such as URLs, thinking in octets may to some
>>> extent be necessary because of backwards compatibility issues
>>> (assume an URL scheme is extended and decides to use some
>>> weird RFC 1522-like method for encoding characters, and this
>>> would have to be grandfathered).
>>>
>>
>>I have thought about the same thing, and I admit that I am not altogether
>>enthusiastic about RFC 1522 style encoding of URNs, but it may be forced
>>upon us. 
>
>Well, I didn't mean that this is currently the case. The ftp
>i18n extensions, for example, are happily going in the direction
>of UTF-8 and would very well fit together with our proposal.
>
>But I have made the experience that trying to specify UNicode only
>can meet quite some resistance. Some people, for whatever reasons,
>are strongly anti-unicode. If you specify something like
>"urns use Unicode and nothing else", they may start to complain.
>If you say "urns should use Unicode, and clients should interpret
>urns as Unicode if possible, but if really necessary, an NSS
>can use something else" then it's difficult to oppose, even
>if maybe in actual practice, there will not be a single NSS
>that ever specifies something else than Unicode.

Huh?  My "knee-jerk" reaction is that by saying that client should convert from
an NSS that isn't in Unicode(10646)/UTF-8 shall be converted before
being sent to the URN resolver handles this nicely.  I include in this statement
the act of entering a NSS at an interface in some other encoding (ASCII, etc.)

>NSSs or URL shemes (I still have problems distingushing them)
>themselves might also do the same thing, namely saying that
>in general, character semantics should be ISO 10646/UTF-8, but
>that other things would be tolerated for backwards compatibility.
>This is exactly the case for ftp, where a lot of 8-bit filenames
>are already existing and in use, although not UTF-8.

I'm not sure I'm comfortable with this.  My view is that the documentation of the NID
would specify this as an exception to the syntax document and the syntax document
says "here's the syntax, but exceptions are allowed for namespaces that document 
there exceptions elsewhere?  Seems awfully kludgy to me...

>It is also important because not every arbitrary sequence of
>8-bit octets is an UTF-8 sequence. What should browsers, resolvers,
>and all the other components of our URN arichitecture do with
>these?

I expect that anything that tries to resolve a sequence of 8-bit octets that aren't a
UTF-8 sequence should fail, unless the namespace has provided information otherwise.
I see this as related to the above issue:  The two basic choices are:

(1) Allow things other than UTF-8 (and force the exceptions to be documented as
part of namespace registration).  The resolvers then have to use the namespace
specific information (including exceptions).  (2) Do not allow other than UTF-8 and
reject the arbitrary 8-bit octet sequence as unresolvable if it is unresolvable.

The first is cleaner from the point of view of the end-users, the second from the point
of view of internal clenliness.

Ryan

Subject: Re: [URN] re URN sytax
To: [email-masked]
Date: Thu, 24 Oct 1996 22:32:25 +0100 (MET)
Cc: [email-masked]
Content-Length: 1079
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Terry Allen writes:

>Martin writes:
>| So I think the spec should go more in the direction of:
>| 
>| - If an NSS contains characters, these should be encoded using UTF-8.
>| - If an NSS contains something else (e.g. pure data), this can be
>| 	encoded directly using %HH.
>
>Just to keep myself clear on what you're saying, ISO 10646 mixes
>glyphs and characters.  By "characters" above, are you excluding
>glyphs-that-are-not-themselves-characters?  Are those glyphs 
>data?  Or do you expect people not to use glyphs that aren't
>characters?

ISO 10646 in theory codes characters, not glyphs. In practice,
the distinction is sometimes difficult to make, and sometimes,
glyphs have sneaked in for backwards compatibility.

Indeed, I expect a rather low use of glyphs that are not characters.
For example, it is rare that any system produces an "fi" ligature
(in the encoded text) if you type "f" and "i", and I don't think
people will care about one or the other in something like an URN.
The same applies for Arabic glyph variants and ligatures, and so on.

Regards,	Martin.

Subject: Re: [URN] Pre release of URN Syntax document....
To: [email-masked]
Date: Thu, 24 Oct 1996 22:11:59 +0100 (MET)
Cc: [email-masked], [email-masked]
Content-Length: 2228
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Ryan Moats wrote:

>On Mon, 21 Oct 1996 20:36:58 +0200 (MET DST), Patrik Faltstrom wrote:
>>
>>On Mon, 21 Oct 1996, Martin J Duerst wrote:
>>
>>> The other big problem is equivalence. For Unicode, character equivalence
>>> is in some cases not the same as codepoint equivalence. Charecter
>>> equivalence is well defined, but there is currently no standard
>>> for normalization.
>>
>>What exists are the decomposition rules for Unicode. Those are well defined.

Yes, but they define equivalence, not normalization. So every
instance wanting to compare two urns would have it included.
With normalization, it would only be those instances that
"produce" urns, i.e. where resources are named or where
urns are entered into a computer.

>>> This does not concern things such as case,
>>> where the user can easily distinguish lower case and upper case,
>>> but cases such as A-with-Grave, which can be encoded both as
>>> one single codepoint and as the sequence A, Grave.
>>
>>The casing is also defined in the Unicode spec.

Yes, but it is clearly NSS-dependent, and language-dependent
in addition. And in contrast to such things as the A-grave
story, no user will be surprised that a lower case and an
upper case character are not the same.

>>> Another problem that should be considered are bidirectionality
>>> for Hebrew and Arabic.
>>
>>It should be defined, just like in MIME, that characters are
>>stored in the order they are stored, not displayed. (At least
>>I remember that we discussed this with display order in the
>>MIME community in an interesting meeting faaaar back in time,
>>which was ended by looking at some example where two hebrew
>>users, using the same computer, was using different display
>>order...).
>
>I agree with Patrik.  Regardless of glyph direction order, NSS octets
>are in order of presentation ie. (for left->right, left most character first,
>for right->left right most character first, etc.)

It's not as easy as that. Are Bidi control characters allowed in
urns? Overrides (overriding implicit reordering and thus
basically specifying presentation order) are very convenient
e.g. for part numbers, and there are quite some similarities
between part numbers and urns.

Regards,	Martin.

Subject: Re: [URN] What is equivalence?
To: [email-masked]
Date: Thu, 24 Oct 1996 22:00:37 +0100 (MET)
Cc: [email-masked], [email-masked], [email-masked]
Content-Length: 2742
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Ron Daniel wrote:

>Thus spoke Larry Masinter (at least at 12:46 AM 10/23/96 PDT)
>
>[I'm responding to Larry's paragraphs in a different order than
>he sent them]
>
>>While there's not much problem if two strings that are not equivalent
>>now might be declared equivalent in the future, there's a serious
>>problem if two strings that are equivalent now are determined to be
>>non-equivalent later.

Unless something like reshuffling the whole of ISO 10646 happens,
this will not occur. It definitely does not occur when introducing
new precombined characters, which is the main thing we have to
worry about.

>>The issue for Unicode decomposition is that it is possible to imagine
>>Unicode adding some new composition rule in the future.  Thus, the
>>time scope of the equivalence relationship is limited:
>
>I asume that the character equivalances in ISO 10646 are set, and
>that any additional equivalances would be under a new standard.

ISO 10646 does not define any character equivalences. Unicode does.
And new equivalences are added with the addition of new characters
that can be decomposed.

>So, while I agree that the equivalances could change over time, the
>URN syntax draft (if we decide to do UNICODE character equivalents)
>should probably say that the 10646 equivalants are the ones we do.
>That set of equivalances would not change over time.

To restrict ourselves to a particular
version of Unicode/ISO 10646 would make sense if we decide that
urns have to be normalized. We might then normalize on precombined
up to version 2.0 (and the corresponding ISO amendments) and
on decomposed for the rest.
If we decide that normalization is done during comparison, then
there is no great benefit in fixing a version; as Larry has pointed
out, there might just be suboptimal equivalence in old implementations.

>Personally, I have no opinion on UNICODE character equivalants.
>Patrik presented the arguments for both sides. I like the implementation
>ease of not doing equivalents, but then we are not doing "true" 10646
>so we have to very careful about the wording of the URN syntax draft.
>Anyone out there with strong opinions one way or the other?

We would actually do something like "true" 10646. But the main point
is that if we don't do equivalence (e.g. in the A-grave case), it's
going to surprise users a lot. If you are looking for a "O", and
find out you typed an "0", you will probably blame yourself.
If you are looking for A-grave, and find out you had to look for
A-grave instead (only that there were two different encodings of
it, on which you are not supposed to have any influence because
they are equivalent), you will blame somebody else, either
Unicode or ISO or the URN group.

Regards,	Martin.

Date: Thu, 24 Oct 1996 22:03:27 +0200 (MET DST)
From: Patrik Faltstrom <[email-masked]>
To: "Gregory J. Woodhouse" <[email-masked]>
Cc: Martin J Duerst <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Unicode for NSS query
Sender: [email-masked]
Reply-To: Patrik Faltstrom <[email-masked]>

On Thu, 24 Oct 1996, Gregory J. Woodhouse wrote:
> 
> I have thought about the same thing, and I admit that I am not altogether
> enthusiastic about RFC 1522 style encoding of URNs, but it may be forced
> upon us. 
>  

This is exactly why I think we should state that only one
character set is used for urn:s which is to be used together
with one kind of encoding. With 1522 you can use any character set
and two different encodings.

  paf

From: [email-masked]
Original-From: "Ryan Moats" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 24 Oct 96 14:57:28 
Priority: Normal
Subject: Re: [URN] Unicode for NSS query
Sender: [email-masked]
Reply-To: [email-masked]

On Thu, 24 Oct 1996 10:25:11 -0700 (PDT), Terry Allen wrote:

>| (Note that the NAPTR resolution scheme is probably going to find
>| it impossible to get people to resolvers if that decision has to be made
>| on non-ASCII characters in the URN. Since NAPTR is intended for
>| Experimental rather than standards track this may be OK. I will take a
>| look at what can be done to deal with UNICODE in regexps.)
>
>Ah, I see.  That part of the NSS that deals with its hierarchy
>(and hence must be dealt with to get the client to a resolver)
>presents a different problem than the rest of it; do I have that
>right?  E.g.,
>
>  urn:world.dynasties:ottomans/15th.century/Bursa/XXXXXXXXXX
>
>has to get to the "Bursa" resolver, but XXXXXXXXXX could be 
>anything?

I would have put this a different way.  My view of the NAPTR proposal is that the
"resolver" is hit once the NID is looked up.  The 'regexp' stuff is how the resolver
handles the NSS string.  Thus, what becomes impossible is not "getting to the resolver"
in my view, it is either "extracting the naming authority" or "resolving the NSS".

Ryan Moats

Subject: Re: [URN] Unicode for NSS query
To: [email-masked] (Gregory J. Woodhouse)
Date: Thu, 24 Oct 1996 21:47:41 +0100 (MET)
Cc: [email-masked], [email-masked], [email-masked]
Content-Length: 2030
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

>
>On Thu, 24 Oct 1996, Martin J Duerst wrote:
>
>> 
>> I have suggested that we might be required to thing in terms of
>> both characters and octets. For some things, similar to a data:
>> URL, thinking in characters might be artificial. For some
>> other things, such as URLs, thinking in octets may to some
>> extent be necessary because of backwards compatibility issues
>> (assume an URL scheme is extended and decides to use some
>> weird RFC 1522-like method for encoding characters, and this
>> would have to be grandfathered).
>>
>
>I have thought about the same thing, and I admit that I am not altogether
>enthusiastic about RFC 1522 style encoding of URNs, but it may be forced
>upon us. 

Well, I didn't mean that this is currently the case. The ftp
i18n extensions, for example, are happily going in the direction
of UTF-8 and would very well fit together with our proposal.

But I have made the experience that trying to specify UNicode only
can meet quite some resistance. Some people, for whatever reasons,
are strongly anti-unicode. If you specify something like
"urns use Unicode and nothing else", they may start to complain.
If you say "urns should use Unicode, and clients should interpret
urns as Unicode if possible, but if really necessary, an NSS
can use something else" then it's difficult to oppose, even
if maybe in actual practice, there will not be a single NSS
that ever specifies something else than Unicode.

NSSs or URL shemes (I still have problems distingushing them)
themselves might also do the same thing, namely saying that
in general, character semantics should be ISO 10646/UTF-8, but
that other things would be tolerated for backwards compatibility.
This is exactly the case for ftp, where a lot of 8-bit filenames
are already existing and in use, although not UTF-8.

It is also important because not every arbitrary sequence of
8-bit octets is an UTF-8 sequence. What should browsers, resolvers,
and all the other components of our URN arichitecture do with
these?

Regards,	Martin.

Subject: Re: [URN] UNICODE or not UNICODE?
To: [email-masked]
Date: Thu, 24 Oct 1996 21:38:19 +0100 (MET)
Cc: [email-masked], [email-masked]
Content-Length: 4139
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

>
>Terry wrote
>> - why care?  the NSS is supposed to be opaque
>> - does this imply that a) NSSs should be formed originally
>>   in Unicode, or that b) NSSs in other coded character sets
>>   must be translated/transliterated into Unicode in forming
>>   URNs, or c) something else?
>
>The problem with not defining a character set is that it will
>be impossible to do any comparison between two URNs. We need to have
>some ability to do comparisons, and the only reasonable way of doing that
>is to use _one_ character set.
>
>To answer the second question, you have to have a urn in a different
>character set in some cases, for example in a client which does not
>use UNICODE. You then have to do translation.
>
>What we did in Digger, the Whois++ server Bunyip has, was using the
>rules for comparison (decomposition + sorting) and translation rules
>that the UINCODE consortium have defined.
>
>The UNICODE tables include for each character one kind of equivalence
>which is the rule for decomposition of that code point in UNICODE
>into more than one other code point. One example, the letter '=C4'.
>
>In UNICODE, this character is defined as:
>
>00C4;LATIN CAPITAL LETTER A WITH DIAERESIS;Lu;0;L;0041 0308;;;;N;
>     LATIN CAPITAL LETTER A DIAERESIS;;;00E4;
>
>One can here see that the codepoint, U+00C4, is equivalent to U+0041
>followed by U+0308. One can also see that the lower case version of this
>character is U+00E4 (among other things).
>
>When comparing two strings, and one of them include "U+00C4"
>and the other one the sequence "U+0041"+"U+0308" these strings
>should be considered equal in the sense of the UNICODE spec.
>
>Note that I am not talking about ISO-10646 here, as I am not at all
>familiar with what parts of this is included in the 10646 spec. This
>is UNICODE 2.0 we are talking about!

ISO 10646 does not define any such equivalences, but also in other
cases defines much less charcter properties and semantics.

>This means that before comparing the strings that include "U+00C4"
>and "U+0041"+"U+0308", all code points have to be decomposed into its
>maximal decomposition possible. I.e. "U+00C4" have to be changed to
>"U+0041"+"U+0308", and these have to be sorted (i.e. one can know
>from the code tables that "U+0041" is to be before "U+0308" in
>a composed character).

Sorting really only occurs on diacritics; the base character
(A or U+0041 here) is not involved. Sorting is necessary becaus
you can have A with X on top and Y below, which you can encode
as AXY or AYX. Sorting is restricted because you can have X
and Z with both go on top, and in this case AXZ means Z atop
X (atop A), and AZX means X atop Z, and these two are not
equivalent.

>THEN we do the comparison codepoint by codepoint.
>
>If we wanted to do case insensitive matching, we use the information
>from the UNICODE consortium about what is a lower case character.

Well, with case we get into problems, as the correspondences
supplied by Unicode work for almost all languages, but have
some exceptions (e.g. Turkish). But case equivalence
is not needed in the general urn syntax.

>>or use Unicode code points that
>>indicate glyph variants of a letter, such as 06AA, "Arabic
>>Letter Swash Kaf," which is lexically the same as 0643,
>>"Arabic Letter Kaf`" or specify some ligatures).
>
>I don't know Arabic, but I am just following the rules that
>UNICODE consortioum have set up, and according to these
>rules, U+06AA and U+0643 is not equivalent characters
>when comparing:
>
>06AA;ARABIC LETTER SWASH KAF;Lo;0;R;;;;;N;ARABIC LETTER SWASH CAF;;;;
>0643;ARABIC LETTER KAF;Lo;0;R;;;;;N;ARABIC LETTER CAF;;;;
>
>I am not arguing if this descision by the UNICODE consortium
>was correct or not, but _someone_ that they trusted must have
>told them these are different characters.

I don't know the use of swash kaf either, but I would assume
that it is used as a special character in some languages,
in some specific cases or to denote a different sound.
This would mean that people who really want to use swash
kaf in their unrs would not have a problem distinguishing
it from the normal kaf.

Regards,	Martin.

Date: Thu, 24 Oct 1996 12:31:49 -0700 (PDT)
From: "Gregory J. Woodhouse" <[email-masked]>
To: Martin J Duerst <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Unicode for NSS query
Sender: [email-masked]
Reply-To: "Gregory J. Woodhouse" <[email-masked]>

On Thu, 24 Oct 1996, Martin J Duerst wrote:

> 
> I have suggested that we might be required to thing in terms of
> both characters and octets. For some things, similar to a data:
> URL, thinking in characters might be artificial. For some
> other things, such as URLs, thinking in octets may to some
> extent be necessary because of backwards compatibility issues
> (assume an URL scheme is extended and decides to use some
> weird RFC 1522-like method for encoding characters, and this
> would have to be grandfathered).
>

I have thought about the same thing, and I admit that I am not altogether
enthusiastic about RFC 1522 style encoding of URNs, but it may be forced
upon us. 

---
Gregory Woodhouse     [email-masked]
home page:            http://www.wnetc.com/
resource page:        http://www.wnetc.com/resource/

Date: Thu, 24 Oct 1996 12:26:53 -0700 (PDT)
From: "Gregory J. Woodhouse" <[email-masked]>
To: [email-masked]
Subject: Re: [URN] Unicode for NSS query
Sender: [email-masked]
Reply-To: "Gregory J. Woodhouse" <[email-masked]>

It seems to me that since URNs are not just protocol elements, but also
function as user interface elements that it is not sufficient to regard the
NSS part of the URN as a string of octets. This would be fine, I suppose if
URNs only appeared in (say) HTTP requests, but since users will enter URNs
int controls in user agents, and since URNs will be published in readable
form (e.g., in bibliographies) we are forced to regard them as being
encoded in a character set (such as Unicode). I know this is basically just
a matteer of stating a tacit assumption, but I believe someone did ask why
we couldn't treat it as an octet stream.

---
Gregory Woodhouse     [email-masked]
home page:            http://www.wnetc.com/
resource page:        http://www.wnetc.com/resource/

Subject: Re: [URN] Unicode for NSS query
To: [email-masked]
Date: Thu, 24 Oct 1996 21:15:30 +0100 (MET)
Cc: [email-masked], [email-masked]
Content-Length: 6937
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Terry Allen wrote:

>Thanks to Patrik and Ron.  I think I need to go out and buy
>those Unicode books today.  Some clarifications:

Version 2.0 is out now, and it's only one book.
Addison-Wesley, urn:isbn:0-201-48345-9 :-).

>| > - why care?  the NSS is supposed to be opaque
>| Which means? I think it means we can't go around inferring
>| structure in arbitrary namespaces. Opaque does not mean
>| that we have to take whatever comes. There can be particular
>| requirements on the characters allowed.
>| I think this WG should make
>| an explicit decision on trying to go to UNICODE rather than
>| just defaulting to ASCII. The reasons for doing so:
>|   1) The IAB workshop tells us to try to do so.
>|   2) Not all the namespaces in the world use the Latin alphabet
>|      without accents.
>|   3) Isn't it time we start getting away from the US-ASCII assumption?
>
>I don't want to assume ASCII, but I was wondering, why think in terms 
>of characters and not octets?

I have suggested that we might be required to thing in terms of
both characters and octets. For some things, similar to a data:
URL, thinking in characters might be artificial. For some
other things, such as URLs, thinking in octets may to some
extent be necessary because of backwards compatibility issues
(assume an URL scheme is extended and decides to use some
weird RFC 1522-like method for encoding characters, and this
would have to be grandfathered).

>If the NSS is thought of as a series 
>of octets, and the meaning of those octets is defined by the scheme, 
>the resolver should have no problem.  You give one reason below
>(getting to the resolver).  What else am I missing?  (transcribability?)

Transcribability is definitely an issue. Assume there is some very
well established tradition

>| > - does this imply that a) NSSs should be formed originally
>| >   in Unicode, or that b) NSSs in other coded character sets
>| >   must be translated/transliterated into Unicode in forming
>| >   URNs, or c) something else?
>| 
>| What I assume happens is that namespaces are defined in terms of
>| glyphs, not coded character sets.

Terry here and below makes many comments about what we want
to encode not being glyphs but characters. I agree. I think
Ron Daniel used the term glyph with the meaning "character
without assigned encoding". To clear up terminology, a
character by itself does not enclude a code. It is 
something like a small logical text component. A glyph
(in standard terminology) is the appearance of a
character. With Latin letters, this distinction only
turns up with e.g. "a" or "g", where the "g" can be
closed at the bottom or not, and these would be two
glyphs for the same character.

So replacing all the occurrences of "glyph" in Ron's comment
by "character", things become much more clear. It's then
basically a discussion of whether:

- Namespaces appear as characters, without specific encoding, or
- Namespaces appear as characters with their encoding already defined

and, for the later, whether:

- They would have to be reencoded to Unicode
- They should be left as is

My personal oppinion is that namespaces will appear in both variants,
both already encoded and not yet encoded, and also as encoded entities
without any relation to characters.

As for reencoding, I would propose to suggest in the document that
NSS define a reencoding if possible and appropriate, and do
so if possible by referring to existing documents (Unicode
has mapping tables between e.g. ISO 8859-6 (Latin/Arabic)
and Unicode).

I would also suggest that the document propose that NSS
or URL schemes that have not yet defined character semantics
beyond ASCII, but that would like to do so, strongly consider
to do so in accordance with URN name syntax (i.e. using UTF-8).

>| >As an example, suppose that I have an existing name space,
>| >well ordered in every respect, in ISO 8859-6 (Latin/Arabic).

>| >I want this name space to be used for URNs, and (supposing
>| >that the coded character set is not an obstacle at this 
>| >point) get it registered.  As the upper half of 8859-6 is
>| >not a subset of Unicode, per the present syntax draft,

>All the *characters* of the upper half of 8859-6 can be represented
>by various combinations of Unicode glyphs, as I understand matters.

Yes. But all the ligatures and contextual forms are in the compatibility
section. The mapping is really straightforward and well-defined.

>| Right. We have been assuming that the user enters a URN into
>| a browser using their local language/script/... and the browser
>| has the job of making it into UNICODE/UTF-8/%encoded.
>
>Terminological question:  is the URN as entered a URN?  or does
>it become a URN only when translated?

Interesting question. But really only terminology. I don't
assume anybody will publish an URN with %HH notation in e.g.
a Japanese newspaper. So even if we terminologically specify
that only the entered and translated URN is an URN, users
will thing differently.

>| Are there guidelines already in place on how, when a user wants
>| an "A" plus "grave" (or whatever), that is to be encoded? Is it
>| reasonable for us to cite such guidelines as the way namespaces
>| should be encoded? (Also, is it SHOULD be encoded or MUST be
>| encoded).
>
>That I can't answer (yet).

I have posted a question to this respect to the unicore (unicode
specialists) list. The answer is that:

- Unicode defines that A-Grave and A followed by combining Grave
	are equivalent.
- Unicode does not give any preference to any one of these forms.

I see the main reason for this state in the fact that up to now,
Unicode was mainly designed with text editing in mind, and it was
assumed that each text editor could convert incomming stuff to
whatever it preferred.

For things such as URNs, it would definitely be nice to have a set
of clear preferences. SHOULD be encoded would not help much,
because it would not take any burden from servers/resolvers
(unless we want to put the burden on the user, which in the
case of A-grave would be a really bad idea).

>| >  Say
>| >I can have outcomes A, B, and C, all of them legitimate
>| >representations of my 8859-6 name in Unicode.  Are 
>| >urn:mynamespace:A, urn:mynamespace:B, and urn:mynamespace:C
>| >equivalent?
>| 
>| I think that we can't mandate that they be lexically equivalent.
>| That requires FAR too much knowledge on the part of all URN software.
>| It may be that a resolver can be made smart enough that, when
>| dealing with a particular language and alphabet, it can recognize
>| "A with grave" as equivalent to "A" and "grave". I think that is outside
>| the bounds of what we standardize.
>
>Fine by me.

I think that for Arabic and similar cases, with lots of compatibility
codes, it would be nice to say that compatibility codes SHOULD not
be used in URNs. This is not a problem of 8859-6 -> Unicode conversion,
but just of Arabic in general.

Regards,	Martin.

Date: Thu, 24 Oct 1996 11:45:01 -0700 (PDT)
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Unicode for NSS query
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

Having bought the book (The Unicode Standard, Version 2.0, with
CD, $55 at Computer Literacy), and without working out the whole
problem, I can see that 8859-6 > Unicode is a well defined path.
The Arabic block is divided into a range "Based on ISO 8859-6,"
a range "Points [diacritical marks] from ISO 8859-6", a range
"Arabic-Indic digits" corresponding to the digits in 8859-6
(which are doubled up on their Latin equivalents in 8859-6),
and some other ranges.  So coming from 8859-6 there is only one
choice for each character conversion, and given the resolver's
context when receiving a Unicode URN, backconversion to 8859-6
should also be unambiguous.

I won't be able to read the CD for a couple weeks, but the print
answers the question I was asking.  I'll just admire the cover
(the front cover uses the Rosetta Stone as background, including
hieroglyphs that can't be encoded in Unicode ...).

Regards,
    Terry Allen    Fujitsu Software Corp.    [email-masked]
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

Date: Thu, 24 Oct 1996 10:25:11 -0700 (PDT)
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Unicode for NSS query
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

Thanks to Patrik and Ron.  I think I need to go out and buy
those Unicode books today.  Some clarifications:

| > - why care?  the NSS is supposed to be opaque
| Which means? I think it means we can't go around inferring
| structure in arbitrary namespaces. Opaque does not mean
| that we have to take whatever comes. There can be particular
| requirements on the characters allowed.
| I think this WG should make
| an explicit decision on trying to go to UNICODE rather than
| just defaulting to ASCII. The reasons for doing so:
|   1) The IAB workshop tells us to try to do so.
|   2) Not all the namespaces in the world use the Latin alphabet
|      without accents.
|   3) Isn't it time we start getting away from the US-ASCII assumption?

I don't want to assume ASCII, but I was wondering, why think in terms 
of characters and not octets?  If the NSS is thought of as a series 
of octets, and the meaning of those octets is defined by the scheme, 
the resolver should have no problem.  You give one reason below
(getting to the resolver).  What else am I missing?  (transcribability?)

| It may be that the group decides not to do UNICODE because of technical
| objections. That would be fine with me, I just want the decision to be
| explicit.

I'm not arguing either way on Unicode (for this purpose).

| > - does this imply that a) NSSs should be formed originally
| >   in Unicode, or that b) NSSs in other coded character sets
| >   must be translated/transliterated into Unicode in forming
| >   URNs, or c) something else?
| 
| What I assume happens is that namespaces are defined in terms of
| glyphs, not coded character sets. Browsers have the job of taking
| some coded representation of the glyph and translating it (if necessary)
| to a 10646 coded version of the glyph. Then they do UTF-8 and %encoding
| before sending it on the wire to a resolver.

But many name spaces *are* defined in terms of [un]coded character sets.
I didn't give a full example framing my question about Arabic Kaf, but 
8859-6 doesn't define glyphs, it defines characters.  

| (Note that the NAPTR resolution scheme is probably going to find
| it impossible to get people to resolvers if that decision has to be made
| on non-ASCII characters in the URN. Since NAPTR is intended for
| Experimental rather than standards track this may be OK. I will take a
| look at what can be done to deal with UNICODE in regexps.)

Ah, I see.  That part of the NSS that deals with its hierarchy
(and hence must be dealt with to get the client to a resolver)
presents a different problem than the rest of it; do I have that
right?  E.g.,

  urn:world.dynasties:ottomans/15th.century/Bursa/XXXXXXXXXX

has to get to the "Bursa" resolver, but XXXXXXXXXX could be 
anything?

| >As an example, suppose that I have an existing name space,
| >well ordered in every respect, in ISO 8859-6 (Latin/Arabic).
| 
| Is this assumption of characterset appropriate? Is it not more
| likely that the namespace will say "names are formed from the
| set of glyphs [x-y]" (where x and y are denoting arbitrary glyphs, not
| the Latin letters x and y) leaving the problem of how to code those
| things as bits up to someone else?

For many existing name spaces, the current definition will be
in terms of letters or ideographs, not tied to any set of 
glyphs.  (I'll bet that even ISBNs may not be defined in terms
of ASCII.)  Should some binding to a glyphset be made in the
registration process?

| >I want this name space to be used for URNs, and (supposing
| >that the coded character set is not an obstacle at this 
| >point) get it registered.  As the upper half of 8859-6 is
| >not a subset of Unicode, per the present syntax draft,
| 
| Do you mean that:
|   a) The glyphs in the upper half of 8859-6 are not in UNICODE
|   b) The glyphs are there but the bit patterns of their coded representation
|      differ
|   c) (B) + non-unique mappings from 8859-6 to same glyph in UNICODE

All the *characters* of the upper half of 8859-6 can be represented
by various combinations of Unicode glyphs, as I understand matters.
(Digression:  There are additional noncharacter glyphs in the "Arabic" 
section of Unicode, some of them more like SGML entities than glyphs,
e.g., a rosette glyph for the start of a Qur'anic verse, for which no 
standard glyph has ever been used in Arabic printing.  These are
pretty questionable, but not at issue in the 8859-6>Unicode direction.)

| >I can't use it directly in an URN (although doing so would
| >pose no problem I can think of, supposing that it is a rule
| >of the name space that its names are in 8859-6).
| >
| >When I translate that 8859-6 name into Unicode I have more
| >than one possible outcome (depending on whether I keep it
| >simple, using 0621--064A or use Unicode code points that
| >include diacritical marks or use Unicode code points that
| >indicate glyph variants of a letter, such as 06AA, "Arabic
| >Letter Swash Kaf," which is lexically the same as 0643,
| >"Arabic Letter Kaf`" or specify some ligatures).

[Patrik says it isn't equivalent per Unicode; must investigate.]

| Right. We have been assuming that the user enters a URN into
| a browser using their local language/script/... and the browser
| has the job of making it into UNICODE/UTF-8/%encoded.

Terminological question:  is the URN as entered a URN?  or does
it become a URN only when translated?

| Are there guidelines already in place on how, when a user wants
| an "A" plus "grave" (or whatever), that is to be encoded? Is it
| reasonable for us to cite such guidelines as the way namespaces
| should be encoded? (Also, is it SHOULD be encoded or MUST be
| encoded).

That I can't answer (yet).

| >  Say
| >I can have outcomes A, B, and C, all of them legitimate
| >representations of my 8859-6 name in Unicode.  Are 
| >urn:mynamespace:A, urn:mynamespace:B, and urn:mynamespace:C
| >equivalent?
| 
| I think that we can't mandate that they be lexically equivalent.
| That requires FAR too much knowledge on the part of all URN software.
| It may be that a resolver can be made smart enough that, when
| dealing with a particular language and alphabet, it can recognize
| "A with grave" as equivalent to "A" and "grave". I think that is outside
| the bounds of what we standardize.

Fine by me.

| The place to attack this problem of A, B, and C all being legitimate
| UNICODE representations of some sequence of glyphs is when the
| glyphs are first translated to UNICODE. If there are recommendations
| on preferred encodings, we should cite those. If not, then we should
| decide on which is more important - UNICODE's capabilities or
| unambiguous encoding.

Right.  Onward to the bookstore.

Regards,
    Terry Allen    Fujitsu Software Corp.    [email-masked]
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

Subject: Re: [URN] What is equivalence?
To: [email-masked]
Date: Thu, 24 Oct 1996 17:21:53 +0100 (MET)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Content-Length: 733
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

James K. Tauber wrote:

>The full name of "10646-1" is:
>
>ISO/IEC 10646-1:1993 Information technology -- Universal Multiple-Octet
>Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual
>Plane 
>
>The "-1" refers to the part number and the 1993 to the version.
>
>Note that there have been two amendments (for UTF-16 and UTF-8) and one
>technical corrigendum to 10646-1:1993.

What is more important, several amendments are in preparation and
have advanced through the voting process. Of particular interest
is amendment 5, which completely redefines the Hangul (Korean)
composed syllables. It is the first, last, and only (so everybody
assures) case that things actually have been moved around.

Regards,	Martin.

Date: Thu, 24 Oct 1996 09:25:49 -0600
To: Terry Allen <[email-masked]>, [email-masked]
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] Unicode for NSS query
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke Terry Allen (at least at 03:52 PM 10/23/96 -0700)

[on the subject of UNICODE, aka 10646, for URNs]

> - why care?  the NSS is supposed to be opaque

Which means? I think it means we can't go around inferring
structure in arbitrary namespaces. Opaque does not mean
that we have to take whatever comes. There can be particular
requirements on the characters allowed.

I think this WG should make
an explicit decision on trying to go to UNICODE rather than
just defaulting to ASCII. The reasons for doing so:
  1) The IAB workshop tells us to try to do so.
  2) Not all the namespaces in the world use the Latin alphabet
     without accents.
  3) Isn't it time we start getting away from the US-ASCII assumption?

It may be that the group decides not to do UNICODE because of technical
objections. That would be fine with me, I just want the decision to be
explicit.

> - does this imply that a) NSSs should be formed originally
>   in Unicode, or that b) NSSs in other coded character sets
>   must be translated/transliterated into Unicode in forming
>   URNs, or c) something else?

What I assume happens is that namespaces are defined in terms of
glyphs, not coded character sets. Browsers have the job of taking
some coded representation of the glyph and translating it (if necessary)
to a 10646 coded version of the glyph. Then they do UTF-8 and %encoding
before sending it on the wire to a resolver.

(Note that the NAPTR resolution scheme is probably going to find
it impossible to get people to resolvers if that decision has to be made
on non-ASCII characters in the URN. Since NAPTR is intended for
Experimental rather than standards track this may be OK. I will take a
look at what can be done to deal with UNICODE in regexps.)

>As an example, suppose that I have an existing name space,
>well ordered in every respect, in ISO 8859-6 (Latin/Arabic).

Is this assumption of characterset appropriate? Is it not more
likely that the namespace will say "names are formed from the
set of glyphs [x-y]" (where x and y are denoting arbitrary glyphs, not
the Latin letters x and y) leaving the problem of how to code those
things as bits up to someone else?

>I want this name space to be used for URNs, and (supposing
>that the coded character set is not an obstacle at this 
>point) get it registered.  As the upper half of 8859-6 is
>not a subset of Unicode, per the present syntax draft,

Do you mean that:
  a) The glyphs in the upper half of 8859-6 are not in UNICODE
  b) The glyphs are there but the bit patterns of their coded representation
     differ
  c) (B) + non-unique mappings from 8859-6 to same glyph in UNICODE

>I can't use it directly in an URN (although doing so would
>pose no problem I can think of, supposing that it is a rule
>of the name space that its names are in 8859-6).
>
>When I translate that 8859-6 name into Unicode I have more
>than one possible outcome (depending on whether I keep it
>simple, using 0621--064A or use Unicode code points that
>include diacritical marks or use Unicode code points that
>indicate glyph variants of a letter, such as 06AA, "Arabic
>Letter Swash Kaf," which is lexically the same as 0643,
>"Arabic Letter Kaf`" or specify some ligatures).

Right. We have been assuming that the user enters a URN into
a browser using their local language/script/... and the browser
has the job of making it into UNICODE/UTF-8/%encoded.

Are there guidelines already in place on how, when a user wants
an "A" plus "grave" (or whatever), that is to be encoded? Is it
reasonable for us to cite such guidelines as the way namespaces
should be encoded? (Also, is it SHOULD be encoded or MUST be
encoded).

>  Say
>I can have outcomes A, B, and C, all of them legitimate
>representations of my 8859-6 name in Unicode.  Are 
>urn:mynamespace:A, urn:mynamespace:B, and urn:mynamespace:C
>equivalent?

I think that we can't mandate that they be lexically equivalent.
That requires FAR too much knowledge on the part of all URN software.
It may be that a resolver can be made smart enough that, when
dealing with a particular language and alphabet, it can recognize
"A with grave" as equivalent to "A" and "grave". I think that is outside
the bounds of what we standardize.

The place to attack this problem of A, B, and C all being legitimate
UNICODE representations of some sequence of glyphs is when the
glyphs are first translated to UNICODE. If there are recommendations
on preferred encodings, we should cite those. If not, then we should
decide on which is more important - UNICODE's capabilities or
unambiguous encoding.

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: Thu, 24 Oct 1996 14:44:44 +0200
To: "Ryan Moats" <[email-masked]>, "[email-masked]" <[email-masked]>
From: Patrik Faltstrom <[email-masked]>
Subject: Re: [URN] UNICODE or not UNICODE?
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]
Reply-To: Patrik Faltstrom <[email-masked]>

At 07.27 +0200 96-10-24, [email-masked] wrote:
>>To answer the second question, you have to have a urn in a different
>>character set in some cases, for example in a client which does not
>>use UNICODE. You then have to do translation.
>
>You are assuming translation at the resolver here?

No. The URN is passed in UTF-8 from the client to the resolver.
The translation I am talking about is done within the client. I.e.
the client have to change it's internal representation to
UNICODE before sending the URN over the wire to the resolution server.

On the other hand, depending on the resolution protocol itself,
different character sets might be used. In Whois++ for example,
the client can specify what character set it is using. In Z39.50,
I don't have a clue how to specify the character set.

What we say with UTF-8 in the URN spec is that the generic format for
a URN is in UTF-8, and because of that all glyphs available in
UNICODE 2.0 is available for use in a URN.

I.e. you just reminded me that I am mixing resolution protocol and
URN specification...yak... A resolution protocol for URNs must be
able to handle the UTF-8 encoding of UNICODE, i.e. be 8-bit clean,
and/or handle %encoding of the UTF-8 bytes that have to be protected
according to the URI spec.

If using HTML as resolution protocol for example, the string that is
passed is in UTF-8, not ISO-8859-1. That is what I would like.

(I think ;-) Help...I am almost lost in a cloud of logic...!)

   Patrik

From: [email-masked]
Original-From: "Ryan Moats" <[email-masked]>
To: "Patrik Faltstrom" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Thu, 24 Oct 96 07:27:29 
Priority: Normal
Subject: Re: [URN] UNICODE or not UNICODE?
Sender: [email-masked]
Reply-To: [email-masked]

On Thu, 24 Oct 1996 11:08:19 +0200, Patrik Faltstrom wrote:

>Terry wrote
>> - why care?  the NSS is supposed to be opaque
>> - does this imply that a) NSSs should be formed originally
>>   in Unicode, or that b) NSSs in other coded character sets
>>   must be translated/transliterated into Unicode in forming
>>   URNs, or c) something else?
>
>The problem with not defining a character set is that it will
>be impossible to do any comparison between two URNs. We need to have
>some ability to do comparisons, and the only reasonable way of doing that
>is to use _one_ character set.
>
>To answer the second question, you have to have a urn in a different
>character set in some cases, for example in a client which does not
>use UNICODE. You then have to do translation.

Patrik-

You are assuming translation at the resolver here?

Ryan

P.S.  The rest of the discussion I am still digesting.  I plan
on revamping the equivalence section of the syntax doc on
the plane tomorrow (10/25) and seeing if I can't submit it to
the "editors" next week.  If we want to change it before San Jose,
we can, otherwise we have something to go with...

Date: Thu, 24 Oct 1996 11:08:19 +0200
To: [email-masked]
From: Patrik Faltstrom <[email-masked]>
Subject: [URN] UNICODE or not UNICODE?
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Patrik Faltstrom <[email-masked]>

Terry wrote
> - why care?  the NSS is supposed to be opaque
> - does this imply that a) NSSs should be formed originally
>   in Unicode, or that b) NSSs in other coded character sets
>   must be translated/transliterated into Unicode in forming
>   URNs, or c) something else?

The problem with not defining a character set is that it will
be impossible to do any comparison between two URNs. We need to have
some ability to do comparisons, and the only reasonable way of doing that
is to use _one_ character set.

To answer the second question, you have to have a urn in a different
character set in some cases, for example in a client which does not
use UNICODE. You then have to do translation.

What we did in Digger, the Whois++ server Bunyip has, was using the
rules for comparison (decomposition + sorting) and translation rules
that the UINCODE consortium have defined.

The UNICODE tables include for each character one kind of equivalence
which is the rule for decomposition of that code point in UNICODE
into more than one other code point. One example, the letter '=C4'.

In UNICODE, this character is defined as:

00C4;LATIN CAPITAL LETTER A WITH DIAERESIS;Lu;0;L;0041 0308;;;;N;
     LATIN CAPITAL LETTER A DIAERESIS;;;00E4;

One can here see that the codepoint, U+00C4, is equivalent to U+0041
followed by U+0308. One can also see that the lower case version of this
character is U+00E4 (among other things).

When comparing two strings, and one of them include "U+00C4"
and the other one the sequence "U+0041"+"U+0308" these strings
should be considered equal in the sense of the UNICODE spec.

Note that I am not talking about ISO-10646 here, as I am not at all
familiar with what parts of this is included in the 10646 spec. This
is UNICODE 2.0 we are talking about!

When comparing strings, one have to do decomposition, and the definition
of decomposition is:

>Decomposition.
>       (1) the process of separating or analyzing a text element into
>           component units. These component units may not
>           have any functional status, but may be simply formal units, i.e.=
,
>           abstract shapes; (2) the process of replacing a
>           code element with multiple code elements, which, together,
>           represent the original code element in some
>           manner, e.g., the shapes associated with the resulting
>           code elements may combine to form the shape associated
>           with the original code element.

This means that before comparing the strings that include "U+00C4"
and "U+0041"+"U+0308", all code points have to be decomposed into its
maximal decomposition possible. I.e. "U+00C4" have to be changed to
"U+0041"+"U+0308", and these have to be sorted (i.e. one can know
from the code tables that "U+0041" is to be before "U+0308" in
a composed character).

THEN we do the comparison codepoint by codepoint.

If we wanted to do case insensitive matching, we use the information
from the UNICODE consortium about what is a lower case character.

Terry continues:

>When I translate that 8859-6 name into Unicode I have more
>than one possible outcome (depending on whether I keep it
>simple, using 0621--064A or use Unicode code points that
>include diacritical marks

If one have a look at the UNICODE tables, one can see that for example
U+0621 is a final form of a whole series of other glyphs,
for example

=46E80;ARABIC LETTER HAMZA ISOLATED FORM;Lo;0;R;<isolated> 0621;;;;N;
     GLYPH FOR ISOLATE ARABIC HAMZAH;;;;

which is the special glyph used in isolated form. You see that U+FE08
should be equivalent to U+0621, so when using the decomposition
rules before comparing strings, U+FE80 and U+0621 are considered
equivalent.

This is exactly why decomposition is needed.

>or use Unicode code points that
>indicate glyph variants of a letter, such as 06AA, "Arabic
>Letter Swash Kaf," which is lexically the same as 0643,
>"Arabic Letter Kaf`" or specify some ligatures).

I don't know Arabic, but I am just following the rules that
UNICODE consortioum have set up, and according to these
rules, U+06AA and U+0643 is not equivalent characters
when comparing:

06AA;ARABIC LETTER SWASH KAF;Lo;0;R;;;;;N;ARABIC LETTER SWASH CAF;;;;
0643;ARABIC LETTER KAF;Lo;0;R;;;;;N;ARABIC LETTER CAF;;;;

I am not arguing if this descision by the UNICODE consortium
was correct or not, but _someone_ that they trusted must have
told them these are different characters.

>Say
>I can have outcomes A, B, and C, all of them legitimate
>representations of my 8859-6 name in Unicode.  Are
>urn:mynamespace:A, urn:mynamespace:B, and urn:mynamespace:C
>equivalent?  Once the URN is passed to the resolver, is
>it contemplated that the resolver will translate the URN's
>NSS back into 8859-6?

When mapping to/from ISO-8859-6 and UNICODE, the consortium
have a table which one should use. In that table I can
read out that U+0643 in ISO-8859-6 is 0xE3, but that
U+06AA is missing from ISO-8859-6. A client have because of
this know that UNICODE is what the URN is specified in,
and do appropriate mappings -- i.e. if a URN have U+06AA
as one of the characters, that URN can not be entered
directly on a client working in ISO-8859-6 (and neither
on a client working in ISO-8859-1 or US-ASCII).

In this case %encoding can be used.

    Patrik

--------------------------------------------------------------------
   Senior Researcher, Tele2/SwipNet     Stockholm, Sweden
   [email-masked]                         Phone: +46-8-56264000
   urn:inet:urn.paf.se

   In theory, there's no difference between theory and practice,
   but in practice, there is.

From: "James K. Tauber" <[email-masked]>
To: "Terry Allen" <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [URN] What is equivalence?
Date: Thu, 24 Oct 1996 12:17:32 +0800
Sender: [email-masked]
Reply-To: "James K. Tauber" <[email-masked]>

> ISO 10646 comes in versions.  There was 10646-1 and now (as I
> understand it) there is 10646-2.  If the syntax doc is to
> talk about 10646 it should refer to a specific version; then
> if the rules change in say, 10646-3, one can adopt the
> changes or not, but there will be no ambiguity.
> 
> "10646-1" is what I see in Unicode Technical Report #4;
> I'm not sure that's the formal identifying string, especially
> as SGML uses a different format for identifying versions:
> 8879:1986, giving the date of the revision rather than a
> number.

The number following the hyphen is not a version number but a part number
where it is decided to release the standard in separate parts (cf ISO
8859-n where different n doesn't mean different editions but separately
released parts of the same standard)

The full name of "10646-1" is:

ISO/IEC 10646-1:1993 Information technology -- Universal Multiple-Octet
Coded Character Set (UCS) -- Part 1: Architecture and Basic Multilingual
Plane 

The "-1" refers to the part number and the 1993 to the version.

Note that there have been two amendments (for UTF-16 and UTF-8) and one
technical corrigendum to 10646-1:1993.

James

--
 James K. Tauber / [email-masked]
 University CWIS Coordination Officer
 The University of Western Australia

 Room 2.42, Scholars' Centre, Reid Library
 Phone: +61 9 380 7136 FAX: +61 9 380 1128

Date: Wed, 23 Oct 1996 15:52:54 -0700 (PDT)
From: Terry Allen <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: [URN] Unicode for NSS query
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

The syntax draft says that Unicode shall be used for the
name-specific string part of a URN.  I find myself wondering
about some questions, which I ask for sake of information,
not as objections:

 - why care?  the NSS is supposed to be opaque
 - does this imply that a) NSSs should be formed originally
   in Unicode, or that b) NSSs in other coded character sets
   must be translated/transliterated into Unicode in forming
   URNs, or c) something else?

As an example, suppose that I have an existing name space,
well ordered in every respect, in ISO 8859-6 (Latin/Arabic).
I want this name space to be used for URNs, and (supposing
that the coded character set is not an obstacle at this 
point) get it registered.  As the upper half of 8859-6 is
not a subset of Unicode, per the present syntax draft,
I can't use it directly in an URN (although doing so would
pose no problem I can think of, supposing that it is a rule
of the name space that its names are in 8859-6).

When I translate that 8859-6 name into Unicode I have more
than one possible outcome (depending on whether I keep it
simple, using 0621--064A or use Unicode code points that
include diacritical marks or use Unicode code points that
indicate glyph variants of a letter, such as 06AA, "Arabic
Letter Swash Kaf," which is lexically the same as 0643,
"Arabic Letter Kaf`" or specify some ligatures).  Say
I can have outcomes A, B, and C, all of them legitimate
representations of my 8859-6 name in Unicode.  Are 
urn:mynamespace:A, urn:mynamespace:B, and urn:mynamespace:C
equivalent?  Once the URN is passed to the resolver, is
it contemplated that the resolver will translate the URN's
NSS back into 8859-6?

This problem arises even with digits-only Arabic NSSs,
as Unicode provides two ranges of numerals, Arabic-Indic
and Eastern Arabic-Indic, which (I presume, not being
able to find my all-the-glyphs document) represent
exactly the same characters.  But maybe it's not a
problem?

Regards,
    Terry Allen    Fujitsu Software Corp.    [email-masked]
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

Date: Wed, 23 Oct 1996 11:49:34 -0700 (PDT)
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: [URN] What is equivalence?
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

ISO 10646 comes in versions.  There was 10646-1 and now (as I
understand it) there is 10646-2.  If the syntax doc is to
talk about 10646 it should refer to a specific version; then
if the rules change in say, 10646-3, one can adopt the
changes or not, but there will be no ambiguity.

"10646-1" is what I see in Unicode Technical Report #4;
I'm not sure that's the formal identifying string, especially
as SGML uses a different format for identifying versions:
8879:1986, giving the date of the revision rather than a
number.

Either way, the same goes for name space specifications:
refer to them by version or date of publication, and you
avoid problems when they are revised.

Regards,
    Terry Allen    Fujitsu Software Corp.    [email-masked]
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

Date: Wed, 23 Oct 1996 11:04:51 -0700 (PDT)
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [URN] What is equivalence?
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

| Now, if we only look at the urn equivalence rules, what do we
| want byte-by-byte or character by character matchings? In
| UNICODE we can write characters like "A-With-Grave" or
| "A"+"COMPOSING GRAVE". For some groups of characters,
| especially Arabic, one UNICODE character might expand
| (decompose) into not two or three, but up to 32 characters.

No.  There is one Unicode code point (which I cannot find at the 
moment) that maps to a pious phrase as represented by a single glyph 
(think "piece of cold type"), which may be what you're thinking of.  
That Unicode Arabic code point does not represent the phrase as written
out in letters, it represents the single glyph. 

Regards,
    Terry Allen    Fujitsu Software Corp.    [email-masked]
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

Date: Wed, 23 Oct 1996 12:38:19 -0500
To: Ron Daniel <[email-masked]>, [email-masked]
From: [email-masked] (Jim Conklin)
Subject: Re: [URN] Pre release of URN Syntax document....
Cc: URN Mailing list <[email-masked]>
Sender: [email-masked]
Reply-To: [email-masked] (Jim Conklin)

At 10:12 AM 10/23/96, Ron Daniel wrote:
> ...
>What I would like to see happen is that a URN resolution algorithm
>becomes the "unknown scheme" error handler in browsers. ...

  I think that makes a lot of sense, Ron.

Jim

Date: Wed, 23 Oct 1996 10:12:44 -0600
To: "James K. Tauber" <[email-masked]>, "Larry Masinter" <[email-masked]>, <[email-masked]>
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] Pre release of URN Syntax document....
Cc: <[email-masked]>
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke James K. Tauber (at least at 11:56 AM 10/23/96 +0800)
>
>I haven't got ISO/IEC 9070 in front of me at the moment but my notes  give
>the canonical public identifier owner name form of ISBNs as being hyphen
>separated.

Sounds good to me.

>While I'm on the subject of ISO/IEC 9070...
>
>Is there an argument for using the ISO/IEC 9070 scheme for grandfathering*
>ISBNs in?

Can you give us a brief synopsis of the scheme? My (probably faulty)
understanding is that 9070 uses the "publisher id" part of an
ISBN to identify naming authorities, but that they can then
assign their own strings to make the rest of an identifier. Is
that true?

>Also, do people think it worthwhile for the IETF (or whoever) to get an ISO
>identified organisation authority prefix? This would allow the trivial
>assignment of an ISO/IEC 9070 identifier for every URN, regardless of
>namespace.

If it is just a matter of buying a small block of ISBN space and
only using the prefix, I don't see any serious objections. I'm not
sure of the cost and where the funds would come from. I'll ask our
area directors.

While I don't have serious objections, I don't see the benefits.
Do we NEED to be able to assign 9070 identifiers for any URN? Why?

Does 9070 allow other registries for naming authorities? Specifically,
does it allow ISO Object Identifiers? Since the IETF already does
a lot with OIDs, and OIDs are a lot closer to arbitrary scalability
than ISBN publisher IDs, I would tend to prefer that approach if it
is possible.  "Constructed OIDs" are another possible way to make
a valid identifier in some ISO scheme out of an arbitrary URN.

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, 23 Oct 1996 09:42:45 -0600
To: Larry Masinter <[email-masked]>, [email-masked]
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] What is equivalence?
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke Larry Masinter (at least at 12:46 AM 10/23/96 PDT)

[I'm responding to Larry's paragraphs in a different order than
he sent them]

>While there's not much problem if two strings that are not equivalent
>now might be declared equivalent in the future, there's a serious
>problem if two strings that are equivalent now are determined to be
>non-equivalent later.

Agreed.

>The issue for Unicode decomposition is that it is possible to imagine
>Unicode adding some new composition rule in the future.  Thus, the
>time scope of the equivalence relationship is limited:

I asume that the character equivalances in ISO 10646 are set, and
that any additional equivalances would be under a new standard.
(Can anyone confirm or deny this?)
So, while I agree that the equivalances could change over time, the
URN syntax draft (if we decide to do UNICODE character equivalents)
should probably say that the 10646 equivalants are the ones we do.
That set of equivalances would not change over time.

Personally, I have no opinion on UNICODE character equivalants.
Patrik presented the arguments for both sides. I like the implementation
ease of not doing equivalents, but then we are not doing "true" 10646
so we have to very careful about the wording of the URN syntax draft.
Anyone out there with strong opinions one way or the other?

>Do the namespaces 'define' equivalence, or do they 'implement' it?
>
>That is, would you want to assert that if
>   isbn:0-13-443672-5 and isbn:013443672-5 
>are ever to be treated the 'same', then they must always be treated
>the 'same'? Otherwise, a client which has 'knowledge about the
>namespace' might find that knowledge out of date.

If the rules of a namespace change, it should probably be considered
a new namespace and get a new namespace ID. If the change is such that
names that used to be considered equivalant can no longer be considered
such, then a new ID is certainly called for.

I think this means that namespaces "define" equivalence.

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, 23 Oct 1996 09:12:39 -0600
To: [email-masked]
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] Pre release of URN Syntax document....
Cc: URN Mailing list <[email-masked]>
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke YON - Jan C. Hardenbergh (at least at 07:06 AM 10/23/96 -0400)
>Ron Daniel wrote:
>> Thus spoke Daniel LaLiberte (at least at 11:54 AM 10/21/96 -0500)
>> >Is the intent that "urn:" be optional within more contexts, such
>> >as within HTML documents following "HREF="?
>> 
>> That is *my* intent, although I would be interested in feedback
>> from the list on the subject.

>>From a VRML point of view, we need it to be there. While we have not
>quite written it in to the spec, yet. There is a notion that one can
>create extenions to VRML and have them defined by a URN. The browser
>can then use native implementations for URNs it recognizes.

This is to solve the generic telephone problem?
Can you please give an example of the URNs you are thinking of?

>I don't understand how it can be optional. Is it that it is the
>URN resolution is the default protocol? How do we know that there
>is not an isbn: protocol?

The URN syntax says [urn:] NID ':' NSS
In other words, the urn: is *always* followed by a Namespace Identifier.
It is my thinking (which I believe is shared by many others on this list)
that new namespaces go through the same sort of review process as new
URL schemes do. Therefore, we would have a mechanism for ensuring that
URN namespace IDs did not use the same character string as a URL protocol.
That is how we would know there is not an isbn: protocol, as opposed to
an isbn: namespace.

Given that URNs have to provide a namespace ID, and that the namespace ID
will be distinct from URL protocols, the urn: prefix does not add a
great deal of information. Since it has been the source of religious
controversy in the past, I suggested making it optional. (I also
like using isbn: as an example, rather than urn:isbn:).

What I would like to see happen is that a URN resolution algorithm
becomes the "unknown scheme" error handler in browsers. Browsers
continue to have a lookup table of schemes and function pointers
to handle those schemes. When an unknown scheme is encountered, they
can assume it is a new URN namespace and try to resolve it that way.
The URN resolver would then report an unknown namespace error, or
send back info on "speak HTTP to this resolver to get the resource".

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"

Date: Wed, 23 Oct 1996 07:06:18 -0400
From: "YON - Jan C. Hardenbergh" <[email-masked]>
Organization: Netscape Communications
To: Ron Daniel <[email-masked]>
Cc: Daniel LaLiberte <[email-masked]>, Ian Higgs +44 171 542 8595 <[email-masked]>, URN Mailing list <[email-masked]>, Ryan Moats <[email-masked]>
Subject: Re: [URN] Pre release of URN Syntax document....
Sender: [email-masked]
Reply-To: "YON - Jan C. Hardenbergh" <[email-masked]>

Ron Daniel wrote:
> 
> Thus spoke Daniel LaLiberte (at least at 11:54 AM 10/21/96 -0500)
> 
> >Is the intent that "urn:" be optional within more contexts, such
> >as within HTML documents following "HREF="?
> 
> That is *my* intent, although I would be interested in feedback
> from the list on the subject. The bit about the urn: being optional
> is because its presence or absence has always degenerated into
> a religious war. I think you are the one who described it as
> "unnecessary, but harmless". I think allowing it can ease the
> transition period, since Navigator clients will send things starting
> with urn: to the HTTP proxy instead of reporting an unknown protocol
> error. Other than that I agree with your statement.

>From a VRML point of view, we need it to be there. While we have not
quite written it in to the spec, yet. There is a notion that one can
create extenions to VRML and have them defined by a URN. The browser
can then use native implementations for URNs it recognizes.

I don't understand how it can be optional. Is it that it is the
URN resolution is the default protocol?  How do we know that there
is not an isbn: protocol?

-- 
YON - Jan C. Hardenbergh, [email-masked], www.netscape.com/people/jch
"Imagination is more important than knowledge" A. Einstein

From: [email-masked]
Original-From: "Ryan Moats" <[email-masked]>
To: "Terry Allen" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 22 Oct 96 18:52:50 
Priority: Normal
Subject: Re: [URN] re urn: optional
Sender: [email-masked]
Reply-To: [email-masked]

On Tue, 22 Oct 1996 10:06:59 -0700 (PDT), Terry Allen wrote:

>Within appropriate markup, urn: may add no information, e.g.,
><biblioentry>
> <title>A Complete History of Algiers</title>
>  ...
>  <urn>sbn:8371-3613-X</urn>
></biblioentry>
>
>(yes, this book identifies iteself by SBN, not ISBN).
>
>It might be desireable to cat on "URN:" when using this
>information in some contexts, and to avoid confusion,
>"URN" should not be used as the name space identifier
>for any naming scheme registered as an URN scheme, that
>is, no URN:URN:something.  
>

Does anybody have a problem with this?  Should this be in the framework
document or the syntax document (my first reaction is that the syntax doc
is not the place to handle this).

Ryan

From: [email-masked]
Original-From: "Ryan Moats" <[email-masked]>
To: "URN mailing list" <[email-masked]>
Date: Tue, 22 Oct 96 18:50:53 
Priority: Normal
Subject: Re: [URN] Pre release of URN Syntax document....
Sender: [email-masked]
Reply-To: [email-masked]

On Tue, 22 Oct 96 12:27:42, Ryan Moats wrote:

>Hmmm, that's an interesting concept.  I have been considering 
>"lexical equivalence" at the client and what you call "functionally equivalent"
>at the server to be the same thing.  Basically, my definition of lexical equivalence
>is that "two URNs are considered lexical equivalent at a machine if that machine
>can determine unequivically USING ONLY LOCAL KNOWLEDGE that the two
>URNs will return in the same resource."
>
>(Of course, I can change this given a good enough reason).
>
>Thus, Ian's example above (with/without urn:) is one where the two URN's
>are lexically equivalent at both a client and a URN resolver.  However,
>Patrik's example is one where the two URN's are not lexically equivalent
>at a client but would be lexically equivalent at a URN resolver.
>
>The bottom line is that I view lexical equivalence as a local phenomenom, rather
>than a global one.  It dawns on me that I should probably add words to that affect
>(and possibly use these examples to highlight this) in the draft.
>

Ok.  Based on all the discussion, I will add some text to the lexical
equivalence section that discusses the fact that lexical equivalence
is a local phenomenon. (Amazing what happens when you are on a plane!)

Ryan

To: [email-masked]
Cc: [email-masked]
Subject: Re: [URN] What is equivalence?
From: Larry Masinter <[email-masked]>
Date: Wed, 23 Oct 1996 00:46:40 PDT
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

Do the namespaces 'define' equivalence, or do they 'implement' it?

That is, would you want to assert that if
   isbn:0-13-443672-5 and isbn:013443672-5 
are ever to be treated the 'same', then they must always be treated
the 'same'? Otherwise, a client which has 'knowledge about the
namespace' might find that knowledge out of date.

On the other hand, you might want to allow 
    duns:ibm to be the same as duns:international-business-machines
but are you willing to allow that equivalence to be cached in clients
or wired into them?

In general, when you talk about 'equivalence', even for names of
global scope in place, you have to define the time scope too.

The issue for Unicode decomposition is that it is possible to imagine
Unicode adding some new composition rule in the future.  Thus, the
time scope of the equivalence relationship is limited:

While there's not much problem if two strings that are not equivalent
now might be declared equivalent in the future, there's a serious
problem if two strings that are equivalent now are determined to be
non-equivalent later.

Larry

Date: Wed, 23 Oct 1996 07:50:39 +0200
To: [email-masked]
From: Patrik Faltstrom <[email-masked]>
Subject: [URN] What is equivalence?
Sender: [email-masked]
Reply-To: Patrik Faltstrom <[email-masked]>

First, sorry for not turning on my brain before starting
to explain what I really wanted to say about equivalence
regarding URNs. My point is that we have two different
levels of equivalence to define:

1) Equivalence that is defined in the urn syntax paper
2) Equivalence that the namespace define

We should here only talk about (1), and I will first try to explain
why, and then talk about the specifik questions that arises
when talking about (1) and at the same time UNICODE.

When the client compares to URNs, we have to use the comparison
algorithms we define in the framework or syntax document for
urns. They can only be based on character-by-character
comparisons (or byte-by-byte). The questions is which of
these methods we use. Especially when using UTF-8 we have
exactly the same comparison problems with decomposition in
UNICODE that Bunyip have been working on for years with the
Digger server (see proceeding from the last UNICODE
conference where I and Philippe Boucher did have a paper
which describes the UNICODE decomposition library developed
for the Whois++/Digger server).

Then, on the namespace level, you have a different comparison
algorithm. With knowledge about the namespace (which the client
_might_ have) equivalence might be defined as something
completely different. For example, for ISBNs the ISBNs
0-13-443672-5 and 013443672-5 and even 13443672-5
or 0134436725 can be treated as "same" (yes, I did not
type the leading "0" in the third example -- in Sweden
it is very common to skip the leading "91"). But, these
equivalence rules are something that we can not incorporate into
the urn equivalence rules, only into the namespace specific
equivalence rules.

Now, if we only look at the urn equivalence rules, what do we
want byte-by-byte or character by character matchings? In
UNICODE we can write characters like "A-With-Grave" or
"A"+"COMPOSING GRAVE". For some groups of characters,
especially Arabic, one UNICODE character might expand
(decompose) into not two or three, but up to 32 characters.
How one character should be decomposed are defined in the
UNICODE spec.

The basic comparison rules in UNICODE say that before comparing two
characters they have to be decomposed maximally and then all
characters they decompose into have to be sorted according to given rules.
After these two steps, byte-by-byte comparison can be done.

All of this is "simple" to code because all of these operations are
just table lookups. The problem is that the tables are large...

BUT we can also just say that we on the urn level are looking at
simpler equivalence, which means that "A"+"Combining Grave" is
not the same as "A With Grave" even though the UNICODE spec
states that so is the case. I.e. we say that equivalence is
based on character by character without decomposition.

The former is better, the latter is _much_ simpler to implement,
and who needs that refined comparison algorithms on the urn
level when the namespace probably define it's own rules anyway?

   Patrik

--------------------------------------------------------------------
   Senior Researcher, Tele2/SwipNet     Stockholm, Sweden
   [email-masked]                         Phone: +46-8-56264000
   urn:inet:urn.paf.se

   In theory, there's no difference between theory and practice,
   but in practice, there is.

From: "James K. Tauber" <[email-masked]>
To: "Ron Daniel" <[email-masked]>, "Larry Masinter" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: Re: [URN] Pre release of URN Syntax document....
Date: Wed, 23 Oct 1996 11:56:50 +0800
Sender: [email-masked]
Reply-To: "James K. Tauber" <[email-masked]>

I haven't got ISO/IEC 9070 in front of me at the moment but my notes  give
the canonical public identifier owner name form of ISBNs as being hyphen
separated.

While I'm on the subject of ISO/IEC 9070...

Is there an argument for using the ISO/IEC 9070 scheme for grandfathering*
ISBNs in?

*a word that my Australian ears learnt from IETF WG discussions :-)

Also, do people think it worthwhile for the IETF (or whoever) to get an ISO
identified organisation authority prefix? This would allow the trivial
assignment of an ISO/IEC 9070 identifier for every URN, regardless of
namespace.

--
 James K. Tauber / [email-masked]
 University CWIS Coordination Officer
 The University of Western Australia

 Room 2.42, Scholars' Centre, Reid Library
 Phone: +61 9 380 7136 FAX: +61 9 380 1128

Date: Tue, 22 Oct 1996 16:39:10 -0600
To: Patrik Faltstrom <[email-masked]>, Larry Masinter <[email-masked]>
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] Pre release of URN Syntax document....
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke Patrik Faltstrom (at least at 11:31 PM 10/22/96 +0200)
>On Tue, 22 Oct 1996, Larry Masinter wrote:

>> For example, the NAPTR resolution scheme depends on regular expression
>> patterns which will not work well if all of the different syntactic
>> variations of URNs might be allowed.

>So far in the
>NAPTR proposal, _no_ regular expression is operating on the
>opaque string, even though that is possible, and interesting,
>in some namespaces.

Sorry Patrik, but the CID example and HTTP example both
extract a domain name from the opaque (NSS) portion of the URN.
Larry is correct that allowing lots of legal syntactic variants
can cause problems for the NAPTR scheme.

(Although the particular example of ISBNs would almost certainly
not be one of the cases where a problem arises. But I digress).

However, we are not talking about the same problems here.
One problem is that of lexical equivalance - the mappings all clients
need to know in order to answer the question "is it safe to regard
URN1 and URN2 as identifying the same resource". The second problem
is that of "is this URN a legal name from namespace foo"? The
second problem can't be solved in general by clients without
adopting extraordinary means, means that we have not in the past been
willing to require and I have no desire to start requiring now.

I agree that we need to define the legal form for names from namespaces
like ISBN. I think that will happen by someone preparing drafts with
titles like "The ISBN: Namespace" and we run them through review. Those
documents will have to define what are legal encodings of names, and
I think there should be as little variation as possible. But since
a client can't answer the question of "is this name legal" all it can
do is start following a resolution procedure. Resolution procedures
that try to support namespace foo MUST be able to handle the legal
encodings of names from that namespace. If that procedure wants
to attempt some sophisticated error recovery, to handle names that
have a different encoding, I say let it. If the sense of the list
is to prohibit sophisticated error recovery, well, then any documents
I edit will say that it is prohibited behavior.

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: Tue, 22 Oct 1996 16:39:10 -0600
To: Larry Masinter <[email-masked]>, [email-masked]
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] Pre release of URN Syntax document....
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke Larry Masinter (at least at 01:51 PM 10/22/96 PDT)
>Patrik Falstrom wrote:

>So I disagree with the assertion:
>
># For an ISBN, the followings should be equivalent:
>#   isbn:0-201-10174-2
>#   isbn:0201101742

I believe Patrik was saying that clients should *NOT* regard the
two as equivalent. The difference is whether some server, that
deals with ISBNs on a regular basis, may use a comparison algorithm
that is more accurate than the one clients have.

>which sounds like, but isn't the same as, what we wrote for the 'URN
>requirements' document in RFC 1737:
>
>>   o Simple comparison: A comparison algorithm for URNs is simple,
>>     local, and deterministic. That is, there is a single algorithm for
>>     comparing two URNs that does not require contacting any external
>>     server, is well specified and simple.

I think we all agree that clients need a simple algorithm, which will
probably be character-by-character comparison after we have removed
any %encoding, normalized any lexical equivalances (like the case of
the NID), etc. Patrik has raised one issue - should the "decomposition
rules in UNICODE [...] be part of these lexical equivalence
rules". I need to know more about those decomposition rules before I
can have an opinion on the subject, but it appears as if those
decomposition rules are going to be fixed across all namespaces.

As for the ISBN example above, decomposition rules or not, the
presence of hypens in one identifier and their absence in another
will cause the clients to say that the two identifiers are not the
same, although we happen to know they really do identify the same
resource. That's OK, the consequences of a false negative are much
milder than the conseqences of a false positive, so a simple comparison
procedure errs on the side of safety.

An issue that is open right now is if  we happen to be running a
server dealing with lots of ISBNs, are we allowed to run a better
equivalance algorithm that exploits our greater knowledge of the
ISBN namespace? Personally, I think that is a reasonable thing to
do. So, if such a server *somehow* gets two consecutive requests,
one for an ISBN with hypens and another for an ISBN without hyphens,
can it return the same resource or does it have to signal an error
in one of those cases? I think it should be able to return the resource
in either case, although there may be some way of indicating that
a particular form of ISBN is preferred in the future.

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]
Original-From: "Ryan Moats" <[email-masked]>
To: "Ian Higgs +44 171 542 8595" <[email-masked]>, "Patrik Faltstrom" <[email-masked]>
Cc: "URN Mailing list" <[email-masked]>
Date: Tue, 22 Oct 96 12:27:42 
Priority: Normal
Subject: Re: [URN] Pre release of URN Syntax document....
Sender: [email-masked]
Reply-To: [email-masked]

On Tue, 22 Oct 1996 07:40:45 +0200 (MET DST), Patrik Faltstrom wrote (>):
On Tue, 22 Oct 1996 11:25:46 -0400 (EDT), Ian Higgs +44 171 542 8595 replied (!):

>
>On Mon, 21 Oct 1996, Ian Higgs +44 171 542 8595 wrote:
>> 
>> ] 3. Lexical Equivalence
>> 
>> Are the following lexically equivalent?
>>         urn:isbn:0-201-10174-2
>>         isbn:0-201-10174-2
>> 
>> If so - add an example to highlighht this.
>
>It is even worse. For an ISBN, the followings should be equivalent:
>
>isbn:0-201-10174-2
>isbn:0201101742

!Maybe part of the registration process should include a definition of 
!the canonical representation of the Namespace Specific String.
!
!In practice, I would assume that the 'resource server' would accept a 
!range of formats for the NSS and would treat them as equivalent.
!This is not strictly 'lexically equivalent' - just 'functionally 
!equivalent' and would depend on the specific resource server.
!
!Aside: Do we have a generic term for the creature that returns the 
!actual resource? Is 'resource server' OK?

Hmmm, that's an interesting concept.  I have been considering 
"lexical equivalence" at the client and what you call "functionally equivalent"
at the server to be the same thing.  Basically, my definition of lexical equivalence
is that "two URNs are considered lexical equivalent at a machine if that machine
can determine unequivically USING ONLY LOCAL KNOWLEDGE that the two
URNs will return in the same resource."

(Of course, I can change this given a good enough reason).

Thus, Ian's example above (with/without urn:) is one where the two URN's
are lexically equivalent at both a client and a URN resolver.  However,
Patrik's example is one where the two URN's are not lexically equivalent
at a client but would be lexically equivalent at a URN resolver.

The bottom line is that I view lexical equivalence as a local phenomenom, rather
than a global one.  It dawns on me that I should probably add words to that affect
(and possibly use these examples to highlight this) in the draft.

Ryan

P.S.  BTW, Anybody know the deadline for I-D submission for San Jose?  I
am planning on incorperating as many of the comments as I've gotten on the
syntax draft before submitting for publication before Dec., and I haven't seen
a date (and I'm stuck on a plane right now, so I don't have access to our
mirror sites of this type of information).

Date: Tue, 22 Oct 1996 23:31:48 +0200 (MET DST)
From: Patrik Faltstrom <[email-masked]>
To: Larry Masinter <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [URN] Pre release of URN Syntax document....
Sender: [email-masked]
Reply-To: Patrik Faltstrom <[email-masked]>

On Tue, 22 Oct 1996, Larry Masinter wrote:

> >   o Simple comparison: A comparison algorithm for URNs is simple,
> >     local, and deterministic. That is, there is a single algorithm for
> >     comparing two URNs that does not require contacting any external
> >     server, is well specified and simple.
> 
> This was discussed at length. It's true that it would be useful for
> those who know about ISBNs to allow both isbn:0-201-10174-2 and
> isbn:0210101742, but having a large variety of syntactic equivalences
> has a large cost.

What I am trying to say is that the general URN comparison algorithm
must define a case of equivalence which is useful for some applications,
but not for other. It can only deal with lexical equivalence,
and what we are discussing are things like if the decomposition
rules in UNICODE should be part of these lexical equivalence
rules.

On a different level, the namespace itself can define a kind
of equivalence which makes it possible for example to use
the urn "urn:isbn:0-201-10174-2" or "urn:isbn:0210101742"
and get the same object. They are syntactical equivalent,
but not lexical.

> For example, the NAPTR resolution scheme depends on regular expression
> patterns which will not work well if all of the different syntactic
> variations of URNs might be allowed.

The NAPTR proposal does only say that you can use regular expressions
to find the resolution service. When you have found that service,
you always pass the full URN to that service (if nothing special
is specified as a protocol specific functionality). So far in the
NAPTR proposal, _no_ regular expression is operating on the
opaque string, even though that is possible, and interesting,
in some namespaces.

You have to remember that the regular expression is constructed
and stored by the owner of the URN which the expression is
operating on, so that person knows what target the expression
is operating on. Just like the fact that one namespace might
have its own ways of defining the word equivalence when accessing
the final resolution service.
 
> So I disagree with the assertion:
> 
> # For an ISBN, the followings should be equivalent:
> #   isbn:0-201-10174-2
> #   isbn:0201101742
> 
> If you're going to 'grandfather' ISBN numbers, you should do so in a
> single unambiguous way.

You have to differ between what result you get when you "just"
compare the lexical equivalence between the two urns and what
you get when you try to resolve the two urns in the final
resolver which knows about isbns. I.e. one thing is the
equivalence when looking at them as urns, and then they
are different, but later, when having knowledge about the
isbn namespace, they should be equivalent.

One thing is defined in the urn paper, and one in the paper
which describes the isbn namespace.

I don't think the urn paper and the namespace papers have to
have the same definition of "equivalent".

   Patrik

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [URN] Pre release of URN Syntax document....
From: Larry Masinter <[email-masked]>
Date: Tue, 22 Oct 1996 13:51:55 PDT
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

Patrik Falstrom wrote:

# Exactly my point, but I was not explicit. Lexical equivalence must
# be something that is handled by the resource server for that specific
# namespace. On the URN "level" we can only state some kind of
# very, very simple comparison methods and point out that it is
# the resource service for that namespace that handles the real
# comparison.

which sounds like, but isn't the same as, what we wrote for the 'URN
requirements' document in RFC 1737:

>   o Simple comparison: A comparison algorithm for URNs is simple,
>     local, and deterministic. That is, there is a single algorithm for
>     comparing two URNs that does not require contacting any external
>     server, is well specified and simple.

This was discussed at length. It's true that it would be useful for
those who know about ISBNs to allow both isbn:0-201-10174-2 and
isbn:0210101742, but having a large variety of syntactic equivalences
has a large cost.

For example, the NAPTR resolution scheme depends on regular expression
patterns which will not work well if all of the different syntactic
variations of URNs might be allowed.

So I disagree with the assertion:

# For an ISBN, the followings should be equivalent:
#   isbn:0-201-10174-2
#   isbn:0201101742

If you're going to 'grandfather' ISBN numbers, you should do so in a
single unambiguous way.

Larry

Date: Tue, 22 Oct 1996 12:21:28 -0500 (CDT)
From: Daniel LaLiberte <[email-masked]>
To: Ron Daniel <[email-masked]>
Cc: URN Mailing list <[email-masked]>
Subject: Re: [URN] Pre release of URN Syntax document....
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Ron Daniel writes:
 > I think you are the one who described it as "unnecessary, but harmless".

"Unnecessary and insufficient, but harmless." is a good paraphrase of
my WWW4 panel presentation
<URL:http://union.ncsa.uiuc.edu/~liberte/www/URN-prefix.html> 
'"URN:" is neither necessary nor sufficient - but it's OK'

If anyone wants to continue this, email me.

dan

Date: Tue, 22 Oct 1996 10:06:59 -0700 (PDT)
From: Terry Allen <[email-masked]>
To: [email-masked]
Subject: [URN] re urn: optional
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

Within appropriate markup, urn: may add no information, e.g.,
<biblioentry>
 <title>A Complete History of Algiers</title>
  ...
  <urn>sbn:8371-3613-X</urn>
</biblioentry>

(yes, this book identifies iteself by SBN, not ISBN).

It might be desireable to cat on "URN:" when using this
information in some contexts, and to avoid confusion,
"URN" should not be used as the name space identifier
for any naming scheme registered as an URN scheme, that
is, no URN:URN:something.  

Regards,
    Terry Allen    Fujitsu Software Corp.    [email-masked]
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

Date: Tue, 22 Oct 1996 18:32:54 +0200
To: Ron Daniel <[email-masked]>, URN Mailing list <[email-masked]>
From: Patrik Faltstrom <[email-masked]>
Subject: Re: [URN] Pre release of URN Syntax document....
Sender: [email-masked]
Reply-To: Patrik Faltstrom <[email-masked]>

At 09.46 -0600 96-10-22, Ron Daniel wrote:
>>] It is even worse. For an ISBN, the followings should be equivalent:
>>]
>>] isbn:0-201-10174-2
>>] isbn:0201101742
>
>This sort of lexical equivalance cannot be determined in general. It
>is specific to the namespace. A client without special knowledge of
>the isbn: namespace cannot be expected to compare
>isbn:0-201-10174-2 to isbn:0210101742 and conclude they are equivalent.

Exactly my point, but I was not explicit. Lexical equivalence must
be something that is handled by the resource server for that specific
namespace. On the URN "level" we can only state some kind of
very, very simple comparison methods and point out that it is
the resource service for that namespace that handles the real
comparison.

  paf

--------------------------------------------------------------------
   Senior Researcher, Tele2/SwipNet     Stockholm, Sweden
   [email-masked]                         Phone: +46-8-56264000
   urn:inet:urn.paf.se

   In theory, there's no difference between theory and practice,
   but in practice, there is.

Date: Tue, 22 Oct 1996 10:31:34 -0600
To: Daniel LaLiberte <[email-masked]>, Ian Higgs +44 171 542 8595 <[email-masked]>
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] Pre release of URN Syntax document....
Cc: URN Mailing list <[email-masked]>, Ryan Moats <[email-masked]>
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke Daniel LaLiberte (at least at 11:54 AM 10/21/96 -0500)

>Is the intent that "urn:" be optional within more contexts, such
>as within HTML documents following "HREF="?

That is *my* intent, although I would be interested in feedback
from the list on the subject. The bit about the urn: being optional
is because its presence or absence has always degenerated into
a religious war. I think you are the one who described it as
"unnecessary, but harmless". I think allowing it can ease the
transition period, since Navigator clients will send things starting
with urn: to the HTTP proxy instead of reporting an unknown protocol
error. Other than that I agree with your statement.

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: Tue, 22 Oct 1996 09:46:32 -0600
To: URN Mailing list <[email-masked]>
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] Pre release of URN Syntax document....
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke Ian Higgs +44 171 542 8595 (at least at 11:25 AM 10/22/96 -0400)
>Then Patrik Faltstrom wrote:
>
>] It is even worse. For an ISBN, the followings should be equivalent:
>] 
>] isbn:0-201-10174-2
>] isbn:0201101742

This sort of lexical equivalance cannot be determined in general. It
is specific to the namespace. A client without special knowledge of
the isbn: namespace cannot be expected to compare
isbn:0-201-10174-2 to isbn:0210101742 and conclude they are equivalent.

A resolver or resource server may have such knowledge, since if they
deal with any ISBNs, they probably deal with a lot of them. I think this
example illustrates just what the syntax draft is talking about when
it makes a distinction between the equivalance procedure that can be
applied at a client and at a server. The client procedure is going
to give a lot of false negatives, the server procedure will be able
to give fewer false negatives.

>Maybe part of the registration process should include a definition of 
>the canonical representation of the Namespace Specific String.

Sounds reasonable.

>In practice, I would assume that the 'resource server' would accept a 
>range of formats for the NSS and would treat them as equivalent.
>This is not strictly 'lexically equivalent' - just 'functionally 
>equivalent' and would depend on the specific resource server.

Yes, but this will be up to the people running the resource
servers.

>Aside: Do we have a generic term for the creature that returns the 
>actual resource? Is 'resource server' OK?

I have been calling it the "repository" in off-list communication,
but "resource server" is OK. Either way.
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"

Mr-Received: by mta REC.MUAS; Relayed; Tue, 22 Oct 1996 11:25:46 -0400
Mr-Received: by mta RE5; Relayed; Tue, 22 Oct 1996 11:25:50 -0400
Mr-Received: by mta RITIG4; Relayed; Tue, 22 Oct 1996 11:26:20 -0400
Disclose-Recipients: prohibited
Date: Tue, 22 Oct 1996 11:25:46 -0400 (EDT)
From: Ian Higgs +44 171 542 8595 <[email-masked]>
Subject: Re: [URN] Pre release of URN Syntax document....
To: Patrik Faltstrom <[email-masked]>
Cc: URN Mailing list <[email-masked]>, Ryan Moats <[email-masked]>
Autoforwarded: false
Importance: normal
Priority: urgent
Sensitivity: Company-Confidential
Ua-Content-Id: 11AAB2D92E00
X400-Mts-Identifier: [;8146251122101996/A24314/RE5]
Hop-Count: 2
Sender: [email-masked]
Reply-To: Ian Higgs +44 171 542 8595 <[email-masked]>

] On Mon, 21 Oct 1996, Ian Higgs +44 171 542 8595 wrote:
] > Are the following lexically equivalent?
] >         urn:isbn:0-201-10174-2
] >         isbn:0-201-10174-2

Then Patrik Faltstrom wrote:

] It is even worse. For an ISBN, the followings should be equivalent:
] 
] isbn:0-201-10174-2
] isbn:0201101742

Maybe part of the registration process should include a definition of 
the canonical representation of the Namespace Specific String.

In practice, I would assume that the 'resource server' would accept a 
range of formats for the NSS and would treat them as equivalent.
This is not strictly 'lexically equivalent' - just 'functionally 
equivalent' and would depend on the specific resource server.

Aside: Do we have a generic term for the creature that returns the 
actual resource? Is 'resource server' OK?

/Ian

Date: Tue, 22 Oct 1996 07:40:45 +0200 (MET DST)
From: Patrik Faltstrom <[email-masked]>
To: Ian Higgs +44 171 542 8595 <[email-masked]>
Cc: URN Mailing list <[email-masked]>, Ryan Moats <[email-masked]>
Subject: Re: [URN] Pre release of URN Syntax document....
Sender: [email-masked]
Reply-To: Patrik Faltstrom <[email-masked]>

On Mon, 21 Oct 1996, Ian Higgs +44 171 542 8595 wrote:
> 
> ] 3. Lexical Equivalence
> 
> Are the following lexically equivalent?
>         urn:isbn:0-201-10174-2
>         isbn:0-201-10174-2
> 
> If so - add an example to highlighht this.

It is even worse. For an ISBN, the followings should be equivalent:

isbn:0-201-10174-2
isbn:0201101742

   paf

From: "Ryan Moats" <[email-masked]>
To: "Martin J Duerst" <[email-masked]>, "Patrik Faltstrom" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Mon, 21 Oct 96 15:04:20 
Priority: Normal
Subject: Re: [URN] Pre release of URN Syntax document....
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Mon, 21 Oct 1996 20:36:58 +0200 (MET DST), Patrik Faltstrom wrote:

>
>On Mon, 21 Oct 1996, Martin J Duerst wrote:
>
>> The other big problem is equivalence. For Unicode, character equivalence
>> is in some cases not the same as codepoint equivalence. Charecter
>> equivalence is well defined, but there is currently no standard
>> for normalization.
>
>What exists are the decomposition rules for Unicode. Those are well defined.

True, but I should probably add some stuff to section 3 about this.

>> This does not concern things such as case,
>> where the user can easily distinguish lower case and upper case,
>> but cases such as A-with-Grave, which can be encoded both as
>> one single codepoint and as the sequence A, Grave.
>
>The casing is also defined in the Unicode spec.
>
>What you do is to first decompose the string (i.e. change
>A-with-Grave into A, Grave), and then do the case insensitive
>comparison (if you want to).
>
>All of this is implemented in the Digger Whois++ server from
>Bunyip. It is doable!

Ah, yes but in the server, rather than in the client...

>> Another problem that should be considered are bidirectionality
>> for Hebrew and Arabic.
>
>It should be defined, just like in MIME, that characters are
>stored in the order they are stored, not displayed. (At least
>I remember that we discussed this with display order in the
>MIME community in an interesting meeting faaaar back in time,
>which was ended by looking at some example where two hebrew
>users, using the same computer, was using different display
>order...).

I agree with Patrik.  Regardless of glyph direction order, NSS octets
are in order of presentation ie. (for left->right, left most character first,
for right->left right most character first, etc.)

>> It would be a good idea if URN resolvers could alos care about
>> UNicode character equivalence. But maybe some schemes would do
>> that easier than others?
>
>It is the resolution service that have to care about character
>equivalence. The URN spec should only say UTF-8 from my point of
>view. It could though be noted that A-with-grave and A, Grave in
>Unicode is regarded as an example of equivalent characters.

I agree with Patrik again.  I have added the note.

Ryan

From: "Ryan Moats" <[email-masked]>
To: "Martin J Duerst" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Mon, 21 Oct 96 14:57:48 
Priority: Normal
Subject: Re: [URN] Pre release of URN Syntax document....
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

Since I've seen Patrik's comments, I'll only comment on things that
he didn't and then add mine in a reply to his comments in a minute...

On Mon, 21 Oct 1996 19:38:53 +0100 (MET), Martin J Duerst wrote:

>Ryan Moats wrote:
>
>Well, first a great scream of joy and congratulations that you have
>made it with iso10646/UTF-8. More comments on that below.

I'll admit that it was a last minute addition, and did hold things up a
bit while some issues were sorted out.  However, might as well get things
going now...

>>1.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>         ::= <letter> [ <let-hyp> ]
>>
>>   <let-hyp>     ::= <letter> | "-"
>>
>>   <letter>      ::= any one of the 52 alphabetic characters A through Z
>>                     in upper case and a through z in lower case
>>
>>   This is slightly more restrictive that what is stated in RFC 1738 [4]
>>   (which allows the period "."). Further, the Namespace Identifier is
>>   case insensitive, so that "ISBN" and "isbn" refer to the same
>>   namespace.
>
>Kind of disappointed that i18n didn't make it for NIS. But it's probably
>not necessary. And if it becomes necessary, we could just create a new
>NIS, "i" for short, and could prefix it. Or am I stretching my understanding
>of URN syntax too much?

I don't like this,  because it precludes freedom in the resolving scheme.

>One main problem is that while the URL/URI didn't specify any
>character semantics, this proposal defines everything in terms
>of characters.
>For URL/URIs, it was not defined what character, or part of a
>character, bytes above 0x7F were denoting, nor was one even sure,
>after reading the specs, that an "A" in an URL was supposed to be
>the character "A". One only got a certain confidence in such
>coincidences after having a look at some actual examples.
>This had some advantages, as it left open any decisions for
>the individual protocols, and it also considered cases where
>the information in the URL did not have anything to do with
>characters (e.g. something like the data URL).
>So I think the spec should go more in the direction of:
>
>- If an NSS contains characters, these should be encoded using UTF-8.
>- If an NSS contains something else (e.g. pure data), this can be
>	encoded directly using %HH.
>- If an NSS, for some reasons, decides to use a different encoding
>	for characters, this is not prohibited (but not suggested).
>
>When the second point is introduced, the third cannot be avoided
>anyway, because a NSS scheme may just define that it does %HH encoding
>on its own, using a different character syntax, and the NSS encoding
>of the characters in that scheme would only trivially encode
>ASCII characters (with lots of "%" in it).
>
>This will also mean that NSS are not limited to be correct UTF-8
>sequences.

I'll have to think about all of this, but my first reaction is that I don't like
it.

The rest will come in the next mail message...

>>2. Grand-fathering
>>
>>   To allow for grand-fathering of existing naming systems (as required
>>   by [2]), the Namespace Specific String shall be considered an "opaque
>>   string" in the sense of structure except as mentioned in Section 1.
>
>Just the fact that it is considered a string of characters in all cases
>is somewhat restricting.

Oh, I see.  I wasn't thinking in terms of strings of characters, I was thinking in
terms of string of octets. Guess I should change this, then.

Lexica Equivalence will come in the next message.

Ryan

Date: Mon, 21 Oct 1996 12:40:59 -0700 (PDT)
From: Terry Allen <[email-masked]>
To: [email-masked]
Subject: [URN] re URN sytax
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

Martin writes:
| So I think the spec should go more in the direction of:
| 
| - If an NSS contains characters, these should be encoded using UTF-8.
| - If an NSS contains something else (e.g. pure data), this can be
| 	encoded directly using %HH.

Just to keep myself clear on what you're saying, ISO 10646 mixes
glyphs and characters.  By "characters" above, are you excluding
glyphs-that-are-not-themselves-characters?  Are those glyphs 
data?  Or do you expect people not to use glyphs that aren't
characters?

Regards,
    Terry Allen    Fujitsu Software Corp.    [email-masked]
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

From: "Ryan Moats" <[email-masked]>
To: "Daniel LaLiberte" <[email-masked]>
Cc: "URN Mailing list" <[email-masked]>
Date: Mon, 21 Oct 96 14:37:43 
Priority: Normal
Subject: Re: [URN] Pre release of URN Syntax document....
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Mon, 21 Oct 1996 11:54:35 -0500 (CDT), Daniel LaLiberte wrote:

>Regarding grandfathering (a clear definition would be useful), I just
>want to point out that when incorporating existing names from a name
>scheme into another scheme, there is almost always some translation
>that is required.  The translation might just be to mapping to a
>different character set, or it might involve a more radical
>restructuring of the syntax.  The important thing to preserve in a
>name scheme is the semantics, or the higher-level structure.  For
>example, if a name scheme supports a hierarchy of naming authorities,
>then the notation for expressing the hierarchy in a name might be
>different (e.g.  different delimiter or reverse the order of
>components), but the hierarchy should still be accessible.

Since grandfathering is meant as supporting existing legacy naming systems,
I want to minimize the amount of translation necessary.  I also feel that the
structure is required at the resolver, but not the client.  Thinking about syntax,
the previous sentence has become an important consideration, not only for
grandfathering (sorry, american colloquialism) but also for lexical equivalence
(see forthcoming message)...

"I see discussion, lots of discussion"...

Ryan Moats

From: "Ryan Moats" <[email-masked]>
To: "Ian Higgs +44 171 542 8595" <[email-masked]>, "URN Mailing list" <[email-masked]>
Date: Mon, 21 Oct 96 14:32:05 
Priority: Normal
Subject: Re: [URN] Pre release of URN Syntax document....
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

>] Abstract
>] 1. Syntax
>]    requirement to grandfather existing naming systems has the effect of
>
>"grandfather" as a verb? There is no definition of what that means here.

American colloquialism strikes again.  I will replace "grandfather existing
naming systems" with "support existing legacy naming systems", as that
is the connotation wanted here.

>RFC1630 allows URI scheme names to include all letters and digits, 
>as well as a whole bunch of punctuation. Hosts names also include digits.
>
>Why not digits in namespace identifiers? They should be harmless enough.
>(We could probably allow some punctuation too.)

Well, this is where it starts to get a little more difficult.  I can live with numbers
and some other characters, but punctuation is not acceptable.  The problem
is supporting the broadest range of potential resolution scheme (the "let a
million flowers bloom concept").

>] 1.2 Namespace Specific String Syntax
>]    Therefore, each namespace shall indicate which characters have
>]    special meaning and how (if possible) to encode those characters if
>]    used in a literal sense.
>
>Where and how shall a namespace indicate this? Include the BNF in the NID?
>
>Do you mean something like ...
>
>   The process of registering a namespace identifier shall included
>   publication of a definition of which characters have a special
>   meaning and how to encode those characters if used in a literal sense.

Yes, this is what I meant.  I have replaced my wording with yours.

>] 2. Grand-fathering
>
>It may be well understood by the URI/URN regulars, but please define here
>what is meant by "Grand-fathering". The term is not defined in RFC1737.

See my above comment about "grandfathering".

>] 3. Lexical Equivalence
>
>Are the following lexically equivalent?
>        urn:isbn:0-201-10174-2
>        isbn:0-201-10174-2
>
>If so - add an example to highlighht this.

Yes, they are, and I have added an example.

>] 4. Security considerations
>]    ... Each namespace shall therefore indicate which characters ...
>
>How? Where?

This is a restatement of the stuff in section 1.2.  I have used the replacement text
here, also.

>] 6. References
>]          [1]         L. L. Diagle, P. Falstrom, R. Iannella.  "A Frame-
>]                      work for the Assignment and Resolution of Uniform
>]                      Resource Names", Internet Draft (work in progress).
>]                      June 1996.
>
>URL?

I didn't get this...

>Should this document make any reference to the process for registering
>namespace identifiers?

I don't think so.  I think that should be part of  the framework document (MHO).

Ryan Moats

Date: Mon, 21 Oct 1996 20:36:58 +0200 (MET DST)
From: Patrik Faltstrom <[email-masked]>
To: Martin J Duerst <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Pre release of URN Syntax document....
Sender: [email-masked]
Reply-To: Patrik Faltstrom <[email-masked]>

On Mon, 21 Oct 1996, Martin J Duerst wrote:

> The other big problem is equivalence. For Unicode, character equivalence
> is in some cases not the same as codepoint equivalence. Charecter
> equivalence is well defined, but there is currently no standard
> for normalization.

What exists are the decomposition rules for Unicode. Those are well defined.

> This does not concern things such as case,
> where the user can easily distinguish lower case and upper case,
> but cases such as A-with-Grave, which can be encoded both as
> one single codepoint and as the sequence A, Grave.

The casing is also defined in the Unicode spec.

What you do is to first decompose the string (i.e. change
A-with-Grave into A, Grave), and then do the case insensitive
comparison (if you want to).

All of this is implemented in the Digger Whois++ server from
Bunyip. It is doable!

> Another problem that should be considered are bidirectionality
> for Hebrew and Arabic.

It should be defined, just like in MIME, that characters are
stored in the order they are stored, not displayed. (At least
I remember that we discussed this with display order in the
MIME community in an interesting meeting faaaar back in time,
which was ended by looking at some example where two hebrew
users, using the same computer, was using different display
order...).

> It would be a good idea if URN resolvers could alos care about
> UNicode character equivalence. But maybe some schemes would do
> that easier than others?

It is the resolution service that have to care about character
equivalence. The URN spec should only say UTF-8 from my point of
view. It could though be noted that A-with-grave and A, Grave in
Unicode is regarded as an example of equivalent characters.

    Patrik

Subject: Re: [URN] Pre release of URN Syntax document....
To: [email-masked]
Date: Mon, 21 Oct 1996 19:38:53 +0100 (MET)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Content-Length: 6658
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Ryan Moats wrote:

>Well folks, we've reached the point where this is ready for the list
>to scream about (semi :-) ).

Well, first a great scream of joy and congratulations that you have
made it with iso10646/UTF-8. More comments on that below.

>Internet-Draft                                                Ryan Moats
>draft-ietf-urn-syntax-00.txt                                        AT&T
>Expires in six months                                       October 1996

>Abstract
>
>   This document presents the syntax for Uniform Resource Names (URNs).
>   More information on the purpose of URNs is available from [1].
>
>1. Syntax
>
>   All URNs have the following syntax:
>
>
>   <URN> ::= ["urn:"] <NID> ":" <NSS>
>
>   <NID> is the Namespace IDentifier, and <NSS> is the Namespace
>   Specific String.  The Namespace ID is used to determine the
>   _syntactic_ interpretation of the Namespace Specific String to the
>   extent of extracting the Naming Authority information (as discussed
>   in [1]).

>1.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>         ::= <letter> [ <let-hyp> ]
>
>   <let-hyp>     ::= <letter> | "-"
>
>   <letter>      ::= any one of the 52 alphabetic characters A through Z
>                     in upper case and a through z in lower case
>
>   This is slightly more restrictive that what is stated in RFC 1738 [4]
>   (which allows the period "."). Further, the Namespace Identifier is
>   case insensitive, so that "ISBN" and "isbn" refer to the same
>   namespace.

Kind of disappointed that i18n didn't make it for NIS. But it's probably
not necessary. And if it becomes necessary, we could just create a new
NIS, "i" for short, and could prefix it. Or am I stretching my understanding
of URN syntax too much?

>1.2 Namespace Specific String Syntax
>
>   Depending on the rules governing a namespace, valid identifiers in a
>   namespace might contain characters that are reserved characters in
>   URI syntax or non-printable ASCII characters.  To accommodate the
>   largest set of valid identifiers, the NSS portion of a URN shall use
>   UTF-8 representation of ISO 10646 as its character set.

This is really what I have waited for for a long time. As I wrote in
a different mail, I have discussed that with many people on many
occasions. It is definitely the right direction to go. But it needs
a few refinements to assure it will work nicely, and to assure it
won't be getting unnecessary opposition. Hopefully, these things
can be integrated in this document; maybe another document is
needed.

One main problem is that while the URL/URI didn't specify any
character semantics, this proposal defines everything in terms
of characters.
For URL/URIs, it was not defined what character, or part of a
character, bytes above 0x7F were denoting, nor was one even sure,
after reading the specs, that an "A" in an URL was supposed to be
the character "A". One only got a certain confidence in such
coincidences after having a look at some actual examples.
This had some advantages, as it left open any decisions for
the individual protocols, and it also considered cases where
the information in the URL did not have anything to do with
characters (e.g. something like the data URL).
So I think the spec should go more in the direction of:

- If an NSS contains characters, these should be encoded using UTF-8.
- If an NSS contains something else (e.g. pure data), this can be
	encoded directly using %HH.
- If an NSS, for some reasons, decides to use a different encoding
	for characters, this is not prohibited (but not suggested).

When the second point is introduced, the third cannot be avoided
anyway, because a NSS scheme may just define that it does %HH encoding
on its own, using a different character syntax, and the NSS encoding
of the characters in that scheme would only trivially encode
ASCII characters (with lots of "%" in it).

This will also mean that NSS are not limited to be correct UTF-8
sequences.

The other big problem is equivalence. For Unicode, character equivalence
is in some cases not the same as codepoint equivalence. Charecter
equivalence is well defined, but there is currently no standard
for normalization. This does not concern things such as case,
where the user can easily distinguish lower case and upper case,
but cases such as A-with-Grave, which can be encoded both as
one single codepoint and as the sequence A, Grave.

Another problem that should be considered are bidirectionality
for Hebrew and Arabic.

>   URN resolvers MUST be capable of accepting URNs that have been
>   %encoded for either 8-bit clean or 7-bit transports.  %encoding is
>   removed first, then UTF-8 decoding is performed.  URN resolvers MUST
>   return identical results from ANY legally encoded form of the URN.

It would be a good idea if URN resolvers could alos care about
UNicode character equivalence. But maybe some schemes would do
that easier than others?

>   It should be noted that certain characters in the Namespace Specific
>   String syntax may have special meaning in certain namespaces.
>   Therefore, each namespace shall indicate which characters have
>   special meaning and how (if possible) to encode those characters if
>   used in a literal sense.

Rather a great requirement on implementors, because they have to know
new things for every new namespace. But maybe it cannot be avoided.
The question here is: How to escape a character beyond ASCII?
Would it be possible to specify that all characters in ASCII,
if in %HH form, are to be considered escaped?

>2. Grand-fathering
>
>   To allow for grand-fathering of existing naming systems (as required
>   by [2]), the Namespace Specific String shall be considered an "opaque
>   string" in the sense of structure except as mentioned in Section 1.

Just the fact that it is considered a string of characters in all cases
is somewhat restricting.

>3. Lexical Equivalence
>   Lexical equivalence at the server is dependent on the namespace, and
>   thus each namespace shall indicate how lexical equivalence may be
>   determined by servers for URNs specifying resources in that
>   namespace.

As said, some general help or suggestions for Unicode character
equivalence might be in order here. This does not restrict
individual namespaces to go further in declaring equivalences.

That's it, for the moment. Looking forward to interesting discussions.
Regards,	Martin.

Date: Mon, 21 Oct 1996 11:54:35 -0500 (CDT)
From: Daniel LaLiberte <[email-masked]>
To: Ian Higgs +44 171 542 8595 <[email-masked]>
Cc: URN Mailing list <[email-masked]>, Ryan Moats <[email-masked]>
Subject: Re: [URN] Pre release of URN Syntax document....
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Ian Higgs writes:
 > ] 3. Lexical Equivalence
 > 
 > Are the following lexically equivalent?
 >         urn:isbn:0-201-10174-2
 >         isbn:0-201-10174-2

Good question.  I think the answer must be "yes".  I noticed that the
syntax made "urn:" optional, but nothing more was said about it.
Since it is optional, it is much like the "URL:" prefix that is also
optional in some circumstances, usually within arbitrary text.
Is the intent that "urn:" be optional within more contexts, such
as within HTML documents following "HREF="?

Regarding grandfathering (a clear definition would be useful), I just
want to point out that when incorporating existing names from a name
scheme into another scheme, there is almost always some translation
that is required.  The translation might just be to mapping to a
different character set, or it might involve a more radical
restructuring of the syntax.  The important thing to preserve in a
name scheme is the semantics, or the higher-level structure.  For
example, if a name scheme supports a hierarchy of naming authorities,
then the notation for expressing the hierarchy in a name might be
different (e.g.  different delimiter or reverse the order of
components), but the hierarchy should still be accessible.

This probably raises more questions than it answers.  That was my intent.

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

Mr-Received: by mta REC.MUAS; Relayed; Mon, 21 Oct 1996 17:17:36 -0400
Mr-Received: by mta RE5; Relayed; Mon, 21 Oct 1996 17:17:38 -0400
Mr-Received: by mta RITIG4; Relayed; Mon, 21 Oct 1996 17:18:05 -0400
Disclose-Recipients: prohibited
Date: Mon, 21 Oct 1996 17:17:36 -0400 (EDT)
From: Ian Higgs +44 171 542 8595 <[email-masked]>
Subject: Re: [URN] Pre release of URN Syntax document....
To: URN Mailing list <[email-masked]>
Cc: Ryan Moats <[email-masked]>
Autoforwarded: false
Importance: normal
Priority: urgent
Sensitivity: Company-Confidential
Ua-Content-Id: 11AAAC512400
X400-Mts-Identifier: [;8336171721101996/A16366/RE5]
Hop-Count: 2
Sender: [email-masked]
Reply-To: Ian Higgs +44 171 542 8595 <[email-masked]>

] Well folks, we've reached the point where this is ready for the list
] to scream about (semi :-) ).
] Have at it....

I have a few gentle comments - no screams (as yet)

+++START+++

] Abstract
] 1. Syntax
]    requirement to grandfather existing naming systems has the effect of

"grandfather" as a verb? There is no definition of what that means here.

] 1.1 Namespace Identifier Syntax
]    <NID>         ::= <letter> [ <let-hyp> ]
]    <let-hyp>     ::= <letter> | "-"

RFC1630 allows URI scheme names to include all letters and digits, 
as well as a whole bunch of punctuation. Hosts names also include digits.

Why not digits in namespace identifiers? They should be harmless enough.
(We could probably allow some punctuation too.)

] 1.2 Namespace Specific String Syntax
]    Therefore, each namespace shall indicate which characters have
]    special meaning and how (if possible) to encode those characters if
]    used in a literal sense.

Where and how shall a namespace indicate this? Include the BNF in the NID?

Do you mean something like ...

   The process of registering a namespace identifier shall included
   publication of a definition of which characters have a special
   meaning and how to encode those characters if used in a literal sense.

] 2. Grand-fathering

It may be well understood by the URI/URN regulars, but please define here
what is meant by "Grand-fathering". The term is not defined in RFC1737.

] 3. Lexical Equivalence

Are the following lexically equivalent?
        urn:isbn:0-201-10174-2
        isbn:0-201-10174-2

If so - add an example to highlighht this.

] 4. Security considerations
]    ... Each namespace shall therefore indicate which characters ...

How? Where?

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

URL?

+++END+++

Should this document make any reference to the process for registering
namespace identifiers?

Regards
/Ian Higgs
-------------------------------------------------
 Ian Higgs
 Reuters Limited,  Email:  [email-masked]
 85 Fleet Street,  Fax:    +44 171 542 8314
 London EC4P 4AJ,  Phone:  +44 171 542 8595
 England
-------------------------------------------------

From: "Ryan Moats" <[email-masked]>
To: "URN mailing list" <[email-masked]>
Cc: "Leslie Daigle" <[email-masked]>, "Michael Mealling" <[email-masked]>, "Ron Daniel" <[email-masked]>, "Martin J Duerst" <[email-masked]>, "Patrik Faltstrom" <[email-masked]>
Date: Fri, 18 Oct 96 12:52:34 
Priority: Normal
Subject: [URN] Pre release of URN Syntax document....
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

Well folks, we've reached the point where this is ready for the list
to scream about (semi :-) ).

Have at it....

Ryan Moats
InterNIC Directory and Database Services
[email-masked]

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

Internet-Draft                                                Ryan Moats
draft-ietf-urn-syntax-00.txt                                        AT&T
Expires in six months                                       October 1996

                               URN Syntax
                 Filename: draft-ietf-urn-syntax-00.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

   This document presents the syntax for Uniform Resource Names (URNs).
   More information on the purpose of URNs is available from [1].

1. Syntax

   All URNs have the following syntax:

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

   <NID> is the Namespace IDentifier, and <NSS> is the Namespace
   Specific String.  The Namespace ID is used to determine the
   _syntactic_ interpretation of the Namespace Specific String to the
   extent of extracting the Naming Authority information (as discussed
   in [1]).

   RFC 1737 [2] puts additional requirements on URN encoding, which all

Expires 4/97                                                    [Page 1]

INTERNET DRAFT                 URN Syntax                   October 1996

   have implications as far as limiting syntax.  On the other hand, the
   requirement to grandfather existing 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.

1.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>         ::= <letter> [ <let-hyp> ]

   <let-hyp>     ::= <letter> | "-"

   <letter>      ::= any one of the 52 alphabetic characters A through Z
                     in upper case and a through z in lower case

   This is slightly more restrictive that what is stated in RFC 1738 [4]
   (which allows the period "."). Further, the Namespace Identifier is
   case insensitive, so that "ISBN" and "isbn" refer to the same
   namespace.

1.2 Namespace Specific String Syntax

   Depending on the rules governing a namespace, valid identifiers in a
   namespace might contain characters that are reserved characters in
   URI syntax or non-printable ASCII characters.  To accommodate the
   largest set of valid identifiers, the NSS portion of a URN shall use
   UTF-8 representation of ISO 10646 as its character set.

   Clients MUST be capable of %encoding the UTF-8 formatted NSS,
   according the rules in [3] with the following exceptions:

      1. [3] states that occurrence of the '/' character in URIs must
      denote hierarchy, so that partial forms of a URI are possible.
      This restriction is unenforceable, and relative URLs do not have a
      scheme prefix, so we allow URNs to contain unescaped occurrences
      of the '/' character that do not denote hierarchy.

      2. As an optimization when the transport between systems is known
      to be 8-bit-clean, clients MAY omit the %encoding on 8-bit
      characters but MUST still %encode the reserved characters below.

   For historic reasons, the characters "#", "?", "%", "*", "!", "<",
   ">", and '"', are reserved and must be encoded with '%'.  Thus client

Expires 4/97                                                    [Page 2]

INTERNET DRAFT                 URN Syntax                   October 1996

   implementers should accept URNs from users in an unencoded form but
   must encode them before sending them to a resolver.

   URN resolvers MUST be capable of accepting URNs that have been
   %encoded for either 8-bit clean or 7-bit transports.  %encoding is
   removed first, then UTF-8 decoding is performed.  URN resolvers MUST
   return identical results from ANY legally encoded form of the URN.

   It should be noted that certain characters in the Namespace Specific
   String syntax may have special meaning in certain namespaces.
   Therefore, each namespace shall indicate which characters have
   special meaning and how (if possible) to encode those characters if
   used in a literal sense.

2. Grand-fathering

   To allow for grand-fathering of existing naming systems (as required
   by [2]), the Namespace Specific String shall be considered an "opaque
   string" in the sense of structure except as mentioned in Section 1.

3. Lexical Equivalence

   As discussed previously, Namespace Identifiers are to be considered
   case-insensitive. That is, the following two URNs are lexically
   equivalent:

           urn:isbn:0-201-10174-2
           urn:ISBN:0-201-10174-2

   Lexical equivalence at the client is restricted to unencoding '%'
   sequences, with other comparisons being considered case sensitive.
   That is, the following two URNs are lexically equivalent at a client:

           urn:foo:John DeSilva
           urn:foo:John%20DeSilva

   but the following two URNs are NOT lexically equivalent at a client:

           urn:foo:John%20DeSilva
           urn:foo:John%20deSilva

   Lexical equivalence at the server is dependent on the namespace, and
   thus each namespace shall indicate how lexical equivalence may be
   determined by servers for URNs specifying resources in that
   namespace.

Expires 4/97                                                    [Page 3]

INTERNET DRAFT                 URN Syntax                   October 1996

4. Security considerations

   Because of the number of potential namespaces, it must be restated
   that certain of the characters in the Namespace Specific String may
   have special meaning to certain namespace resolvers.  Each namespace
   shall therefore indicate which characters have special meaning and
   how (if possible) to encode those characters if used in a literal
   sense.

5. Acknowledgments

   Thanks to various members of the URN working group and <<your name
   here!!>> for comments on earlier drafts of this document.  This work
   was partially supported by the National Science Foundation.

6. References

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

         [1]         L. L. Diagle, P. Falstrom, 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.

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

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

7. Author's address

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

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

Expires 4/97                                                    [Page 4]

INTERNET DRAFT                 URN Syntax                   October 1996

                This Internet Draft expires April 1, 1997.

Expires 4/97                                                    [Page 5]

Date: Thu, 17 Oct 1996 15:12:51 -0600
To: Larry Masinter <[email-masked]>
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] a possible security architecture for URNs
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke Larry Masinter (at least at 10:37 AM 10/17/96 PDT)
[And I said:]
>>         We shouldn't define an all-encompassing
>>         security policy for URNs.
>
>I agree with that. However, I had interpreted some messages (not from
>you, but from Michael and Terry) a different position, e.g., that the
>URN working group shouldn't worry about security.

Yeah, I meant to quibble a bit with Terry's message and
say that we should ensure the tools are available, but I thought
his main point was that we can't mandate the policy.
I just never got that message sent.  (Hey, I'm still working
on my reply in our off-list thread. :-)

>My primary technical concern about using DNS security for NAPTR is
>the issue of the granularity of authority. For example, it's likely
>that any authority with the ability to change ONE of the NAPTR entries
>for 'duns.urn.net' will have the ability to change all of the rest of
>the records.

I think that the entity that writes the check to have the "foo.urn.net"
namespace gets to decide what NAPTR records go there, and bears any
legal responsibility for what they do and do not put there.

>Is this the right granularity of authority? 

Seems OK to me. Further, it seems isomorphic to the Rivest paper.
The owner of a naming context decides what names to put there.
If they make their naming context public, and someone doesn't
like what they have done, they can sue. Not a technical issue.

>Let's suppose that
>'duns.urn.net' has replicated resolution services around the world,
>one in the US, one in Japan, one in Australia, one in Russia:
>
>duns.urn.net
>;;      order pref flags service            replacement                regexp
> IN NAPTR 100  10  "s"  "dunslink+N2L+N2C" _dunslink._udp.isi.dandb.com ""
> IN NAPTR 100  20  "s"  "rcds+N2C"         _rcds._udp.duns.com.au	""
> IN NAPTR 100  30  "s"  "http+N2L+N2C+N2R" _http._tcp.dandb.co.jp	""
> IN NAPTR 100  30  "s"  "http+N2L+N2C+N2R" _http._tcp.duns.co.ru	""
>
>but that the Russian operator needs to change the domain name. Or
>wants to.

Then they can communicate that desire to the owners of the duns.urn.net
domain, who will or will not honor the request, and should accept the
consequences.

{As a correction to your example, which does not change the thrust of
your question, you had a couple of entries of the form: 

> IN NAPTR 100  30  "s"  "http+N2L+N2C+N2R" _http._tcp.dandb.co.jp	""
> IN NAPTR 100  30  "s"  "http+N2L+N2C+N2R" _http._tcp.duns.co.ru	""

where the same service (same resolution protocol and same resolution
services) would be available from two different domain names. We expect the
SRV record to handle that. The NAPTR would have one entry of the form

  IN NAPTR 100  30  "s"  "http+N2L+N2C+N2R" _http._tcp.duns.com

and the SRV record for _http._tcp.duns.com would list names like
whatever.duns.co.ru and something.dandb.co.jp.  } The contents
of that SRV record are still at the discretion of whoever owns
_http._tcp.duns.com.

>Or that the Australian operator of the resolution service disputes the
>Japanese operator over the spelling of a DUNS name that is in tradmark
>dispute in the two countries.

I don't understand this example, but I still think it is the case
that if I am paying the money for a domain name, I get to say what
goes into records for that domain name, and I bear the legal
consequences for inclusion or ommision of information.

> Are you
>presuming (as is presumed with MX records for mail, which I'm assuming
>is the model for NAPTR) that the operators of the resolution services
>for a single global name space are the same commercial entity?

No, but I think we have a terminology clash.

As above, I assume there is some entity that is "responsible"
for a namespace (or at least its top level). That entity may have
contracted with some other entity (or entities) for the day-to-day
operation of resolution services. Presumably the contract spells out
what the operators will do for the owner, but that's not our problem.

>The URN Framework document says only that 
[...]
>but I think that any URN _resolution mechanism_ must be much more
>explicit to be credible

I think you are merging issues that the framework wants to keep
seperate. The framework is based on the notion that we want to
seperate name assignment from resolution, so that different
resolution mechanisms can be used over time for the same namespace,
and so that the same resolution mechanism can be used for different
namespaces (Grandfathering support is the most obvious example of 
why we would want to do this, but I think it is a really good idea
in general).

>it is absolutely imperative that any system of naming that is
>intended to be permanent (a prime URN requirements) must explicitly
>deal with the issue of how the _resolution mechanism_ deals with
>organizational change: not just the introduction of new organizations
>but also mergers and divestitures.

I agree with the sentiment but disagree with the details. I think that
proposals for namespaces that are intended to be permanent should
deal with the issues of how organizational change and conflict are
handled in that namespace, and how the *results* of that process can
be made available to resolution systems. The resolution mechanisms
should be told "OK, entity X is now authoritative for portion Y of
namespace Z", and it is their problem how to do the resolution once they
have that knowledge. They should not get involved in the struggles that
lead up to such a decision.

The rest of the message was a reply to Jon Knight's material.
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"

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [URN] a possible security architecture for URNs
From: Larry Masinter <[email-masked]>
Date: Thu, 17 Oct 1996 10:37:07 PDT
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

>         We shouldn't define an all-encompassing
>         security policy for URNs.

I agree with that. However, I had interpreted some messages (not from
you, but from Michael and Terry) a different position, e.g., that the
URN working group shouldn't worry about security.

> As far as the NAPTR proposal goes, those tools come from DNSSEC.

My primary technical concern about using DNS security for NAPTR is
the issue of the granularity of authority. For example, it's likely
that any authority with the ability to change ONE of the NAPTR entries
for 'duns.urn.net' will have the ability to change all of the rest of
the records.

Is this the right granularity of authority? Let's suppose that
'duns.urn.net' has replicated resolution services around the world,
one in the US, one in Japan, one in Australia, one in Russia:

duns.urn.net
;;      order pref flags service            replacement                regexp
 IN NAPTR 100  10  "s"  "dunslink+N2L+N2C" _dunslink._udp.isi.dandb.com ""
 IN NAPTR 100  20  "s"  "rcds+N2C"         _rcds._udp.duns.com.au	""
 IN NAPTR 100  30  "s"  "http+N2L+N2C+N2R" _http._tcp.dandb.co.jp	""
 IN NAPTR 100  30  "s"  "http+N2L+N2C+N2R" _http._tcp.duns.co.ru	""

but that the Russian operator needs to change the domain name. Or
wants to.

Or that the Australian operator of the resolution service disputes the
Japanese operator over the spelling of a DUNS name that is in tradmark
dispute in the two countries.

Without having actually worked out the framework of authority in the
URN framework, there are no guidelines for how the implementation
should either control or evolve authority on the participants. Are you
presuming (as is presumed with MX records for mail, which I'm assuming
is the model for NAPTR) that the operators of the resolution services
for a single global name space are the same commercial entity?

The URN Framework document says only that 

> Some set of criteria must be established to govern what can and cannot
> be used as a (top-level) namespace (NID assignment).  This can include:

>	. demonstration of an established namespace management system
>	  (including an overview of mechanisms for preventing the
>	  duplication/reassignation of name identifiers.  These mechanisms
>	  are particular to the individual namespaces).
>	. multi-organization participation in the naming system
>	. rules on how names are assigned, name assignment authority
>	  delegation
>	. provision of escape clause 

but I think that any URN _resolution mechanism_ must be much more
explicit to be credible: "multi-organization participation in the
naming system" must deal with not just cooperation but contention.
And it is absolutely imperative that any system of naming that is
intended to be permanent (a prime URN requirements) must explicitly
deal with the issue of how the _resolution mechanism_ deals with
organizational change: not just the introduction of new organizations
but also mergers and divestitures. (How do you deal with the split of
AT&T and Bell Labs in the NAPTR records for tpc.urn.net?  What happens
to duns.urn.net if Duns has a big argument with Bradstreet?)

> As far as I can see, all you get from their
> scheme's _naming_ technique (as distinct from their security architecture)
> that is different from a NAPTR style URN is the ability to refer to things
> as relative to yourself.  This doesn't appear to be too useful as if you
> distribute this name widely, people will either have to be given it in a
> global form or be told where you are in the global scheme of things and
> how your local namespace works.  You can't use somebody else's relative
> names without either having their principle name in your local namespace
> or just using their global name rooted at one of the special root names
> (Rivest and Lampson explicitly point this out in the paper, "The
> principal you call alice-smith may be different from the principal I call 
> alice-smith.".  So putting just "alice-smith" in a the bibliography of
> another document wouldn't be much use to anyone bar the creator). 

Well, no. If I'm going to write a bibliography for publication, I'll
put in references that are relative to an authority that we mutually
recognize. That's the whole point of putting 'publisher' in the
references anyway: the publisher is the authority. ACM's Larry
Masinter's article. The publication itself forms the context, and peer
reviewers are expected to note references. Let's look at the
references in draft-daniel-naptr-01.txt 

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

IETF's RFC's 1737

# [2] draft-daigle-urn-framework-00.txt "A Uniform Resource Naming
#    Framework", Leslie Daigle and Patrik Faltstrom, June, 1996.

IETF's drafts' daigle-urn-framework-00

# [4] Paul Vixie, personal communication.
#

author's Paul Vixie

with some assertion at the top that 

author = (LANL's Ron Daniel) + (Georgia Tech's Micahel Mealling)

How would _you_ write URNs for those references?  What are the
authorities involved in assigning those references, and what would
necessary for someone 50 years from now to be able to follow those
references?

Larry

Date: Thu, 17 Oct 1996 10:31:13 -0600
To: Larry Masinter <[email-masked]>, [email-masked]
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] a possible security architecture for URNs
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke Larry Masinter (at least at 02:21 AM 10/17/96 PDT)

>[...] the best we get from NAPTR is
>a hand-wave and protests that security isn't important because it
>might be expensive to implement.

That misrepresents my position on security.
But before I can boil down my position to a single statement,
let me establish some background.

Security is not a binary
property of a system. There is no such thing as a "secure"
system or a "non-secure" system. Systems can be secured
against particular forms of attack. That does not make those
attacks impossible, it makes them more difficult and expensive
to mount, lowers their probability of success, increases the
probability of detection and response, etc. Systems cannot be
made invulnerable to all possible forms of attack. Furthermore,
each threat that must be countered raises the cost of constructing
and operating the system. There is no point in spending more on
securing the system than the value of the information in the system,
the profit that can be derived from its operation, etc.

The forms of attack that might be mounted, the resources available
to an attacker, the costs of the measures required to defend
against them, *and the decision on whether or not to implement those
measures* cannot be evaluated in general. The likely threats and
countermeasures to employ will depend on the information in the system
and the resources available to the publisher of that information. *We
cannot make that decision for them*.

Of course, all these caveats are too tedious to mention in normal
conversation, so we tend to say things like "secure system" when
we really mean "a system that is hard to subvert using some common
attacks, but still not too expensive to operate".

With that background established, I can now state my position on
URN security as:

          We shouldn't define an all-encompassing
          security policy for URNs.

Not only does this mean that we should not establish a policy that
requires everyone to implement defenses against many forms of
attack, it also means that we should not prevent people from
implementing those defenses. I will object to any standards-track
proposal for a URN resolution proposal that does not provide the tools
to allow people to implement defenses against common attacks. Not
"all known tools" or "all possible attacks", but what in my best
technical judgement are basic tools against common attacks. I am not
a security expert, just an informed layman, so my technical judgement
in such cases will rely on people who are expert in the area. This means
people from the security area of the IETF, and some of my co-workers.

As far as the NAPTR proposal goes, those tools come from DNSSEC.
This toolkit does not include arbitrary encryption, but it
does include key management, signatures, and some authentication.
Arbitrary encryption would be nice, but it is unexportable. It
appears to be the rough consensus of the DNSSEC-WG that the tools
in the DNSSEC proposal are as much as can be provided at this time.

How do those tools affect the NAPTR proposal? The NAPTR resource
records themselves will, in all but the most unusual cases, be
things like:
   If the URI you are trying to resolve contains "foo", ask
   server "bar" how to procede.
or just
   ask server "baz", and talk to them using protocol X, Y, or Z.

Although it is possible that such information could be highly
confidential, it is not likely. Therefore the lack of arbitrary
encyption does not, in my best techincal opinion, greatly concern me.
Other attacks, such as spoofing responses, seem much more likely.
However, those are precisely the attacks that DNSSEC counters.

Once it comes time to talk with the resolver and actually put
the URN onto the wire (it has not left the client up to this
point) then we are no longer using DNS, we will be using one
of the "resolution protocols" such as HTTP, HDL, RWHOIS, RCDS, etc.
The security capabilities of these protocols are outside the
bounds of the NAPTR proposal, but I will note that allowing
the resolver to use different protocols allows the publisher
to pick one suited to their security needs.

Finally, note that the NAPTR proposal is targeted for an Experimental
RFC, not a proposed standard. Using it, along with the capabilities
of DNSSEC, allows those who care to gain experience with operating
"secure" resolvers. That experience can then be used when it comes
time to evaluate the security tools provided by standards-track
URN resolution proposals.

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: Thu, 17 Oct 1996 12:50:26 +0100 (BST)
From: Jon Knight <[email-masked]>
To: Larry Masinter <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] a possible security architecture for URNs
Sender: [email-masked]
Reply-To: Jon Knight <[email-masked]>

On Thu, 17 Oct 1996, Larry Masinter wrote:
> I want to be able to transition from
> 
> Herman Melville's Moby Dick
> to
> LOC's Herman Melville's Moby Dick
> or
> OCLC's Herman Melville's Moby Dick
> 
> The naming scheme in SDSI not only allows relative names, but some way
> of merging the trees (or not, as you choose).

Er, but surely these are just different instances (locations) of the same
resource?  So the URN will return a number of pointers to possible
resources?  Or am I misunderstanding what you mean?
 
> As long as you have a completely global name space, you don't have a
> way to talk about migration. By adding relative paths and later
> identity, you can deal with migration by asserting that there are some
> authorities YOU are willing to trust to assert name bindings for other
> entities who are no longer in the name binding game.

I don't understand this at all, and I've just read the Rivest and Lampson
paper from top to tail.  As far as I can see, all you get from their
scheme's _naming_ technique (as distinct from their security architecture)
that is different from a NAPTR style URN is the ability to refer to things
as relative to yourself.  This doesn't appear to be too useful as if you
distribute this name widely, people will either have to be given it in a
global form or be told where you are in the global scheme of things and
how your local namespace works.  You can't use somebody else's relative
names without either having their principle name in your local namespace
or just using their global name rooted at one of the special root names
(Rivest and Lampson explicitly point this out in the paper, "The
principal you call alice-smith may be different from the principal I call 
alice-smith.".  So putting just "alice-smith" in a the bibliography of
another document wouldn't be much use to anyone bar the creator). 

In fact, I'd say that they just describe a "LISPy" way of making a user
interface allowing short cuts for commonly used parts of global
namespaces. As they specifically say that their object names are just
Octet strings, there's no reason why you couldn't use their security
structure with the currently defined URN naming schemes.  Cool, a
ready made security architecture that will work with URNs and that's been
written by crypto big boys for free.  But I've probably misunderstood it
all.

Tatty bye,

Jim'll

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Jon "Jim'll" Knight, Researcher, Sysop and General Dogsbody, Dept. Computer
Studies, Loughborough University of Technology, Leics., ENGLAND.  LE11 3TU.
* I've found I now dream in Perl.  More worryingly, I enjoy those dreams. *

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [URN] a possible security architecture for URNs
From: Larry Masinter <[email-masked]>
Date: Thu, 17 Oct 1996 02:21:29 PDT
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

I want to be able to transition from

Herman Melville's Moby Dick
to
LOC's Herman Melville's Moby Dick
or
OCLC's Herman Melville's Moby Dick

The naming scheme in SDSI not only allows relative names, but some way
of merging the trees (or not, as you choose).

As long as you have a completely global name space, you don't have a
way to talk about migration. By adding relative paths and later
identity, you can deal with migration by asserting that there are some
authorities YOU are willing to trust to assert name bindings for other
entities who are no longer in the name binding game.

> I don't see how they have thought it out any more than we have.
> What are we missing?

I think 'thought' is the wrong term. They've 'written' it out more
than you have.

The Rivest & Lampson paper at least a *sketch* of how authority and
naming and delegation might work, while the best we get from NAPTR is
a hand-wave and protests that security isn't important because it
might be expensive to implement.

Larry

Date: Wed, 16 Oct 1996 16:54:11 -0500 (CDT)
From: Daniel LaLiberte <[email-masked]>
To: Larry Masinter <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [URN] a possible security architecture for URNs
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Larry Masinter writes:
 > > Linked local name spaces. SDSI does not utilize a global name
 > > space,

Don't be fooled by that statement.  They do utilize a global name
space, as they later admit.

 > With this background, we come to the part that I think represents a
 > viable URN framework for uniform universal names that can be
 > implemented in a distributed resolution framework with adequate
 > security:
 > 
 > > Accomodation for ``standard roots'' and global name spaces: We recognize
 > > that there are likely to be a set of standard ``special root'' principals
 > > that are ``universally'' recognized. These principals have SDSI reserved
 > > names ending with double exclamation marks (!!):
 > 
 > >        VeriSign!!
 > >        IAPR!!
 > >        USPS!!
 > >        DNS!!
 > 
 > > There will be very few of these special roots, and their names
 > > are bound to the same principal in every name space.

That's the only way to get a global name space with the same meaning
for everyone, as I have been arguing all along.

 > > This is
 > > arranged with suitable procedures (appropriate publicity, manual
 > > installation, cross-checking, etc.); we do not try to describe
 > > this in more detail. This gives SDSI access to ``standard'' name
 > > spaces:
 > 
 > >        VeriSign!!'s MicroSoft's Encarta-Division's Susan-Smith
 > >        DNS!!'s edu's mit's lcs's theory's Silvio-Micali
 > >        USPS!!'s USA's DOD's DCI
 > >        IAPR!!'s PCA-commerce's DEC's SRC's abadi
 > >        VeriSign!!'s Visa's account-234156742
 > 
 > > Each of these should be viewed as global names that evaluates to
 > > the same principal in every name space, since the first name
 > > (e.g. VeriSign!!) always evaluates to the same principal, and all
 > > of the subsequent names are relative.
 > 
 > > Although SDSI provides for special roots within a set of linked
 > > name spaces, this does not imply that each principal has a unique
 > > ``global name.'' A principal will have multiple global names if
 > > there are multiple paths from special roots to that
 > > principal. Thus,
 > 
 > >         VeriSign!!'s MicroSoft's CEO
 > >         DNS!!'s com's microsoft's "Bill Gates"
 > 
 > > may refer to the same principal. (Of course, one can check
 > > whether these two names evaluate to give the same public key, if
 > > one wishes.)

This is all fine.  But how is it any different architecturally from
the path scheme and the NAPTR scheme?  All are hierarchical, and
within each nested name space, local names can be defined to map
to another name space.  So we could use

  path:/DNS!!/com/microsoft/"Bill Gates"

The NAPTR scheme is much the same with a different notation and
resolution mechanism.

 > I hope this clarifies what I was asking people to "check out", namely:
 > a system of hierarchical naming where the issues of identity and
 > authority have been actually thought out.

I don't see how they have thought it out any more than we have.
What are we missing?

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

Date: Wed, 16 Oct 1996 16:03:29 -0600
To: Larry Masinter <[email-masked]>
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] a possible security architecture for URNs
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke Larry Masinter (at least at 02:19 PM 10/16/96 PDT)

>Ron, I think I might not have been clear about what part of that
>document I thought you should check out. It isn't the particular
>security mechanism that I was pointing to, but rather to the naming
>method that was contained within the paper that had the important
>property that it ALLOWED a security structure to be built that
>accomodated it. What I found most compelling was how the authors had
>thought through the issues of naming authority.

Ah, sorry for the misunderstanding. I will take another look at the
naming ideas in the paper.

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: Larry Masinter <[email-masked]>, [email-masked]
Subject: Re: [URN] a possible security architecture for URNs
Date: Wed, 16 Oct 1996 21:52:27 +0200
Sender: [email-masked]
Reply-To: [email-masked]

Just a brief note....

the TIS DNSSEC implementation is released with an "all but Cuba"
style export license. You can get an RSAREF workalike from Europe
and run it anywhere in the world (except Cuba and so on).

So code (beta) for secure DNS exists.

                   Harald A

To: [email-masked]
Cc: [email-masked]
Subject: Re: [URN] a possible security architecture for URNs
From: Larry Masinter <[email-masked]>
Date: Wed, 16 Oct 1996 14:19:25 PDT
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

>Thus spoke Larry Masinter (at least at 01:01 AM 10/15/96 PDT)
>>Check out 
>>Rivest & Lampson, "A Simple Distributed Security Infrastructure"
>>	http://theory.lcs.mit.edu/~rivest/sdsi10.html

> Thanks for the citation. The paper is interesting. Unfortunately,
> we (the URN-WG) are not competent to judge the merits of this
> proposal relative to the SPKI work already going on in the IETF.

Ron, I think I might not have been clear about what part of that
document I thought you should check out. It isn't the particular
security mechanism that I was pointing to, but rather to the naming
method that was contained within the paper that had the important
property that it ALLOWED a security structure to be built that
accomodated it. What I found most compelling was how the authors had
thought through the issues of naming authority.

Let me excerpt the 'naming' part of the Rivest & Lampson paper, so
that it's clear that I'm talking about naming and not 'security' when
I say that this is an important paper to read:

> Egalitarian design-no global hierarchy necessary. Our proposal is
> egalitarian: each principal can make (signed) statements and requests on the
> same basis as any other principal. No hierarchical global infrastructure is
> required. Of course, in practice some principals would be more important
> than others, and SDSI allows for some principals to have special status as
> ``special roots,'' allowing SDSI to accomodate ``global names.'' But that is
> for convenience rather than necessity.

URNs are 'global names'. Any URN framework should clearly lay out how
the authority for naming gets delegated to sub-authorities in a way
that accomodates a wide variety of real world situations. The current
URN proposals lack the kind of flexibility that is contained in the
Rivest & Lampson document; that Rivest & Lampson have also laid out a
way in which authorization and name resolution can be distributed in a
trusted way is just an additional reason to pay attention to their
proposal.

> Local name spaces. Each principal can create his own local names with which
> he can refer to other principals. These local names arbitrarily chosen; they
> may be derived from nicknames, email addresses, account numbers, etc.:

>        jim
>        "Bob Jones, Jr."
>        account-314568901387
>        WebCo-Vice-President-John-Smith
>        [email-masked]
>        ( Accounting Bob-Smith )

>There is no fixed ``global'' name space giving a unique name for principals.
>The principal you call alice-smith may be different from the principal I
>call alice-smith. An exception is made for a small set of ``special root''
>principals, whom everyone calls by the same name.

Just as URLs needed "relative URLs", I think that this is an important
element of a global naming system. And the 'special root' principals
are indeed the top level of the URN hierarcies.

...

> Linked local name spaces. SDSI does not utilize a global name space, but
> rather provides means for conveniently linking local name spaces. Each
> principal can ``export'' his name/value bindings to others, by issuing
> name/value certificates. Thus, if my local name bob refers to some
> principal, then I can refer to the principal that bob calls alice as
>        ( ref: bob alice ) .
> We suggest that the user interface supply a bit of syntactic sugar to
> represent this as
>        bob's alice

...

> One can also have longer references, such as
>        bob's alice's mother ,

> which is the syntactically sugared version of
>        ( ref: bob alice mother ) .

> This reference is well-defined (for me) if I have bound bob to some
> principal, who in turn has bound alice to some second principal, who in turn
> has bound mother to some third principal. Other examples of extended
> references (with syntactic sugar) are:

>        Visa's account-314568901387
>        mit's lcs's rivest
>        cmu's eecs-dept's search-committee's chairman
>        GE's lighting-division's vp-of-marketing's secretary's assistant

...

With this background, we come to the part that I think represents a
viable URN framework for uniform universal names that can be
implemented in a distributed resolution framework with adequate
security:

> Accomodation for ``standard roots'' and global name spaces: We recognize
> that there are likely to be a set of standard ``special root'' principals
> that are ``universally'' recognized. These principals have SDSI reserved
> names ending with double exclamation marks (!!):

>        VeriSign!!
>        IAPR!!
>        USPS!!
>        DNS!!

> There will be very few of these special roots, and their names are bound to
> the same principal in every name space. This is arranged with suitable
> procedures (appropriate publicity, manual installation, cross-checking,
> etc.); we do not try to describe this in more detail. This gives SDSI access
> to ``standard'' name spaces:

>        VeriSign!!'s MicroSoft's Encarta-Division's Susan-Smith
>        DNS!!'s edu's mit's lcs's theory's Silvio-Micali
>        USPS!!'s USA's DOD's DCI
>        IAPR!!'s PCA-commerce's DEC's SRC's abadi
>        VeriSign!!'s Visa's account-234156742

> Each of these should be viewed as global names that evaluates to the same
> principal in every name space, since the first name (e.g. VeriSign!!) always
> evaluates to the same principal, and all of the subsequent names are
> relative.

> Although SDSI provides for special roots within a set of linked name spaces,
> this does not imply that each principal has a unique ``global name.'' A
> principal will have multiple global names if there are multiple paths from
> special roots to that principal. Thus,

>         VeriSign!!'s MicroSoft's CEO
>         DNS!!'s com's microsoft's "Bill Gates"

> may refer to the same principal. (Of course, one can check whether these two
> names evaluate to give the same public key, if one wishes.)

> DNS names have a special status. By special dispensation from its designers,
> SDSI includes custom treatment for DNS (Internet email) names, so that

>         [email-masked]

> is equivalent to:

>         DNS!!'s com's microsoft's penguin's Bob.Smith

> -that is, to:

>         ( ref: DNS!! com microsoft penguin Bob.Smith ) .

> How this works is described later on.

I hope this clarifies what I was asking people to "check out", namely:
a system of hierarchical naming where the issues of identity and
authority have been actually thought out.

I'll respond to other points in your message separately.

Larry

Subject: Re: [URN] Internationalization!
To: [email-masked]
Date: Wed, 16 Oct 1996 19:09:51 +0100 (MET)
Cc: [email-masked]
Content-Length: 5564
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

When I received the anoucement for the new URN mailing list
some time ago, I thought that one point would definitely turn
up, namely internationalization. I had this expectation because
in an earlier discussion on the uri mailing list, I was told
that I came at a bad time, but that this could be dealt with
with URNs.

After following the discussion for some time, I realized that
a lot of issues have come up, but internationalization was never
mentionned. This is not a good sign, and I want to change it
herewith.

Internationalization, for those that don't know it, means
support for different scripts and languages as they are used
around the world. Internationalization is often abbreviated I18N.

Why is internationalization of URLs and URNs an issue?

- In some cases, URL/N contents is per definition international.
	Think about a query to a Japanese->English dictionary server.
- In some cases, resource locations (e.g. file names) contain
	non-ASCII characters. On some OSs, there is absolutely
	nothing strange about such things.
- Many names of resources (think about book titles) are inherently
	in various languages.
- Company names, product names, and so on, are much better known
	to local users in their local form. It is tedious and
	error-prone, and maybe very difficult, to remember the
	ascii equivalent.

Why are URNs affected?

- URNs advertise such things as grandfathering of namespaces.
	Maybe grandfathering could be a mechanism to deal with
	some internationalization issues.
- URNs are names. Names are intrinsically meaningful, and therefore
	need internationalization to be meaningful in the right context.
- URNs look a lot like URLs, so they may be affected in the same way
	as URLs by internationalization issues.
- Time is now. The earlier the direction for URL/N i18n is established,
	the easier it is to make it work consistently, and the less
	legacy issues have to be dealt with.
- Internationalization is an important issue in general, and not
	considering it nowadays is definitely not good practice.

What people might say agaist the internationalization of URL/Ns,
but is just not true:

- International URL/Ns create ambiguity.
	The ambiguity is about the same as with 0/O or 1/l/I.

- URL/Ns are just like phone numbers.
	Even for phone numbers, people try to create easy ways
	to remember them. And even if 99% of the URL/Ns are
	like phone numbers, not designed to be understod by
	any human reader, it's the rest of 1% that is important.

- Everybody should be able to type in an URL/N, everywhere.
	A lot of people have problems to type standard URLs
	on their keyboards because they are not used to
	the Latin alphabet. And does it matter whether you
	can type an URL/N, if you can't understand the contents
	of the resource it is pointing to anyway? If you
	understand the URL/N, but can't type it at the place
	you are, web servers can easily be constructed that
	provide such an input service. And finally, the
	information providers will be mature enough to
	decide what their audience prefers.

What are the problems for URL/N internationalization?

- Decide on character encoding and semantics.
	URLs currently allow to represent arbitrary octets (bytes).
	An octet 01000010 is represented as "B", an octet
	10001111 is represented as "%8F". Nothing in the URL
	spec says clearly that a "B" in an URL is actually
	supposed to mean a "B" in a context where one could
	ask what character that octet is representing
	(this means in almost all contexts, except e.g.
	for the data: URL).
	Hovewer, in fact the situation is much different
	for the "B" and the "%8F". The "B" is, although
	the spec does not require it, always just a "B".
	And the character "B" never turns up in another
	form in an URL than as a "B". For the "%8F",
	however, things are completely different. There
	is no standard or custom whatsoever saying what
	character (or part of a character) the octet
	represented by "%8F" could or should be, or by
	which octet or octets certain characters should
	be encoded. To some degree, such octets are used
	to denote some i18n characters, but if this works,
	it is only due to a lot of assumptions and guesswork
	on both client and server side.

	Some proposals tried to encode the relation between
	characters and octets as part of the URL itself
	(e.g. aka RFC 1522), which lead to very clumsy
	syntax and lots of other problems (esp. where exactly
	to put it and what it should apply to). An IMHO
	much better solution is to use an uniform encoding.
	Using UNicode/ISO 10646 and UTF-8, this could be done
	in a clear fashion, without affecting any ASCII
	URL/Ns, with large reserves for the future (2 Giga
	codepoints!), and with lots of other benefits.

- Specify in which cases which notation is to be used.
	E.g. on paper: International notation or %HH
	notation if unavoidable, on the line: preferably
	raw UTF-8, but %HH if a protocol prefers it,...

- Recommend ways for upgrades for the various schemes/
	protocols.

- Encourage browser and server implementors to go on with
	it.

Anyway, this is just a first mail to make you aware of the
issues. I look forward to an interesting and fruitful
discussion.

Regards,	Martin.

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

Date: Wed, 16 Oct 1996 08:47:05 -0700 (PDT)
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] a possible security architecture for URNs
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

I agree with Ron that security is not our concern at this point.

And I say again that all matters related to security, authority,
and the like related to URNs will be determined by lawyers and
the world's legal systems.  Nothing we could do or write would
have the least effect on the outcome.

Regards,
    Terry Allen    Fujitsu Software Corp.    [email-masked]
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

Date: Tue, 15 Oct 1996 10:48:22 -0600
To: Larry Masinter <[email-masked]>, [email-masked]
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] a possible security architecture for URNs
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke Larry Masinter (at least at 01:01 AM 10/15/96 PDT)
>Check out 
>Rivest & Lampson, "A Simple Distributed Security Infrastructure"
>	http://theory.lcs.mit.edu/~rivest/sdsi10.html

Thanks for the citation. The paper is interesting. Unfortunately,
we (the URN-WG) are not competent to judge the merits of this
proposal relative to the SPKI work already going on in the IETF.

Larry has raised the issue of security in a few different places:
first he said that the lack of security and administration tools
in DNS made NAPTRs unacceptable, later he made a similar criticism
of the framework.

However, the URN requirements draft does not mandate that any particular
level of security must be provided. That RFC says:
  "...there are several issues dealing with support for
   replication of resources and security that have been
   discussed; however, the problems are not well enough
   understood at this time to include specific requirements
   in those areas here."
I am unaware of any changes to that status. 

Security has its costs. While it would be nice to have URN resolution
systems that met a requirements statement like:
   URN resolution systems shall be invulnerable to forged responses,
   shall ensure that only authorized accesses are possible, shall
   provide for the complete confidentiality of the resource, and
   shall be immune to traffic analysis and denial of service attacks"
who is going to pay for such high levels of security? Such measures are
not appropriate for all the resources people will identify with URNs.

My contention is that such objections should not slow the NAPTR
draft from going to experimental status. Here are my reasons:
  1) As shown above, the URN requirements RFC has no requirement
     for security. This was not an oversight, it was because we were
     not ready to impose security requirements on all URN systems.
  2) Experimental RFCs are not standards-track documents. The goal
     is to gain experience with a new protocol with the explicit
     understanding that it is an experiment and may never go to the
     standards track.
     We actually have some useful things to learn from NAPTRs.
     URNs are supposed to be long-lived, location-independent identifiers.
     The NAPTR draft gives us a way to look at location independence
     in action. Michael has mentioned on this list that he is working
     on an rwhois-based alternative to NAPTRs. He has stated to me
     that he would like to see NAPTRs deployed and running so that he
     can learn from that system while he continues to develop his.
     Experimental status seems perfectly appropriate for this purpose.
  3) While it is easy to ask for security, it is hard to deploy. The DNSSEC
     work is actually rather far along. The main impediment to further
     progress appears to be the difficulty in fielding implementations.
     This difficulty is due to export control issues surrounding the
     crypto code, and is a difficulty that *any* resolution system
     with strong security would face.
     
Allowing the NAPTR draft to procede as an Experimental RFC will let us
get the operational experiance with resource replication that the URN
Requirements RFC says we need. The possibility also exists that the
export control problems associated with DNSSEC will be overcome during
the experimental period. We can then experiment with the SIG resource
record and gain experience with the security issues that the requirents
document says we need.

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"

To: [email-masked]
Subject: [URN] a possible security architecture for URNs
From: Larry Masinter <[email-masked]>
Date: Tue, 15 Oct 1996 01:01:08 PDT
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

Check out 
Rivest & Lampson, "A Simple Distributed Security Infrastructure"
	http://theory.lcs.mit.edu/~rivest/sdsi10.html

for a proposal for security of name bindings that allows for
delegation. It may be that the only way to have both secure and
long-lived names is by resorting to an authority that asserts
name-bindings where the authority has a longer lifetime than the
binding, e.g., 

   LOC's Melville's MobyDick

With a suitable syntax, there's even a place for 'relative URNs'.

Regards,

Larry

To: [email-masked]
Subject: [URN] suggestions for "A Framework for the Assignment and Resolution ..."
From: Larry Masinter <[email-masked]>
Date: Sat, 12 Oct 1996 23:31:26 PDT
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

We were asked to keep the discussion of 'NAPTR vs PURL' offline, and
keep the mailing list focused on the framework document.

The Framework document needs references; clearly, after such a very
long period of discussions of what URNs are and are not, it would help
to distinguish this framework from, say, the approaches of

Winograd, "Stable Network File URLs as a Mechanism for Uniform
Naming", 1993: <http://www.saintjoe.edu/URI/stanf.html>

Kahn & Wilensky, "A Framework for Distributed Digital Object
Services", cnri.dlib/tn95-01,
<http://www.cnri.reston.va.us/home/cstr/arch/k-w.html>

or even mention the background in 

Arms et al, "Uniform Resource Names", D-Lib Magazine, February 1996,
<http://www.dlib.org/dlib/february96/02arms.html>

even though almost all of the authors of that article are listed in
the framework acknowledgements.

The framework document has a section labeled "Authority Over Name
Strings", but the section doesn't actually go into any details about
the difficult elements of name migration. It says "Rules for
individual namespaces are determined by the owners of the namespace
before they are registered in the NID registry", but this kind of
analysis omits the important element of what omits any mention of the
difficult problems that arise when namespace owners themselves
disappear.

This is a rather old song, but I will sing it again:
draft-daigle-urnframework-00.txt is inadequate because it does not
deal with any of the issues of administration & security & migration &
longevity that are the entire motivation for having 'URNs' instead of
'URLs'.

You might argue that those issues are social issues and not technical
ones, and that this is an engineering group, not a social policy
group. However, engineering solutions are often advanced as solutions
to social policy questions. For example, for better or worse, several
mechanisms for 'key recovery' have been advanced as an engineering
solution to the social policy question of balancing between police
investigative capabilities and personal privacy.

Those same mechanisms might be used, for example, as a way of allowing
the 'owner' of a name to have the exclusive right to assign metadata
or location information by signing such assignments with the owner's
private key, but also allowing the infrastructure to recover when an
owner disappears or is unresponsive by resorting to some form of key
recovery or delegation.

I don't think the framework needs to specify the mechanism by which an
name's authority might assert a relationship between the name and
various pieces of metadata and location information, but the nature of
the assertions made, the roles of third parties in either verifying
the assertions or providing clients the means of verifying, the ways
in which authority can either migrate to different organizations or be
supplanted by the moral equivalent of "trusted librarians" needs to be
addressed in far more detail than appears here.

Regards,

Larry

Date: Thu, 10 Oct 1996 20:42:25 -0700 (PDT)
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [URN] advantages of NAPTR over PURLs
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>
Larry:

| NAPTR suddenly
| intertwines name resolution with one of the most obscure parts of the
| Internet infrastructure.

Only *one means* of URN (not URL) resolution.  NAPTR is not obviously
the one shiningly best means of URN resolution, but PURLs very obviously
are not (if, for example, you have a business disagreement with OCLC).
I don't *have* to use NAPTR to resolve URNs, and in a well developed
landscape I'll have other choices.  Some URNs may never be resolved
through NAPTR.

But with PURLs I'm chained to purl.org.  

Regards,
    Terry Allen    Fujitsu Software Corp.    [email-masked]
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

Date: Thu, 10 Oct 1996 20:31:38 -0700 (PDT)
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] advantages of NAPTR over PURLs
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

Yes, your quotation supports entirely my claim that PURLs are not
an implementation of URNs.  Please make the following thought experiment:
Write a sentence using a URN, then the same using a PURL.  Imagine
that 20 years hence, urn.net and purl.org have gone away.

With URNs:
"Foobar says blort in <urn>blart:baz/far/bomb</urn>."

With PURLs:
"Foobar says blort in [something pointed to by the HTTP URL <...>]."

I can have some hope of still resolving the URN, because, Larry,
it's a name; I have little hope of resolving the ancient reference
to a reference that no longer exists, because it's a pointer, and
not a name.  I still have a sentence that makes sense in the first
case, whereas in the second I have a sentence with a blank waiting
to be filled in.

PURLs are "item number 32 on page 153 of K's manuscript catalogue
of Mozart's works."
URNs are "K. 459".

URNs do not require resolution by the naming authority.  That's
the point here.

>From [email-masked] Wed Oct  9 18:59 PDT 1996
To: [email-masked]
CC: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] advantages of NAPTR over PURLs
From: Larry Masinter <[email-masked]>
Date: Wed, 9 Oct 1996 18:59:34 PDT

>  But PURLs are not an implementation of URNs...

Please review http://purl.oclc.org/OCLC/PURL/INET96 :

> PURLs are a direct result of OCLC's work in the Uniform Resource Name
> (URN) standards and library cataloging communities. The assignment of
> PURLs is an intermediate step towards the time when URNs are an
> integral part of the Internet information architecture. The eventual
> syntax of URNs is clear enough at this time to afford confidence that
> the syntax of PURLs can be inexpensively and mechanically translated
> to the eventual URN form. For instance, the PURL

>     http://purl.oclc.org/keith/home
>     ----   ------------- ----------
>       /           |               \
>  protocol    resolver address     name  

> could be written something like the following using the Path URN syntax:

>     URN:/org/oclc/purl/keith/home
>          ------------- ----------
>                |           |
>       naming authority   name

> where the URN is essentially a hierarchical name with the first
> portion representing the naming authority and the second portion
> signifying the local name. Note that the naming authority in this
> example is merely the resolver address of the corresponding PURL
> written backwards (with slashes instead of dots) and the local name
> is the same.

> Syntax aside, one way to think of URNs and PURLs is to consider what
> it would take to turn a PURL Server into a URN Server: very
> little. If Web browsers were changed to recognize the syntax
> URN:/org/oclc/purl/keith/home and could then connect to the resolver
> at purl.oclc.org, the resolver could then resolve the name
> /keith/home.

Regards,
    Terry Allen    Fujitsu Software Corp.    [email-masked]
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

From: [email-masked] (Leslie Daigle)
Date: Thu, 10 Oct 1996 08:20:07 -0400
To: [email-masked]
Subject: [WGC] Re: [URN] advantages of NAPTR over PURLs
Sender: [email-masked]
Reply-To: [email-masked] (Leslie Daigle)

Okay, I think this thread is starting to lose its focus.  It started off
using PURLs as an example to illustrate areas of the Framework that need to be
better documented.  A lot of good material has been generated on that
front.

But, as it has aged, it seems to have taken on more of the characteristics
of a debate about which "is better" -- PURLs or NAPTR-based URNs.

In fact, that's not what we are here to discuss.  We have on the table
a proposed approach to URNs -- the Framework -- and a first round 
implementation of a system based on that approach -- NAPTR.  We should
discuss things to move those forward -- that is what we've been chartered
to do.

Since it now seems to have reached the stage where there is more about
NAPTR-vs-PURL, and less about What should the Framework say, I believe
it is time for this thread to be stopped, and material generated thus
far will be addressed in a revision of the Framework document.
If anyone has specific issues relating to the Framework _document_,
that's fine.  If people still have things they wish to get off their
chests on the subject of PURLs-as-URNs, I would appreciate it very much
if they could sort out the details off-line, and bring back to the list
whatever is generated in terms of concrete proposals for the Framework.

Thanks!
Leslie.

-- 

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

  "The light at the end of the tunnel             Leslie Daigle
     is often the blindingly obvious..."          Vice President, Research
                                                  Bunyip Information Systems
                      -- ThinkingCat              (514) 875-8611
                                                  [email-masked]
----------------------------------------------------------------------------

From: [email-masked]
To: Ron Daniel <[email-masked]>
Cc: Larry Masinter <[email-masked]>, [email-masked]
Subject: Re: [URN] advantages of NAPTR over PURLs
Date: Wed, 09 Oct 1996 23:54:00 +0200
Sender: [email-masked]
Reply-To: [email-masked]

Ron said:
>Both registries should be mentioned in the framework draft. We need a
>really good lawyer to look at the language. Anyone know of a likely
>candidate who would do it pro-bono?

The IETF has a relationship with a law firm (I forget the name)
that does pro bono work for us. Once we have language that needs
checking, and we're reasonably sure it means what WE want it to
say, we can use some of their time for it.

The good thing about these guys is that they know us by now, so
they kind of know what kinds of trouble we're afraid of.

              Harald A

Date: Wed, 9 Oct 1996 22:59:02 -0700 (PDT)
From: "David W. Morris" <[email-masked]>
To: [email-masked]
Subject: Re: [URN] advantages of NAPTR over PURLs
Sender: [email-masked]
Reply-To: "David W. Morris" <[email-masked]>

On Wed, 9 Oct 1996, Larry Masinter wrote:

> > One point though: adminisration and security are two things you do AFTER
> > you have a system that can scale and function. If you don't have 
> > something that works then all the security and administration in the
> > world won't get you squat.
> 
> This just doesn't hold water. Most of the issues we have to deal with
> in 'scalability' are administration and security. We can't design
> protocols that way any more. It is completely unacceptable that after
> three years of talking about URNs and meeting about URNs that the
> first 'URN implementation' doesn't have a credible story about
> administration and security.

My response was a lot less polite than Larry's. Operational scalability
is the whole problem. If we are not to worry about administaration and
security, there is no point to URNs ... URLs scale just fine ... but
they are hell to administer when one gets down to little issues like
persistence.

Dave Morris

To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] advantages of NAPTR over PURLs
From: Larry Masinter <[email-masked]>
Date: Wed, 9 Oct 1996 22:30:36 PDT
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

> Actually, the fact that the NAPTR proposal uses DNS as part of its
> infrastructure doesn't seem to me to be a huge issue.

Oh, I think it's the source of most of its problems. If it were in
some application protocol rather than DNS -- something that had a
reasonable administrative & security model and a distributed
implementation that actually dealt with updates -- most of the
problems I have with it would go away.

> One point though: adminisration and security are two things you do AFTER
> you have a system that can scale and function. If you don't have 
> something that works then all the security and administration in the
> world won't get you squat.

This just doesn't hold water. Most of the issues we have to deal with
in 'scalability' are administration and security. We can't design
protocols that way any more. It is completely unacceptable that after
three years of talking about URNs and meeting about URNs that the
first 'URN implementation' doesn't have a credible story about
administration and security.

Larry

Date: Wed, 9 Oct 1996 21:14:17 -0700 (PDT)
From: "Gregory J. Woodhouse" <[email-masked]>
To: Michael Mealling <[email-masked]>
Cc: Larry Masinter <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] advantages of NAPTR over PURLs
Sender: [email-masked]
Reply-To: "Gregory J. Woodhouse" <[email-masked]>

Actually, the fact that the NAPTR proposal uses DNS as part of its
infrastructure doesn't seem to me to be a huge issue. The reason is that
under the NAPTR proposal namespaces are completely abstract, and it would
be possible to implement those same namespaces using an entirely different
mechanism. In fact, with a judicious use of replication, I don't see why it
wouldn't be possible to smoothly transition to a new URN resolution scheme
and have the process be completely transparent to users. Of course, this is
conceptually possible with PURLs (because http://www.purl.org/* could be
treated as an abstract namespace) but it does tie us to namespaces of a
rather restrictive form.

Incidentally, I find this whole thread rather useful. I had originally
planned to give a 1 hour brownbag presentation to some of my co-workers on
URNs an the NAPTR proposal. Basically, this would have been part 2 of the
DNS class I gave last week. Anyway, it was postponed/cancelled because of
other priorities, but preparing for this presentation was an interesting
experience. One reason is that I was forced to consider how I would respond
to the question: "What is it about this resolution scheme that justifies its
complexity?" Of course, I never actually had to answer that question, but
I was certainly dreading it.

One final comment: I agree that there is no real need for a large number of
resolution protocols, but I don't see this as a problem with the NAPTR
proposal. Rather, I prefer to think of the proposal as purposely not
specifying the actual protocol(s). This doesn't seem to me to be a design
flaw, but just the opposite. In general, it i just good software
engineering to keep the various components of a system a loosely coupled as
possible, and this is just what the proposal does.

---
Gregory Woodhouse     [email-masked]
home page:            http://www.wnetc.com/
resource page:        http://www.wnetc.com/resource/

Date: Wed, 9 Oct 1996 20:51:48 -0700 (PDT)
From: "Gregory J. Woodhouse" <[email-masked]>
To: Michael Mealling <[email-masked]>
Cc: Larry Masinter <[email-masked]>, [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] advantages of NAPTR over PURLs
Sender: [email-masked]
Reply-To: "Gregory J. Woodhouse" <[email-masked]>

On Wed, 9 Oct 1996, Michael Mealling wrote:

> Larry Masinter wrote:
> > 
> > > Sorry, but SRV records cannot be used for HTTP without changing all
> > > implementations of HTTP. The spec would also need to be changed to
> > > say if SRV requests or A requests should occur first, because
> > > behavior will differ.
> > 
> > Did SMTP implementations change with the introduction of MX records,
> > or was it done at some other level?
> 
> Yes. In order to take advantage of MX records ALL implementations of
> SMTP had to know to look up that RR instead of just getting the A 
> record.
>

Well, mail routing is actually descibed in RFC 974. RFC 821 only describes
a single transaction (okay, perhaps a poor choice of words). But on the
other hand, if SMTP made the assumption that it was only necesary to give a
userename to identify a mail recipient and only used

RCPT To:<username>

then the MX mechnism could not work without modifying the protocol.
 
---
Gregory Woodhouse     [email-masked]
home page:            http://www.wnetc.com/
resource page:        http://www.wnetc.com/resource/

Date: Wed, 09 Oct 1996 23:35:38 -0400
From: Michael Mealling <[email-masked]>
Organization: Network Solutions
To: Larry Masinter <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] advantages of NAPTR over PURLs
Sender: [email-masked]
Reply-To: Michael Mealling <[email-masked]>

Larry Masinter wrote:
> 
> > Sorry, but SRV records cannot be used for HTTP without changing all
> > implementations of HTTP. The spec would also need to be changed to
> > say if SRV requests or A requests should occur first, because
> > behavior will differ.
> 
> Did SMTP implementations change with the introduction of MX records,
> or was it done at some other level?

Yes. In order to take advantage of MX records ALL implementations of
SMTP had to know to look up that RR instead of just getting the A 
record.

> 
> > You are not talking abut PURLs as set forth by OCLC. You are
> > talking about something that is halfway between the original Handle
> > proposal and PURLs. The idea of a global resolver (on replicated servers)
> > that would handle all resolution requests was the key feature of the
> > original Handle proposal. It was found unacceptable for several reasons,
> > two of which were:
> >  1) Potential for surgical denial of sevice attacks
> 
> You'll have to convince me that NAPTR implementations are less
> succeptable than PURL implementations. Why should that be so? There
> are still replicated services.

Because of two reasons:

a) the root doesn't change very often. Therefore it is cacheable and
therefore doesn't need to be queried.

b) all other queries are to delegated servers. A denial of service
attack can take out one but not ALL of those delegated servers.
Its very difficult if not impossible to cause all DNS server
to just stop working.

This does not take into account the possiblity of corrupting
the records at the root so that everyone goes down a dead-end
path. We hope that DNSSEC will fix that. Or that another
protocol will come along that does this job better than
DNS.

-MM

-- 
------------------------------------------------------------------------------
Michael Mealling	| 505 Huntmar Park Drive       | Phone:  (703)742-0400
Software Engineer	| Herndon, VA 22070	       | Fax:    (703)742-9552
Network Solutions	| <URL:http://www.netsol.com>  | [email-masked]

Date: Wed, 9 Oct 1996 23:03:16 -0400
From: Lewis Girod <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [URN] advantages of NAPTR over PURLs
Sender: [email-masked]
Reply-To: Lewis Girod <[email-masked]>

   Date: Wed, 09 Oct 1996 08:50:07 -0600
   From: Ron Daniel <[email-masked]>

   [One difference is...]

   The PURL-like approaches send the entire request, document-id and all,
   to the root resolver. This allows fun little things like surgical
   denial of service and usage tracking which tend to get people excited.

This is a valid concern, and NAPTR is superior in terms of privacy.
However even with NAPTR surgical denial of service is possible (to a
limited extent) if a regexp rule upstream of the client misdirects
resolution conditionally on matching specific stuff in that client's
URNs.  And, as you point out, a PURL-type system would make this sort
of thing easier and more transparent.

   NAPTR and PURL resolution are very different. All NAPTR does is get
   us to a resolver, without requiring that the location of the resolver be
   buried in the URN or that we have a global resolver that is fixed for
   all time.  PURLs get us to the resolver by putting its location into
   the identifier. Larry has suggested some modifications to PURLs where
   we don't put the location of the resolver into the identifier, but
   everyone knows that purl.org (or whatever) is the place to go to start
   resolution. 

It is a question of how much indirection is really necessary...  I
don't think anyone is proposing to use a PURL-type architecture for
eternity.  However, it is a simple technique that provides a
reasonable amount of indirection and persistence, if it is set up
properly.  The only location that _must_ appear in a PURL is that of
the top-level resolver (or should we say redirector), which in the
case of NAPTR is ``buried'' in the browser rather than in the URN.

   >and if your names were originally delegated from foo.com,
   >you will probably end up going through foo.com forever, even if the
   >resolution is actually done by someone else.

   That depends on the namespace that is used. For namespaces like
   CID or INET, that is true. For namespaces like ISBN, resolution will
   probably be accomplished by an organization like Bowker, even
   if the name was originally assigned by Prentice-Hall.

Just out of curiosity, in the case of ISBN, would the initial rule
then point directly to Bowker's resolver?  It could also be done by
pulling out publisher codes, I suppose...

		- Lewis

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [URN] advantages of NAPTR over PURLs
From: Larry Masinter <[email-masked]>
Date: Wed, 9 Oct 1996 19:57:03 PDT
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

> Sorry, but SRV records cannot be used for HTTP without changing all
> implementations of HTTP. The spec would also need to be changed to
> say if SRV requests or A requests should occur first, because
> behavior will differ.

Did SMTP implementations change with the introduction of MX records,
or was it done at some other level?

> You are not talking abut PURLs as set forth by OCLC. You are
> talking about something that is halfway between the original Handle
> proposal and PURLs. The idea of a global resolver (on replicated servers)
> that would handle all resolution requests was the key feature of the
> original Handle proposal. It was found unacceptable for several reasons,
> two of which were:
>  1) Potential for surgical denial of sevice attacks

You'll have to convince me that NAPTR implementations are less
succeptable than PURL implementations. Why should that be so? There
are still replicated services.

> 2) Organizations such as mine, who cannot put information about
>    some of our documents into a system that is not cleared for
>    handling classified work. (Company proprietary information is
>    an analogous problem).

This works with NAPTR? That documents don't need a new name when they
get declassified? Or that a company can have a selective release of
confidential information on a 'need to know' basis without renaming?

> Every time I have heard the OCLC people talk about PURLs, they have
> been careful to say that they are not URNs. Their focus was to do as
> much as possible without changing client-side code.

There are changes and then there are changes. It's one thing to change
the protocol that is implemented to open another connection, do an
indirection, look in a cache, etc. However, most of HTTP is completely
independent of DNS or TCP or even the Internet. NAPTR suddenly
intertwines name resolution with one of the most obscure parts of the
Internet infrastructure.

Larry

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [URN] advantages of NAPTR over PURLs
From: Larry Masinter <[email-masked]>
Date: Wed, 9 Oct 1996 19:45:40 PDT
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

I'm really dismayed though by the amount of narrow defensiveness
that's been shown here, though.  Every protocol has problems. I
certainly don't believe that PURLs actually solve the Internet naming
problem. People are acting like I'm saying their puppy is ugly, just
because I'm pushing on the NAPTR proposal.

> These topics are very young, so nobody has had anything to say on them
> yet. How about you?

Honestly, I don't think you can really fault me for not being vocal.

Earlier in an interchange, someone defended NAPTRs as having been the
topic of discussion of many meetings.

> Does my suggestion of using the flags field overcome your concern
> about versioning?

I didn't think you were seriously proposing that the version of NAPTR
record elements be restricted to a number between 0 and 9. What
happens when you make the 10th revision?

> Do you have any further arguments on why a version field should be
> needed when we cannot change the number, type, or order of fields in a
> DNS record once it is out there?

Oh, no! I never suggested that you needed version numbers! My problem
was that you were using tokens "dun-and-bradstreet-lookup" without any
control on the meaning of the name!

> When clients and servers are not required to understand and support all
> the N2C, N2L, ... requests? 

What? Clients don't have to understand what N2C means? Or how to do
one? 

> I assume you have more knowledge of the Z39.50 URL schemes than I,
> is my concern about using URL standards-track documents as the
> "registry" misplaced? What about an IMT-style registry instead?

I don't actually think the world NEEDS a large number of resolution
protocols, any more than the world NEEDS a zillion HTML tags. The only
reason why we might see all of dun-and-bradstreet-lookup and z39.50
lookup and NAPTR lookup and ISBN-Bowker-lookup is a combination of
ignorance ("oh, they already had a protocol?"), vanity ("mine! my
protocol!") and greed ("they'll have to either pay me or see my
advertising").

Allowing lots of resolution protocols and a registry is really
counter-productive. At least there's some REASON why some applications
need audio/basic and not image/gif (even though there's no good reason
why we need both image/png and image/tiff).

Why don't we just fight it out now and save everyone grief later?

Larry

Date: Wed, 09 Oct 1996 22:47:08 -0400
From: Michael Mealling <[email-masked]>
Organization: Network Solutions
To: Larry Masinter <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] advantages of NAPTR over PURLs
Sender: [email-masked]
Reply-To: Michael Mealling <[email-masked]>

Larry Masinter wrote:
> 
> > Do you see where you're going Larry? You are putting everything
> > we've already got in the URN framework and the NAPTR proposal
> > into PURLs.
> 
> A new NAPTR DNS record type with protocol names & syntax that requires
> parsing and interpretation as a 'regular expression' isn't part of the
> PURL proposal. 

Right. PURLs have hidden that 'rule' inside the server where noone but
the server knows what it is. Whether that 'rule' is based on a direct
mapping from a database or is a rule based on some language that can
be generalized isn't the point. It has to be done somewhere. What NAPTR
does is make that rule visible to the client so it can cache it. If it
never sees that rule it can't cache it.

> PURLs don't relegate the security issues to DNS
> security but rather rely on HTTP security.  

But PURLs relegate it to someone. We never said that DNS' security
was better than anyone elses. Its rather dismal. But its the easiest
thing to implement to right now.

> PURLs don't require that
> application clients know anything about DNS other than 'Connect me to
> some machine that goes by this name'.

And that its problem: the client application know nothing. Therefore you
have to go to that huge database.

> I think that _relying_ on parsing data out of DNS records is very
> fragile, and most of purported advantages for NAPTRs are mainly vapor.

You suggest a beter system that gives us all of the advantages that
NAPTR has over PURLs.

> > But you ARE changing the intent and current design of PURLS.
> 
> I think we read different papers about PURLs; the paper I read made it
> seem like it was intended as a low-cost implementation of URNs.

I read it as a low-cost hack that when URNs are finished can be
shoe-horned
into the URN proposal. Also that at the time it was talking about URNs
as implemented by the PATH scheme which noone is using or is even
advocating
anymore. (If someone is advocating its use then I apologize for not
being
aware of it.)

> > If you can come up with a DISTRIBUTED database that has is as large
> > and as widespread as DNS that we can test the framework on then by all
> > means let us know cause we'll build the framework on that too.
> 
> I think this is misleading, since the NAPTR proposal doesn't
> distribute resolution services widely.

Huh? It distributed resolution services to whatever degree you want.
Down
to the character level. Back when I was at Tech I was intending on
setting up a NAPTR based service that distributed resolution services
down to the arbitrary unit level within departments. I could have
gone deeper but I let the departments decide that.

In any case, your saying that a single replicated PURL database is
more or less equally as distributed as DNS?

> 
> > If you've got a problem with NAPTR then you either have a problem
> > with the framework or DNS.
> 
> No, I have a problem with THAT particular USE of DNS.

Do you have a better solution that fits the framework?

> Let me get down to the basics, though:
> 
> DNS updates are unreliable.

No argument there! ;-)

> DNS administration is a nightmare. 

No argument there either! ;-)

> The PURL proposal has worked out many of the issues of administration and
> security that are necessary for actual deployment of URNs,

Because its based on a single database on a single machine. I could
build
adminstrative tools on that fairly easily. On a system like that with
one
point of update it should be fairly easy to have secure updates. I'm
actually kind of dissapointed that they aren't using SSL for secure
updates
on their web pages.....

One point though: adminisration and security are two things you do AFTER
you have a system that can scale and function. If you don't have 
something that works then all the security and administration in the
world won't get you squat.

> and the NAPTR proposal has only a wave at DNSSEC.

DNS security is the business of another working group. What would you
have
us do? Override them and implement our own security?

> > I hope that won't be the case very soon. I'm building a
> > parallel registry in rwhois. It doesn't have the restrictions
> > that DNS does. Its more generalized and doesn't need to
> > be re-written everytime you add a field.
> 
> That's great! If you're building a parallel registry in rwhois, I hope
> that you address the administrative and update issues that were worked
> out in the PURL paper and that we can leave NAPTR behind.

Actually, ours are better. We have complete security for on the fly
updates.
If you can put up with the security and management issues that the
InterNic
has to put with then you should be happy with what we have.

-MM

-- 
------------------------------------------------------------------------------
Michael Mealling	| 505 Huntmar Park Drive       | Phone:  (703)742-0400
Software Engineer	| Herndon, VA 22070	       | Fax:    (703)742-9552
Network Solutions	| <URL:http://www.netsol.com>  | [email-masked]

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [URN] advantages of NAPTR over PURLs
From: Larry Masinter <[email-masked]>
Date: Wed, 9 Oct 1996 19:16:47 PDT
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

> Do you see where you're going Larry? You are putting everything
> we've already got in the URN framework and the NAPTR proposal
> into PURLs. 

A new NAPTR DNS record type with protocol names & syntax that requires
parsing and interpretation as a 'regular expression' isn't part of the
PURL proposal. PURLs don't relegate the security issues to DNS
security but rather rely on HTTP security.  PURLs don't require that
application clients know anything about DNS other than 'Connect me to
some machine that goes by this name'.

I think that _relying_ on parsing data out of DNS records is very
fragile, and most of purported advantages for NAPTRs are mainly vapor.

> But you ARE changing the intent and current design of PURLS.

I think we read different papers about PURLs; the paper I read made it
seem like it was intended as a low-cost implementation of URNs.

> If you can come up with a DISTRIBUTED database that has is as large
> and as widespread as DNS that we can test the framework on then by all
> means let us know cause we'll build the framework on that too.

I think this is misleading, since the NAPTR proposal doesn't
distribute resolution services widely.

> If you've got a problem with NAPTR then you either have a problem
> with the framework or DNS.
 
No, I have a problem with THAT particular USE of DNS.

Let me get down to the basics, though:

DNS updates are unreliable. DNS administration is a nightmare. The
PURL proposal has worked out many of the issues of administration and
security that are necessary for actual deployment of URNs, and the
NAPTR proposal has only a wave at DNSSEC.

> I hope that won't be the case very soon. I'm building a
> parallel registry in rwhois. It doesn't have the restrictions
> that DNS does. Its more generalized and doesn't need to
> be re-written everytime you add a field.

That's great! If you're building a parallel registry in rwhois, I hope
that you address the administrative and update issues that were worked
out in the PURL paper and that we can leave NAPTR behind.

Regards,

Larry

To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] advantages of NAPTR over PURLs
From: Larry Masinter <[email-masked]>
Date: Wed, 9 Oct 1996 18:59:34 PDT
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

>  But PURLs are not an implementation of URNs...

Please review http://purl.oclc.org/OCLC/PURL/INET96 :

> PURLs are a direct result of OCLC's work in the Uniform Resource Name
> (URN) standards and library cataloging communities. The assignment of
> PURLs is an intermediate step towards the time when URNs are an
> integral part of the Internet information architecture. The eventual
> syntax of URNs is clear enough at this time to afford confidence that
> the syntax of PURLs can be inexpensively and mechanically translated
> to the eventual URN form. For instance, the PURL

>     http://purl.oclc.org/keith/home
>     ----   ------------- ----------
>       /           |               \
>  protocol    resolver address     name  

> could be written something like the following using the Path URN syntax:

>     URN:/org/oclc/purl/keith/home
>          ------------- ----------
>                |           |
>       naming authority   name

> where the URN is essentially a hierarchical name with the first
> portion representing the naming authority and the second portion
> signifying the local name. Note that the naming authority in this
> example is merely the resolver address of the corresponding PURL
> written backwards (with slashes instead of dots) and the local name
> is the same.

> Syntax aside, one way to think of URNs and PURLs is to consider what
> it would take to turn a PURL Server into a URN Server: very
> little. If Web browsers were changed to recognize the syntax
> URN:/org/oclc/purl/keith/home and could then connect to the resolver
> at purl.oclc.org, the resolver could then resolve the name
> /keith/home.

Date: Wed, 09 Oct 1996 10:18:08 -0600
To: Larry Masinter <[email-masked]>, [email-masked]
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] advantages of NAPTR over PURLs
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke Larry Masinter (at least at 02:13 AM 10/9/96 PDT)

>Presumably if you have SRV records, you could use them for HTTP
>servers too, including http://www.purl.org. 

Sorry, but SRV records cannot be used for HTTP without changing all
implementations of HTTP. The spec would also need to be changed to
say if SRV requests or A requests should occur first, because
behavior will differ.

>> Because it has "purl.org" in it which is OWNED by OCLC. They pay the
>> bill.
>
>Look, every place I've said "purl.org", change it to "purl.net" and
>register "purl.net" in a standards track document, 'owned' by IANA.
>
>If you did that, what would distinguishes 'urn.net' and 'purl.net' in
>terms of longevity?

Nothing. But there are distinctions other than longevity that
are important, starting with the overall design of the system.

You are not talking abut PURLs as set forth by OCLC. You are
talking about something that is halfway between the original Handle
proposal and PURLs. The idea of a global resolver (on replicated servers)
that would handle all resolution requests was the key feature of the
original Handle proposal. It was found unacceptable for several reasons,
two of which were:
 1) Potential for surgical denial of sevice attacks
 2) Organizations such as mine, who cannot put information about
    some of our documents into a system that is not cleared for
    handling classified work. (Company proprietary information is
    an analogous problem).

>> Because we don't to be tied to DNS. The URN framework (not NAPTR)
>> works in all situations no matter if you have DNS or not. You
>> can run the service in an OSI world using X.500 (everyone scream).
>
>I'm sorry, I was trying to establish the advantage of the NAPTR
>implementation against the PURL implementation of URNs, [...]

Every time I have heard the OCLC people talk about PURLs, they have
been careful to say that they are not URNs. Their focus was to do as
much as possible without changing client-side code.

>> 3) Other available protocols. The PURL doesn't tell me what other
>>    protocols are available and which one it considers the best.
>
>If the 303 response from HTTP includes multiple Location: results, you
>could pick the one you liked the best.

And 10 years from now, when HTTP has been supplanted by 2 generations
of further work in protocols, we are still supposed to start off
all resolution requests by sending an HTTP GET to something.purl.net?
I'm sorry, but this doesn't sound like a solution that will gracefully
adapt to the future.

>> There is not ONE killer reason why the URN framework is better than
>> PURLs. There are alot of smaller ones....
>
>I think you misunderstood: I'm not questioning the 'URN
>framework'. I'm questioning the NAPTR implementation of the framework.

Oh, that has not been clear to me. I thought you were looking for
a comparison between NAPTRs and PURLs. Since OCLC's PURLs are not an
implementation of the URN framework, and NAPTRs are supposed to be,
explaining some of the differences between them requires that we make
reference to the URN framework.

>I'm dubious about these DNS records with 'dblookup+N2C' in the middle
>of them and the idea that just because the syntax is embedded in DNS
>as a transmission mechanism that it isn't a 'protocol'.

I could be wrong about this, but I don't recall anyone ever saying that
NAPTRs were not a 'protocol', but please correct me if I am wrong about that.

You say you are "dubious" about the proposal. That's fine, lets
talk about your areas of concern.

Yesterday you raised a couple of concrete objections to the NAPTR "protocol",
namely that there was no versioning and that there was no change control
over the resolution protocols (rcds, rcds2, ..). I pointed out how we
could accomodate versioning in the flags field. 
I also said that we should discuss change control on the protocols, and
that your suggestion that they be registered as URL schemes was a
reasonable starting point for the discussion. To begin that discussion
I also said that I was unsure this was the best thing to do, since in the
past some protocols (Z39.50 in particular) have had trouble mapping all
their capabilities into a URL. However, I don't have any better
suggestions at this time. Perhaps we should look to a registry like the
media type registry as our model?

These topics are very young, so nobody has had anything to say on them
yet. How about you? Does my suggestion of using the flags field overcome
your concern about versioning? If not, why not? Do you have any further
arguments on why a version field should be needed when we cannot change
the number, type, or order of fields in a DNS record once it is out there?
When clients and servers are not required to understand and support all
the N2C, N2L, ... requests? 

Your point on versioning of the resolution protocols is well-taken. I
agree we should address that somehow - probably in the framework
document, but the NAPTR draft should, at least, cite the framework draft
as the source of information on that topic. We should discuss ow to do it,
so lets discuss it.
I assume you have more knowledge of the Z39.50 URL schemes than I,
is my concern about using URL standards-track documents as the "registry"
misplaced? What about an IMT-style registry instead?

Do you have any further concrete areas of concern about the NAPTR
implementation of the framework?

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"

Date: Wed, 09 Oct 1996 08:50:07 -0600
To: Lewis Girod <[email-masked]>
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] advantages of NAPTR over PURLs
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke Lewis Girod (at least at 08:08 PM 10/8/96 -0400)

[Lewis talks about having a PURL-like resolver forward resolution
requests]

>While it is true that the client's resolutions would continue to go
>``through'' whatever.resolver.purl.org, this is really because that is
>the naming authority that delegated the names.  NAPTR has this very
>same property -- all resolutions go through the root (cached)
>registry, [...]

Actually, no.

The PURL-like approaches send the entire request, document-id and all,
to the root resolver. This allows fun little things like surgical
denial of service and usage tracking which tend to get people excited.

The NAPTR appoach does not send the entire resolution request to the
root (urn.net). All we ask of it is "how do I resolve names from
namespace X?".

NAPTR and PURL resolution are very different. All NAPTR does is get
us to a resolver, without requiring that the location of the resolver be
buried in the URN or that we have a global resolver that is fixed for
all time. PURLs get us to the resolver by putting its location into
the identifier. Larry has suggested some modifications to PURLs where
we don't put the location of the resolver into the identifier, but
everyone knows that purl.org (or whatever) is the place to go to start
resolution.

>and if your names were originally delegated from foo.com,
>you will probably end up going through foo.com forever, even if the
>resolution is actually done by someone else.

That depends on the namespace that is used. For namespaces like
CID or INET, that is true. For namespaces like ISBN, resolution will
probably be accomplished by an organization like Bowker, even
if the name was originally assigned by Prentice-Hall.

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, 09 Oct 1996 10:37:48 -0400
From: Michael Mealling <[email-masked]>
Organization: Network Solutions
To: Larry Masinter <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [URN] advantages of NAPTR over PURLs
Sender: [email-masked]
Reply-To: Michael Mealling <[email-masked]>

Larry Masinter wrote:
> 
> > The only way to do this is with a new record. That record is the
> > SRV record which a lot of people are planning on using. A records
> > only have the IP address, nothing else.
> 
> Presumably if you have SRV records, you could use them for HTTP
> servers too, including http://www.purl.org. So the fact that this is a
> general mechanism means that 'priority' is no longer an advantage of
> NAPTR vs. PURL.

Do you see where you're going Larry? You are putting everything
we've already got in the URN framework and the NAPTR proposal
into PURLs. 

> > Because it has "purl.org" in it which is OWNED by OCLC. They pay the
> > bill. As far as the NIC is concerned they can do with it whatever
> > they want and we can't do squat about it. NAPTR should eventually
> > be a TLD all its own that is not 'owned' by anyone but the IANA (which
> > has its own problems but I won't go into that).
> 
> Look, every place I've said "purl.org", change it to "purl.net" and
> register "purl.net" in a standards track document, 'owned' by IANA.
> 
> If you did that, what would distinguishes 'urn.net' and 'purl.net' in
> terms of longevity?

Nothing. But you ARE changing the intent and current design of PURLS.

> > Because we don't to be tied to DNS. The URN framework (not NAPTR)
> > works in all situations no matter if you have DNS or not. You
> > can run the service in an OSI world using X.500 (everyone scream).
> 
> I'm sorry, I was trying to establish the advantage of the NAPTR
> implementation against the PURL implementation of URNs, not against
> the 'framework'.

NAPTR is just one implementation. Its not the best because of 
limitations of DNS. If you've got problems with NAPTR because of
that then take them up with Paul Vixie. If you can come up with
a DISTRIBUTED database that has is as large and as widespread
as DNS that we can test the framework on then by all means let
us know cause we'll build the framework on that too.

If you've got a problem with NAPTR then you either have a problem
with the framework or DNS.

> > 1) Areas of Authority. purl.org is authoritative for everything. I doubt
> >    if that scales. If its not authoritative how do I find the authoritative
> >    server?
> 
> Who is the authority of "urn.net"? The authority for purl.net can be
> delegated in the same way that NAPTR delegates the authority for
> urn.net.

Huh? How can purl.net delegate authority without having to go
through purl.net first? Who the authority is for urn.net is
the IANA hopefully. The IANA could also be the authority for
purl.net. That's not the issue. I'm talking about subdelegation
of entire naming authority spaces such as "ibm", "compuserve",
"thompson publishing", etc.

> > 2) Services. I don't want just the URL. I want a URC. But I want it in
> >    SGML and not MARC. How can I get that out of a PURL?
> 
> This is really speculative, of course, since there's never quite been
> agreement on exactly what a 'URC' might be. But I'd conjecture that
> the way you get something out of a resource other than the resource
> itself is by applying some other method than GET.

Ok. Granted. URCs don't exist. What happens when the resource
itself on one server and the metadata is on another. To find
both I have to go to purl.net. Larry, I don't know if you've
got some awsome machine up your sleave but if you've got a database
that can a) handle HTTP b) be replicated reliably and quickly around
all of the SRV replicated PURL servers and c) handle the millions
of queries a second that are going to come to purl.net because
it is the one place that knows where all of the URNs and URLs and
URCs are then you've got something truly amazing. Who the hells
gonna pay for it?

> 
> > 3) Other available protocols. The PURL doesn't tell me what other
> >    protocols are available and which one it considers the best.
> 
> If the 303 response from HTTP includes multiple Location: results, you
> could pick the one you liked the best. It's true that the results
> don't rank order them, but is that actually practical?

Yes. If I'm serving SGML based something or others then I want you
to use Z39.50 or some other deep search tool. You should know
that even though you like HTTP its not going to get you the
information that I know is in that database.

Plus, I still have to go to one of those big purl database machines
even to find out what protocols are available.

You've done nothing more than stick the hidden the re-write rules
inside the PURL database and made everyone go to it in order
to do the mapping. You've basically collapsed the NAPTR proposal
into one BIG  PURL database by forcing everyone to go to it 
in order to find out what the URLs are for the authoritative
resources.

That just won't scale.

> > 4) Equivalence. How do I match equivalence? Do I just match on
> >    the part after the hostname? If so then authority areas cannot
> >    exist. If not then your protocol is indistinquishable from the
> >    rest of the authority area.
> 
> I'm not sure where the 'equivalence' requirement came from, since it
> was specifically not a URN requirement. It wasn't a URN requirement
> primarily because it was considered impossible.

One server gives me a document called URN:FOO. Another services gives 
another document called URN:FOO. I know that for their purposes
those organizations think those two things are the same.

If I have http://foobar.purl.net/saldkfasldkfjsldfj and
http://barbaz.purl.net/saldkfasldkfjsldfj. Are they byte equal?

> 
> > There is not ONE killer reason why the URN framework is better than
> > PURLs. There are alot of smaller ones....
> 
> I think you misunderstood: I'm not questioning the 'URN
> framework'. 

The framework specifies everything that NAPTR must do. DNS 
specifies everything that NAPTR can do. How would you build
something that follows the framework that doesn't require
everyone to go to one HUGE replicated database? The only
widely available distributed database we have right now
is DNS. 

I hope that won't be the case very soon. I'm building a
parallel registry in rwhois. It doesn't have the restrictions
that DNS does. Its more generalized and doesn't need to
be re-written everytime you add a field.

> I'm questioning the NAPTR implementation of the framework.
> I'm dubious about these DNS records with 'dblookup+N2C' in the middle
> of them and the idea that just because the syntax is embedded in DNS
> as a transmission mechanism that it isn't a 'protocol'.

Noone ever said it wasn't a protocol. Its a distributed
database for looking up the rules for finding the authoritative
servers and services for a given URN. The NAPTR proposal 
gives the algorithm for interpreting the records in that database. 
Of course in order to use that database you have to access it 
somehow and thats a protocol.
-- 
------------------------------------------------------------------------------
Michael Mealling	| 505 Huntmar Park Drive       | Phone:  (703)742-0400
Software Engineer	| Herndon, VA 22070	       | Fax:    (703)742-9552
Network Solutions	| <URL:http://www.netsol.com>  | [email-masked]

Date: Wed, 9 Oct 1996 07:21:50 -0700 (PDT)
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [URN] advantages of NAPTR over PURLs
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>
Larry:

| I'm sorry, I was trying to establish the advantage of the NAPTR
| implementation against the PURL implementation of URNs, not against
| the 'framework'.

But PURLs are not an implementation of URNs.  They do not grandfather
in existing name spaces, for example.  They are a clever use of
indirection with URLs.  

I think you're comparing apples and oranges, Larry.

Regards,
    Terry Allen    Fujitsu Software Corp.    [email-masked]
"In going on with these experiments, how many pretty systems do we build,
 which we soon find outselves obliged to destroy?" - Benjamin Franklin
  A Davenport Group Sponsor:  http://www.ora.com/davenport/index.html

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [URN] advantages of NAPTR over PURLs
From: Larry Masinter <[email-masked]>
Date: Wed, 9 Oct 1996 02:13:03 PDT
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

> The only way to do this is with a new record. That record is the
> SRV record which a lot of people are planning on using. A records
> only have the IP address, nothing else.

Presumably if you have SRV records, you could use them for HTTP
servers too, including http://www.purl.org. So the fact that this is a
general mechanism means that 'priority' is no longer an advantage of
NAPTR vs. PURL.

> No. It has to do with the allowable packets size for DNS via UDP.
> If it goes over then the packet is truncated causing the client
> to have to reconnect via TCP. IF the part that is truncated
> though is in the additional information field then the user
> is NOT given an error. This is a problem with DNS that
> cannot be fixed. Even if you consider it a problem....

I'm really confused why long A records are a problem and long SRV
records aren't a problem, but I suppose I can take your word for it.

> Because it has "purl.org" in it which is OWNED by OCLC. They pay the
> bill. As far as the NIC is concerned they can do with it whatever
> they want and we can't do squat about it. NAPTR should eventually
> be a TLD all its own that is not 'owned' by anyone but the IANA (which
> has its own problems but I won't go into that).

Look, every place I've said "purl.org", change it to "purl.net" and
register "purl.net" in a standards track document, 'owned' by IANA.

If you did that, what would distinguishes 'urn.net' and 'purl.net' in
terms of longevity?

> Because we don't to be tied to DNS. The URN framework (not NAPTR)
> works in all situations no matter if you have DNS or not. You
> can run the service in an OSI world using X.500 (everyone scream).

I'm sorry, I was trying to establish the advantage of the NAPTR
implementation against the PURL implementation of URNs, not against
the 'framework'.

> 1) Areas of Authority. purl.org is authoritative for everything. I doubt
>    if that scales. If its not authoritative how do I find the authoritative
>    server?

Who is the authority of "urn.net"? The authority for purl.net can be
delegated in the same way that NAPTR delegates the authority for
urn.net.

> 2) Services. I don't want just the URL. I want a URC. But I want it in
>    SGML and not MARC. How can I get that out of a PURL?

This is really speculative, of course, since there's never quite been
agreement on exactly what a 'URC' might be. But I'd conjecture that
the way you get something out of a resource other than the resource
itself is by applying some other method than GET.

> 3) Other available protocols. The PURL doesn't tell me what other
>    protocols are available and which one it considers the best.

If the 303 response from HTTP includes multiple Location: results, you
could pick the one you liked the best. It's true that the results
don't rank order them, but is that actually practical?

> 4) Equivalence. How do I match equivalence? Do I just match on
>    the part after the hostname? If so then authority areas cannot
>    exist. If not then your protocol is indistinquishable from the
>    rest of the authority area. 

I'm not sure where the 'equivalence' requirement came from, since it
was specifically not a URN requirement. It wasn't a URN requirement
primarily because it was considered impossible.

> There is not ONE killer reason why the URN framework is better than
> PURLs. There are alot of smaller ones....

I think you misunderstood: I'm not questioning the 'URN
framework'. I'm questioning the NAPTR implementation of the framework.
I'm dubious about these DNS records with 'dblookup+N2C' in the middle
of them and the idea that just because the syntax is embedded in DNS
as a transmission mechanism that it isn't a 'protocol'.

Larry

From: Renato Iannella <[email-masked]>
Date: Wed, 9 Oct 1996 17:14:46 +1000 (EST)
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re[4]: [URN] advantages of NAPTR over PURLs
Sender: [email-masked]
Reply-To: Renato Iannella <[email-masked]>

Larry Masinter <[email-masked]> wrote:
> 
> Extensions to actually retrieving metadata for resources shouldn't be
> restricted to any URN implementation, should it?

Not exclusive for URNs, but I can see the increasing 
overloading of the use of URLs becoming epidemic!

In resolving a URN, we need to be able to specify
a range of options (eg: format/part of URC, best/cheapest
or closest place to resolve this, etc).

PURLs are great for those who need to move resources
around within an organisation. We need URNs (and NAPTRs)
for more sophisticated uses (as Ron and others have 
outlined).

Cheers... Renato
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dr Renato Iannella                  http://www.dstc.edu.au/RDU/staff/ri
Research Data Network CRC              urn:inet:dstc.edu.au:renato:home
DSTC Pty Ltd, Uni Qld, 4072, AUSTRALIA    phone/fax: +61 7 3365 4310/11
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Australian WWW Technical Conference '97 -> http://www.dstc.edu.au/aw3tc

Date: Wed, 9 Oct 1996 07:57:22 +0200 (MET DST)
From: Patrik Faltstrom <[email-masked]>
To: Larry Masinter <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Re[2]: [URN] advantages of NAPTR over PURLs
Sender: [email-masked]
Reply-To: Patrik Faltstrom <[email-masked]>

On Tue, 8 Oct 1996, Larry Masinter wrote:

> Many people want metadata from URLs too. A simple way to add metadata
> would be to add a new operation (GETMETA) where the format of the
> metadata is returned according to the Accept: headers.
> 
> Extensions to actually retrieving metadata for resources shouldn't be
> restricted to any URN implementation, should it?

No, but in the case of having this as a new operation that means
that the metadata (basically) have to be stored where the target
of the URL is stored, or one have to have special functions
in giving redirects when doing this command and not giving back the
target itself -- and update this redirect table where the
URL points (here we come back to what Ron was talking about
administrative responsibility for information).

I am not saying that metadata should only exist when dealing
with URNs. I am only saying that it is easier to use a scheme
like NAPTR where you do the DNS query and immediately know
where to go when asking for the metadata, and when asking for
the target. One save at least one TCP connection. That is
not peanuts on todays internet -- if it was only traffic
we were talking about. 

The biggest advantage is that one organization can have one
document, have a URN to that resourse and then outsource
the resolution service for the metadata and the data
(including replication) from a service provider. The owner
of the information creates a couple of NAPTR records pointing
to this service providers services.

The service provider is having some SRV records translating this
abstract names into the actual host/port number where the service
is running. The result is information about where the document is
stored, where the metadata is stored etc.

This distiction between what the owner of the document is doing and
what the service provider is doing is very important and needed
from my point of view.

    Patrik

To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Re[2]: [URN] advantages of NAPTR over PURLs
From: Larry Masinter <[email-masked]>
Date: Tue, 8 Oct 1996 22:15:22 PDT
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

Many people want metadata from URLs too. A simple way to add metadata
would be to add a new operation (GETMETA) where the format of the
metadata is returned according to the Accept: headers.

Extensions to actually retrieving metadata for resources shouldn't be
restricted to any URN implementation, should it?

Larry

From: Renato Iannella <[email-masked]>
Date: Wed, 9 Oct 1996 14:39:11 +1000 (EST)
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re[2]: [URN] advantages of NAPTR over PURLs
Sender: [email-masked]
Reply-To: Renato Iannella <[email-masked]>

Michael Mealling <[email-masked]> wrote:

> This doesn't give you several things:

> 2) Services. I don't want just the URL. I want a URC. But I want it in
>    SGML and not MARC. How can I get that out of a PURL?

I agree strongly here with Michael on this point.
PURLs can give you URLs, but we need the metadata (URCs)
to create _smarter_ and more _efficient_ internet clients.

Cheers... Renato
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dr Renato Iannella                  http://www.dstc.edu.au/RDU/staff/ri
Research Data Network CRC              urn:inet:dstc.edu.au:renato:home
DSTC Pty Ltd, Uni Qld, 4072, AUSTRALIA    phone/fax: +61 7 3365 4310/11
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Australian WWW Technical Conference '97 -> http://www.dstc.edu.au/aw3tc

Date: Tue, 08 Oct 1996 22:44:01 -0600
To: Terry Allen <[email-masked]>
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] advantages of NAPTR over PURLs
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke Terry Allen (at least at 03:38 PM 10/8/96 -0700)

>Which are the two registries?

The namespace registry (urn.net) and the protocol registry (URL
schemes ala Larry's suggestion).

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: Tue, 8 Oct 1996 20:08:35 -0400
From: Lewis Girod <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [URN] advantages of NAPTR over PURLs
Sender: [email-masked]
Reply-To: Lewis Girod <[email-masked]>

   From: Ron Daniel <[email-masked]>

   [...]

   Larry is correct that a great level of indirection can be achieved
   by changing the set of IP addresses that are returned when looking up
   some domain name, such as "resolver.purl.org". But all this indirection
   is simply changing the list of machines that are part of some business
   agreement with one organization. PURLs do not provide the indirection
   that is necessary to switch resolution from one organization to another.
   Assume we start with purl.org doing our resolution, and now want to do it
   ourselves. Maybe we want to go into competition with purl.org. Or maybe
   we are affiliated with the US Government and they mandate that all resources
   paid for by US tax dollars shall be resolved at gpo.gov.
   There are a number of believable scenarios where we want resolution to
   occur on machines that *cannot* be pointed to by the domain name purl.org.
   (Or any other single domain name).

One part of this argument is that PURL provides a ``direct''
resolution service, while NAPTR points the client _to_ a resolution
service.  However, a (differently implemented) server operating within
the same basic architecture as the existing PURL server could redirect
an arbitrary set of a client's PURLs to some other PURL server, ad
nauseum, thus gaining the desired property of pointing to other
resolvers.  (Essentially this might involve extending the notion of a
``partial redirect''.)

While it is true that the client's resolutions would continue to go
``through'' whatever.resolver.purl.org, this is really because that is
the naming authority that delegated the names.  NAPTR has this very
same property -- all resolutions go through the root (cached)
registry, and if your names were originally delegated from foo.com,
you will probably end up going through foo.com forever, even if the
resolution is actually done by someone else.

The main difference is that NAPTR requires modifications to the client
side and requires the client to execute the rewrite rules (which is
part of the work involved in the resolution).  In the PURL
architecture all that work would be done on the server, and it could
be arbitrarily complex (even more powerful than regexps ;-).  There
are cases in which each of these options is the more efficient one:

* In the case of NAPTR all of the information for locating resolvers
can be cached, whereas with PURL only information pertaining to
specific PURLs can be cached.

* In the case of NAPTR, if the _right_ answer(s) are readily computed
it is faster to have the client compute it than to look it up from a
server, as it would work with PURL.

* However, if the computation results in a number of matches that each
have to be tried, then it might be more efficient to do that work on
the server side.  One thing that has long worried me about NAPTR is
that as the namespace gets more fragmented the lookup to the DNS that
originally brought back one or two records might end up returning
hordes of records pointing where each individual fragment went.

In any case, yes, the PURL server as implemented has the properties
Ron stated, but the architecture _can_ support those indirection
features, without client-side changes.

		- Lewis

Date: Tue, 8 Oct 1996 15:38:05 -0700 (PDT)
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: [URN] advantages of NAPTR over PURLs
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

Ron writes:
| More contentious will be the registry for the namespaces. This is
| a place where we stand a good chance of repeating the TLD battle
| that is making life unpleasant for some of our colleagues. My current
| rules for what should be allowed to be registered as namespaces are:
|   1) Is it a namespace established by a recognized international
|      standards body?  (ISBN, ISSN, SICI, ISAN, ISWC, FPI, OID, and
|      a few others fit here).
|   2) Is it a namespace estabished by an industry standards body with
|      broad particiation? (SMPTE, IEEE, EIA,... are examples of the
|      groups I am thinking of).
|   3) This one is harder - is it a namespace established by a
|      commercial organization for the use of any organization following
|      normal business practices?  (This is to allow namespaces such as
|      DUNS (30 million identified organizations), some of the Barcode
|      registries (each can accomodate a few 10s of thousands of companies),
|      etc. It is intended to disallow vanity namespaces. This may be
|      impossible.

For "established," above, I think "maintained" would be better, or
perhaps "supervised, audited, licensed".  And this should apply
only to name spaces that these organizations themselves count
as eligible.

| 
| Both registries should be mentioned in the framework draft. We need a
| really good lawyer to look at the language. Anyone know of a likely
| candidate who would do it pro-bono?
| 

Which are the two registries?

Regards,
(at a new address)

    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: Tue, 08 Oct 1996 14:46:20 -0600
To: Larry Masinter <[email-masked]>
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] advantages of NAPTR over PURLs
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

I'm going to try to summarize the last batch of messages from
Larry, Patrik, Michael, and myself.

A key point of contention seems to be shown when Larry says (at 07:10 PM
10/7/96 PDT)

>The DNS entries for resolver.purl.org already give you all the
>indirection you need. Why add more?

I (and I assume Michael and Patrik) do not agree with the assertion that
this is all the indirection that is needed. Let me try to show why, and
Larry can let us know if the reasons are convincing or if he wants to try
and change our minds.

Larry is correct that a great level of indirection can be achieved
by changing the set of IP addresses that are returned when looking up
some domain name, such as "resolver.purl.org". But all this indirection
is simply changing the list of machines that are part of some business
agreement with one organization. PURLs do not provide the indirection
that is necessary to switch resolution from one organization to another.
Assume we start with purl.org doing our resolution, and now want to do it
ourselves. Maybe we want to go into competition with purl.org. Or maybe
we are affiliated with the US Government and they mandate that all resources
paid for by US tax dollars shall be resolved at gpo.gov.
There are a number of believable scenarios where we want resolution to
occur on machines that *cannot* be pointed to by the domain name purl.org.
(Or any other single domain name).

Several of Larry's other questions, such as

> I don't understand why www.purl.org must have a shorter lifetime than
> any NAPTR name. You just vow to not reassign the name.

are answered by the above. It is not just that www.purl.org might go away,
it is that we might want to move resolution of our identifiers off
of any machines that can be identified by www.purl.org and onto machines
identified by the domain name of a competitor to purl.org, while purl.org
still exists.

So, that is why we believe that changing IP addresses under a fixed
domain name is not sufficient *indirection* capabilities.

In responding to the same point, Patrik said that

> it does not give the information about priority and
> protocol that is needed.

and Larry asked for the justification for the need for
priority information. Let me take a stab at that as well.

Assume we have a set of N machines which are providing the
service for scheme.purl.com. There is no reason to assume that
all these machines are equally capable. Some will be very
capable hosts, others not so able. The priority field is used
to preferentially direct resolution requests towards the more
capable machines, while still allowing some requests to be
sent to the less powerful ones. NAPTRs themselves do not provide
this field, we rely on the SRV record for that.

There were some other questions about A records and bugs, Michael
has addressed those.

Other arguments, both technical and business, can be made against the
notion of having the IETF standardize a resolution procedure that says
"map <scheme>:<id> to http://<scheme>.purl.org/<id>". The technical
arguments are analogous to those that were raised against the original
version of the handle protocol. Business arguments show up when Larry
quotes me:

> > For PURLs, we not only have to know the identifier, we have to know
> > what resolver to contact. We end up with things like:
> >   http://purl.bowker.com/isbn/1-56604-355-7
> >   http://purl.agicoa.com/isan/9961231234567891
> 
> oh no! Clearly you only want to use the resolver.purl.org name.

Saying that all resolution requests go to <scheme>.purl.org mandates that
all organizations like Bowker, AGICOA, ASCAP, BMI, etc. (who have the
databases of identifiers and resources for particular schemes) establish a
business relationship with OCLC (*and any unspecified party that OCLC allows
to take over purl.org at any point in the future, no matter what their
policies*). This is not an acceptable solution.

In a later message, (Tue, 8 Oct 1996 00:59:24 PDT)
Larry raises a good point about the NAPTR resolution procedure not
having version information, so how do we know about:
  1) N2L, N2C, ... meaning the same things across time
  2) how to handle protocol changes such as rcds going to rcds2

First, changes in rcds (or other protocols) can be handled by
naming those protocols as rcds, rcds2, rcds3, ... in the protocol
portion of the services field.

If the group is concerned about versioning of the NAPTR record contents
and semantics, we have a couple of choices. One is that we define a
new RR at some point in the future. The second choice is that we use the
"flags" field. Currently we are allowing the digits 0-9 in the flags
field to be used for local experimentation (although I have no idea
what those experiments might be). We could reserve 2-9 for versions of
the interpretation of the fields of the NAPTR record. (The actual
number, type, and order of the fields in a DNS RR cannot be changed
once established, new RRs have to be defined to replace them). 

I am not convinced that adding a new resolution request (call it N2X for
argument) mandates a new "version" of the NAPTR record. The services
field can easily accomodate it, it has no backward incompatabilitites,
clients and servers are not required to support all resolution services.
Adding a new request will require that all protocols that want to
support it specify how the request and result will be mapped into their
protocol, but if necessary the protocols themselves can be versioned
as noted above.

Larry also raise a good point when he says that:

>if you force people to register "dunslink" and "rcds" as new
>URL schemes, we'll have a mechanism for dealing with those tokens in a
>standards-track way. As you've specified it, there's no change-control
>on what those tokens might mean: if there are two versions of
>rcds, should NAPTR records upgrade all their records when the resolver
>upgrades from rcds1 to rcds2? If there's a version skew between the
>client rcds and the server rcds such that the server rcds can't
>respond to the client's ancient rcds implementation, should the
>rejection influence the handling of priorities?

We do need some registry for the protocols to have a degree of
change control. I am not sure that URL schemes are the best way to do
it, because of difficulties some protocols (Z39.50 for example) have
had in the past with making all their capabilities show up in a URL.
However, it is a reasonable starting point for discussion.

More contentious will be the registry for the namespaces. This is
a place where we stand a good chance of repeating the TLD battle
that is making life unpleasant for some of our colleagues. My current
rules for what should be allowed to be registered as namespaces are:
  1) Is it a namespace established by a recognized international
     standards body?  (ISBN, ISSN, SICI, ISAN, ISWC, FPI, OID, and
     a few others fit here).
  2) Is it a namespace estabished by an industry standards body with
     broad particiation? (SMPTE, IEEE, EIA,... are examples of the
     groups I am thinking of).
  3) This one is harder - is it a namespace established by a
     commercial organization for the use of any organization following
     normal business practices?  (This is to allow namespaces such as
     DUNS (30 million identified organizations), some of the Barcode
     registries (each can accomodate a few 10s of thousands of companies),
     etc. It is intended to disallow vanity namespaces. This may be
     impossible.

Both registries should be mentioned in the framework draft. We need a
really good lawyer to look at the language. Anyone know of a likely
candidate who would do it pro-bono?

Enough for now,

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"

To: [email-masked]
Subject: [URN] NAPTR time, folks
Date: Tue, 08 Oct 1996 14:45:56 +0100
From: Martin Hamilton <[email-masked]>
Sender: [email-masked]
Reply-To: Martin Hamilton <[email-masked]>

For info - I just noticed the latest BIND test release (4.9.5-T6B)
has support for NAPTR records.

Martin

Date: Tue, 08 Oct 1996 09:50:04 -0400
From: Michael Mealling <[email-masked]>
Organization: Network Solutions
To: Larry Masinter <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [URN] advantages of NAPTR over PURLs
Sender: [email-masked]
Reply-To: Michael Mealling <[email-masked]>

Larry Masinter wrote:
> Re replication:
> 
> > We can provide multiple A records for www.purl.org, but there is no
> > way to do smart prioritization between the more and less capable
> > hosts.
> 
> Why is this easier to do with NAPTR records than A records? Could we
> extend A records for HTTP servers so that you could do smart
> prioritization? ("If this is such a great idea, why save it for
> URNS").

The only way to do this is with a new record. That record is the
SRV record which a lot of people are planning on using. A records
only have the IP address, nothing else.

> > Depending on how the multiple A records are provided, there may also
> > be an obscure error that truncates the list of responses. The NAPTR
> > proposal will not suffer that error.
> 
> Is this a bug in the implementation of DNS? If the bug is there for A
> records, why wouldn't it be there for NAPTR records? Is this a design
> error that could be fixed?

No. It has to do with the allowable packets size for DNS via UDP.
If it goes over then the packet is truncated causing the client
to have to reconnect via TCP. IF the part that is truncated
though is in the additional information field then the user
is NOT given an error. This is a problem with DNS that
cannot be fixed. Even if you consider it a problem....

> > The real point of the NAPTR proposal is that it gives us a way to cope
> > with names, such as www.purl.org, that should be long-lived but aren't.
> 
> I don't understand why www.purl.org must have a shorter lifetime than
> any NAPTR name. You just vow to not reassign the name. If you can't do
> that with ".org", then pick a new top level domain.

Because it has "purl.org" in it which is OWNED by OCLC. They pay the
bill. As far as the NIC is concerned they can do with it whatever
they want and we can't do squat about it. NAPTR should eventually
be a TLD all its own that is not 'owned' by anyone but the IANA (which
has its own problems but I won't go into that).

> >>Well, www.purl.org can migrate, too, can't it?
> > I'm sorry I wasn't clear. By "migrating a resolver" I mean moving it onto
> > a machine that cannot be identified by the domain name that was used
> > for the earlier resolver, and terminating service on the original machine,
> > even if that machine remains up and running for other purposes.
> > So, no, www.purl.org cannot migrate according to my definition. (Better
> > terminology welcomed).
> 
> If you want to be able to migrate PURL resolvers to other machines,
> you just assign a new IP address to the PURL resolver name. This is
> completely flexible. Don't use that DNS name for anything other than
> PURL resolution service. E.g., call it <scheme>.resolver.purl.org
> instead of just www.purl.org.
> 
> The DNS entries for resolver.purl.org already give you all the
> indirection you need. Why add more?

Because we don't to be tied to DNS. The URN framework (not NAPTR)
works in all situations no matter if you have DNS or not. You
can run the service in an OSI world using X.500 (everyone scream).

> >>> and the resolution process allows multiple protocols
> >>The URL in the 'Location:' header of purl.org's response need not be
> >>'http:'.
> 
> >We are not talking about the same thing. One could assign PURLs such as
> >   ftp://purl.foo.com/whatever
> >but once that PURL is assigned, we have to use FTP to resolve it. Since
> >the NAPTR draft doesn't require the resolution protocol to be embedded in
> >the identifier, we are free to offer multiple resolution protocols and to
> >change them over time. This is an important point, since over time we
> >will have increasingly efficient protocols.
> 
> In the "PURL" method, the "resolution" is accomplished by using HTTP
> to talk to the resolution service and (if what you do is a GET)
> getting back a "303" response with a Location: header to do the
> URN->URL mapping.

This doesn't give you several things:
1) Areas of Authority. purl.org is authoritative for everything. I doubt
   if that scales. If its not authoritative how do I find the
authoritative
   server?

2) Services. I don't want just the URL. I want a URC. But I want it in
   SGML and not MARC. How can I get that out of a PURL?

3) Other available protocols. The PURL doesn't tell me what other
   protocols are available and which one it considers the best.
  
4) Equivalence. How do I match equivalence? Do I just match on
   the part after the hostname? If so then authority areas cannot
   exist. If not then your protocol is indistinquishable from the
   rest of the authority area. 

There is not ONE killer reason why the URN framework is better than
PURLs. There are alot of smaller ones....

-MM
-- 
------------------------------------------------------------------------------
Michael Mealling	| 505 Huntmar Park Drive       | Phone:  (703)742-0400
Software Engineer	| Herndon, VA 22070	       | Fax:    (703)742-9552
Network Solutions	| <URL:http://www.netsol.com>  | [email-masked]

Date: Tue, 08 Oct 1996 09:12:02 -0400
From: Michael Mealling <[email-masked]>
Organization: Network Solutions
To: [email-masked]
Subject: [URN] [Fwd: 4.9.5 T6B] NAPTR/SRV beta support in bind available
Sender: [email-masked]
Reply-To: Michael Mealling <[email-masked]>

This is a multi-part message in MIME format.

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

I just received this from Paul Vixie. This is a beta release so
be careful if really depend on your DNS server. Enjoy!

Thanks Paul!

-MM

-- 
------------------------------------------------------------------------------
Michael Mealling	| 505 Huntmar Park Drive       | Phone:  (703)742-0400
Software Engineer	| Herndon, VA 22070	       | Fax:    (703)742-9552
Network Solutions	| <URL:http://www.netsol.com>  | [email-masked]

--------------31DA64A630DE
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

To: [email-masked]
Subject: 4.9.5 T6B
Date: Mon, 07 Oct 1996 21:56:20 -0700
From: Paul A Vixie <[email-masked]>
Sender: <[email-masked]>
Reply-To: Paul A Vixie <[email-masked]>

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

This fixes all the nits reported for T4B.  It adds NAPTR support.  It is a
release candidate.  A complete revision history since 4.9.4-P1 is included
below.

Location:	<URL:ftp://ftp.vix.com/pub/bind/testing/bind-4.9.5-T6B.tar.gz>
POSIX Checksum:	2039359057 2203287
MD5 Checksum:	5f7f9304bfe341493f5778baf25c14cb

PGP Signature:

- -----BEGIN PGP MESSAGE-----
Version: 2.6.2

iQCVAwUAMlnd53cdkq6JcsfBAQEe5QQAkFtt+geItsx7XheeCF2YU0SHvw1iEQ7m
LgH5/nWKyDhJHtjXZ4reuR06HwBnagrmEij4BBHRSsePKDCUhUp2uE3KFund9qfy
Suul9poyinMPinpMVkImKFetTOJirNUrglUw8oA/0LBZrl2VV9GGcIX3a9XldybR
EJX1Tm74CNo=
=6Imd
- -----END PGP MESSAGE-----

        --- 4.9.5-t6b released ---

740. [bug]      dangling cname checking had a few memory leaks.

739. [func]     SRV support made more complete; NAPTR support added.

738. [protocol] dangling CNAMEs are no longer considered format errors.

737. [bug]      owner domain names like "*." were not considered valid.

736. [contrib]  new version of contrib/host included.

735. [doc]      added some text to shres/solaris/INSTALL.

734. [bug]      loading a zone with a single line SOA RR killed following line.

733. [bug]      priming could deadlock in odd cases.

732. [bug]      SIGHUP now caught before initial zone load.

731. [bug]      IP/TCP session logging now controlled by #ifdef DEBUG.

730. [port]     untested HPUX 10 support added to top level Makefile.

729. [port]     ultrix vs. _res_close(); ultrix wins.

728. [bug]      several d_rcode references weren't #ifdef'd NCACHE.

727. [bug]      SOA timer warnings now consistently logged at LOG_WARNING.

726. [protocol] added T_NAPTR as RR type 35, hoping the IANA concurs.

        --- 4.9.5-t5b released ---

725. [port]     shared libraries should work on Linux now.

724. [bug]      "dig @0 VERSION.BIND TXT CHAOS" had never been tested.

723. [port]     Solaris 2.6 has AF_LINK but not sa_len.

722. [protocol] verify RdLength of A and AAAA RRs.

721. [port]     missing include directories will be made during "install".

720. [port]     solaris and sunos should use native assemblers with gcc.

719. [port]     cleaned up some A/UX linkages.

718. [func]     some SOA sanity checks were changed from errors to warnings.

717. [port]     BSD/named/Makefile needed to have dmalloc.c reference removed.

716. [protocol] cnames and referrals were generating spurious log messages.

715. [port]     ultrix PCC didn't like a =&, said it was ambigious somehow.

        --- 4.9.5-t4b released ---

714. [port]     contrib/os2-emx now contains files nec'y for OS/2 (EMX).

713. [func]     gethostbyname2(x, AF_INET6) now accepts address literals.

712. [bug]      gethostbyname() wasn't seeing RES_USE_INET6 early enough.

711. [bug]      nslookup was printing IPv6 addresses improperly.

710. [port]     an alignment bug was found and fixed by Cray.

709. [bug]      named-xfer was dumping core on incoming LOC RRs.

708. [protocol] primary zones are edited to make rrset ttl's coherent during
                loading.

707. [protocol] rrsets with coherent ttl's won't be overridden by new rrsets
                with incoherent ttl's.

706. [port]     Ultrix portability restored.

705. [func]     added "limit files XXX" to boot file.

704. [bug]      trace generation code was getting unaligned accesses.

703. [contrib]  added contrib/getkeyby, from [email-masked].

702. [func]     MAXDNAME is now 4*256+1 to allow for \000 and the NUL.

701. [bug]      samedomain() wasn't paying attention to escapes.

700. [func]     allow long text strings in T_X25 RRs.

699. [port]     added base64.c to shres/*/Makefile.

698. [port]     picked some lint out of tools/nslookup/getinfo.c.

697. [bug]      we were calling isupper() without calling isascii() first.

696. [protocol] a new kind of bad referral is now caught and ignored.

        --- 4.9.5-t3b released ---

695. [func]     Use delete_stale() in preference to delete_all() more often.

694. [func]     DATUMREFCNT is no longer an option.

693. [port]     fixed up the CPPFLAGS usage in the top level Makefile.

692. [port]     fixed up the __ defines (for POSIX.3) in include/resolv.h.

691. [port]     removed all uses of "ssize_t", the world is not ready for it.
                (fixed two latent signed/unsigned code bugs in the process.)

        --- 4.9.5-t3a released ---

690. [bug]      the stale() and delete_all() calls in finddata() weren't
                respectful toward T_ANY and C_ANY queries.

689. [lint]     miscellaneous compiler warnings were disappeared.

688. [func]     handles insane/unreachable root servers a little better now.

687. [bug]      T1A's core dumps from bad databufs should be all fixed now.

686. [func]     overlong TXT strings should work again.

685. [port]     updated compat/include/sys/cdefs.h to BSD 4.4-Lite (8.7) vers.

684. [doc]      doc/i-d/* added.

683. [contrib]  "nslint" added to contrib/.

682. [protocol] irrelevant authority information is now correctly ignored.

681. [func]     DO_RELOAD Is no longer optional.

680. [cleanup]  ALLOW_UPDATES is gone.

679. [port]     some systems need _res to be in text rather than bss.

678. [port]     -Dssize_t=int is gone; see portability.h.

677. [contrib]  outdates #671; update to contrib/host version 960808.

676. [doc]      formatting fix to man/named.man8.

        --- 4.9.5-t2a released ---

675. [lint]     various.

674. [feature]  support added for SRV RR (untested).

673. [protocol] added definitions for EID, NIMLOC, SRV, ATMA, and IXFR.

672. [bug]      fixed decoding problem wrt AAAA in tools/nslookup/debug.c.

671. [bug]      fixed formatting problem wrt TXT in contrib/host/host.c.

        --- 4.9.5-t1a released ---

670. [feature]  added SIG and KEY RR support (without signature or
                verification).

669. [internal] name/number translations are now mostly table driven.

668. [feature]  nslookup now has better[/different] error messages.

667. [feature]  inet_neta(), inet_net_ntop(), inet_net_pton() added.

666. [bug]      parent zone will be reloaded when a child zone changes.

665. [protocol] RETURNSOA logic has been refined, and now ships "enabled."

664. [protocol] cached RRsets are now completely flushed when new data arrives.

663. [port]     IRIX shared libraries are now supported.

662. [port]     SCO OSE5 support has been upgraded slightly.

661. [bug]      insane root servers will now be handled correctly.

660. [bug]      TXT RRs are now parsed and displayed in full RFC1035 form.

659. [port]     UXP/DS is now supported in the top level Makefile.

658. [feature]  BIND now checks that UDP checksums are enabled in the kernel.

        --- 4.9.4-p1 released ---

--------------31DA64A630DE--

Date: Tue, 8 Oct 1996 14:33:55 +0200
To: Larry Masinter <[email-masked]>
From: Patrik Faltstrom <[email-masked]>
Subject: Re: [URN] advantages of NAPTR over PURLs
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Patrik Faltstrom <[email-masked]>

At 00.59 -0700 96-10-08, Larry Masinter wrote:
>> The A record does not have a priority. MX-records do have that,
>> A records does not. You can not change the spec of A-records.
>
>Tell me again why replicated services need to have 'a priority'.
>What requirements does it help satisfy?

Because the cost, performance or other issues. When using A-records
the servers _have_ to be the same. When talking about URNs I personally
would like to be able to host these kind of requirements, even though
(or especially because of the fact that) we don't know everything about
all future protocols or resolution services.

>Are you saying that you'd expect NIS to work with NAPTR but not to
>work with long A records?

No, I don't expect to use NAPTR to be used in NIS. This was an example
of a broken resolver system which have to be replaced. Because it has
to be replaced anyway, it shows that the requirement of choosing PURLs
because you can use existing resolver implementations is not always
true. If you have to change the resolver anyway because of bugs, you can
change to something that supports SRV and NAPTR.

>PURLs
>handle renaming of resources by letting you go to the PURL server and
>tell the PURL server where the resource is now.
>	PURL -> URL -> resource
>If the resource gets renamed, you change the PURL -> URL mapping. No
>second level abstraction needed.

It is needed if the service moves from one resolution protocol (HTTP)
to something else because the resolution protocol is part of the PURL,
which is not the fact with the NAPTR proposal.

>This protocol uses DNS, but it is still a protocol. It has a syntax,
>the syntax must be parsed, the syntax has no version information, the
>syntax is not in itself widely implemented, might need to be changed,
>etc.
>
>The PURL system also has a single protocol for finding an appropriate
>resolution service. That protocol consists of doing a DNS A record
>lookup on duns.resolver.purl.org, then picking one of the IP addresses
>you get, and doing a HTTP request.

You need both DNS and HTTP. Not only DNS. I trust the lifespan for DNS
more than the lifespan for HTTP (i.e. not that HTTP will go away but
might be replace with something else like LIFN resolvers).

>While HTTP might not be 'long-lived', are you claiming that this
>design of NAPTR is longer-lived, or should be? How long? On what
>grounds to you evaluate longevity of protocols? There is "N2L", "N2C"
>and "N2R", will there not be another kind of category of "N2X" for 20
>years?

The only thing I claim is that the NAPTR proposal follows the URN
requirements RFC better than the PURLs. Of course some of this is
depending on what "trust" each one of us personally have for each
one of the protocols that are used.

I have just stated my personal opinion.

>I'm just asking you to write down what the advantage actually is.
>I understand and I'm willing to trust that there advantages, but you
>should say.

Let's say that I have a Whois++ server with all metadata of all
documents we have on our www-server. That server is replicated into
a LDAPv3 server so it also can be accessed via LDAPv3, and not only
Whois++. Because of schema-definition problems, the Whois++ server
is the primary server, so the Whois++ server should have higher
priority than the LDAPv3 one (or vice versa).

I.e. when mirroring data between servers -- especially when mirroring
between servers with different access protocols which I think will be
more and more common -- loss of data will happen. You also might loose
data if you have a primary server and a secondary one outside a
firewall etc. Just as with MX records, you should first try to access
the internal server, and then the external one.

>To reiterate a bit on the 'protocol' issue: it's always possible to
>delegate to some other protocol in a 303 Location: response; at least,
>though, if you force people to register "dunslink" and "rcds" as new
>URL schemes, we'll have a mechanism for dealing with those tokens in a
>standards-track way.

This is true, but you do need then:

 DNS -> HTTP -> new_protocol

Instead of

 DNS -> new_protocol

>As you've specified it, there's no change-control
>on what those tokens might mean: if there are two versions of
>rcds, should NAPTR records upgrade all their records when the resolver
>upgrades from rcds1 to rcds2? If there's a version skew between the
>client rcds and the server rcds such that the server rcds can't
>respond to the client's ancient rcds implementation, should the
>rejection influence the handling of priorities?

This should be something the one designing (choosing) the protocol
used in the NAPTR records. If the rcds protocol is not backward
compatible in future versions, that is obviously a bad choice for
the use as resolution protocol.

This is not something that should be part of the NAPTR framework.
What the URN framework is, is a way of describing what the NAPTR
framework have to handle, which in turn sets limitations and
recommendations on the resolution protocols used. When using PURL,
you have to use HTTP, which already today is changed.

With NAPTR (and rcds for example) you have something that can use
UDP for the whole resolution process which is more effective than
using TCP and HTTP.

>     z3950r://isite.bogus.com/0123@ab125212312xx0A
>and you refer to it with
>     urn:duns:002372413:annual-report-1997
>
>you can still use PURLs to do it, by looking up
>    http://duns.resolver.purl.org/002372413:annual-report-1997
>
>and getting back a
>    303
>    Location: z3950r://isite.bogus.com/0123@ab125212312xx0A

Yes, _if_ you have both DNS and HTTP protocols part from
the Z39.50 protocol.

>Maybe one way to improve PURLs would be to have the 'redirect' message
>in HTTP allow pattern-redirects.

This is from my point of view something that might be needed anyway,
but is an implementation problem and not a HTTP problem.

Note that I am not saying that PURLs should go away, die or something
like that. It works perfectly in some environments and solve tons
of problem todays version of usage of URLs have. You have though to
use HTTP and you have no priority (as two things missing). With
NAPTR and SRV records, you can change the protocols aswell without
using HTTP, i.e. with only the use of DNS, and that is for me
something that is very important. DNS have been around some
7 years longer than HTTP.

   Regards, Patrik

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [URN] advantages of NAPTR over PURLs
From: Larry Masinter <[email-masked]>
Date: Tue, 8 Oct 1996 00:59:24 PDT
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

This sounds a bit more like a diatribe than I'd like.... I started out
trying to get some explicit description of the advantages of NAPTR
over what seems like a far simpler method (PURLs).

> The A record does not have a priority. MX-records do have that,
> A records does not. You can not change the spec of A-records.

Tell me again why replicated services need to have 'a priority'.
What requirements does it help satisfy?

> This is just how things are implemented, especially when one
> start using things that is not really DNS (NIS for example).
> To be able to get around this problem -- we need a new resource
> record type.

Are you saying that you'd expect NIS to work with NAPTR but not to
work with long A records? I vaguely remember a patch several years ago
to the Sun NIS implementation to fix the problem with a server
(merit.edu?) that had more A records than before. I think that to get
around a bug in implementations of DNS, you need to fix the bug.

>> I don't understand why www.purl.org must have a shorter lifetime than
>> any NAPTR name. You just vow to not reassign the name. If you can't do
>> that with ".org", then pick a new top level domain.

> Because the NAPTR record is the second abstraction level you really
> need to be able to handle renaming of resources on the net.

I've stared at this, but it seems like you're saying that "you need it
because you really need it". Why do you need a second abstraction
level to be able to handle renaming of resources on the net? PURLs
handle renaming of resources by letting you go to the PURL server and
tell the PURL server where the resource is now.
	PURL -> URL -> resource
If the resource gets renamed, you change the PURL -> URL mapping. No
second level abstraction needed.

> You also can handle other protocols than HTTP which makes the NAPTR
> proposal (NAPTR records together with SRV records) much more long
> lived.

The NAPTR proposal has a single protocol for finding an appropriate
resolution service. The NAPTR protocol suggests that looking up
    urn:duns:002372413:annual-report-1997

means a DNS NAPTR lookup on duns.urn.net, examining the syntax for
tokens N2L/N2C/N2R, followed by another DNS lookup for the SRV record.

This protocol uses DNS, but it is still a protocol. It has a syntax,
the syntax must be parsed, the syntax has no version information, the
syntax is not in itself widely implemented, might need to be changed,
etc.

The PURL system also has a single protocol for finding an appropriate
resolution service. That protocol consists of doing a DNS A record
lookup on duns.resolver.purl.org, then picking one of the IP addresses
you get, and doing a HTTP request.

While HTTP might not be 'long-lived', are you claiming that this
design of NAPTR is longer-lived, or should be? How long? On what
grounds to you evaluate longevity of protocols? There is "N2L", "N2C"
and "N2R", will there not be another kind of category of "N2X" for 20
years?

>> The DNS entries for resolver.purl.org already give you all the
>> indirection you need. Why add more?

> No, it does not give the information about priority and
> protocol that is needed. We should not at all of the meetings
> we had last year still be talking about NAPTR records which
> forces everyone to change their resolvers if it was not needed.

On 'priority', you haven't actually said why you need priority. In
this paragraph you assert that you had a meeting where everyone agreed
that priority was needed, but it's not apparent why URN resolution
needs priority. That you talked about NAPTR records and decided you
needed priority then still doesn't explain WHY you thought you needed
it. I'm just asking you to write down what the advantage actually is.
I understand and I'm willing to trust that there advantages, but you
should say.

To reiterate a bit on the 'protocol' issue: it's always possible to
delegate to some other protocol in a 303 Location: response; at least,
though, if you force people to register "dunslink" and "rcds" as new
URL schemes, we'll have a mechanism for dealing with those tokens in a
standards-track way. As you've specified it, there's no change-control
on what those tokens might mean: if there are two versions of
rcds, should NAPTR records upgrade all their records when the resolver
upgrades from rcds1 to rcds2? If there's a version skew between the
client rcds and the server rcds such that the server rcds can't
respond to the client's ancient rcds implementation, should the
rejection influence the handling of priorities?

> The PURL methods do work for locating HTTP servers, IF you
> name your resources exactly the way you point it out Larry,
> i.e. that you do have a special namespace allocated for the
> PURL names which does not have anything in common with the
> hostname namespace.

a) Are you claiming that PURL is limited to "locating HTTP servers"?
The PURL method could work for locating any resource that can be
located by a URL. The PURL method happens to use HTTP to do the
location. However, if you have a report stored in a z39.50 server with
URL

     z3950r://isite.bogus.com/0123@ab125212312xx0A
and you refer to it with 
     urn:duns:002372413:annual-report-1997

you can still use PURLs to do it, by looking up
    http://duns.resolver.purl.org/002372413:annual-report-1997

and getting back a 
    303
    Location: z3950r://isite.bogus.com/0123@ab125212312xx0A

b) "IF you name your resources exactly the way you point it out"

This is the rub: PURLs don't have regular expression matching.
And the DNS caching allows caching of patterns.

> When coming to this conclusion, we did also think about the
> need for different resolution protocols (to handle the case
> when someone is running a resolution service for a publisher,
> and who is responsible for what in the resolution process)

The purl system is potentially recursive. You could redirect from one
URL to another. So it allows multiple roles or a single one. NAPTR
however seems to have only two roles: you either own the DNS entry and
manipulate that, or else you own the resolver. That's an advantage, I
suppose, but it seems less flexible.

There's a performance issue, in that DNS records cache better,
although TTL seems as risky as max-age in HTTP.

Maybe one way to improve PURLs would be to have the 'redirect' message
in HTTP allow pattern-redirects.

Regards,

Larry

Date: Tue, 8 Oct 1996 06:30:40 +0200 (MET DST)
From: Patrik Faltstrom <[email-masked]>
To: Larry Masinter <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [URN] advantages of NAPTR over PURLs
Sender: [email-masked]
Reply-To: Patrik Faltstrom <[email-masked]>

On Mon, 7 Oct 1996, Larry Masinter wrote:
> 
> > We can provide multiple A records for www.purl.org, but there is no
> > way to do smart prioritization between the more and less capable
> > hosts.
> 
> Why is this easier to do with NAPTR records than A records? Could we
> extend A records for HTTP servers so that you could do smart
> prioritization? ("If this is such a great idea, why save it for
> URNS"). 

The A record does not have a priority. MX-records do have that,
A records does not. You can not change the spec of A-records.

> > Depending on how the multiple A records are provided, there may also
> > be an obscure error that truncates the list of responses. The NAPTR
> > proposal will not suffer that error.
> 
> Is this a bug in the implementation of DNS? If the bug is there for A
> records, why wouldn't it be there for NAPTR records? Is this a design
> error that could be fixed?

This is just how things are implemented, especially when one
start using things that is not really DNS (NIS for example).
To be able to get around this problem -- we need a new resource
record type.
 
> > The real point of the NAPTR proposal is that it gives us a way to cope
> > with names, such as www.purl.org, that should be long-lived but aren't.
> 
> I don't understand why www.purl.org must have a shorter lifetime than
> any NAPTR name. You just vow to not reassign the name. If you can't do
> that with ".org", then pick a new top level domain.

Because the NAPTR record is the second abstraction level you really
need to be able to handle renaming of resources on the net. You also
can handle other protocols than HTTP which makes the NAPTR proposal
(NAPTR records together with SRV records) much more long lived.
 
> The DNS entries for resolver.purl.org already give you all the
> indirection you need. Why add more?

No, it does not give the information about priority and
protocol that is needed. We should not at all of the meetings
we had last year still be talking about NAPTR records which
forces everyone to change their resolvers if it was not needed.

The PURL methods do work for locating HTTP servers, IF you
name your resources exactly the way you point it out Larry,
i.e. that you do have a special namespace allocated for the
PURL names which does not have anything in common with the
hostname namespace.

When coming to this conclusion, we did also think about the
need for different resolution protocols (to handle the case
when someone is running a resolution service for a publisher,
and who is responsible for what in the resolution process)
and especially for priority between different servers with
different access protocols. I.e. PURLS solves tons of
problems with URLs that we have today, but it does not solve
the requirements in the URN requirements paper.

We have some people thinking that not even the NAPTR proposal
does that -- and we have not claimed that NAPTR solves the
URN naming problem. The URN's do solve the problem by later
having functionality of grandfathering the NAPTR scheme
into some other scheme later on -- when DNS is replaced :-)

> >We are not talking about the same thing. One could assign PURLs such as
> >   ftp://purl.foo.com/whatever
> >but once that PURL is assigned, we have to use FTP to resolve it. Since
> >the NAPTR draft doesn't require the resolution protocol to be embedded in
> >the identifier, we are free to offer multiple resolution protocols and to
> >change them over time. This is an important point, since over time we
> >will have increasingly efficient protocols.
> 
> In the "PURL" method, the "resolution" is accomplished by using HTTP
> to talk to the resolution service and (if what you do is a GET)
> getting back a "303" response with a Location: header to do the
> URN->URL mapping.

This is exactly what one of the problems is. We think that DNS
that have been around for some years is more stable than HTTP.

What do you do with PURLs if HTTP is replaced with something else?
Or if you have one primary server handling FTP and a secondary
one using HTTP and a third HTTP++ (whatever that can be?). In
the PURL scheme you _HAVE_ to have one primary protocol which is
served on each one of the servers:

  ftp://purl.acme.com/  ===>  Use FTP to connect to purl.acme.com

  purl.acme.com. IN A foo.acme.com
  purl.acme.com. IN A bar.acme.com

Both of these servers _have_ to have ftp access 
and both _have_ to have the ability (if needed) 
to give a redirect to the protocol which is 
needed to access that perticular server.

In the NAPTR proposal, each one of foo.acme.com 
and bar.acme.com can, part from being 
prioritized also use different access protocols.                             

> > For PURLs, we not only have to know the identifier, we have to know
> > what resolver to contact. We end up with things like:
> >   http://purl.bowker.com/isbn/1-56604-355-7
> >   http://purl.agicoa.com/isan/9961231234567891
> 
> oh no! Clearly you only want to use the resolver.purl.org name.

Or rather:

http://purl.bowker.se/isbn/91-46-14140-5
http://purl.bowker.se/isbn/46-14140-5
http://purl.bowker.se/isbn/4614140-5
http://purl.bowker.se/isbn/46141405
http://purl.bowker.se/isbn/9146141405

...which all might have to be supported if you use HTTP as access
protocol (with todays HTTP backends which PURL uses).

If you allow a different "ISBN-resolution-protocol" to be the
access for ISBNs, which we can handle in the NAPTR proposal,
we solving naming problems on the right level of the stack.

   Patrik

To: [email-masked]
Cc: [email-masked]
Subject: [URN] advantages of NAPTR over PURLs
From: Larry Masinter <[email-masked]>
Date: Mon, 7 Oct 1996 19:10:09 PDT
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

Ron & I have been offline, but I thought I'd move the discussion back
onto list... It's not that I'm a PURL bigot, but I think www.purl.org
has an interesting simplicity and that pushing on PURL vs. NAPTR
really gets at what the _actual_ advantages might be.

Re replication:

> We can provide multiple A records for www.purl.org, but there is no
> way to do smart prioritization between the more and less capable
> hosts.

Why is this easier to do with NAPTR records than A records? Could we
extend A records for HTTP servers so that you could do smart
prioritization? ("If this is such a great idea, why save it for
URNS"). 

> Depending on how the multiple A records are provided, there may also
> be an obscure error that truncates the list of responses. The NAPTR
> proposal will not suffer that error.

Is this a bug in the implementation of DNS? If the bug is there for A
records, why wouldn't it be there for NAPTR records? Is this a design
error that could be fixed?

> The real point of the NAPTR proposal is that it gives us a way to cope
> with names, such as www.purl.org, that should be long-lived but aren't.

I don't understand why www.purl.org must have a shorter lifetime than
any NAPTR name. You just vow to not reassign the name. If you can't do
that with ".org", then pick a new top level domain.

>>Well, www.purl.org can migrate, too, can't it?
> I'm sorry I wasn't clear. By "migrating a resolver" I mean moving it onto
> a machine that cannot be identified by the domain name that was used
> for the earlier resolver, and terminating service on the original machine,
> even if that machine remains up and running for other purposes.
> So, no, www.purl.org cannot migrate according to my definition. (Better
> terminology welcomed).

If you want to be able to migrate PURL resolvers to other machines,
you just assign a new IP address to the PURL resolver name. This is
completely flexible. Don't use that DNS name for anything other than
PURL resolution service. E.g., call it <scheme>.resolver.purl.org
instead of just www.purl.org.

The DNS entries for resolver.purl.org already give you all the
indirection you need. Why add more?

>>> and the resolution process allows multiple protocols
>>The URL in the 'Location:' header of purl.org's response need not be
>>'http:'.

>We are not talking about the same thing. One could assign PURLs such as
>   ftp://purl.foo.com/whatever
>but once that PURL is assigned, we have to use FTP to resolve it. Since
>the NAPTR draft doesn't require the resolution protocol to be embedded in
>the identifier, we are free to offer multiple resolution protocols and to
>change them over time. This is an important point, since over time we
>will have increasingly efficient protocols.

In the "PURL" method, the "resolution" is accomplished by using HTTP
to talk to the resolution service and (if what you do is a GET)
getting back a "303" response with a Location: header to do the
URN->URL mapping.

If you want "PURL" resolution to not be embedded in the URN, then
define a translation from URN notation to PURL by, for example,
defining that:

	  <scheme>:<docid>

        is (currently) implemented by translating it into

          http://<scheme>.resolver.purl.org/<docid>'

and now you have a resolution implementation that doesn't embed the
resolution protocol in the name. Of course, you are free to offer
other resolution protocols besides HTTP and change them over time.
E.g., define that

  isbn:1-56604-355-7
	=>  http://isbn.resolver.purl.org/1-56604-355-7
  issn:1077-2014
	=>  http://issn.resolver.purl.org/1077-2014

> For PURLs, we not only have to know the identifier, we have to know
> what resolver to contact. We end up with things like:
>   http://purl.bowker.com/isbn/1-56604-355-7
>   http://purl.agicoa.com/isan/9961231234567891

oh no! Clearly you only want to use the resolver.purl.org name.

Larry

From: [email-masked] (Leslie Daigle)
Date: Mon, 7 Oct 1996 11:55:15 -0400
To: Ron Daniel <[email-masked]>, Larry Masinter <[email-masked]>
Subject: Re: [URN] Re: The WG is putative no longer...
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked] (Leslie Daigle)

I think Larry brings up an important point about needing to make it clear
what _this_ approach has going for it.  

[Ron wrote:]
> I will make the mention of the benefits of the approach less subtle, but
> I don't think the NAPTR spec should get into a comparison with PURLs. NAPTR
> resolution achieves the benefits mentioned above because it follows the
> principle of separating the design of the namespace from the resolution
> procedure. This principle is part of the framework draft, and any
> resolution mechanism that follows it can achieve equivalent benefits.
> So, if we *have* to do a comparison with PURLs, I think the framework
> draft is the place to do so.

I agree that the NAPTR document is not the place to discuss PURLs directly 
  -  the purpose of the NAPTR document is to describe an implementation,
not make a salespitch for the approach.

If the framework document is written will, it definitely should make
clear what problems this approach solves that PURLs do not solve by
themselves.  This is, perhaps, best addressed by making it increasingly
clear what problem this approach does solve. 

Leslie.

-- 

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

                                                      Leslie Daigle
   "Learn and live."                                  Vice President, Research
                                                      Bunyip Information Systems
                          -- ThinkingCat              (514) 875-8611
                                                      [email-masked]
------------------------------------------------------------------------------

Date: Sun, 06 Oct 1996 21:45:37 -0600
To: Larry Masinter <[email-masked]>
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] Re: The WG is putative no longer...
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke Larry Masinter (at least at 11:30 AM 10/5/96 PDT)
>Ron & Michael:
>
>I'd like somewhere (either in this document or a separate one) for an
>elaboration of what this mechanism brings over and above the simple
>mechanism already deployed by www.purl.org.

Hi Larry,

I think the benefits of the NAPTR mechanism over PURLs are in the
document, but they are not pulled together into a "benefits" section
and there is no comparison with PURLs.

The draft currently mentions that the NAPTR approach allows the resolvers,
as well as the resources, to be replicated. (It is mentioned as a subtle
but important point). The resolver(s) can also be migrated, and the
resolution process allows multiple protocols. Migration is not explicitly
mentioned.
If memory serves, the abstract and intro call out the multi-protocol
capability as a benefit, and also mention the ability to accommodate
a variety of namespaces. I see all of these as advantages of the NAPTR
approach over PURLs. (Backward compatibility with existing browsers
is the advantage of PURLs over the NAPTR approach).

I will make the mention of the benefits of the approach less subtle, but
I don't think the NAPTR spec should get into a comparison with PURLs. NAPTR
resolution achieves the benefits mentioned above because it follows the
principle of separating the design of the namespace from the resolution
procedure. This principle is part of the framework draft, and any
resolution mechanism that follows it can achieve equivalent benefits.
So, if we *have* to do a comparison with PURLs, I think the framework
draft is the place to do so.

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: Sun, 06 Oct 1996 15:44:20 -0400
From: Michael Mealling <[email-masked]>
Organization: Network Solutions
To: Larry Masinter <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [URN] Re: The WG is putative no longer...
Sender: [email-masked]
Reply-To: Michael Mealling <[email-masked]>

Larry Masinter wrote:
> I'd like somewhere (either in this document or a separate one) for an
> elaboration of what this mechanism brings over and above the simple
> mechanism already deployed by www.purl.org.
> 
> Could you please elaborate either in this document or a companion?

Umm...I'm writing several at this point. You'll have to remind me which
one your talking about. If you're talking about the NAPTR draft then I 
doubt if it'd be appropriate since that's just an implementation of the
framework. I think it would be more appropriate for the framework
document myself. Is that an acceptable place to approach the subject?

-MM

-- 
------------------------------------------------------------------------------
Michael Mealling	| 505 Huntmar Park Drive       | Phone:  (703)742-0400
Software Engineer	| Herndon, VA 22070	       | Fax:    (703)742-9552
Network Solutions	| <URL:http://www.netsol.com>  | [email-masked]

To: [email-masked]
Cc: [email-masked]
Subject: Re: [URN] Re: The WG is putative no longer...
From: Larry Masinter <[email-masked]>
Date: Sat, 5 Oct 1996 11:30:50 PDT
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

Ron & Michael:

I'd like somewhere (either in this document or a separate one) for an
elaboration of what this mechanism brings over and above the simple
mechanism already deployed by www.purl.org.

Could you please elaborate either in this document or a companion? 

Thanks,

Larry

 

Date: Fri, 04 Oct 1996 13:05:37 -0600
To: [email-masked]
From: Ron Daniel <[email-masked]>
Subject: [URN] Re: The WG is putative no longer...
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Putative no more ... yippie!

Thus spoke Leslie Daigle (at least at 11:09 AM 10/4/96 -0400)
> [...] documents that need to be revised/created [...]

>	. The NAPTR document.  Ron promises another draft real soon.

The current state of the draft is appended. The previous version is
available from the Internet-drafts index as draft-daniel-naptr-01.txt.
The working version will be available from
    http://www.acl.lanl.gov/URN/naptr.txt

I'd like some discussion before submitting it to the Internet drafts
editor. (I also need to clean up the references section).

---------

INTERNET DRAFT                                                  Ron Daniel
draft-ietf-urn-naptr-00.txt                 Los Alamos National Laboratory
                                                          Michael Mealling
                                                   Network Solutions, Inc.
                                                              4 Oct., 1996

[revisions since draft-daniel-naptr-01.txt:
  1) Added substitution expression grammar and reference to POSIX Extended
     Regular Expressions instead of sentence saying "sed(1)-style substitution
     expression".
  2) Added "hdl" and "rwhois" to list of known protocols.
  3) Minor editing cleanups.
  4) Added "P" flag
  5) Added N2Ns
  6) Changed order of "repl" and "regexp" fields to ease computation of
     compressed vs. uncompressed NAME sizes.
  7) Changed name to reflect new WG status of URN effort.
  8) Updated Michael's contact info
  9) Added brief security consideration about checking regexps instead of
     blindly executing them.
 10) Added note about why trailing '.' does not appear in examples but
     should be in the zone files.
 11) Clarified stuff on provision of additional info
 12) Clarified wildcard example
]

              Resolution of Uniform Resource Identifiers
                     using the Domain Name System

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

    This document is an Internet-Draft.  Internet-Drafts are working
    documents of the Internet Engineering Task Force (IETF), its
    areas, and its working groups.  Note that other groups may also
    distribute working documents as Internet-Drafts.
  
    Internet-Drafts are draft documents valid for a maximum of six
    months and may be updated, replaced, or obsoleted by other
    documents at any time.  It is inappropriate to use Internet-
    Drafts as reference material or to cite them other than as
    ``work in progress.''
  
    To learn the current status of any Internet-Draft, please check
    the ``1id-abstracts.txt'' listing contained in the Internet-
    Drafts Shadow Directories on ftp.is.co.za (Africa),
    nic.nordu.net (Europe), munnari.oz.au (Pacific Rim),
    ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast).

    This draft expires 7 April, 1997.

Abstract:
=========

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

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

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

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

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

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

The developers of various URN proposals have held a series of meetings,
resulting in a compromise known as the Knoxville framework. The major
principle behind the Knoxville framework is that any name assignment
hierarchy should be separate from the resolution hierarchy. This is in
marked contrast to the Domain Name System, where the two are identical.
Readers are referred to [2] for background on the Knoxville framework and
for additional information on the context and purpose of this proposal.

For the reasons mentioned earlier, we want to be able to resolve URNs
and URLs within the same framework. For the short term, DNS is the
obvious candidate for the resolution framework, since it is widely
deployed and understood. However, it is not appropriate to use DNS to
maintain information on a per-resource basis. First of all, DNS was
never intended to handle that many records.  Second, the limited record
size is inappropriate for catalog information.  Third, we have the
requirement mentioned above about grandfathering of other name
systems.

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

Locating a resolver through the rewrite procedure may take multiple
steps, but the beginning is always the same. Every URI has a
colon-delimited prefix.  NAPTR resolution begins by taking this prefix,
appending the well-known suffix ".urn.net", and querying the DNS for NAPTR
records at that domain name.  Based on the results of this query, zero
or more additional DNS queries may be needed to locate resolvers for the
URI. Three brief examples of this procedure are given in the next
section.

The NAPTR RR provides the level of indirection needed to keep the naming
system independent of the resolution system, its protocols, and services.
Coupled with the new SRV resource record proposal[3] there is also the
potential for replicating the resolver on multiple hosts, overcoming some
of the most significant problems of URLs. This is an important and subtle
point. Not only do the NAPTR and SRV records allow us to replicate
the resource, we can replicate the resolvers that know about the replicated
resource. Preventing a single point of failure at the resolver level
is a significant benefit. 

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

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

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

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

The key fields in the NAPTR RR are order, preference, service, flags,
regexp, and replacement:
* The order field specifies the order in which records MUST be processed
  when multiple NAPTR records are returned in response to a single query.
  A naming authority may have delegated a portion of its namespace to
  another agency. Evaluating the NAPTR records in the correct order is
  necessary for delegation to work properly.
* The preference field specifies the order in which records SHOULD
  be processed when multiple NAPTR records have the same value of "order".
  This field lets a service provider specify the order in which resolvers
  are contacted, so that more capable machines are contacted in preference
  to less capable ones.
* The service field specifies the resolution protocol and resolution
  service(s) that will be available if the rewrite specified by the
  regexp or replacement fields is applied. Resolution protocols are
  the protocols used to talk with a resolver. They will be specified in
  other documents. Resolution services are operations such as
  N2R (URN to Resource), N2L (URN to URL), N2C (URN to URC), etc.
  These are discussed in the URN Framework document[2], and their behavior
  in a particular resolution protocol will be given in the specification for
  that protocol.
* The flags field contains modifiers that affect what happens in the
  next DNS lookup, typically for optimizing the process.
* The regexp field is one of two fields used for the rewrite rules, and is
  the core concept of the NAPTR record. The regexp field is a String
  containing a sed-like substitution expression. (The actual grammar for
  the substitution expressions is given later in this draft). The
  substitution expression is applied to the original URN to determine the
  next domain name to be queried. The regexp field should be used when the
  domain name to be generated is conditional on information in the URI. If
  the next domain name is always known, which is anticipated to be a common
  occurrence, the replacement field should be used instead.
* The replacement field is the other field that may be used for the rewrite
  rule. It is an optimization of the rewrite process for the case where the
  next domain name is fixed instead of being conditional on the content of
  the URI. The replacement field is a domain name (subject to compression if
  a DNS sender knows that a given recipient is able to decompress names in
  this RR type's RDATA field). If the rewrite is more complex than a simple
  substitution of a domain name, the replacement field should be set to . and
  the regexp field used. 

Note that the client applies all the substitutions and performs all
lookups - this is not handled in DNS servers. Note also that there is no
reason to provide values in both the replacement and regexp field. Only
one should be specified. If a value is specified in both, the replacement
name MUST be used and the regexp string MUST be ignored. It is the belief
of the developers of this document that regexps should rarely be used. The
replacement field seems adequate for the vast majority of situations. Regexps
are only necessary when portions of a namespace are to be delegated to
different resolvers.

Example 1
---------

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

                 urn:duns:002372413:annual-report-1997

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

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

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

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

Since our example RR specified the "s" flag, it was terminal. Our
next action is to lookup SRV RRs for _rcds._udp.isi.dandb.com, which
will tell us hosts that can provide the necessary resolution service. 
That lookup might return:

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

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

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

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

Example 2 
---------

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

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

*.gatech.edu IN NAPTR
;;       order pref flags service           regexp  replacement
  IN NAPTR 100  50  "s"  "z3950+N2L+N2C"    ""   _z3950._tcp.gatech.edu.
  IN NAPTR 100  50  "s"  "rcds+N2C"          ""   _rcds._udp.gatech.edu.
  IN NAPTR 100  50  "s"  "http+N2L+N2C+N2R"  ""   _http._tcp.gatech.edu.

(Unlike all the other example records in this draft, the one above
is the contents of a zone file, not the response received by the
client).

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

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

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

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

Example 3
---------

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

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

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

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

This expression returns everything after the first double slash and
before the next slash or colon. Backslashes are needed to escape the
forward slash since the forward slash character is what separates the
components of the substitution expression. (Recall from the previous
example that in the zone file, this pattern actually needs to be
entered as "/.*\\/\\/([^\\/:]+)/\\1/i").  Applying this pattern to the
URL extracts "www.foo.com". Looking up NAPTR records for that might
return:

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

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

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

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

    Domain TTL Class Order Preference Flags Service Regexp Replacement 

where:

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

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

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

       At this time only three flags, "S", "A", and "P", are defined. "S"
       means that the next lookup should be for SRV records instead of NAPTR
       records. "A" means that the next lookup should be for A records. The
       "P" flag says that the remainder of the resolution shall be carried
       out in a Protocol-specific fashion, and we should not do any more
       DNS queries.
       
       The remaining alphabetic flags are reserved. The numeric flags may be
       used for local experimentation. The S, A, and P flags are all mutually
       exclusive, and resolution libraries MAY signal an error if more
       than one is given. We anticipate that multiple flags will be allowed
       in the future, so implementors MUST NOT assume that the flags field
       can only contain 0 or 1 characters.

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

           service_field = [ [protocol] *("+" rs)]
           protocol      = "rcds" / "http" / "hdl" / "rwhois"
           rs            = "N2L" / "N2Ls" / "N2R" / "N2Rs" / "N2C"
                         / "N2Ns" / "L2R" / "L2Ns" / "L2Ls" / "L2C"

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

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

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

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

       The actual format of the service request and response will be
       determined by the resolution protocol, and is the subject for other
       documents. Protocols need not offer all services.

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

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

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

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

  subst_expr   = "/"   ere  "/"  repl  "/"  *flags
  ere          = POSIX Extended Regular Expression (see [9], section 2.8.4)
  repl         = dns_str /  backref / repl dns_str  / repl backref
  dns_str      = ...... which RFC can I cite for this? 1035 seems obsolete .....
  backref      = "\" 1POS_DIGIT
  flags        = "i" 
  DNS_CHAR     = "_" / "0" / "1" / ... / "9" / "a" / ... / "z"
  POS_DIGIT    = "1" / "2" / ... / "9"  ; 0 is not an allowed backref value

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

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

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

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

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

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

Usage
=====

Pseudocode for a client routine using NAPTRs is given below:

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

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

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

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

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

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

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

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

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

The authors would like to thank Keith Moore for all his consultations
during the development of this draft. We would also like to thank Paul
Vixie for his assistance in debugging our implementation, and his answers
on our questions.

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

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

[2] draft-daigle-urn-framework-00.txt "A Uniform Resource Naming
    Framework", Leslie Daigle and Patrik Faltstrom, June, 1996.

[3] draft-gulbrandsen-dns-rr-srvcs-03.txt  " A DNS RR for specifying the
    location of services (DNS SRV)",  Arnt Gulbrandsen and Paul Vixie,
    March 1996.

[4] Paul Vixie, personal communication.

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

[6] Keith Moore, personal communication.

[7] Keith Moore, "Resource Cataloging and Distribution Service", ???
    (insert as [4], renumber the others?)

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

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

[10] ... rwhois spec ...
[11] ... encoding resolution service requests in HTTP...

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

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

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

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

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

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

    This draft expires 7 April, 1997.

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: Leslie Daigle <[email-masked]>
Date: Fri, 4 Oct 1996 11:09:59 -0400
To: [email-masked]
Subject: [URN] The WG is putative no longer...
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Well, the rate of subscription to the mailing list has dropped off, so it
seems like a good time to get the ball rolling under our new _official_
guise as the IETF URN Working Group.  I've attached the announcement in
case anyone missed it -- it includes our official charter. (I will also
be updating the web page, http://www.bunyip.com/research/ietf/urn-ietf/,
just as soon as I get a few minutes to swap in the scanty shreds of basic
HTML that I know...).

After the Montreal BOF, the draft WG charter was submitted for consideration
by the Area Directors, and refinements (per the usual criteria of 
achievability and viability) followed.  The resultant charter holds the
spirit of what was in the Montreal BOF, but has the further benefit of
addressing a few issues raised by the IESG.  [Hey, I wasn't _at_ the
discussions, I can blissfully assume it was only a few  :-)  ]

To recap briefly, what we have on the table is an abstract framework, or
architecture, for URN resolution.  It identifies basic system components 
and their responsibilities in the process, with a view to being able to
accommodate as many namespaces as possible, while applying the minimal
amount of interoperability infrastructure necessary to be able to call
these names "uniform".  

Separately, we also have one concrete proposal for one system that implements
this abstract architecture -- the NAPTR work.  This is a flagship implementation
to demonstrate that URNs can work _today_.   

Also, we have a separate paper that was prepared independently of the above
work, which provides some important considerations for any system attempting
to do URN resolution -- some of which have already been discussed (at the
BOF, on this list, etc).

The purpose of this working group, then, is to refine the description of
the abstract framework, see one system specified (NAPTR), and enough component
pieces to demonstrate the concept.  

To that end, there are 3 documents that need to be revised/created nownow:

	. The framework document.  This document needs to be fleshed
	  out.

	. The NAPTR document.  Ron promises another draft real soon.

	. The syntax document.  Any volunteers to write up what should be
	  a very short document outlining the components of the URN syntax?

Anyone who wishes to volunteer, send me an e-mail.  

In general, the documents that we're chartered to write are as follows:

URN Framework document:

	Overview of the basic components necessary to support this approach
	to URN resolution/management.  In addition to sketching out the
	basic architecture, this includes descriptions of the minimal
	requirements of the components (including namespaces).

NAPTR proposal:

	A specific proposal for an implementation of the approach.

Syntax document:

	The URN syntax, so that we have agreement about what is opaque
	and what is not.  This should be a _real_ short document.

N2L/N2R/etc document:

	What gets returned upon reslution of URNs.

New Namespace document:

	While the Framework document lays out the requirements of namespaces,
	each namespace that will be used in URNs needs to be formally
	described in terms of how it meets the requirements, and how it
	is used in the URN space.

	The first step, then, is to present a sample new namespace (e.g.,
	"inet").

Grandfathered Namespace document:

	One of the goals of URNs is to be able to support existing 
	namespaces.  Thus, we need to demonstrate the feasibility by
	writing out the spec for including one such existing namespace
	in URN form.

While we get rolling on refinements of the system documents, it's worth
determining which new/old namespaces we'll address (and volunteers!).

That's pretty much it, and the layout of the work ahead...  Sound like a plan?

Cheers!
Leslie.

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

Uniform Resource Names (urn)
----------------------------
 
 Chair(s):
     Leslie Daigle <[email-masked]>
     John Curran <[email-masked]>
 
 Applications Area Director(s): 
     Keith Moore  <[email-masked]>
     Harald Alvestrand  <[email-masked]>
 
 Area Advisor
     Harald Alvestrand  <[email-masked]>
 
 Mailing lists: 
     General Discussion:[email-masked]
     To Subscribe:      [email-masked]
         In Body:       In body of message: subscribe urn-ietf
     Archive:           ftp://ftp.bunyip.com/pub/mailing-lists/urn-ietf.archive
 
Description of Working Group:
 
The goal of this working group is to define both a Uniform Resource
Name (URN) framework and an initial set of components that fit this
framework.

URNs are persistent identifiers for information resources.  The output
of this Working Group will comply with RFC 1737, which defines URNs and
gives requirements for them.  The framework will define the mechanics
for enabling global scope, persistence, and legacy support requirements
of URNs; requirements for namespaces to support this structure will
also be defined.   Although the framework will allow URNs to be defined
that vary in terms of degree of scalability and persistance, ensuring
"user friendliness" of all resultant identifiers is beyond the scope of
this group.

This WG will define the framework for URNs, at least one resolution
registry system, and at least one namespace.  RFCs describing
additional material will also be developed (per the milestones,
below).

Input documents: 

 o A Framework for the Assignment and Resolution of Uniform Resource
   Names <draft-daigle-urnframework-00.txt>

 o Resolution of Uniform Resource Identifiers using the Domain Name
   System <draft-daniel-naptr-01.txt>

 o Requirements for URN Resolution Systems
   <draft-girod-urn-res-require-00.txt>

 Goals and Milestones: 
 
   Oct 96       Submit revision of URN Framework document as Internet-Draft.   

   Oct 96       Submit revised version of the NAPTR proposal as an 
                Internet-Draft.                                                

   Oct 96       Submit Syntax document as an Internet-Draft.                   

   Oct 96       Submit document detailing the N2L/N2R/etc resolution results as
                an Internet-Draft.                                             

   Nov 96       Submit document describing one (new) namespace as an 
                Internet-Draft.                                                

   Dec 96       Submit paper outlining grandfathering one namespace into the 
                framework as an Internet-Draft.                                

   Dec 96       Submit revised N2L/N2R/etc document as an Internet-Draft.      

   Dec 96       Submit NAPTR proposal to IESG as Experimental RFC.             
                Submit Framework document to IESG for publication as an RFC.   
                Submit syntax paper to IESG for publication as an RFC.         

   Feb 97       Submit revised new Namespace document as Internet-Draft.       

   Feb 97       Submit revised grandfather namespace document as 
                Internet-Draft.                                                

   Feb 97       Submit N2L/N2R/etc document to IESG for publication as RFC.    

   Mar 97       Submit grandfathered namespace paper to IESG for publication as
                RFC.                                                           
                Submit new namespace proposal to IESG for publication as RFC.  

-- 

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

                                                      Leslie Daigle
   "Learn and live."                                  Vice President, Research
                                                      Bunyip Information Systems
                          -- ThinkingCat              (514) 875-8611
                                                      [email-masked]
------------------------------------------------------------------------------

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

                                                      Leslie Daigle
   "Learn and live."                                  Vice President, Research
                                                      Bunyip Information Systems
                          -- ThinkingCat              (514) 875-8611
                                                      [email-masked]
------------------------------------------------------------------------------