Subject: Re: [URN] URN resolution requirements and framework
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked]
Date: Fri, 29 Nov 1996 18:13:46 -0800 (PST)

I trust the following will not be taken as a rotten egg or
a tomato (much less a gas-green tomato):

Summary:  The case for unfriendly/meaningless/semantic-free naming
is made much more strongly in the framework doc than in RFC 1737,
and inappropriately so in view of recent discussions on the issue
here.  Please suppress.  Details:

| The Uniform Resource Identifier Working Group defined a naming
| architecture, as demonstrated in a series of three RFCs 1736[RFC1736],
| 1737{RFC1737}, and 1738[RFC1738].  Although several further documents
| are needed to complete the description of that architecture, it
| incorporates three core functions often associated with "naming":
| identification, location, and mnemonics or semantics.  Names may provide
| the ability to distinguish one resource from another, by distinguishing
| their "names".  Names may help to provide access to a resource by
| including "location" information.  Lastly, names may have other semantic
| or mnemonic information that either helps human users remember or figure
| out the names, or include other semantic information about the resource
| being named.  The URI working group concluded that there was need for
| persistent, globally unique identifiers, distinct from location or other
| semantic information; these "names" provide identity, in that if two of
| them are "the same" (under some simple rule of canonicalization), they
| identify the same resource.  Furthermore, the group decided that these
| "names" were generally to be for machine, rather than human consumption.

Where does it say that in the RFCs you refer to?  I find in RFC 1737
only the assertion that URNs should be machine-parseable.  There is
a weak sentence claiming that on the assumption that semantic drift
is a problem for names, naming authorities should be discouraged from 
using meaningful names (actually, names that employ information about
the resource; meaningful names are not advised against *per se*).
That's far short of what you're saying here, now.

| One can imagine a variety human-friendly naming (HFN) schemes supporting
| different suites of applications and user communities.  These will need
| to provide mappings to URNs in tighter or looser couplings, depending on
| the namespace.  It is these that will be mnemonic, content-full, and
| perhaps mutable, to track changes in use and semantics.  They may

Or they will be URNs themselves.  I can imagine that, too. 
This is a document on URNs, not HFNs.  The general mechanism of
"hints" can cover HFNs; there is no need to assert that the future
will instantiate your views on meaningful naming.  Especially if
consensus is desired.

The argument below, about URLs, is not about separation of semantics 
from identification, as claimed, it's about the different utilities of 
naming and pointing.

| Today we see the problem most clearly with the use of URLs for
| identification.  When a web page moves, its URL becomes invalid.
| Suppose such a URL is embedded in some page, stored in long term
| storage.  There are three possible outcomes to this scenario.  One
| possibility is that the client is left high and dry with some message
| saying that the page cannot be found.  Alternatively, a "forwarding
| pointer" may be left behind, in the form of an explicit page requesting
| the client to click on a new URL.  Although this will allow the client
| to find the intended page, the broken link cannot be fixed because the
| URL is embedded in a file outside of the client's control.  A third
| alternative is that the target server supplies an HTTP redirect so that
| the new page is provided for the client automatically.  In this case,
| the client may not even realize that the URL is no longer correct.  The
| real problem with both of these latter two situations is that they only
| work as long as the forwarding pointer can be found at the old URL.

So far, so good.  And no mention of semantics.

| Semantics, in this case location information, was embedded in the
| identifier, and the resolution system was designed to depend on the
| semantics being correct.  There are few cases in which we can expect

That's one way of thinking of it; it depends on the URL and the resolution
system.  This is not a strong argument that it's semantics that make
URLs fragile;  "http://192.240.3.1/nnnnn/zzzzz" is just as fragile.

| semantics of any sort to remain valid for a long time, but in many cases
| references need to have long lifespans.  Most documents are only useful
| while their references still function.

You are arguing that semantic drift in naming is so great that it
affects some appreciable number of documents during their useful
lifetime.  I don't buy it.  Take out the semantics part and you
have a good argument for why we need URNs; isn't that why it's
here?  What follows by way of "postulation re scope of evolution" 
might better be replaced with a less controversial example just
as apt to the point.  Or just leave it out:  these aliases are
nothing but hints, right?

| We expect the evolution to separation of semantics from identification
| to move along at least three paths.  The first will be to develop
| temporary aliases to capture the semantics currently embedded in
| identifiers.  This will require additional translation, but it will
| allow for the development of semantics-free URNs.  Second, we expect
| locally shared or private aliases to arise, again supported by a
| translation mechanism and allowing for the long-term storage of global,
| semantics-free URNs.  Such an aliasing scheme may be used to permit
| local aliases for named resources as well as to present these aliases to
| users in lieu of the URNs themselves.  Lastly, we expect there may be a
| development of global aliases.  These will be more user friendly "names"
| that would be shared on a much larger scale, and might be defined in
| some global registry.  This may include trademarked names as well as
| names in extremely common use.  As with the other alias systems, a
| facility for translation is needed.  However, in this case, since the
| system of aliases is of global scope, the translation facility will be
| very slow if each time an alias is translated it needs to query a
| centralized or even reasonably distributed global registry.  In order to
| achieve acceptable speeds, the translation facility will need to
| maintain a local cache, possibly in cooperation with other nearby alias
| caches.  Clearly this is all postulation at present, but it is provided
| here to demonstrate some of the scope of evolution for which we must be
| prepared.

That it may be, but it is also declaring a position on human-friendly
naming that we do not agree upon.  Stu Weibel gave us good advice:
take no position on the issue.

| In summary, the requirements in the area of evolvability are:
|    * To support evolution of mechanisms, specifically for
|       a) a growing set of URN schemes;
|       b) new local URN resolution schemes;
|       c) new authentication schemes;
|       d) alternative UDS schemes active simultaneously;
|    * To support and encourage the evolution toward the separation of
|      global identification from short-lived, locally useful, or human
|      friendly semantics;

"To permit" is sufficient; or, in the language used in every other
point in this list, "To support".

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: Fri, 29 Nov 1996 16:42:08 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: Leslie Daigle <[email-masked]>
Cc: Ryan Moats <[email-masked]>, URN mailing list <[email-masked]>
Subject: Re: [URN] Collecting open issue information on the syntax draft...
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

On Fri, 22 Nov 1996, Leslie Daigle wrote:

> [Ryan brought up:]
> > 4. human readability for new namespaces: MUST/SHOULD?
> 
> If that is the case, I would propose the following change to the syntax
> draft:
> 
> > 3. Support of existing legacy naming systems and new naming systems
> 
>    > URN-aware applications MAY accept as input other resource identifiers
>    > from existing legacy namespaces.  If such identifiers contain
>    > characters that are not members of the URN character set specified in
>    > section 2.2, the identifier MUST be translated to canonical format as
>    > discussed in section 2.2.
> > 
>    > Some existing name spaces that have the properties of the URN-space
>    > contain some human-significant components, and these exist in a wide
>    > variety of languages.  However, URNs are NOT intended to convey
>    > information that is significant to humans.  While the translation
>    > rule in section 2.2 is provided for existing namespaces, new
>    > namespaces, as part of their registration documentation, MUST define
>    > a discipline for assigning new URNs that does not simplify the
>    > generation of human-significant names.
> 
>  would become:
> 
> 
> 3. Support of existing legacy naming systems and new naming systems
> 
>    Any namespace (existing or newly-devised) that is proposed as a 
>    URN-namespace and fulfills the criteria of URN-namespaces must
>    be expressed in this syntax.  If names in these spaces contain
>    characters other than those defined for the URN character set,
>    they must be translated into canonical format as discussed in
>    section 2.2.

I can only support Leslie's proposal (just change "spaces" on
line 3 to "name spaces" and "canonical format" to "canonical form".)

Regards,	Martin.

Date: Thu, 28 Nov 1996 19:37:49 +0100 (MET)
From: "Martin J. Duerst" <[email-masked]>
To: Ryan Moats <[email-masked]>
Cc: URN mailing list <[email-masked]>
Subject: Re: [URN] Collecting open issue information on the syntax draft...
Sender: [email-masked]
Reply-To: "Martin J. Duerst" <[email-masked]>

On Fri, 22 Nov 1996, Ryan Moats wrote:

> Folks-
> 
> I've been going back over the open issues with the syntax draft
> and trying to ensure that I have all of them before I start thinking
> about slides for San Jose.  

> When does a URN end?
> ---------------------------------------
> 
> It has also been pointed out to me that the syntax draft does not indicate
> when a URN ends.  Some statement should be added to indicate this
> situation.  My current preference is to state that a "On the line, the
> URN ends with an octet that is not a member of the URN charset",
> or something like that, but what about other formats?

If you think about SGML public identifiers, which are quite long,
or if you consider narrow columns in newspapers, having all of
an URN on one line may not be possible.
You may find a solution in draft-fielding-url-syntax-00.txt,
but maybe there is none (I quickly scanned it and didn't find
any).

Regards,	Martin.

Date: Wed, 27 Nov 1996 13:18:25 -0700
To: [email-masked]
From: Ron Daniel <[email-masked]>
Subject: [URN] some more NAPTR edits
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Hi,

I've been looking some more at security for NAPTR resolution and
think there may be times when people will want to provide
encrypted info in a NAPTR record. I'm considering some
changes to the draft to accomodate this - the main part of those
changes is appended. I'll wait until after San Jose to
actually make the edits to the draft and resubmit, because
these changes may be controversial.

Regards,
Ron
===============
Flags

A String giving flags to control aspects of the rewriting. Flags are
characters from the set [0-9A-Z]. The case of the alphabetic
characters is not significant. Multiple flags may appear in the flags
field. The flags A-Z are reserved, 0-9 are available for local
experimentation.

At this time there are 5 defined flags: A, S, P, R and E. S, A, and P
all indicate that the NAPTR is terminal and the next lookup should
be for A records, SRV records, or protocol-known records, respectively.
The A, S, and P flags are mutually exclusive.

The "R" flag indicates that the regexp field is to be treated
as a Raw string, not as a substitution expression. The interpretation
to be placed on that string will be set by other flags. When the "R"
flag is given, there MUST be a value in the regexp field. There MAY
be a value in the replacement field, in which case that shall be
the next domain name to be contacted. The "R" flag may be combined
with one of the "A", "S", or "P" flags. Specifying the "R" flag is
the only time it is not an error to have a value in both the regexp
and replacement fields.

The "E" flag specifies that the regexp field holds an encrypted string.
The "R" flag must be specified if the "E" flag is given. Further details
on the encryption protocol will be specified in subsequent releases of
this draft.
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, 26 Nov 1996 03:37:05 -0500
To: Larry Masinter <[email-masked]>
From: Towsner <[email-masked]>
Subject: Re: [URN] Persistence as part of URN framework
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Towsner <[email-masked]>

At 8:36am -0500 11/26/96, Larry Masinter wrote:
># All I wanted was an *optional* persistence value to be possible, so that the
># URN resolution service could indicate the longevity of the resolver (not the
># URN), at least until the longevity was extended once the people managing it
># were willing to commit to a longer running service.
>
>...
>
># No-one seems to be able to get their head round the fact that such expiry
># times are meaningless if you don't know how long you will be able to resolve
># URNs which end up pointing to HTTP, but might point to another scheme later
># to keep them alive. I think the problem is that people just aren't thinking
># in terms of how much the world will change in the decades ahead. All I'm
># trying to propose is a way to avoid having to poll for broken resolution
># services in the future.
>
># I give up.
>
>No URN resolution protocol that doesn't explicitly deal with the
>issues of what happens when providers quit, merge, or split can
>seriously claim to address URN requirements.
>
>A protocol can be marked as 'Experimental', but even Experimental
>drafts can be marked to clearly indicate what parts of the problem
>they're not handling. The experiment then can help determine how
>serious, in practice, the problem really is.
	I think some type of persistance check is important.  The ability
to mark information as transient should definately be part of the URN
framework.

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

Date: Tue, 26 Nov 1996 03:34:47 -0500
To: Ron Daniel <[email-masked]>, Fisher Mark <[email-masked]>, urn-ietf <[email-masked]>
From: Towsner <[email-masked]>
Subject: Re: [URN] Collecting open issue information on the   syntaxdraft...
Sender: [email-masked]
Reply-To: Towsner <[email-masked]>

>What I want to
>see first is the use of internationally standardized namespaces such
>as ISBN for on-line access to books, ISSN/SICI for access to magazine,
>journal, and newspaper articles; ISAN for access to video programs and
>movies; ISWC/ASCAP/BMI identifiers for access to music; UPC for access
>to product descriptions, etc. National Standards bodies, such as ANSI,
>and industry associations, such as the EIA, may also have developed
>namespaces we could support.
>
>The Fortune 500 already make use of one or more of these namespaces
>for particular purposes (especially UPC).

	From what I've read of the proposals, it seems to me that URN's are
not intended as a replacement for URL's.  They are intended to be used to
locate *resources,* such as product descriptions or documents.  URL's are
capable of locating some company's web page, URN's, however, are better
suited for locateing RFC 112 anywhere on the internet.

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

Date: Tue, 26 Nov 1996 13:00:09 -0700
To: Bob Briscoe <[email-masked]>
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] Persistence as part of URN framework
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke Bob Briscoe (at least at 10:27 AM 11/26/96 +0000)

>[...] No-one seems to be able to get their head round the fact that [...]

I'm trying to understand your point, and am sorry that its taking
so much time. Lets try again.

>All I wanted was an *optional* persistence value to be possible,

Because of the limitations on DNS response sizes, there is a strong
incentive not to put in any fields that are not needed. If we can
agree that what you are asking for is necessary functionality not
achievable by other means, then we will modify the NAPTR proposal to
allow it. But I have not yet been convinced on that point. In fact,
during the course of preparing this reply, I am more firmly of the
view that the combination of DNS TTLs and the "Expires:" header of
the HTTP resolution protocol (and equivalant features in other
protocols) can achieve enough of what you are asking for that a
seperate "lifetime" field is not justified.

Let me try again to state what I think you are asking for and why. Then I
will explain what it won't achieve. Finally I will explain what it
will achieve beyond the combo of DNS TTL and "Expires:"-type info, and
why I think the additional benefit is not significant.

What I think you want:
=======================
A way to determine the minimum remaining lifetime of a resolver without
contacting that resolver to ask it. In other words, a new "lifetime"
field in the NAPTR record.

Why I think you want it:
========================
In an earlier message you indicated that one application of such a
capability would be to automate the maintenance of links in HTML-like
resources without continual polling, where a poll would probably be the
wasteful operation of fetching the resource then throwing it away. In
another message you said that this information will help in the migration
from one resolution protocol to another.

Why what you are asking for does not achieve at least some of
what you want:
===========================================================
Imagine that today (11/26/96) a customer signs a contract
with a Resolution Service Provider (RSP) for one year's worth of service.
You seem to be asking that the RSP be capable
of updating their NAPTR record to indicate that the HTTP resolver they
run will be available until at least 11/26/97. But of course,
new customers come along and sign new contracts, again for a year's
service. The NAPTR record could be continually updated to reflect that
the RSP is now contractually bound to provide the HTTP resolver for
a year after the most recent agreement with a customer. But why? It
does not mean that the the original customer's URNs will still be
resolvable there. Their contract was only for one year. Maybe they
have decided to contract with a different RSP that can offer the spiffy
new X2Y service.

This is why I think that a special "lifetime" field in the NAPTR
record does not achieve what you want from the "link maintenence" example.
If I write a paper and use a URN to link to someone else's resource, the
lifetime of the resolver does not necessarily tell me the lifetime of
their resolution info on that resolver. However, if I go ahead and ask
the resolver about that particular URN (assuming the approach in the HTTP
Conventions draft), the HTTP Expires: header can be used to provide
the detailed information on just how long one particular URN will
continue to be resolvable on one particular resolution server under
a particular resolution protocol. (This will be the minimum of the
time remaining on that customer's contract, the time until the
resolution service provider wants to scrap a particular resolution
protocol, and the time remaining on the resolution service provider's
contract with whoever they got their domain name from). When that
time has expired I can try to resolve the name again and see what
happens.

What it *would* achieve over existing capabilities and why I think
the additional benefit is not significant:
=================================================================
>I've been off-line with Ron Daniel who is happy that schemes such as HTTP
>which have expiry headers can get this information to you once you have
>resolved how to speak to HTTP.
>
>No-one seems to be able to get their head round the fact that such expiry
>times are meaningless if you don't know how long you will be able to resolve
>URNs which end up pointing to HTTP, but might point to another scheme later
>to keep them alive. I think the problem is that people just aren't thinking
>in terms of how much the world will change in the decades ahead. All I'm
>trying to propose is a way to avoid having to poll for broken resolution
>services in the future.

Let's look at a case where a resolution service provider (RSP) wants to
swap from HTTP to some other resolution protocol - Z39.50 for example.
We will also look at a couple of clients and how the swap affect them.

RSP:
----
When the RSP starts offering HTTP_based resolution, they might say
"OK, we will try this HTTP thing for 6 months as see how it goes".
Their N2L, N2C, ... scripts generate an Expires: header that clocks
down to that 6 month deadline. The NAPTR record for their HTTP-based
resolver has a TTL that is considerably shorter - 1 week perhaps -
to allow them to change the resolution services offered during the
initial experimental period with only the week's advance notice.

Client 1:
---------
Somewhere along the way, a smart link manager is given a URN and
starts to resolve it. It gets the Expires: header from the RSP's
HTTP-based resolver and caches the expiry data with the URN. Its
job as a "smart" link manager will be to recheck the availability of
the resource and flag an error when it is no longer resolvable. It
should do this in the least intrusive fashion possible.

RSP:
----
Sometime later, the RSP decides that they don't like the HTTP-based
approach and want to switch to a Z39.50-based approach. They will
wait until the 6-month period expires before killing off the HTTP
daemon, but in the meantime they bring up their Z39.50-based server and
install a NAPTR record to point to it. They also decide that they
want the NAPTR record for their HTTP server to disappear about a
week before the server itself is killed. So, they start clocking
down the TTL on the HTTP server's NAPTR record to that T=6mo-1week
deadline. At that time the HTTP daemon's NAPTR record will be removed. 

Client 2:
---------
Before that T=6mo-1week deadline, a different user agent attempts to
resolve the URN and now encounters 2 terminal NAPTR records - one for
the HTTP resolver and one for the Z39.50 resolver. It picks which one to
talk to based on the protocols it knows how to speak, the services they
offer, etc. If it knows both resolution protocols, it MAY make the
decision based on the TTL of the NAPTR records. Once it has contacted
the resolver the client will know how long the resolver guarrantees to
provide resolution for that URN. As shown in the "contract" example
earlier, this can be a considerably shorter time than the lifetime of
the resolver.

Client 1:
---------
The 6 month expiry date comes along, and a random time later the
link manager wants to recheck the URN. It starts a new NAPTR resolution
which, some number of DNS probes later, gets it to the terminal NAPTR
records. There is now a new terminal NAPTR record for a Z39.50-based
resolver, but no HTTP-based record. If the client knows Z39.50
it can do something like N2Ls and get new expiry info. If not,
it can use the TTL as a provisional expiry date and do more frequent checks
of the DNS records in the hopes that a known resolution protocol will
be offered at some time in the future. When it is, a more accurate
expiry time can be obtained.

Your request for a resolver lifetime field would modify the scenario
above in two places.

In the Client 2 paragraph, in the case where the client could
speak more than one of the resolution protocols that were offered,
it could make the decision on which one to pursue based on the resolver
lifetime rather than the NAPTR TTL. However, as the "contract" example
shows, this does not guarantee that the resolver with the longer
minimum guaranteed lifetime actually will resolve that resource
longer than the other one. So, the difference here does not seem
all that significant.

The second place where the "lifetime" field would change the scenario
is in the last step where Client 1 does not know the new protocol.
Rather than marking the URN provisionally resolvable with the NAPTR
TTL as the time for the next check, it could mark it provisionally
resolvable with the Z39.50 resolver lifetime as the time for the next
check. The TTL is never longer than the resolver lifetime, so the TTL
is the safer choice although it will lead to more "polls". In this
case, however, a "poll" is fairly light weight - some DNS probes to
see if the terminal NAPTR for the unknown protocol still exits (in which
case we retain the provisionally resolvable status and check back later)
or if new NAPTRs exist that we can follow. These could be introduced
at any time so checking for them periodically is not a bad thing.
Here again, the benefit from the new field does not seem so clear-cut that
I'm not convinced it is necessary.

I'm willing to be convinced of the necessity for such a field. However,
since it requires extra space in the records and changes to running
code you have to make a good case for it. If you can show me where the
combination of DNS TTLs and resolution-specific Expiry info does not
provide enough info to handle an important case, and the new field would,
I'll change the spec.

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, 26 Nov 1996 11:50:00 -0500
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Subject: [URN] resending
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

Don't know what happened, but here's the whole document...Thanks to
those of you who pointed this out to me.

			Karen

______________________________

Internet Draft                                          Karen R. Sollins
draft-ietf-urn-req-frame-00.txt                                  MIT/LCS
Expires May 26, 1997                                   November 26, 1996

	Requirements and a Framework for URN Resolution Systems

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

1. Introduction

The purpose of this document is to lay out the engineering criteria for
what we will call here a URN-resolution-service discovery service (UDS).
__________

Acknowledgments

Foremost acknowledgment for this document goes to Lewis Girod, as my
co-author on a previous URN requirements document and for his insightful
comments on this version of the document.  In addition, I recognize the
contributors to a previous URN framework document, the "Knoxville"
group.  There are too many of you to acknowledge here individually, but
thank you.  Finally, I must thank the contributors to the URN working
group mailing list ([email-masked]), for their animated discussions
on these and related topics.

URN Resolution Requirements                                      Page  1

This is a component of the realization of an information infrastructure.
In the case of this work, that infrastructure is to be available, "in
the Internet" or globally, and hence the solutions to the problems we
are addressing must globally scalable.  In this work, we are focussing
specifically on naming of resources and resolution of those names to the
exclusion of other problems such as typing, resource access and
availability, security of the resources, etc.  Those are all important
problems, but not part of this effort.

The Uniform Resource Identifier Working Group defined a naming
architecture, as demonstrated in a series of three RFCs 1736[RFC1736],
1737{RFC1737}, and 1738[RFC1738].  Although several further documents
are needed to complete the description of that architecture, it
incorporates three core functions often associated with "naming":
identification, location, and mnemonics or semantics.  Names may provide
the ability to distinguish one resource from another, by distinguishing
their "names".  Names may help to provide access to a resource by
including "location" information.  Lastly, names may have other semantic
or mnemonic information that either helps human users remember or figure
out the names, or include other semantic information about the resource
being named.  The URI working group concluded that there was need for
persistent, globally unique identifiers, distinct from location or other
semantic information; these "names" provide identity, in that if two of
them are "the same" (under some simple rule of canonicalization), they
identify the same resource.  Furthermore, the group decided that these
"names" were generally to be for machine, rather than human consumption.
One can imagine a variety human-friendly naming (HFN) schemes supporting
different suites of applications and user communities.  These will need
to provide mappings to URNs in tighter or looser couplings, depending on
the namespace.  It is these that will be mnemonic, content-full, and
perhaps mutable, to track changes in use and semantics.  They may
provide nicknaming and other aliasing, relative or short names, context
sensitive names, descriptive names, etc.  The URI naming architecture as
described in the introductions to RFCs 1736 and 1737 lays out three
sorts of components to the naming architecture: identifiers called
Uniform Resource Names (URNs), locators called Uniform Resource Locators
(URLs) and semantic meta-information called Uniform Resource
Characteristics (URCs).  This document focusses on part of the problem
of the translation from URN to URL and/or URC.

Within the URI community there has been a concept used frequently that
for lack of a better term we will call a _hint_.  A hint is something
that helps in the resolution of a URN.  Examples of hints are: 1) the
name of a resolution service that may further resolve the URN, 2) the
address of such a service, 3) a location at which the resource was
previously found.  The defining feature of hints is that they are only
hints; they may be out of date, temporarily invalid, or only applicable
within a specific locality.  They do not provide a guarantee of access,
but they probably will help in the resolution process.  Wemust assume
that most resolutions of URNs will be provided by the use of locally
stored hints, because maintaining a database of globally available,
completely up-to-date location information is infeasible for performance
reasons.  There are a number of circumstances in which one can imagine
that hints become invalid, either because a resource has moved or
because a different URN resolution service has taken over the

URN Resolution Requirements                                      Page  2

responsibility for resolution of the URN.  Hints may be found in a
variety of places.  It is generally assumed that a well engineered
system will maintain a set of hints for each URN at each location where
that URN is found.  In addition, for those situations in which those
hints found locally fail, a well-engineered system will provide a
fall-back mechanism for discovering further hints.  It is this fall-back
mechanism, a UDS, that is being addressed in this document.  As with all
hints, there can never be a guarantee that access to a resource will be
available to all clients, even if the resource is accessible to some.
However, a UDS is expected to work with reasonably high reliability,
and, hence, may result in increased response time.  The remainder of
this document falls into three sections.  The first identifies several
sets of assumptions underlying this work.  The next lays out the
requirements for a URN-resolution-service discovery service.  This
section is probably the most critical of the document, because it is
this that provides the metric for whether or not a proposed scheme for a
UDS is adequate or not.  For the reader short on time, each of the three
major subsections of the requirements section concludes with a summary
list of the requirements identified in that section.  The final section
of the document lays out a framework for such UDSs.  The purpose of this
last section is to bound the search space for UDS schemes.  One must be
careful not to assume that because a UDS scheme fits within the
framework that it necessarily meets the requirements.  As will be
discussed further in this last section, designing within the framework
does not guarantee compliance, so compliance evaluation must also be
part of the process of evaluation of a scheme.

2. Assumptions

Based on previous internet drafts and discussion in both the URN BOFs
and on the URN WG mailing list, three major areas of assumptions are
apparent: longevity, delegation, and independence.  Each will be
discussed separately.

The URN requirements state that a URN is to be a "persistent
identifier".  It is probably the case that nothing will last forever,
but in the time frame of resources, users of those resources, and the
systems to support the resources, the identifier should be considered to
be persistent or have a longer lifetime than those other entities.
There are two assumptions that are implied by longevity of URNs:
mobility and evolution.  "Mobility" assumes that.  everything will move
over the life of a URN.  For example, resources will move from one
machine to another, because individual machines have a much shorter
lifetime than resources, generally measured in a number of years less
than a decade.  Owners of resources may move and wish their resources to
follow them.  The services themselves will move.  "Evolutions" assumes
that the supporting infrastructure will evolve.  This may take the form
of entirely new transport protocols or new versions of existing
protocols.  Furthermore, services such as storage services may evolve;
it is even possible that within a human lifetime the Unix file system
model may no longer be in use!  Clearly there will be evolution of and
improvement in supporting authentication and security mechanisms.  These
are only examples.  In general, we must assume that almost any piece of
the supporting infrastructure of URN resolution will evolve.  In order
to deal with both the mobility and evolution assumptions that derive

URN Resolution Requirements                                      Page  3

from the assumption of longevity, we must assume that users and their
applications can remain independent of these mutating details of the
supporting infrastructure.

The second and third assumptions are two forms of modularity, delegation
and isolation.  The delegation assumption is that an entity may
partition and pass off some of its authority or responsibility.  One of
those responsibilities is for assigning URNs; practically speaking,
there cannot be only a single authority for assigning URNs.  We expect
that there will be a multi-tiered naming authority delegation.
Furthermore, it is difficult to imagine a non-partitioned and delegated
global UDS, meaning that hint discovery and resolution will be
partitioned and delegated.  In some UDS schemes, the delegation of
naming authority will form a basis for delegating the management and
dispensing of location information.

The third assumption is independence or isolation of one authority from
another and, at least to some extent from its parent.  Underlying much
of the thinking and discussion in the URI and URN working groups has
been the assumption that when a component delegates authority to another
component, the delegatee can operate in that domain independently of its
peers and within bounds specified by the delegation, independently of
the delegator.  This isolation is critically important in order to allow
for independence of policy and mechanism.

There are a number of more specific assumptions that fall under this
rubric of isolation.  First, we assume that the publisher of a resource
can choose resolution services, independently of choices made by others.
At any given time, the owner of a namespace may choose a particular URN
resolution service for that delegated namespace.  Such a URN resolution
service may be outside the UDS service model, and just identified or
located by the UDS service.  Second, it must be possible to make a
choice among UDS services, perhaps based on different underlying
internal architectures.  The reason that this is an assumption is that
there must be an evolutionary path through a sequence of core UDS
services.  Although at any given time there is likely to be only one or
a small set of such services, the number is likely to increase during a
transition period from one architecture to another.  Thus, it must be
assumed that clients can make a choice among a probably very small set
of UDSs.  Third, there must be independence in the choice about levels
and models of security and authenticity required.  This choice may be
made by the owner of a naming subspace, in controlling who can modify
hints in that subspace.  A naming authority may delegate this choice to
the owners of the resources named by the names it has assigned.  There
may be limitations on this freedom of choice in order to allow other
participants to have the level of security and authenticity they
require, for example, in order to maintain the integrity of the UDS
infrastructure as a whole.  Fourth, there is an assumption of
independence of choice of the rule of canonicalization of URNs within a
namespace, limited by any restrictions or constraints that may have been
set by its parent namespace.  This is a choice held by naming
authorities over their own subnamespaces.  Rules for canonicalization
will be discussed further in the framework section below.  Thus, there
are assumptions of independence and isolation to allow for delegated,
independent authority in a variety of domains.

URN Resolution Requirements                                      Page  4

The modularity assumptions of delegation and isolation imply
independence of decision and implementation, leading to a
decentralization that provides a certain degree of safety from denial of
service.  Based on these these assumptions in conjunction with that of
longevity and those for URLs and URNs as detailed in RFCs 1736 and 1737,
we can now turn to the requirements for a URN services delegation
service.

3. Requirements

The requirements applying to a URN-resolution-service discovery service
or UDS center around three important design goals: evolvability,
usability, and security and privacy.  At its core the function of a UDS
is to provide hints for accessing a resource given a URN for it.  These
hints may range in applicability from local to global, and from
short-lived to long-lived.  They also may vary in their degree of
verifiable authenticity.  While it may be neither feasible nor necessary
that initial implementations support every requirement, every
implementation must support evolution to systems that do support every
requirement.

It is also important to note that there are other requirements, not
applicable specifically to a UDS that must also be met.  A whole URN
system will consist of namespaces, the resolution information for them,
and the mapping from names in the namespaces to resolution information
(or hints).  URN schemes must meet the requirements of RFC 1737.
Resolution information, to the extent it is expressed as URLs must meet
the requirements of RFC 1736.  But this does not tell the whole story.
Although the URN working group will identify several acceptable
namespaces and the rules binding them, such as how delegation occurs,
how it is expressed in the names, how and to what extent binding to hint
information will be constrained by the namespace, in the long run a
document will be needed to guide the evaluation criteria for acceptance
of new namespaces.  These are not included in the list of requirements
below because they are not requirements for a UDS, but rather for naming
schemes themselves.

3.1 Evolution

One of the lessons of the Internet that we must incorporate into the
development of mechanisms for resolving URNs is that we must be prepared
for change.  Such changes may happen slowly enough to be considered
evolutionary modifications of existing services or dramatically enough
to be considered revolutionary.  They may permeate the Internet universe
bit by bit, living side by side with earlier services or they may take
the Internet by storm, causing an apparent complete transformation over
a short period of time.  There are several directions in which we can
predict the need for evolution, even at this time, prior to the
deployment of any such service.  At the very least, the community and
the mechanisms proposed should be prepared for these.

First, we expect there to be additions and changes to the mechanisms.
The community already understands that there must be a capacity for new
URN schemes.  A URN scheme will define a set of URNs that meet the URN
requirements[RFC1737], but may have further constraints on the internal

URN Resolution Requirements                                      Page  5

structure of the URN.  The requirements document would allow for an
overall plan in which URN schemes are free to specify parts of the URN
that are left opaque in the larger picture.  In fact, a URN scheme may
choose to make public the algorithms for any such "opaque" part of the
URN.  For example, although it may be unnecessary to know the structure
of an ISBN, the algorithm for understanding the structure of an ISBN has
been made public.  Other schemes may either choose not to make their
algorithms public, or choose a scheme in which knowledge of the scheme
does not provide any significant semantics to the user.  In any case, we
must be prepared for a growing number of URN schemes.

Often in conjunction with a new URN scheme, but possibly independently
of any particular URN scheme, new resolution services may evolve.  For
example, one can imagine a specialized resolution service based on the
particular structure of ISBNs that improves the efficiency of finding
documents given their ISBNs.  Alternatively, one can also imagine a
general purpose resolution service that trades performance for
generality; although it exhibits only average performance resolving
ISBNs, it makes up for this weakness by understanding all existing URN
schemes, so that its clients can use the same service to resolve URNs
regardless of naming scheme.  In this context, there will always be room
for improvement of services, through improved performance, better
adaptability to new URN schemes, or lower cost.  In any case, new models
for URN resolution will evolve and we must be prepared to allow for
their participation in the overall resolution of URNs.

If we begin with one overall plan for URN resolution, into which the
enhancements described above may fit, we must also be prepared for an
evolution in the authentication schemes that will be considered either
useful or necessary in the future.  There is no single globally accepted
authentication scheme, and there may never be one.  Even if one does
exist at some point in time, there will always be threats to it, and so
we must always be prepared to move on to newer and better schemes, as
the old ones become too easily spoofed or guessed.

Lastly, in terms of mechanism, although we may develop and deploy a
single UDS scheme initially, we must be prepared for that top level
model to evolve.  Thus, if the UDS model supports an apparently
centralized (from a policy standpoint) scheme for inserting and
modifying authoritative information, over time we must be prepared to
evolve to a different model, perhaps one that has a more distributed
model of authority and authenticity.  If the model has no core but
rather a cascaded partial discovery of information, we may find that
this becomes unmanageable with an increase in scaling.  Whatever the
core of the model, we must be prepared for it to evolve with changes in
scaling, performance, and policy constraints such as security and cost.

Second, in addition to the evolution of resolution mechanisms, we expect
that the community will follow an evolutionary path towards the
separation of semantics from identification.  The URN requirements
document suggested this path as well, and there has been general
agreement in much of the community that such a separation is desirable.
This is a problem that the public at large has generally not understood.
Today we see the problem most clearly with the use of URLs for
identification.  When a web page moves, its URL becomes invalid.

URN Resolution Requirements                                      Page  6

Suppose such a URL is embedded in some page, stored in long term
storage.  There are three possible outcomes to this scenario.  One
possibility is that the client is left high and dry with some message
saying that the page cannot be found.  Alternatively, a "forwarding
pointer" may be left behind, in the form of an explicit page requesting
the client to click on a new URL.  Although this will allow the client
to find the intended page, the broken link cannot be fixed because the
URL is embedded in a file outside of the client's control.  A third
alternative is that the target server supplies an HTTP redirect so that
the new page is provided for the client automatically.  In this case,
the client may not even realize that the URL is no longer correct.  The
real problem with both of these latter two situations is that they only
work as long as the forwarding pointer can be found at the old URL.
Semantics, in this case location information, was embedded in the
identifier, and the resolution system was designed to depend on the
semantics being correct.  There are few cases in which we can expect
semantics of any sort to remain valid for a long time, but in many cases
references need to have long lifespans.  Most documents are only useful
while their references still function.

We expect the evolution to separation of semantics from identification
to move along at least three paths.  The first will be to develop
temporary aliases to capture the semantics currently embedded in
identifiers.  This will require additional translation, but it will
allow for the development of semantics-free URNs.  Second, we expect
locally shared or private aliases to arise, again supported by a
translation mechanism and allowing for the long-term storage of global,
semantics-free URNs.  Such an aliasing scheme may be used to permit
local aliases for named resources as well as to present these aliases to
users in lieu of the URNs themselves.  Lastly, we expect there may be a
development of global aliases.  These will be more user friendly "names"
that would be shared on a much larger scale, and might be defined in
some global registry.  This may include trademarked names as well as
names in extremely common use.  As with the other alias systems, a
facility for translation is needed.  However, in this case, since the
system of aliases is of global scope, the translation facility will be
very slow if each time an alias is translated it needs to query a
centralized or even reasonably distributed global registry.  In order to
achieve acceptable speeds, the translation facility will need to
maintain a local cache, possibly in cooperation with other nearby alias
caches.  Clearly this is all postulation at present, but it is provided
here to demonstrate some of the scope of evolution for which we must be
prepared.

A third evolutionary requirement is even more mechanical than the
others.  At any point in time, the community is likely to be supporting
a compromise position with respect to resolution.  We will probably be
operating in a situation balanced between feasibility and the ideal,
perhaps with policy controls used to help stabilize the service.
Ideally, the service would be providing exactly what the customers
wanted and they in turn would not request more support than they need.
Since we will always be in a situation in which some service provision
resources will be in short supply, some form of policy controls will
always be necessary.  For example, suppose hint entries are being
submitted in such volume that the hint servers are using up their excess

URN Resolution Requirements                                      Page  7

capacity and need more disk space.  An effective solution to this
problem would be a mechanism such as a pricing policy.  This pricing
policy has the dual effect of both encouraging conservative use of
resources and collecting revenue for the improvement and maintenance of
the system.  As technology changes and the balance of which resources
are in short supply changes, the mechanisms and policies for controlling
their use must evolve as well.

In summary, the requirements in the area of evolvability are:

   * To support evolution of mechanisms, specifically for
      a) a growing set of URN schemes;
      b) new local URN resolution schemes;
      c) new authentication schemes;
      d) alternative UDS schemes active simultaneously;
   * To support and encourage the evolution toward the separation of
     global identification from short-lived, locally useful, or human
     friendly semantics;
   * To support the development and deployment of pricing models to
     manage human behavior with respect to limited resources.

3.2 Usability and Feature Set Requirements

Usability can be evaluated from three distinct perspectives: those of a
publisher wishing to make a piece of information public, those of a
client requesting URN resolution, and those of the provider or manager
of resolution information.  We will separately address the usability
requirements from each of these three perspectives.

It is worth noting that there are two additional sorts of participants
in the whole naming process, as discussed in the URN WG.  They are the
naming authorities which choose and assign names, and the authors who
include URNs in their resources.  These two are not relevant to the
design of a UDS and hence are not discussed further here.

3.2.1 The Publisher

The publisher must be able to make URNs known to potential customers.
>From the perspective of a publisher, it is of primary importance that
URNs be correctly and efficiently resolvable by potential clients.
Publishers also stand to gain from long-lived URNs, since they increase
the chance that references continue to point to their published
resources.  The publisher must also be able to choose easily among a
variety of potential services that might translate URNs to location
information.  In order to allow for this mobility among resolution
services, the architecture for resolution services specified within the
IETF should not result in a scenario in which changing from one
resolution service to another is an expensive operation.

The publisher should be able to arrange for multiple access points to a
published resource.  For this to be useful, resolution services should
be prepared to provide different resolution or hint information to
different clients, based on a variety of information including location
and the various access privileges the client might have.  For example,
companies might arrange for locally replicated copies of popular

URN Resolution Requirements                                      Page  8

resources, and would like to provide access to the local copies only for
their own employees.  This is distinct from access control on the
resource as a whole, and may be applied differently to different copies.

The publisher should be able to provide both long and short term
information about accessing the resource.  Long term information is
likely to be such information as the long term location of the resource
or the location or identity of a resolution service with which the
publisher has a long term relationship.  One can imagine that the
arrangement with such a long term "authoritative" resolution service
might be a guarantee of reliability, resiliency to failure, and atomic
updates.  Shorter term information is useful for short term changes in
services or to avoid short lived congestion or failure problems.  For
example, if the actual repository of the resource is temporarily
inaccessible, the resource might be made available from another
repository.  This short term information can be viewed as temporary
refinements of the longer term information, and as such should be more
easily and quickly made available, but may be less reliable.

Lastly, the publishers will be the source of much hint information that
will be stored and served by the manager of the infrastructure.  Despite
the fact that many publishers will not understand the details of the UDS
mechanism, it must be easy and straightforward to install hint
information.  The publisher must be able not only to express hints, but
also to verify that what is being served by the manager is correct.
Furthermore, to the extent that there are security constraints on hint
information, the publisher must be able to both express them and verify
compliance to them easily.

3.2.2 The Client

>From the perspective of the client, simplicity and usability are
paramount.  Of critical importance to serving clients effectively is
that there be an efficient protocol through which the client can acquire
hint information.  Since resolving the name is only the first step on
the way to getting access to a resource, the amount of time spent on it
must be minimized.

Furthermore, it will be important to be able to build simple, standard
interfaces to the UDS so that both the client and applications on the
client's behalf can interpret hints and subsequently make informed
choices.  The client, perhaps with the assistance of the application,
must be able to specify preferences and priorities and then apply them.
If the ordering of hints is only partial, the client may become directly
involved in the choice and interpretation of them and hence they must be
understandable to that client.  On the other hand, in general it should
be possible to configure default preferences, with individual
preferences viewed as overriding any defaults.

>From the client's perspective, although URNs will provide important
functionality, the client is most likely to interact directly only with
human friendly names (HFNs).  As in direct human interaction (not
computer mediated), the sharing of names will be on a small,private, or
domain specific scale.  HFNs will be the sorts of references and names
that are easy to remember, type, choose among, assign, etc.  There will

URN Resolution Requirements                                      Page  9

also need to be a number of mechanisms for mapping HFNs to URNs.  Such
services as "yellow pages" or "search tools" fall into this category.
Although we are mentioning HFNs here, it is important to recognize that
HFNs and the mappings from HFNs to URNs is and must remain a separate
functionality from a UDS.  Hence, although HFNs will be critical to
clients, they do not fall into the domain of this document.

3.2.3 The Management

Finally, we must address the usability concerns with respect to the
management of the hint infrastructure itself.  What we are terming
"management" is a service that is distinct from publishing; it is the
core of a UDS.  It involves the storage and provision of hints to the
clients, so that they can find published resources.  It also provides
security to the extent that there is a commitment for provision of such
security; this is addressed below.

The management of hints must be as unobtrusive as possible. First, its
infrastructure (hint storage servers and distribution protocols) should
have as little impact as possible on other network activities.  It must
be remembered that this is an auxiliary activity and must remain in the
background.

Second, in order to make hint management feasible, there will need to be
a system for economic incentives and disincentives.  Recovering the cost
of running the system is only one reason for levying charges.  The
introduction of payments often has a beneficial impact on social
behavior.  It may be necessary to discourage certain forms of behavior
that when out of control have serious negative impact on the whole
community.  At the same time, payment policies should encourage behavior
that benefits the community as a whole.  Thus, for example, a small
one-time charge for authoritatively storing a hint will encourage
conservative use of hints.  If we assume that there is a fixed cost for
managing a hint, then the broader its applicability across the URN
space, the more cost effective it is.  That is, when one hint can serve
for a whole collection of URNs, there will be an incentive to submit one
general hint over a large number of more specific hints.  Similar
policies can be instituted to discourage the frequent changing of hints.
In these ways and others, cost effective behavior can be encouraged.

Lastly, symmetric to issues of usability for publishers, it must also be
simple for the management to configure the mapping of URNs to hints.  It
must be easy both to understand the configuration and to verify that
configuration is correct.  With respect to management, this requirement
may have an impact not only on the information itself but also on how it
is partitioned among network servers that collaboratively provide the
management service or UDS.  For example, it should be straightforward to
bring up a server and verify that the data it is managing is correct.
Since we are discussing a global and probably growing service,
encouraging volunteer participants requires that, as with the DNS, such
volunteers can feel confident about the service they are providing and
its benefit to both themselves and the rest of the community.

URN Resolution Requirements                                      Page 10

To summarize, the usability requirements fall into three areas based on
participation in hint management and discovery:

   * The publisher
      a) URN to hint resolution must be correct and efficient;
      b) Publishers must be able to select among URN resolution
         services to locate their resources;
      c) Publishers must be able to arrange for multiple access points
         for their location information;
      d) Publishers must be able to provide for both long-lived and
         short-lived hints;
      e) It must be relatively easy for publishers to install and
         observer their hint information and any security constraints
         they need for their hints.
   * The client
      a) The interface to the UDS must be simple, effective, and
         efficient;
      b) The client and client applications must be able to understand
         the information stored in and provided by the UDS, in order
         to be able to make informed choices.
   * The management
      a) The management of hints must be as unobtrusive as possible,
         avoiding using too many network resources;
      b) A pricing scheme may be necessary to provide not only cost
         recovery, but also social incentives and disincentives to
         encourage certain sorts of behavior deemed necessary to meet
         other requirements;
      c) The configuration and verification of configuration of
         individual UDS servers must be simple enough not to
         discourage configuration and verification.

3.3 Security and Privacy Requirements

Although much of the information we are discussing in this document
might be considered "meta-information", there are some important
security and privacy concerns that must be addressed by a service
supporting that information.  By first considering the sorts of attacks
that are of concern, we can then focus on the security and privacy
issues that are important.  The reader will notice that integrity plays
less of a role here than might be expected.  To the extent that servers
provide access control, the information they manage will have certain
integrity guarantees.  Beyond that we must recognize that we are dealing
merely with hint information about the location of possibly interesting
resources.  Therefore we believe that the benefit of providing integrity
guarantees beyond those provided by the servers themselves does not
outweigh the cost.

Because the majority of the activity will be the distribution of hint
information, the threats of concern are those affecting the maintenance
of correct information to distribute and the availability of the sources
of information.  The first approach to URN resolution is to discover
local hints.  By being local, they will be as widely distributed as
possible.  The drawback of such wide distribution is the inability to
update them; therefore, they will become out of date with time.  An
alternative or backup mechanism would concentrate hint information in

URN Resolution Requirements                                      Page 11

servers, thus requiring that update information only be distributed to
these servers.  Hence the vulnerable points are the sources of the
information and the distribution network among them.  If one assumes
that there will be principals of some sort that are responsible for the
information about each URN entry in the URN resolution service, then one
major threat is an attacker that masquerades as a valid principal and
inserts incorrect information into the service.  A second threat vector
results from the fact that the service itself will be implemented by a
set of servers that collaborate and share the hint information critical
to their activities.  By masquerading as a valid server in this pool, an
attacker can both provide incorrect information to clients and provide
incorrect information to other servers, which those servers will then
distribute.  A third threat is that if the resolution service is too
centralized, service can be denied by a variety of network attacks
ranging from flooding the service with queries to causing various
network problems that will reduce access to the service.  The more
centralized a service is the more vulnerable is the community that
trusts it not to be compromised.  We can turn each of these into a
security goal.

* ACCESS CONTROL ON HINTS: There needs to be an authoritative version of
  each hint, and it must support change control limited only to those
  principals with the right to modify it.  The choice of who those
  principals are or whether they are unlimited must be made by the
  publisher of a hint. 

* SERVER AUTHENTICITY: Servers and clients must be able to learn the
  identity of the servers with which they communicate.  This will be a
  matter of degree and it is possible that there will be more
  trustworthy, but less accessible servers, supported by a larger
  cluster of less authenticatable servers that are more widely
  available.  In the worst case, if the client receives what appears to
  be invalid information, the client should assume that the hint may be
  inaccurate and confirmation of the data should be sought from more
  reliable but less accessible data.

* SERVER DISTRIBUTION: Broad availability will provide resistance to
  denial of service.  It is only to the extent that the services are
  available that they provide any degree of trustworthiness.  In
  addition, the distribution of services will reduce to vulnerability
  of the whole community, by reducing the trust put in any single
  server.  This must be mitigated by the fact that to the extent trust
  is based on a linked set of servers, if any one fails, the whole
  chain of trust fails; the more elements there are in such a chain,
  the more vulnerable it may become.

_Ensuring_ privacy for clients and publishers is in some respects
essentially impossible.  Fortunately, assuring a reasonable degree of
privacy for those who want it is possible.  The privacy of clients is
primarily threatened by packet sniffers and servers that log requests.
A server or a packet sniffer can without much difficulty record the
contents of queries as they pass by and compile the information into a
relation between URNs and clients.  This can be combatted by anonymizing
queries through a trusted, fairly local gateway, although it involves an

URN Resolution Requirements                                      Page 12

extra step and another potential bottleneck.  The additional step can be
mitigated by caching responses in the gateway, thus often avoiding the
need to forward requests beyond it.  A second alternative is to send
only partial queries.  As will be discussed further in the framework
section, there may be two reasons for transformation of a URN, first to
canonicalize it and second to extract the identity of another server to
which to send a further request.  This second alternative of sending
partial queries would be achieved by also extracting some partial URN to
further resolve at each stage.  This would not anonymize the queries,
but might make them more difficult to chain together into a complete
story for logging.

On the other hand, to the degree that the search process is distributed,
packet sniffing at a single point is less likely to reveal data about a
specific person, and is hence less threatening to privacy.  Furthermore,
if clients have flexibility in terms of the specific services they
choose to use, they can regularly switch services in the hopes of
foiling a packet sniffer watching their usual access point.

The privacy of publishers is much easier to safeguard.  Since they are
trying to publish something, in some situations privacy is probably not
desired.  However, publishers do have information that they might like
to keep private: information about who their clients are, and
information about what names exist in their namespace.  The information
about who their clients are may be difficult to collect depending on the
implementation of the resolution system.  For example, if the resolution
information relating to a given publisher is widely replicated, the hits
to _each_ replicated copy will need to be recorded.  Of course,
determining if a specific client is requesting a given name can be
approached from the other direction, by watching the client as we saw
above.

The other privacy issue for publishers has to do with access control
over URN resolution.  This issue is dependent on the implementation of
the publisher's authoritative URN resolution server.  URN resolution
servers can be designed to require proof of identity in order to be
issued resolution information; if the client does not have permission to
access the URN requested, the service denies that such a URN exists.  An
encrypted protocol can also be used so that both the request and the
response are obscured.  Encryption is possible in this case because the
identity of the final recipient is known (i.e. the URN server).

In summary, security and privacy requirements can be identified as some
degree of protection from threats:

   * It must be possible to create authoritative versions of a hint
     with access to modification privileges controlled;
   * It must be possible to determine the identity of servers or avoid
     contact with unauthenticated servers;
   * Broad availability of servers will reduce the thread to denial
     of service;
   * Client privacy is threatened by packet sniffing and server
     logging.  It is desirable to reduce these threats as much as
     possible;
   * It should be feasible for publishers to keep private certain

URN Resolution Requirements                                      Page 13

     information such as an overall picture of the resources they are
     publishing and the identity of their clients;
   * Publishers should be able to restrict access to the resolution of
     the URNs for the resources they publish, if they wish.

4. The Framework

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

The design of the framework is based on a simple assumption about the
syntax of a URN.  This assumed syntax is:

	URN:<NID>:<NSS>

where URN: is a prefix on all URNs, NID is the namespace identifier, and
NSS is the namespace specific string.  The prefix identifies each URN as
such.  The NID determines the general syntax for all URNs within its
namespace.  The NSS is probably partitioned into a set of delegated and
subdelegated namespaces, and this is probably reflected in further
syntax specifications.  In the more complex environments, each delegated
namespace will be permitted to choose the syntax of the variable part of
the namespace that has been delegated to it.  In simpler namespaces, the
syntax will be restricted completely by the parent namespace.  For
example, although the DNS does not meet all the requirements for URNs,
it has a completely restricted syntax, such that any further structuring
must be done only by adding further refinements to the left, maintaining
the high order to low order, right to left structure.  A delegated
syntax might be one in which a host is named by the DNS, but to the
right of that and separated by an "@" is a string whose internal
ordering is defined by the file system on the host, which may be defined
high order to low order, left to right.  Of course, much more complex
and nested syntaxes should be possible, especially given the need to
grandfather namespaces.  In order to resolve URNs, rules will be needed
for two reasons.  One is simply to canonicalize those namespaces that do
not fall into a straightforward (probably right to left or left to
right) ordering of the components of a URN, as determined by the
delegated naming authorities involved.  It is also possible that rules
will be needed in order to derive from URNs the names of UDS servers to
be used in stages.

The NID defines a top level syntax.  This syntax will determine whether
the NID alone or in conjunction with some extraction from the NSS (for
the top level naming authority name) to identify the first level server

URN Resolution Requirements                                      Page 14

to be contacted.  Each stage of the lookup either a new rule for
generating the strings used in yet another lookup (the strings being the
identify of another UDS server and possibly a string to be resolved if
it is different than the original URN) or a reference outside the UDS to
a private URN resolution service, sidestepping any furthere use of the
UDS scheme.  Figure 1 depicts this process.

                            URN:<NID><NSS>
                                 |
                                 |
                                 |
                                 |
                                 v
                       +-------------------+
                       |Global NID registry|
                       +-------------------+
                                 |
       	       	       	       	 |
                                 |
              (return rule or URN resolution service reference)
                                 |
                                 +----------------------------------+
                                 |                                  |
                       +->(apply rule to determine UDS server)	    |
		       |         |				    |
		       |         |				    |
		       |         |				    |
                       |    +----------+			    |
                       |    |UDS server|	  +-----------------+
                       |    +----------+	  |
                       |      |	  |		  v
 		       |      |	  |   (set of choices)
 		       |      |	  +----+----------(...)--------+
                       |   (rule)      |                       |
                       |      |	       |		       |
 		       |      |	       |		       |
 		       +------+	       |		       |
 			      	       v		       v
 				  +----------+		  +----------+
 				  |private   |		  |private   |
                                  |URN	     |            |URN	     |
                                  |resolution|		  |resolution|
                                  |service   |		  |service   |
 				  +----------+		  +----------+

        Figure 1: A UDS framework

There are several points worth noting about the UDS framework.  First,
it leaves open the determination of the protocols and data organization,
distribution and replication needed to support a particular UDS scheme.
Second, it leaves open the location of the computations engendered by

URN Resolution Requirements                                      Page 15

the rules.  Third, it leaves open the possibility that partitioning
(distribution) of the UDS database need not be on the same boundaries as
the name delegation.  This may seem radical to some, but if the
information is stored in balanced B-trees for example, the partitioning
may not be along those naming authority delegation boundaries.  Lastly,
it leaves open access to the Global NID Registry.  Is this distributed
to every client, or managed in widely distributed servers?  One concept
that has not been addressed in Figure 1 is that there may be more than
one UDS available at any given time, in order to allow for evolution to
new schemes.  Thus, the picture should probably look more like Figure 2.

                         URN:<NID>:<NSS>
                               |
        		       |
		   +-----------+-------(...)-------+
		   |				   |
		   |				   |
		   |				   |
		   v				   v
	 +---------------------+	+---------------------+
	 |Global NID registry 1|        |Global NID registry N|
	 +---------------------+        +---------------------+
                   .                               .
                   .                               .
                   .                               .

        Figure 2: More than one co-existing UDS scheme

If we are to support more than one co-existing UDS scheme, there will
need to be coordination between them with respect to storage and
propagation of information and modifications.  The issue is that
generally it should be assumed that all information should be available
through any operational UDS scheme.  One cannot expect potential
publishers to submit updates to N UDS schemes.  Hence there will need to
be a straightforward mapping of information from one to the other of
these schemes.  It is possible that that transformation will only go in
one direction, because a newer UDS service is replacing an older one,
which is not kept up to date, in order to encourage transfer to the
newer one.  Thus, at some point, updates may be made only to the newer
one and not be made available to the older one.  Such a situation should
probably be avoided, if possible.

This framework is presented in order to suggest to UDS scheme designers
a direction in which to start designing.  It is obvious to the reader
that adherence to this framework will in no way guarantee compliance
with the requirements or even assumption described in Sections 2 and 3.
These must be reviewed independently as part of the design process.
There is no single correct design that will meet these requirements.
Furthermore, it is assumed that preliminary proposals may not meet all
the requirements, but should be expected to itemized and justify any
lack of compliance.

URN Resolution Requirements                                      Page 16

5. References

[RFC1736] Kunze, J., "Functional Recommendations for Internet Resource
Locators", RFC 1736, February, 1995.

[RFC1737] Sollins, K. and Masinter, L., "Functional Requirements for
Uniform Resource Names", RFC 1738, December, 1994.

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

6. Contact information:

Karen Sollins
MIT Laboratory for Computer Science
545 Technology Sq.
Cambridge, MA 02139

Tel: +1 617 253 6006
Email: [email-masked]

This InternetDraft expires on May 26, 1997.

URN Resolution Requirements                                      Page 17


To: urn-ietf <[email-masked]>
Subject: Re: [URN] Collecting open issue information on the  syntaxdraft...
Date: Tue, 26 Nov 1996 16:43:46 +0000
From: Martin Hamilton <[email-masked]>
Sender: [email-masked]
Reply-To: Martin Hamilton <[email-masked]>

Ron Daniel writes:

| What I want to
| see first is the use of internationally standardized namespaces such
| as ISBN for on-line access to books, ISSN/SICI for access to magazine,
| journal, and newspaper articles; ISAN for access to video programs and
| movies; ISWC/ASCAP/BMI identifiers for access to music; UPC for access
| to product descriptions, etc. National Standards bodies, such as ANSI,
| and industry associations, such as the EIA, may also have developed
| namespaces we could support.

How about RFCs for starters ? :-)

Martin

To: IETF-Announce:;
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-req-frame-00.txt
Date: Tue, 26 Nov 1996 09:20:46 -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     : Requirements and a Framework for URN Resolution Systems 
       Author(s) : K. Sollins
       Filename  : draft-ietf-urn-req-frame-00.txt
       Pages     : 17
       Date      : 11/25/1996

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

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-req-frame-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-req-frame-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-req-frame-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-req-frame-00.txt

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

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

--OtherAccess--

--NextPart--

Date: Tue, 26 Nov 1996 08:46:35 -0700
To: Fisher Mark <[email-masked]>, urn-ietf <[email-masked]>
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] Collecting open issue information on the syntaxdraft...
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke Fisher Mark (at least at 08:03 AM 11/26/96 EST)

>I am curious as to how you see URNs being used.  From my perspective as an 
>Intranet service provider, I could well see URNs in use by at least (almost) 
>each Fortune 500 company, as well as many academic and research 
>organizations, with each one having their own namespace.

This is exactly what I do NOT want to see happen early on, although
such namespaces are going to occur in the fullness of time.

What I want to
see first is the use of internationally standardized namespaces such
as ISBN for on-line access to books, ISSN/SICI for access to magazine,
journal, and newspaper articles; ISAN for access to video programs and
movies; ISWC/ASCAP/BMI identifiers for access to music; UPC for access
to product descriptions, etc. National Standards bodies, such as ANSI,
and industry associations, such as the EIA, may also have developed
namespaces we could support.

The Fortune 500 already make use of one or more of these namespaces
for particular purposes (especially UPC).

Until we come up with the procedures for registering company-specific
namespaces and dealing with the inevitable conflicts over trademark-style
issues, I want to err on the side of caution.

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]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Persistence as part of URN framework
From: Larry Masinter <[email-masked]>
Date: Tue, 26 Nov 1996 05:36:16 PST
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

# All I wanted was an *optional* persistence value to be possible, so that the
# URN resolution service could indicate the longevity of the resolver (not the
# URN), at least until the longevity was extended once the people managing it
# were willing to commit to a longer running service.

...

# No-one seems to be able to get their head round the fact that such expiry
# times are meaningless if you don't know how long you will be able to resolve
# URNs which end up pointing to HTTP, but might point to another scheme later
# to keep them alive. I think the problem is that people just aren't thinking
# in terms of how much the world will change in the decades ahead. All I'm
# trying to propose is a way to avoid having to poll for broken resolution
# services in the future.

# I give up.

No URN resolution protocol that doesn't explicitly deal with the
issues of what happens when providers quit, merge, or split can
seriously claim to address URN requirements.

A protocol can be marked as 'Experimental', but even Experimental
drafts can be marked to clearly indicate what parts of the problem
they're not handling. The experiment then can help determine how
serious, in practice, the problem really is.

Larry

From: [email-masked] (Leslie Daigle)
Date: Tue, 26 Nov 1996 09:12:40 -0500
To: Fisher Mark <[email-masked]>, Ron Daniel <[email-masked]>, urn-ietf <[email-masked]>
Subject: Re: [URN] Collecting open issue information on the syntaxdraft...
Sender: [email-masked]
Reply-To: [email-masked] (Leslie Daigle)

[Mark Fisher wrote:]
> I am curious as to how you see URNs being used.  From my perspective as an 
> Intranet service provider, I could well see URNs in use by at least (almost) 
> each Fortune 500 company, as well as many academic and research 
> organizations, with each one having their own namespace.  Sounds like an 
> awful lot of work to me for those of us on the mailing list to have to vet 
> each of those namespaces...

In the running terminology, "a namespace" refers to a particular name
assignment/resolution structuring -- e.g., ISBNs might be "a
namespace".

While there will be some kind of overall governing of individual namespaces,
assignment of subspaces is expected/needed.  I think your examples are
really about individual companies/institutions/ISPs wanting to have
a piece of a space to control, adn that is definitely expected
(e.g., top-level domains are individually controlled and partitioned in
DNS; but the "owner" of a domain name can assign as many subdomains as
they want, subject to the rules of DNS, not the domain-assigner).

I think that, given one or two "inet"-type URN namespaces, what the
organizations you've cited will want is the ability to assign names
in (some part of) those spaces.

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: Fisher Mark <[email-masked]>
To: Ron Daniel <[email-masked]>, urn-ietf <[email-masked]>
Subject: Re: [URN] Collecting open issue information on the syntaxdraft...
Date: Tue, 26 Nov 96 08:03:00 EST
Encoding: 21 TEXT
Sender: [email-masked]
Reply-To: Fisher Mark <[email-masked]>

>I recommend that, for some time, new namespaces receieve standards-track
>review, rather like new URL schemes currently do. That review process
>is the place where we can address concerns such as limited longevity or
>legal liability due to the inclusion of particular attempts at
>"friendliness". The syntax draft does not have to address that issue one
>way or the other.

I am curious as to how you see URNs being used.  From my perspective as an 
Intranet service provider, I could well see URNs in use by at least (almost) 
each Fortune 500 company, as well as many academic and research 
organizations, with each one having their own namespace.  Sounds like an 
awful lot of work to me for those of us on the mailing list to have to vet 
each of those namespaces...

(The "Fortune 500", for non-U.S. listmembers, is the top 500 companies in 
the U.S. as rated by the U.S. magazine "Fortune".  Lots of namespaces to 
check out...)
======================================================================
Mark Leighton Fisher                   Thomson Consumer Electronics
[email-masked]                   Indianapolis, IN

Date: Tue, 26 Nov 1996 10:27:39 +0000
To: Fisher Mark <[email-masked]>
From: Bob Briscoe <[email-masked]>
Subject: Re: [URN] Persistence as part of URN framework
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]
Reply-To: Bob Briscoe <[email-masked]>

Mark,

Many apologies for such a long time replying. I had to get some work
delivered, which translates to "ignore mailing lists".

All I wanted was an *optional* persistence value to be possible, so that the
URN resolution service could indicate the longevity of the resolver (not the
URN), at least until the longevity was extended once the people managing it
were willing to commit to a longer running service.

If the people running the resolver weren't willing to think about
persistence, a default longevity value of 0 could be sent out in the NAPTR
records.

However, I can find no-one else who considers this important, so I'll drop out.

I've been off-line with Ron Daniel who is happy that schemes such as HTTP
which have expiry headers can get this information to you once you have
resolved how to speak to HTTP.

No-one seems to be able to get their head round the fact that such expiry
times are meaningless if you don't know how long you will be able to resolve
URNs which end up pointing to HTTP, but might point to another scheme later
to keep them alive. I think the problem is that people just aren't thinking
in terms of how much the world will change in the decades ahead. All I'm
trying to propose is a way to avoid having to poll for broken resolution
services in the future.

I give up.

Bob

At 09:53 07/11/96 EST, Fisher Mark wrote:
>
>>Using DNS TTL records for this is just broken; DNS TTLs are used
>>to limit caching of name->address mapping, and in the NAPTR proposal,
>>they should be a fraction of the time one expects to have advance
>>warning of a server relocation or mapping restructure.
>>Normal TTLs are on the order of 3 days, and are usually reduced to less
>>than 1 day before serious network reorganizations.
>
>And if you are changing your resolution services faster than that, you are 
>changing them too fast (IMHO).  Perhaps the key idea TimBL came up with in 
>devising the Web was that, unlike other hypertext systems (including the 
>Dexter model), links could be broken, i.e. nonfunctional.  This single idea 
>was perhaps above all others important in spreading the Web far and wide, as 
>perfectly reliable systems as difficult to construct (even for an 
>appropriately low value of "perfect").  Under the Dexter model, an 
>application will die or limp on after reporting an internal error upon 
>encountering a broken hyperlink.  In the Web, the UA just keeps surfing on 
>to the next link.
>
>All that URNs can do is assist in persistence; persistence itself must be 
>maintained outside the URN architecture, as persistence is ultimately a 
>political/economic quality, not a technical quality.  We would expect a BT 
>URN to persist because of our trust in BT, not because there is some 
>technical solution to persistence.  Persistence is assisted in URNs by the 
>ability to hand off resolution duties automagically to successor resolution 
>entities.  I would regard measures of persistence to be an optional but 
>necessary part of the metadata for a URN, not as mandatory metadata.  It is 
>quite possible that URN will see incredibly wide use, as much or more as 
>URLs are now ("every person a URN namespace owner").  Many of these 
>namespaces may just persist for a few years or months, with the owner not 
>caring about measures of persistence.  Persistence is ultimately up to the 
>creating/resolving entity(s).
>
>Uniqueness is an easier problem than persistence, although uniqueness has a 
>strong political/economic component.  One can certainly imagine the case of 
>URNs for government materials that, after they are first created for public 
>consumption, are found to be embarrassing to that government and the URNs 
>are silently, suddenly changed to refer to much more innocuous materials. 
> Uniqueness, also, is ultimately up to the creating/resolving entity.
>======================================================================
>Mark Leighton Fisher                   Thomson Consumer Electronics
>[email-masked]                   Indianapolis, IN
>
>

Date: Mon, 25 Nov 1996 12:05:22 -0500
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Subject: [URN] URN resolution requirements and framework
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

Hi!

Attached is the first draft of a proposed document on requirements and
a framework for URN resolution.  It is based on the internet drafts
presented at the URN BOF in Montreal separately on requirements
(without the discussion of various schemes) and the framework document
by Leslie, Patrik, and Renato.  I have added an additional preliminary
section on assumptions, which seems important in light of some of the
discussions on this list.  I've also tried to enhance the
requirements, again based on discussions and broaden the framework a
little, to make it less specific to the NAPTR proposal, in order to
extend its utility.

We will talk about it in San Jose, but in the meantime comments and
discussion (no rotten eggs or tomatoes, please:-) are welcome.

			Karen

PS: To the Americans on the list, have a nice Thanksgiving!
______________________________

Internet Draft                                          Karen R. Sollins
draft-ietf-urn-req-frame-00.txt                                  MIT/LCS
Expires May 26, 1997                                   November 26, 1996

	Requirements and a Framework for URN Resolution Systems

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

1. Introduction

The purpose of this document is to lay out the engineering criteria for
what we will call here a URN-resolution-service discovery service (UDS).
__________

Acknowledgments

Foremost acknowledgment for this document goes to Lewis Girod, as my
co-author on a previous URN requirements document and for his insightful
comments on this version of the document.  In addition, I recognize the
contributors to a previous URN framework document, the "Knoxville"
group.  There are too many of you to acknowledge here individually, but
thank you.  Finally, I must thank the contributors to the URN working
group mailing list ([email-masked]), for their animated discussions
on these and related topics.

URN Resolution Requirements                                      Page  1

This is a component of the realization of an information infrastructure.
In the case of this work, that infrastructure is to be available, "in
the Internet" or globally, and hence the solutions to the problems we
are addressing must globally scalable.  In this work, we are focussing
specifically on naming of resources and resolution of those names to the
exclusion of other problems such as typing, resource access and
availability, security of the resources, etc.  Those are all important
problems, but not part of this effort.

The Uniform Resource Identifier Working Group defined a naming
architecture, as demonstrated in a series of three RFCs 1736[RFC1736],
1737{RFC1737}, and 1738[RFC1738].  Although several further documents
are needed to complete the description of that architecture, it
incorporates three core functions often associated with "naming":
identification, location, and mnemonics or semantics.  Names may provide
the ability to distinguish one resource from another, by distinguishing
their "names".  Names may help to provide access to a resource by
including "location" information.  Lastly, names may have other semantic
or mnemonic information that either helps human users remember or figure
out the names, or include other semantic information about the resource
being named.  The URI working group concluded that there was need for
persistent, globally unique identifiers, distinct from location or other
semantic information; these "names" provide identity, in that if two of
them are "the same" (under some simple rule of canonicalization), they
identify the same resource.  Furthermore, the group decided that these
"names" were generally to be for machine, rather than human consumption.
One can imagine a variety human-friendly naming (HFN) schemes supporting
different suites of applications and user communities.  These will need
to provide mappings to URNs in tighter or looser couplings, depending on
the namespace.  It is these that will be mnemonic, content-full, and
perhaps mutable, to track changes in use and semantics.  They may
provide nicknaming and other aliasing, relative or short names, context
sensitive names, descriptive names, etc.  The URI naming architecture as
described in the introductions to RFCs 1736 and 1737 lays out three
sorts of components to the naming architecture: identifiers called
Uniform Resource Names (URNs), locators called Uniform Resource Locators
(URLs) and semantic meta-information called Uniform Resource
Characteristics (URCs).  This document focusses on part of the problem
of the translation from URN to URL and/or URC.

Within the URI community there has been a concept used frequently that
for lack of a better term we will call a _hint_.  A hint is something
that helps in the resolution of a URN.  Examples of hints are: 1) the
name of a resolution service that may further resolve the URN, 2) the
address of such a service, 3) a location at which the resource was
previously found.  The defining feature of hints is that they are only
hints; they may be out of date, temporarily invalid, or only applicable
within a specific locality.  They do not provide a guarantee of access,
but they probably will help in the resolution process.  Wemust assume
that most resolutions of URNs will be provided by the use of locally
stored hints, because maintaining a database of globally available,
completely up-to-date location information is infeasible for performance
reasons.  There are a number of circumstances in which one can imagine
that hints become invalid, either because a resource has moved or
because a different URN resolution service has taken over the

URN Resolution Requirements                                      Page  2

responsibility for resolution of the URN.  Hints may be found in a
variety of places.  It is generally assumed that a well engineered
system will maintain a set of hints for each URN at each location where
that URN is found.  In addition, for those situations in which those
hints found locally fail, a well-engineered system will provide a
fall-back mechanism for discovering further hints.  It is this fall-back
mechanism, a UDS, that is being addressed in this document.  As with all
hints, there can never be a guarantee that access to a resource will be
available to all clients, even if the resource is accessible to some.
However, a UDS is expected to work with reasonably high reliability,
and, hence, may result in increased response time.  The remainder of
this document falls into three sections.  The first identifies several
sets of assumptions underlying this work.  The next lays out the
requirements for a URN-resolution-service discovery service.  This
section is probably the most critical of the document, because it is
this that provides the metric for whether or not a proposed scheme for a
UDS is adequate or not.  For the reader short on time, each of the three
major subsections of the requirements section concludes with a summary
list of the requirements identified in that section.  The final section
of the document lays out a framework for such UDSs.  The purpose of this
last section is to bound the search space for UDS schemes.  One must be
careful not to assume that because a UDS scheme fits within the
framework that it necessarily meets the requirements.  As will be
discussed further in this last section, designing within the framework
does not guarantee compliance, so compliance evaluation must also be
part of the process of evaluation of a scheme.

2. Assumptions

Based on previous internet drafts and discussion in both the URN BOFs
and on the URN WG mailing list, three major areas of assumptions are
apparent: longevity, delegation, and independence.  Each will be
discussed separately.

The URN requirements state that a URN is to be a "persistent
identifier".  It is probably the case that nothing will last forever,
but in the time frame of resources, users of those resources, and the
systems to support the resources, the identifier should be considered to
be persistent or have a longer lifetime than those other entities.
There are two assumptions that are implied by longevity of URNs:
mobility and evolution.  "Mobility" assumes that.  everything will move
over the life of a URN.  For example, resources will move from one
machine to another, because individual machines have a much shorter
lifetime than resources, generally measured in a number of years less
than a decade.  Owners of resources may move and wish their resources to
follow them.  The services themselves will move.  "Evolutions" assumes
that the supporting infrastructure will evolve.  This may take the form
of entirely new transport protocols or new versions of existing
protocols.  Furthermore, services such as storage services may evolve;
it is even possible that within a human lifetime the Unix file system
model may no longer be in use!  Clearly there will be evolution of and
improvement in supporting authentication and security mechanisms.  These
are only examples.  In general, we must assume that almost any piece of
the supporting infrastructure of URN resolution will evolve.  In order
to deal with both the mobility and evolution assumptions that derive

URN Resolution Requirements                                      Page  3

from the assumption of longevity, we must assume that users and their
applications can remain independent of these mutating details of the
supporting infrastructure.

The second and third assumptions are two forms of modularity, delegation
and isolation.  The delegation assumption is that an entity may
partition and pass off some of its authority or responsibility.  One of
those responsibilities is for assigning URNs; practically speaking,
there cannot be only a single authority for assigning URNs.  We expect
that there will be a multi-tiered naming authority delegation.
Furthermore, it is difficult to imagine a non-partitioned and delegated
global UDS, meaning that hint discovery and resolution will be
partitioned and delegated.  In some UDS schemes, the delegation of
naming authority will form a basis for delegating the management and
dispensing of location information.

The third assumption is independence or isolation of one authority from
another and, at least to some extent from its parent.  Underlying much
of the thinking and discussion in the URI and URN working groups has
been the assumption that when a component delegates authority to another
component, the delegatee can operate in that domain independently of its
peers and within bounds specified by the delegation, independently of
the delegator.  This isolation is critically important in order to allow
for independence of policy and mechanism.

There are a number of more specific assumptions that fall under this
rubric of isolation.  First, we assume that the publisher of a resource
can choose resolution services, independently of choices made by others.
At any given time, the owner of a namespace may choose a particular URN
resolution service for that delegated namespace.  Such a URN resolution
service may be outside the UDS service model, and just identified or
located by the UDS service.  Second, it must be possible to make a
choice among UDS services, perhaps based on different underlying
internal architectures.  The reason that this is an assumption is that
there must be an evolutionary path through a sequence of core UDS
services.  Although at any given time there is likely to be only one or
a small set of such services, the number is likely to increase during a
transition period from one architecture to another.  Thus, it must be
assumed that clients can make a choice among a probably very small set
of UDSs.  Third, there must be independence in the choice about levels
and models of security and authenticity required.  This choice may be
made by the owner of a naming subspace, in controlling who can modify
hints in that subspace.  A naming authority may delegate this choice to
the owners of the resources named by the names it has assigned.  There
may be limitations on this freedom of choice in order to allow other
participants to have the level of security and authenticity they
require, for example, in order to maintain the integrity of the UDS
infrastructure as a whole.  Fourth, there is an assumption of
independence of choice of the rule of canonicalization of URNs within a
namespace, limited by any restrictions or constraints that may have been
set by its parent namespace.  This is a choice held by naming
authorities over their own subnamespaces.  Rules for canonicalization
will be discussed further in the framework section below.  Thus, there
are assumptions of independence and isolation to allow for delegated,
independent authority in a variety of domains.

URN Resolution Requirements                                      Page  4

The modularity assumptions of delegation and isolation imply
independence of decision and implementation, leading to a
decentralization that provides a certain degree of safety from denial of
service.  Based on these these assumptions in conjunction with that of
longevity and those for URLs and URNs as detailed in RFCs 1736 and 1737,
we can now turn to the requirements for a URN services delegation
service.

3. Requirements

The requirements applying to a URN-resolution-service discovery service
or UDS center around three important design goals: evolvability,
usability, and security and privacy.  At its core the function of a UDS
is to provide hints for accessing a resource given a URN for it.  These
hints may range in applicability from local to global, and from
short-lived to long-lived.  They also may vary in their degree of
verifiable authenticity.  While it may be neither feasible nor necessary
that initial implementations support every requirement, every
implementation must support evolution to systems that do support every
requirement.

It is also important to note that there are other requirements, not
applicable specifically to a UDS that must also be met.  A whole URN
system will consist of namespaces, the resolution information for them,
and the mapping from names in the namespaces to resolution information
(or hints).  URN schemes must meet the requirements of RFC 1737.
Resolution information, to the extent it is expressed as URLs must meet
the requirements of RFC 1736.  But this does not tell the whole story.
Although the URN working group will identify several acceptable
namespaces and the rules binding them, such as how delegation occurs,
how it is expressed in the names, how and to what extent binding to hint
information will be constrained by the namespace, in the long run a
document will be needed to guide the evaluation criteria for acceptance
of new namespaces.  These are not included in the list of requirements
below because they are not requirements for a UDS, but rather for naming
schemes themselves.

3.1 Evolution

One of the lessons of the Internet that we must incorporate into the
development of mechanisms for resolving URNs is that we must be prepared
for change.  Such changes may happen slowly enough to be considered
evolutionary modifications of existing services or dramatically enough
to be considered revolutionary.  They may permeate the Internet universe
bit by bit, living side by side with earlier services or they may take
the Internet by storm, causing an apparent complete transformation over
a short period of time.  There are several directions in which we can
predict the need for evolution, even at this time, prior to the
deployment of any such service.  At the very least, the community and
the mechanisms proposed should be prepared for these.

First, we expect there to be additions and changes to the mechanisms.
The community already understands that there must be a capacity for new
URN schemes.  A URN scheme will define a set of URNs that meet the URN
requirements[RFC1737], but may have further constraints on the internal

URN Resolution Requirements                                      Page  5

structure of the URN.  The requirements document would allow for an
overall plan in which URN schemes are free to specify parts of the URN
that are left opaque in the larger picture.  In fact, a URN scheme may
choose to make public the algorithms for any such "opaque" part of the
URN.  For example, although it may be unnecessary to know the structure
of an ISBN, the algorithm for understanding the structure of an ISBN has
been made public.  Other schemes may either choose not to make their
algorithms public, or choose a scheme in which knowledge of the scheme
does not provide any significant semantics to the user.  In any case, we
must be prepared for a growing number of URN schemes.

Often in conjunction with a new URN scheme, but possibly independently
of any particular URN scheme, new resolution services may evolve.  For
example, one can imagine a specialized resolution service based on the
particular structure of ISBNs that improves the efficiency of finding
documents given their ISBNs.  Alternatively, one can also imagine a
general purpose resolution service that trades performance for
generality; although it exhibits only average performance resolving
ISBNs, it makes up for this weakness by understanding all existing URN
schemes, so that its clients can use the same service to resolve URNs
regardless of naming scheme.  In this context, there will always be room
for improvement of services, through improved performance, better
adaptability to new URN schemes, or lower cost.  In any case, new models
for URN resolution will evolve and we must be prepared to allow for
their participation in the overall resolution of URNs.

If we begin with one overall plan for URN resolution, into which the
enhancements described above may fit, we must also be prepared for an
evolution in the authentication schemes that will be considered either
useful or necessary in the future.  There is no single globally accepted
authentication scheme, and there may never be one.  Even if one does
exist at some point in time, there will always be threats to it, and so
we must always be prepared to move on to newer and better schemes, as
the old ones become too easily spoofed or guessed.

Lastly, in terms of mechanism, although we may develop and deploy a
single UDS scheme initially, we must be prepared for that top level
model to evolve.  Thus, if the UDS model supports an apparently
centralized (from a policy standpoint) scheme for inserting and
modifying authoritative information, over time we must be prepared to
evolve to a different model, perhaps one that has a more distributed
model of authority and authenticity.  If the model has no core but
rather a cascaded partial discovery of information, we may find that
this becomes unmanageable with an increase in scaling.  Whatever the
core of the model, we must be prepared for it to evolve with changes in
scaling, performance, and policy constraints such as security and cost.

Second, in addition to the evolution of resolution mechanisms, we expect
that the community will follow an evolutionary path towards the
separation of semantics from identification.  The URN requirements
document suggested this path as well, and there has been general
agreement in much of the community that such a separation is desirable.
This is a problem that the public at large has generally not understood.
Today we see the problem most clearly with the use of URLs for
identification.  When a web page moves, its URL becomes invalid.

URN Resolution Requirements                                      Page  6

Suppose such a URL is embedded in some page, stored in long term
storage.  There are three possible outcomes to this scenario.  One
possibility is that the client is left high and dry with some message
saying that the page cannot be found.  Alternatively, a "forwarding
pointer" may be left behind, in the form of an explicit page requesting
the client to click on a new URL.  Although this will allow the client
to find the intended page, the broken link cannot be fixed because the
URL is embedded in a file outside of the client's control.  A third
alternative is that the target server supplies an HTTP redirect so that
the new page is provided for the client automatically.  In this case,
the client may not even realize that the URL is no longer correct.  The
real problem with both of these latter two situations is that they only
work as long as the forwarding pointer can be found at the old URL.
Semantics, in this case location information, was embedded in the
identifier, and the resolution system was designed to depend on the
semantics being correct.  There are few cases in which we can expect
semantics of any sort to remain valid for a long time, but in many cases
references need to have long lifespans.  Most documents are only useful
while their references still function.

We expect the evolution to separation of semantics from identification
to move along at least three paths.  The first will be to develop
temporary aliases to capture the semantics currently embedded in
identifiers.  This will require additional translation, but it will
allow for the development of semantics-free URNs.  Second, we expect
locally shared or private aliases to arise, again supported by a
translation mechanism and allowing for the long-term storage of global,
semantics-free URNs.  Such an aliasing scheme may be used to permit
local aliases for named resources as well as to present these aliases to
users in lieu of the URNs themselves.  Lastly, we expect there may be a
development of global aliases.  These will be more user friendly "names"
that would be shared on a much larger scale, and might be defined in
some global registry.  This may include trademarked names as well as
names in extremely common use.  As with the other alias systems, a
facility for translation is needed.  However, in this case, since the
system of aliases is of global scope, the translation facility will be
very slow if each time an alias is translated it needs to query a
centralized or even reasonably distributed global registry.  In order to
achieve acceptable speeds, the translation facility w

Date: Fri, 22 Nov 1996 14:33:35 -0800 (PST)
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Collecting open issue information on the syntax draft...
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

(Apologies for being out of touch recently while at SGML 96.)

>   Any namespace (existing or newly-devised) that is proposed as a
   URN-namespace and fulfills the criteria of URN-namespaces must
   be expressed in this syntax.  If names in these spaces contain
   characters other than those defined for the URN character set,
   they must be translated into canonical format as discussed in
   section 2.2.
                                
I agree with Leslie's proposed emendation and the reasons she
expressed for it.

EXCEPT, that the name space itself need not be expressed in this
syntax, only the URN represntation of that name space.  So perhaps
"must be expressed" should be "must have rules for expressing
its names".

Regards,

Date: Fri, 22 Nov 1996 13:35:59 -0700
To: [email-masked] (Leslie Daigle), "URN mailing list" <[email-masked]>
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] Collecting open issue information on the syntax draft...
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke Leslie Daigle (at least at 02:42 PM 11/22/96 -0500)

>Once we've settled on a syntax and handling mechanisms, we have nothing
>further to say about what people do within those constraints.

Hear! Hear!

I recommend that, for some time, new namespaces receieve standards-track
review, rather like new URL schemes currently do. That review process
is the place where we can address concerns such as limited longevity or
legal liability due to the inclusion of particular attempts at
"friendliness". The syntax draft does not have to address that issue one
way or the other.

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

From: [email-masked] (Leslie Daigle)
Date: Fri, 22 Nov 1996 14:42:00 -0500
To: "Ryan Moats" <[email-masked]>, "URN mailing list" <[email-masked]>
Subject: Re: [URN] Collecting open issue information on the syntax draft...
Sender: [email-masked]
Reply-To: [email-masked] (Leslie Daigle)

This touches on something I asked Ryan about in the draft, and wanted to
bring up here.

In reading through the recent thread on character sets and URNs (admittedly,
slightly out of step with real-time), it seemed to come to a reasoned
and reasonable conclusion about handling character sets other than US-ASCII
in URNs.  I didn't feel that this was completely represented in the
syntax draft, although I'm not sure whether it was because my reading
of the thread was at fault.

[Ryan brought up:]
> 4. human readability for new namespaces: MUST/SHOULD?

This is in reference to the paragraph, in the syntax draft:

      Some existing name spaces that have the properties of the URN-space
      contain some human-significant components, and these exist in a wide
      variety of languages.  However, URNs are NOT intended to convey
      information that is significant to humans.  While the translation
      rule in section 2.2 is provided for existing namespaces, new
      namespaces, as part of their registration documentation, MUST define
      a discipline for assigning new URNs that does not simplify the
      generation of human-significant names.

The way I read this, the only thing the syntax draft is recognizing is
that there may be existing namespaces that have things that happen to
be human-readable, and these may be in character sets other than US-ASCII,
so UTF-8 is proposed as a mechanism of handling these anomalies -- but
that these namespaces should ensure that future names assigned should not
suffer from human-readability.  (Admittedly, a "strong" reading of the
statement, but I'm trying to illustrate the point).

I just don't see the point of such a statement.

The syntax draft defines how to formally express a URN -- in US-ASCII or
UTF-8.  Period.

What things a namespace-proposer chooses to use in their namespace is
not relevant, as long as they can be carried in this syntax, and otherwise
meet the requirements of namespaces (uniqueness of names, etc).  So,
if someone proposes a namespace that happens to be human-friendly (_whatever_
that means!) in spite of meeting all these requirements, cool!

What was intended in the charter was to avoid having the syntax and handling
mechanisms' design _driven_ by a need to keep things "human-friendly"
(e.g., shorter than URLs, no funny punctuation, whatever).

Once we've settled on a syntax and handling mechanisms, we have nothing
further to say about what people do within those constraints.

I bring all of this up because it is not clear to me that particular paragraph
adequately represented what _seemed_ to be consensus on the matter on
the list.

If that is the case, I would propose the following change to the syntax
draft:

> 3. Support of existing legacy naming systems and new naming systems

   > URN-aware applications MAY accept as input other resource identifiers
   > from existing legacy namespaces.  If such identifiers contain
   > characters that are not members of the URN character set specified in
   > section 2.2, the identifier MUST be translated to canonical format as
   > discussed in section 2.2.
> 
   > Some existing name spaces that have the properties of the URN-space
   > contain some human-significant components, and these exist in a wide
   > variety of languages.  However, URNs are NOT intended to convey
   > information that is significant to humans.  While the translation
   > rule in section 2.2 is provided for existing namespaces, new
   > namespaces, as part of their registration documentation, MUST define
   > a discipline for assigning new URNs that does not simplify the
   > generation of human-significant names.

 would become:

3. Support of existing legacy naming systems and new naming systems

   Any namespace (existing or newly-devised) that is proposed as a 
   URN-namespace and fulfills the criteria of URN-namespaces must
   be expressed in this syntax.  If names in these spaces contain
   characters other than those defined for the URN character set,
   they must be translated into canonical format as discussed in
   section 2.2.

Well, it's not the most inspired wording, but can people live with
this?

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: "Ryan Moats" <[email-masked]>
To: "URN mailing list" <[email-masked]>
Date: Fri, 22 Nov 96 10:41:13 
Priority: Normal
Subject: [URN] Collecting open issue information on the syntax draft...
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

Folks-

I've been going back over the open issues with the syntax draft
and trying to ensure that I have all of them before I start thinking
about slides for San Jose.  

The open issues as I see them with this document at this moment in
time are:

1. "urn:" tag: YES/NO?
2. URN char set: additions/deletions?
3. %escaping: just octets outside char set or reserve/literal chars as well?
4. human readability for new namespaces: MUST/SHOULD?
5. equivalency: needs some more work (as you pointed out above)
6. How do we know when a URN ends?

I don't want to necessarily discuss them now, but want to 
be sure that I haven't missed anything before San Jose.

Ryan

P.S.  I'm providing a short synopsis of the issue for those that aren't
straightforward:

%escaping
----------------

The issue here (as I see it) is that the current rules for URN syntax
reserve % for escaping characters outside the URN char set.  A namespace
identifier that use % to escape the literal use of a character that also has
a special meaning for that namespace can not be made into a valid URN.
I happen to think this requires fixing, or at least more thought.

equivalency
------------------

It has been pointed out to me that saying "two URNs are equivalent if 
they return the same resource" is not quite an accurate statement.  This
statement requires some improvement, and such will be discussed.

When does a URN end?
---------------------------------------

It has also been pointed out to me that the syntax draft does not indicate
when a URN ends.  Some statement should be added to indicate this
situation.  My current preference is to state that a "On the line, the
URN ends with an octet that is not a member of the URN charset",
or something like that, but what about other formats?

To: IETF-Announce:;
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-http-conv-00.txt
Date: Fri, 22 Nov 1996 09:41:23 -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     : Conventions for the Use of HTTP for URN Resolution      
       Author(s) : R. Daniel
       Filename  : draft-ietf-urn-http-conv-00.txt
       Pages     : 6
       Date      : 11/21/1996

The URN-WG was formed to specify persistent, location-independent names for
network accessible resources, and resolution mechanisms to retrive the 
resources given such a name. At this time the URN-WG is considering one 
particular resolution mechanism, the NAPTR proposal [1]. That proposal does
not get the client software all the way from the URN to the resource. 
Instead, it gets the client from a URN to a "resolver", which is a system 
that can then tell the client where the resource is. The NAPTR draft 
defines a "resolution protocol" to be the protocol used to speak to a 
resolver in order to obtain the resource, its location(s), or other 
information about the resource. The NAPTR proposal allows different 
resolution protocols to be used for commuicating with resolvers.  

This draft establishes conventions for encoding URN resolution requests and 
responses in HTTP 1.0 (and 1.1) requests and responses. The primary goal of
this draft is to define a convention that is simple to implement and will 
allow existing HTTP servers to easily add support for URNresolution. We 
expect that the resolution databases that arise will be useful when more 
sophisticated resolution protocols are developed later.                    

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
     "get draft-ietf-urn-http-conv-00.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-http-conv-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-http-conv-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-http-conv-00.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce:;
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-naptr-01.txt
Date: Fri, 22 Nov 1996 09:41:32 -0500
Sender: [email-masked]
Reply-To: [email-masked]

--NextPart

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

       Title     : Resolution of Uniform Resource Identifiers using the 
                   Domain Name System                                      
       Author(s) : R. Daniel, M. Mealling
       Filename  : draft-ietf-urn-naptr-01.txt
       Pages     : 13
       Date      : 11/21/1996

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.

Internet-Drafts are available by anonymous FTP.  Login with the username
"anonymous" and a password of your e-mail address.  After logging in,
type "cd internet-drafts" and then
     "get draft-ietf-urn-naptr-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-naptr-01.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-naptr-01.txt".
							
NOTE: The mail server at ds.internic.net can return the document in
      MIME-encoded form by using the "mpack" utility.  To use this
      feature, insert the command "ENCODING mime" before the "FILE"
      command.  To decode the response(s), you will need "munpack" or
      a MIME-compliant mail reader.  Different MIME-compliant mail readers
      exhibit different behavior, especially when dealing with
      "multipart" MIME messages (i.e., documents which have been split
      up into multiple messages), so check your local documentation on
      how to manipulate these messages.

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

From: Leslie Daigle <[email-masked]>
Date: Thu, 21 Nov 1996 21:17:29 -0500
To: [email-masked]
Subject: [URN] Status
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Okay, on the brink of the SJ IETF meeting, it seems a good time to
review the progress of this Fall, particularly with respect to our charter.

So, first of all, congratulations to everybody for a very productive
Fall;  the document editors have been working _very_ hard, and people
have been unstinting in their generous, and constructive,  commentary.   

We now have drafts of:

	. URN Framework and Requirements (soon to be published)
	. URN Syntax
	. NAPTR proposed implementation
	. HTTP resolution conventions

we are _that_ close to having something that can actually be deployed
in a test-fashion.

Ah, yes, there is one thing missing: a namespace.

On previous occasions, one or more people have suggested that they would
be willing to work on the definition of a new namespace, or on the 
use of an existing namespace in the URN context ("grandfathering").  Now
that the syntax is settling down, I would appreciate volunteers and
proposals for namespaces -- please send mail to me, and I will summarize
to the list.

The agenda for the San Jose meeting is pretty straightforward -- there
will be time to talk about specific issues with individual drafts, assessing
where we are, and determining how to tackle the remaining required drafts
(read:  flushing out volunteers, if none are evident before then :-)

Thanks!
Leslie.

P.S.: By the way -- it has been pointed out to me that the URL I circulated
a couple of weeks ago was wrong (although our kindly web-maintainers have
aliased around my gaffe).  The proper URL is:

	http://www.bunyip.com/research/ietf/urn-ietf/

I have updated the page to include our charter and the pointers to
other work that people proposed.  I will include pointers to the new
crop of I-D's, as soon as things settle down (i.e.:  after Tuesday, 5pm!).

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

Agenda for Thursday, December 12, 1996, San Jose, California.

Status review:
	. Status of documents
	. Progress on WG milestones

Discussion of document-specific issues:
	. URN Framework and Requirements
	. URN Syntax
	. NAPTR proposal
	. HTTP conventions

Where to go from here:
	. addressing remaining documents

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

  "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: "Ronald E. Daniel" <[email-masked]>
Date: Wed, 20 Nov 1996 13:33:58 -0700 (MST)
To: [email-masked]
Subject: [URN] NAPTR revision
Sender: [email-masked]
Reply-To: "Ronald E. Daniel" <[email-masked]>

Hi,

I've revised the NAPTR draft to allow characters other than '/' to be used
as the delimiters in the regexp field. I will send this in to the ID editor
later today.

The new version is appended.

Regards,
Ron
===

INTERNET DRAFT                                                  Ron Daniel
draft-ietf-urn-naptr-01.txt                 Los Alamos National Laboratory
                                                          Michael Mealling
                                                   Network Solutions, Inc.
                                                             19 Nov., 1996

                Resolution of Uniform Resource Identifiers
                       using the Domain Name System

[Edits since -00:
1) Changed SRV citation to RFC from ID
2) Pulled underscores from SRV names.
3) Changed syntax of substitution expression to allow delimiter
   characters other than '/'.
]

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 19 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   = delim-char  ere  delim-char  repl  delim-char  *flags
  delim-char   = "/" / "!" / ... (Any non-digit or non-flag character other
                 than backslash '\'. All occurances of a delim_char in a
                 subst_expr must be the same character.)
  ere          = POSIX Extended Regular Expression (see [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.

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

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

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

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

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

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

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] RFC 2052, "A DNS RR for specifying the location of services (DNS SRV)",
    A. Gulbrandsen and P. Vixie, October 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 19 May, 1997.

Ron Daniel Jr.                   email: [email-masked]
Advanced Computing Lab           voice: (505) 665-0597
MS B-287  TA-3  Bldg. 2011         fax: (505) 665-4939
Los Alamos National Lab           http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM,  87545    obscure_term: "hypernym"

From: "Ronald E. Daniel" <[email-masked]>
Date: Wed, 20 Nov 1996 13:31:57 -0700 (MST)
To: [email-masked]
Subject: [URN] HTTP conventions draft
Sender: [email-masked]
Reply-To: "Ronald E. Daniel" <[email-masked]>

Hi,

I've changed the conventions draft to remove the integer from the
text/uri-list media type. The new version is appended. I will
send this to the ID editor later today.

Regards,
Ron
====
INTERNET DRAFT                                                  Ron Daniel
draft-ietf-urn-http-conventions-00.txt      Los Alamos National Laboratory
                                                              13 Nov, 1996

         Conventions for the Use of HTTP for URN Resolution

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 15 May, 1997.

Abstract:
=========

The URN-WG was formed to specify persistent, location-independent names
for network accessible resources, and resolution mechanisms to retrive
the resources given such a name. At this time the URN-WG is considering
one particular resolution mechanism, the NAPTR proposal. That proposal
does not get the client software all the way from the URN to the resource.
Instead, it gets the client from a URN to a "resolver", which is a system
that can then tell the client where the resource is. The NAPTR draft
defines a "resolution protocol" to be the protocol used to speak to a
resolver in order to obtain the resource, its location(s), or other
information about the resource. The NAPTR proposal allows different
resolution protocols to be used for commuicating with resolvers.

This draft establishes conventions for encoding URN resolution requests
and responses in HTTP 1.0 (and 1.1) requests and responses. The primary
goal of this draft is to define a convention that is simple to implement
and will allow existing HTTP servers to easily add support for URN
resolution. We expect that the resolution databases that arise will be
useful when more sophisticated resolution protocols are developed later.

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 /uri-res/<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 /uri-res/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 /uri-res/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 /uri-res/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 /uri-res/N2L/cid:foo%40huh.com HTTP/1.0
    GET /uri-res/N2L/urn:cid:foo%40huh.com HTTP/1.0

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

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 any special status codes that
are likely to arise.

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

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

The request is encoded as above. The URL MUST be returned in a Location:
header for the convienience of the 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. The Internet Media Type (aka ContentType) of the result
may be negotiated using standard HTTP mechanisms if desired. At a
minimum the resolver should support the text/uri-list media type.
(See Appendix A for the definition of this media type). That media
type is suitable for machine-processing of the list of URLs. Resolvers
may also return the results as text/html, text/plain, or any other
media type they deem suitable.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 B. 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 /uri-res/N2L http://urn.acl.lanl.gov/cgi-bin/n2l.pl
Redirect /uri-res/L2N http://urn.acl.lanl.gov/cgi-bin/l2n.pl

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

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

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

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

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

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

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

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

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

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

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

Ron Daniel
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 15 May, 1997.
Ron Daniel Jr.                   email: [email-masked]
Advanced Computing Lab           voice: (505) 665-0597
MS B-287  TA-3  Bldg. 2011         fax: (505) 665-4939
Los Alamos National Lab           http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM,  87545    obscure_term: "hypernym"

Date: Wed, 20 Nov 1996 10:09:19 -0700
To: Bob Briscoe <[email-masked]>, [email-masked]
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] Resolution Services (N2L etc)
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Trolling back through my mail, I discovered that I had a few
partially-completed replies to the issues raised by Bob Briscoe,
but had not sent any of them. sigh. Here are some semi-random notes
on the things he raised.

Thus spoke Bob Briscoe (at least at 10:01 AM 11/5/96 +0000)

>Comments on draft-ietf-urn-naptr-00.txt:
>1.2 It strikes me that specifying available service requests (N2L, N2R etc)
>should not be the job of DNS or any URN resolution mechanism. You are adding
>metadata about the address that the name resolves to (i.e. allowed methods).
>NAPTR should simply get you to the place you asked for by mapping names to
>addresses.

The problem with this is that different places may offer different services.
The various resolution services offered by a resolver are is information about
the resolver and its capabilitities, not about the names on that resolver.

In another message lurking somewhere in my extremely well-organized mail
archives, I recall Bob saying that N2L was the only essential service, all
the others could either be reduced to it or were not important. I disagree,
not that this will surprise anyone. :-)  For the user, N2L and N2R are
equivalent, but N2R can avoid a round trip. N2C is very different from 
N2L or N2R. Furthermore, I happen to think it is very important, and I
already have several exmples of where it might be used in early URN
experiments. The ISBN and UPC namespaces are both cases where we can
obtain a description of the resource (book or product) a lot easier than
we can obtain a copy of the resource. I have things going on at work where
we want tobe able to use N2C.
 
>IOW, the client should already know
>what it is going to do with the address it gets out of the URN service, or
>if it doesn't it should be prepared to find out.

That is not inconsistent with advertising the resolution services in a NAPTR
record. The clients know what they want to do - typically, get the resource
or at least a location for the resource. They can do this in several
fashions.  However, what the client wants to do may not be supported by
the resolver. If not, advertising those services in the NAPTR record lets
the client discover that early, and try contacting another resolver if
possible.

At 10:02 AM 11/5/96 +0000, Bob wrote:

>2. Substitution expression grammar
>2.1 You claim to be copying sed ERE syntax (with the caveat it may all
>change to cover UTF-8).

Not exactly. Sed uses Basic Regular Expression syntax, I suggest that
we use Extended Regular Expression syntax.

> To avoid confusion for sed gits like me, could you
>consider using the escaped parentheses \( and \) to do back refs, rather
>than the one character ones ( and ) which simply imply grouping in POSIX
>EREs by my understanding.

This is the big difference between BRE and ERE syntax. I suggested
using ERE because I think it is going to be simpler for people to
use () than \\(\\). At the time there was some agreement with this
argument, and I don't recall any disagreement. However, if others
come forward to ask for BREs I will certainly consider changing the
draft.

>2.2 Also, it would be friendly to allow any delimiter, like sed does, not
>just "/" (e.g. "!.*//\([^/:]+\)!\1!i" is a lot more readable than
>"/.*\/\/\([^\/:]+\)/\1/i").

Agreed. I'll change the draft on this point to say something like:

"The first character of the substitution expression will be used as the
delimiter character. There MUST be exactly three non-escaped occurrances
of that character in the substitution expression. Because escaped
digits in the replacement portion of the substitution expression are
backrefs, the delimiter character MUST NOT be a digit. Similarly, the
delimiter character MUST NOT be a flag character if that flag is used
in the substitution expression.

I believe Bob's main objection to the NAPTR draft was that there was no
way of indicating the lifetime of a resolver. I'll take that up with him
off-list because I am still not clear on aspects of that objection.

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

From: "Ryan Moats" <[email-masked]>
To: "Franz J. Hauck" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Wed, 20 Nov 96 08:06:18 
Priority: Normal
Subject: Re: [URN] URN Syntax Draft, NSS character set
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Wed, 20 Nov 1996 09:49:07 +0100, Franz J. Hauck wrote:

>Hi,
>
>I'm new to the list and I just read draft-ietf-urn-syntax-01.txt. At the
>definition of the character set for the NSS, there is probably some part
>of a line missing; it looks somehow truncated:
>
><other>      ::= "(" | ")" | "+" | "
>                 ":" | "=" | "?" | "@"
>

Ugh, well that guarantees there will be an -02 ;-)

The missing part (and I just realized why it's missing, grrrrrrrr) is (if you
concatenate this with the first line of other you'll have a repeated
'"'.

"\\" | "," | "-" | "." | "/" |

Ryan 

Date: Wed, 20 Nov 1996 09:49:07 +0100
From: "Franz J. Hauck" <[email-masked]>
Organization: IMMD 4, Univ. Erlangen-Nuernberg
To: [email-masked]
Subject: [URN] URN Syntax Draft, NSS character set
Sender: [email-masked]
Reply-To: "Franz J. Hauck" <[email-masked]>

Hi,

I'm new to the list and I just read draft-ietf-urn-syntax-01.txt. At the
definition of the character set for the NSS, there is probably some part
of a line missing; it looks somehow truncated:

<other>      ::= "(" | ")" | "+" | "
                 ":" | "=" | "?" | "@"

My question: Which are the missing characters here?

Thanks

- Franz J. Hauck

To: IETF-Announce:;
Cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-syntax-01.txt
Date: Tue, 19 Nov 1996 10:03:40 -0500
Sender: [email-masked]
Reply-To: [email-masked]

--NextPart

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

       Title     : URN Syntax                                              
       Author(s) : R. Moats
       Filename  : draft-ietf-urn-syntax-01.txt
       Pages     : 6
       Date      : 11/18/1996

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

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-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-syntax-01.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-01.txt".
							
NOTE: The mail server at ds.internic.net can return the document in
      MIME-encoded form by using the "mpack" utility.  To use this
      feature, insert the command "ENCODING mime" before the "FILE"
      command.  To decode the response(s), you will need "munpack" or
      a MIME-compliant mail reader.  Different MIME-compliant mail readers
      exhibit different behavior, especially when dealing with
      "multipart" MIME messages (i.e., documents which have been split
      up into multiple messages), so check your local documentation on
      how to manipulate these messages.

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

From: "Ryan Moats" <[email-masked]>
To: "Towsner" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 19 Nov 96 08:06:27 
Priority: Normal
Subject: Re: [URN] URN Syntax -01 i-d submission
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Mon, 18 Nov 1996 06:58:26 -0500, Towsner wrote:

>NSS can have letters, numbers, but a NID can only have letters.  Why? It
>seems to me that things should be defined as similarly as possible to avoid
>confusion.
>
>--
><Insert witty signature here>
>-Henry Towsner <[email-masked]>

When the syntax draft started, I remember some off list discussion on whether
the NID should have letters/numbers or just letters.  As I remember it, the 
descision was "take letters for now, and we can always add in numbers later".
Guess later is starting to think about arriving ;-)

Ryan

Date: Mon, 18 Nov 1996 06:58:26 -0500
To: [email-masked]
From: Towsner <[email-masked]>
Subject: Re: [URN] URN Syntax -01 i-d submission
Sender: [email-masked]
Reply-To: Towsner <[email-masked]>

NSS can have letters, numbers, but a NID can only have letters.  Why? It
seems to me that things should be defined as similarly as possible to avoid
confusion.

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

Date: Mon, 18 Nov 1996 16:01:08 -0600
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: [email-masked]
Cc: [email-masked]
Subject: [URN] URN Syntax -01 i-d submission
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

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

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

Status of This Memo

      This document is an Internet-Draft.  Internet-Drafts are working
      documents of the Internet Engineering Task Force (IETF), its
      areas, and its working groups.  Note that other groups may also
      distribute working documents as Internet-Drafts.

      Internet-Drafts are draft documents valid for a maximum of six
      months and may be updated, replaced, or obsoleted by other
      documents at any time.  It is inappropriate to use Internet-
      Drafts as reference material or to cite them other than as ``work
      in progress.''

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

Abstract

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

1. Introduction

   Uniform Resource Names (URNs) are intended to serve as persistent
   resource identifiers and are designed to make it easy to map other
   namespaces (which share the properties of URNs) into URN-space. The
   URN syntax therefore provides a means to encode character data in a
   form that can be sent in existing protocols, transcribed on most
   keyboards, etc.

Expires 5/19/97                                                 [Page 1]

INTERNET DRAFT                 URN Syntax                  November 1996

2. Syntax

   All URNs have the following syntax:

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

   <NID> is the Namespace Identifier, and <NSS> is the Namespace
   Specific String.  The leading case-insensitive "urn:" sequence is
   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] presents additional requirements on URN encoding, which
   all have implications as far as limiting syntax.  On the other hand,
   the requirement to support existing legacy naming systems has the
   effect of broadening syntax.  Thus, we discuss the acceptable syntax
   for both the Namespace Identifier and the Namespace Specific String
   separately.

2.1 Namespace Identifier Syntax

   The following is the syntax for the Namespace Identifier. To (a) be
   consistent with all potential resolution schemes and (b) not put any
   undue constraints on any potential resolution scheme, the syntax for
   the Namespace Identifier is:

   <NID>         ::= <letter> [ <let-hyp> ]

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

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

2.2 Namespace Specific String Syntax

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

Expires 5/19/97                                                 [Page 2]

INTERNET DRAFT                 URN Syntax                  November 1996

   <NSS>        ::= <URN chars>*

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

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

   <hex>        ::= <number> | "A" | "B" | "C" | "D" | "E" | "F"

   <upper>      ::= "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" |
                    "I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" |
                    "Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" |
                    "Y" | "Z"

   <lower>      ::= "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |
                    "i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
                    "q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
                    "y" | "z"

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

   <other>      ::= "(" | ")" | "+" | "
                    ":" | "=" | "?" | "@"

   Depending on the rules governing a namespace, valid identifiers in a
   namespace might contain characters that are not members of the URN
   character set above (<URN chars>).  Such strings MUST be translated
   into canonical NSS format before using them as protocol elements or
   otherwise passing them on to other applications. Translation is done
   by encoding each character outside the URN character set as a
   sequence of one to six octets using UTF-8 encoding, and the encoding
   of each of those octets as "%" followed by two characters from the
   <hex> character set above. The two characters give the hexadecimal
   representation of that octet.

   Namespaces MAY designate one or more characters from the URN
   character set as having special meaning for that namespace. If the
   namespace also uses that character in a literal sense as well, the
   character used in a literal sense must be encoded with "%" followed
   by the hexadecimal representation of that octet.  Therefore, the
   process of registering a namespace identifier shall include
   publication of a definition of which characters have a special
   meaning and how to encode these characters if used in a literal
   sense.

Expires 5/19/97                                                 [Page 3]

INTERNET DRAFT                 URN Syntax                  November 1996

3. Support of existing legacy naming systems and new naming systems

   URN-aware applications MAY accept as input other resource identifiers
   from existing legacy namespaces.  If such identifiers contain
   characters that are not members of the URN character set specified in
   section 2.2, the identifier MUST be translated to canonical format as
   discussed in section 2.2.

   Some existing name spaces that have the properties of the URN-space
   contain some human-significant components, and these exist in a wide
   variety of languages.  However, URNs are NOT intended to convey
   information that is significant to humans.  While the translation
   rule in section 2.2 is provided for existing namespaces, new
   namespaces, as part of their registration documentation, MUST define
   a discipline for assigning new URNs that does not simplify the
   generation of human-significant names.

4. URN presentation and transport

   URN-aware applications MAY support "natural" display of URNs which
   contain characters encoded using "%" notation.  However, they MUST
   provide for display of URNs in canonical form (i.e. in a format
   suitable for transcription).

   URNs may only be transported in canonical format.

5. Equivalence in URNs

URNs are considered equivalent if they return the same resource.  For
various purposes, such as caching, a test is necessary to determine
equivalence without actually resolving the URNs and fetching/comparing
the underlying resources.  "Lexical equivalence" is a stricter condition
that the equivalence described above (functional equivalence).

5.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. drop any preceding "urn:" token
           2. 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

Expires 5/19/97                                                 [Page 4]

INTERNET DRAFT                 URN Syntax                  November 1996

   two URNs are not equivalent if the procedure above says they are
   equivalent.

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

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

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

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

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

Expires 5/19/97                                                 [Page 5]

INTERNET DRAFT                 URN Syntax                  November 1996

                     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.

9. Editor's address

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

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

                 This Internet Draft expires May 19, 1997.

Expires 5/19/97                                                 [Page 6]

Date: Mon, 18 Nov 1996 10:15:28 -0700
To: Terry Allen <[email-masked]>, [email-masked]
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] text/uri-list registration
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke Terry Allen (at least at 08:26 AM 11/17/96 -0800)
>As a nonprogrammer I'm probably missing the obvious, but in the
>interest of clarity, why
>
>>2) The first non-comment line shall be an integer giving the number of
>   URIs in the list.   
>
>so the parser of a uri-list can know when it will have reached
>the end of the list?  to allow error recovery if the uri-list is
>malformed?  something else?

The intention was so that the parser could know how many URIs to expect.
However, as has been pointed out in some off-list mail, this is not
necessary and it introduces the potential for errors when the number
of URLs does not agree with the value of the integer.

I'll revise the format to remove that integer.

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, 17 Nov 1996 08:26:54 -0800 (PST)
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [URN] text/uri-list registration
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

As a nonprogrammer I'm probably missing the obvious, but in the
interest of clarity, why

>2) The first non-comment line shall be an integer giving the number of
   URIs in the list.   

so the parser of a uri-list can know when it will have reached
the end of the list?  to allow error recovery if the uri-list is
malformed?  something else?

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: Fri, 15 Nov 1996 16:11:48 -0500
To: Ron Daniel <[email-masked]>
From: Francois Yergeau <[email-masked]>
Subject: Re: [URN] URI internationalization
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Francois Yergeau <[email-masked]>

[Cross-posted to URI list, from URN-IETF list]

=C0 09:05 15-11-96 -0700, Ron Daniel a =E9crit :
>I think I18N for URLs is a more difficult problem than it has been for
>URNs. We have a large number of existing URLs in a variety of character
>sets.

Well, no, it appears we don't really have that.  I made a search for
non-ASCII URLs last spring (both 8-bit octets and %XY with X>=3D8), and f=
ound
very few out on the Web (cf.
<http://www.alis.com:8085/~yergeau/conf/www5/robot.en.html>).  Less than
0.25% in fact, and then some were typos (divide signs instead of tilde, f=
or
instance) that didn't work until corrected by hand.

Furthermore, compatibility is made easier by the fact that UTF-8 data can=
 be
quite reliably recognized as such.  Given a UR*, a server can test it for
UTF-8 validity; if it fails, it's some 'old' UR* in some encoding other t=
han
UTF-8, the server can process as it did before and nothing is broken; if =
it
passes, just process as UTF-8.  A little experimentation (need more) show=
s
that false positives are unlikely, provided one takes care of 7-bit
ISO-2022-like encodings that look like ASCII (and thus UTF-8) but are not.
As for complexity, a UTF-8 validator fits in about 20 lines of C.

>While I18N for URLs is a legitimate issue, it is not an issue for the
>URN-WG (IMHO). The URI list is still alive, that might be the proper
>place to begin discussions.

Agreed, I cross-posted there.  Please limit replies to the URI list.

Regards,

--=20
Fran=E7ois Yergeau <[email-masked]>
Alis Technologies Inc., Montr=E9al
T=E9l : +1 (514) 747-2547
Fax : +1 (514) 747-2561

Date: Fri, 15 Nov 1996 15:28:10 -0500
To: Ron Daniel <[email-masked]>
From: Francois Yergeau <[email-masked]>
Subject: Re: [URN] Re: I18N does not belong in URNs
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Francois Yergeau <[email-masked]>

=C0 09:27 15-11-96 -0700, Ron Daniel a =E9crit :
>A couple of points here. First, the URI RFC (1630) says that 8-bit
>values should be %encoded.

RFC 1630 is informational, and clearly does not address internationalizat=
ion
issues. This has plagued URLs for a long time, as 8-bit octets have no
defined meaning.

>Not all of the transports through which
>URNs will be sent are 8-bit. An unfortunate fact of life.

True, but of limited relevance.  I'm not calling for forbidding %-encodin=
g,
only for not making it compulsory and burden the whole world *forever* wi=
th
the present-day limitations of basically one Internet "transport" (mail).
If you need to mail an UTF-8 URN, please go ahead and %-encode it, or use
one of the MIME encodings that were designed exactly for that.

>Second, Ryan's "URN Syntax" draft essentially says that, as an optimizat=
ion,
>if a sender and reciever know that they are using an 8-bit clean transpo=
rt,
>then they could sent UTF-8 as octets instead of %HH. This optimization
>may become commonly used, but for compatability with existing software
>we are much safer saying that the standard is %encoded.

This should be exactly the other way around: if you are afraid of a 7-bit
transport, then you MAY %-encode everything.

>Making %encoding the standard seems (to me at least) to be perfectly
>in line with the homily about being conservative in what you send.

The homily is about sending *exactly* what the spec says, not about makin=
g
the spec overly conservative and precluding progress.  Moreover, "Be
conservative in what you send" would mean that with %HH the standard, 8-b=
it
would be effectively forbidden even with 8-bit transports, contradicting =
the
paragraph above.  A useless layer of encoding, plus bandwidth and storage
waste forever.  Not sound design IMHO, there are better ways to deal with
the occasional 7-bit transport than to mandate 7 bits everywhere for all
times; providing a way out for those cases is sufficient.

Regards,

--=20
Fran=E7ois Yergeau <[email-masked]>
Alis Technologies Inc., Montr=E9al
T=E9l : +1 (514) 747-2547
Fax : +1 (514) 747-2561

Subject: Re: [URN] URI internationalization
To: [email-masked] (Ron Daniel)
Date: Fri, 15 Nov 1996 20:01:43 +0100 (MET)
Cc: [email-masked]
Content-Length: 3556
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Hello Ron - Many thanks for your comments. Hope to get more
of these from others in this group.

>Thus spoke Martin J Duerst (at least at 03:57 PM 11/15/96 +0100)
>
>>The internationalization of URNs, URLs, and URIs in general has been
>>raised as a problem or topic in many different places. Given the
>>various recent discussions and the progress made in particular in
>>this group, I think that time has come to address this issue in a
>>more formal way, inside an existing ietf working group or by creating
>>a specific working group for it.
>
>I think I18N for URLs is a more difficult problem than it has been for
>URNs. We have a large number of existing URLs in a variety of character
>sets. Saying "thou shalt use 10646" will meet more resistance than it
>has in this WG, due to backward compatability considerations.

I am very aware of this problem. A lot of it has been discussed e.g.
in the ftp-wg. The basic idea is to have each protocol (and within
that each server) stay with what they have used, but to convert
to using e.g. UTF-8 if and when identification of characters (as
opposed to raw octets) is desired.
Awareness of this fact is why I was repeatedly adressing the question
of what happens with URNs if they don't form correct UTF-8 sequences.

>The first
>question that has to be answered is "Is an I18N scheme for URLs that
>breaks existing URLs acceptable or unacceptable?". If the answer is
>"unacceptable" you have a tremendous technical problem. If the answer
>is "acceptable" you have a MUCH bigger social problem.  Call me a
>coward, but I want no part of the second battle. I want to get on to
>URCs before *all* my hair turns grey.

By getting aware of the fact that correct UTF-8 sequences are really
rare in current URLs, you get more than you would expect.

>While I18N for URLs is a legitimate issue, it is not an issue for the
>URN-WG (IMHO). The URI list is still alive, that might be the proper
>place to begin discussions. I suggest that you wait until the recent
>agreements on UTF-8, %HH, ... for URNs have been codified in the
>Syntax draft, but that is only a suggestion.

Many thanks for these suggestions. One reason of why I wanted to
initiate some discussion now is because next week, there will be
a meeting on WWW i18n in Sevilla, and URI i18n will be one important
topic.

>>The aim would be to produce a document that would include:
>[specific points deleted for brevity]
>
>What you have outlined appears reasonable, but may be best
>handled as a series of documents. As you have outlined it,
>I think you are talking about a 100 page informational RFC.

I guess it will be smaller. I guess we might start with
one document, and split when it gets too large.

>>- What is the best framework/place/list to host this activity.
>
>Your friendly area directors can advise you on this. I suggest
>you come up with an outline of your solution and then ask them if
>it needs a WG or if they want to do a special "last-call" to the
>URI list and some selected experts.

At present, it looks to me like the solution is more or less
defined. Writing the document(s) of course will take some more
time.

>Peer-review of a concrete
>proposal seems to work much better than design by committee.

The reason why I would like to have a WG, or do the work in
the context of a WG, is that I don't want to submit drafts
and RFC in person. Discussions always bring up points that
would have been forgotten, and the work of a WG has (hopefully)
more influence that the work of one or two individuals.

Regards,	Martin.

Subject: Re: [URN] Re: I18N does not belong in URNs
To: [email-masked]
Date: Fri, 15 Nov 1996 19:40:38 +0100 (MET)
Cc: [email-masked], [email-masked]
Content-Length: 4755
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Francois Yergeau wrote:

>I fail to see why the %-encoded URN should be the reference.  This is a
>fallback to the bad old 7-bit days, and results in a needless waste of
>bandwidth and storage resources. Reading the recent report of the IAB
>Character Set Workshop (draft-weider-iab-char-wrkshop-00.txt)

It's nice to have this available finally.

>, I find in
>section 8.2 (Recommendations for new Internet protocols):
>
>  "New protocols do not suffer from the need to be compatible
>   with old 7-bit pipes. New protocol specifications SHOULD
>   use ISO 10646 as the base charset unless there is an
>   overriding need to use a different base charset."

That's indeed what we are doing. Pipe width and base charset are
not directly related.

>Elsewhere (3.4.3), UTF-8 is recommended as the encoding and use of escape
>mechanisms is warned against ("...must be weighed very carefully").

This warns against techniques such as SGML &#nnn;. %HH is not on
the character level, it is on the octet level. And it is already
well established for URLs.

>>   We can define the standard as %-encoded UTF-8, and if people implement
>>this other ways, they are implementing convenience features in the
>>interface: the software will always have the %-encoded URN available.

Much software will probably do so anyway, despite what the standard
says, and without creating a conflict, because storing and comparing
is more efficient on the 8-bit form.

>As if 8-bit octets on-the-wire were something evil!  It is much wiser, IMHO,
>to have the real UTF-8 as the reference value, and have the %-encoding as
>the convenience feature (it must be there anyway for reserved and unsafe
>characters, so there is no risk that an application will not support it).
>If a user needs ASCII-only, let *his* software do the %-encoding for him,
>but let's not force a 9-byte encoding on CJK characters when 3 are enough.
>
>There should be a good reason to burden the whole world forever with
>%-encoding of all 8-bit octets, and I see none at all, except for a visceral
>and unwarranted fear of 8-bit octets.

I think we have to be careful, because there are at least two
ways in which URNs can be transferred/stored:

- In "dedicated" protocols and databases. An example is the header
	of an HTTP request.

- In text. An example is HTML.

For the former, raw 8-bit (i.e. UTF-8) can be used. According to
the standards, officially HTTP headers are limited to ASCII, but
in practice, they will pass 8 bits without problems. (If not,
please don't make a long discussion out of this. It only serves
as an example of a (part of) a protocol that up to now
transmitted "raw" data without consideration to character set
issues.

For the later, as Francois probably knows even better than I do
from his work on URL internationalization, putting an URN with
10646 characters into a HTML document written in iso-8859-1
in raw 8-bit form will produce bad results. Without extremely
clever tool support, it will neither be possible to input
such an URN, nor will an URN show up with the characters it
represents. Transcoding, as well as other operations such as
cut-and-paste, will also not do what everybody would hope for.

Just saying "use 8 bits, use 8 bits" could however give the
impression to some implementors that the UTF-8 8-bit octets
should appear as such in an HTML document in iso-8859-1.

Whatever we make the "standard" or "base" form, or whether
we such a form or not, we should therefore clearly say that
URNs

- Can be transmitted/stored in 8-bit form in protocols/databases
	that accomodate URNs as such, and not as part of text
	and/or associated with character encoding information.
- Have to be interpreted and treated as characters when transmitted
	as part of an encoded text with (explicitly or implicitly)
	associated character encoding information. Those characters
	that cannot be represented in the choosen encoding, as
	well as %HH sequences that do not form valid UTF-8 sequences
	(and of course reserved characters) have to stay in %HH form.

I know that the last point may again frighten some of you. It seems
to introduce a new representation. But if you think about URLs in
EBCDIC, you will see that it is nothing new.

Personally, I think that the second paragraph above could be amended
with a sentence saying that to avoid eventual misinterpretations due
to lack of appropriate information about character encoding, and to
make the URN transcribable to the widest audience, full %HH encoding
can/should be choosen. We may have to discuss about how strong
this wording should be. But we definitely have to include something
that avoids misunderstandings so that raw 8-bit UTF-8 will never
turn up as such in e.g. iso-8859-1 documents.

Regards,	Martin.

Date: Fri, 15 Nov 1996 09:27:55 -0700
To: Francois Yergeau <[email-masked]>
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] Re: I18N does not belong in URNs
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke Francois Yergeau (at least at 10:50 AM 11/15/96 -0500)
>=C0 12:13 14-11-96 -0500, David G. Durand a =E9crit :
>>   We can define the standard as %-encoded UTF-8, and if people implement
>>this other ways, they are implementing convenience features in the
>>interface: the software will always have the %-encoded URN available.
>
>I fail to see why the %-encoded URN should be the reference.  This is a
>fallback to the bad old 7-bit days, and results in a needless waste of
>bandwidth and storage resources.

A couple of points here. First, the URI RFC (1630) says that 8-bit
values should be %encoded. Not all of the transports through which
URNs will be sent are 8-bit. An unfortunate fact of life.

Second, Ryan's "URN Syntax" draft essentially says that, as an optimization,
if a sender and reciever know that they are using an 8-bit clean transport,
then they could sent UTF-8 as octets instead of %HH. This optimization
may become commonly used, but for compatability with existing software
we are much safer saying that the standard is %encoded.

Making %encoding the standard seems (to me at least) to be perfectly
in line with the homily about being conservative in what you send.

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: Fri, 15 Nov 1996 09:05:51 -0700
To: Martin J Duerst <[email-masked]>
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] URI internationalization
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke Martin J Duerst (at least at 03:57 PM 11/15/96 +0100)

>The internationalization of URNs, URLs, and URIs in general has been
>raised as a problem or topic in many different places. Given the
>various recent discussions and the progress made in particular in
>this group, I think that time has come to address this issue in a
>more formal way, inside an existing ietf working group or by creating
>a specific working group for it.

I think I18N for URLs is a more difficult problem than it has been for
URNs. We have a large number of existing URLs in a variety of character
sets. Saying "thou shalt use 10646" will meet more resistance than it
has in this WG, due to backward compatability considerations. The first
question that has to be answered is "Is an I18N scheme for URLs that
breaks existing URLs acceptable or unacceptable?". If the answer is
"unacceptable" you have a tremendous technical problem. If the answer
is "acceptable" you have a MUCH bigger social problem.  Call me a
coward, but I want no part of the second battle. I want to get on to
URCs before *all* my hair turns grey.

While I18N for URLs is a legitimate issue, it is not an issue for the
URN-WG (IMHO). The URI list is still alive, that might be the proper
place to begin discussions. I suggest that you wait until the recent
agreements on UTF-8, %HH, ... for URNs have been codified in the
Syntax draft, but that is only a suggestion.

>The aim would be to produce a document that would include:
[specific points deleted for brevity]

What you have outlined appears reasonable, but may be best
handled as a series of documents. As you have outlined it,
I think you are talking about a 100 page informational RFC.
Splitting it not only makes it easier to read, it makes
it faster to produce since contentious parts don't delay
non-contentious parts.

>- What is the best framework/place/list to host this activity.

Your friendly area directors can advise you on this. I suggest
you come up with an outline of your solution and then ask them if
it needs a WG or if they want to do a special "last-call" to the
URI list and some selected experts. Peer-review of a concrete
proposal seems to work much better than design by committee.

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: Fri, 15 Nov 1996 10:50:24 -0500
To: [email-masked] (David G. Durand)
From: Francois Yergeau <[email-masked]>
Subject: Re: [URN] Re: I18N does not belong in URNs
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Francois Yergeau <[email-masked]>

=C0 12:13 14-11-96 -0500, David G. Durand a =E9crit :
>On the other hand, if the reference
>string is the %-encoded UTF-8 value, then we should be OK for
>transcribability. The issue of user-friendly software that hides %-encod=
ing
>is not part of the protocol, so its _possibility_ shouldn't unduly
>influence us.
>   We can define the standard as %-encoded UTF-8, and if people implemen=
t
>this other ways, they are implementing convenience features in the
>interface: the software will always have the %-encoded URN available.

I fail to see why the %-encoded URN should be the reference.  This is a
fallback to the bad old 7-bit days, and results in a needless waste of
bandwidth and storage resources. Reading the recent report of the IAB
Character Set Workshop (draft-weider-iab-char-wrkshop-00.txt) , I find in
section 8.2 (Recommendations for new Internet protocols):

  "New protocols do not suffer from the need to be compatible
   with old 7-bit pipes. New protocol specifications SHOULD=20
   use ISO 10646 as the base charset unless there is an=20
   overriding need to use a different base charset."

Elsewhere (3.4.3), UTF-8 is recommended as the encoding and use of escape
mechanisms is warned against ("...must be weighed very carefully").

>   We can define the standard as %-encoded UTF-8, and if people implemen=
t
>this other ways, they are implementing convenience features in the
>interface: the software will always have the %-encoded URN available.

As if 8-bit octets on-the-wire were something evil!  It is much wiser, IM=
HO,
to have the real UTF-8 as the reference value, and have the %-encoding as
the convenience feature (it must be there anyway for reserved and unsafe
characters, so there is no risk that an application will not support it).
If a user needs ASCII-only, let *his* software do the %-encoding for him,
but let's not force a 9-byte encoding on CJK characters when 3 are enough.

There should be a good reason to burden the whole world forever with
%-encoding of all 8-bit octets, and I see none at all, except for a visce=
ral
and unwarranted fear of 8-bit octets.

--=20
Fran=E7ois Yergeau <[email-masked]>
Alis Technologies Inc., Montr=E9al
T=E9l : +1 (514) 747-2547
Fax : +1 (514) 747-2561

Subject: [URN] URI internationalization
To: [email-masked]
Date: Fri, 15 Nov 1996 15:57:11 +0100 (MET)
Cc: [email-masked]
Content-Length: 3217
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Ron Daniel wrote:

>Hi,
>
>One of the changes to the "conventions" draft was using text/uri-list
>instead of text/plain as the media type for lists of URIs that would
>be returned by requests such as N2Ls. Here is my first stab at the info
>required to register that type. Any comments before I send it in?
>
>=====================
>
>1. MIME type name: text
>
>
>2. MIME subtype name: uri-list
>
>
>3. Required Parameters: None
>
>
>4. Optional Parameters: charset
>
>   Charset handling for URIs is currently being discussed. This
>   registration shall be updated with a discussion of the interaction
>   of the charset parameter and the upcoming URI charset rules once
>   that interaction is understood.

Several people I am in contact with, and myself, already understand
how this will have to interact. With this mail, I don't want to
force anything into the current draft at a undue time, but I would
like to take this as a chance to address a general topic:

The internationalization of URNs, URLs, and URIs in general has been
raised as a problem or topic in many different places. Given the
various recent discussions and the progress made in particular in
this group, I think that time has come to address this issue in a
more formal way, inside an existing ietf working group or by creating
a specific working group for it.

The aim would be to produce a document that would include:

- 
- A general way to encode the characters used worldwide in URIs.
- Guidelines as to when and how the above general way should be
	used, and what can or should be done if they can or do
	not apply.
- Specifications and guidelines for the use of various forms
	and derivations of the above general way in various
	representations of URIs, e.g. on paper, on screen,
	in text documents, in protocols.
- Guidelines to scheme and protocol designers/implementors
	about how to take worldwide character issues into
	account, and about what to speicify for particular
	URI schemes. Delineation of responsibilites between
	URIs in general and protocols/schemes (so called protocol
	autonomy).
- Specifications and/or guidelines for particular issues related
	to worldwide characters and URIs, such as bidirectionality,
	equivalence, and others.

For this work, I would like suggestions and advice on:

- What is the best framework/place/list to host this activity.
- How to do this (both formal ietf procedure and actual tips).
- What other lists/groups have come upon similar problems,
	should be contacted,...
- Who would be interested to contribute, as wg chair, or whatever.
- What topics have been forgotten in the above list.
- What people generally think about URI internationalisation,
	what ideas they have of how to solve the problem, and
	so on (maybe better save this for the actual discussion).

Many thanks in advance for all your kind help.

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

Subject: Re: [URN] Re: I18N does not belong in URNs
To: [email-masked]
Date: Fri, 15 Nov 1996 12:18:16 +0100 (MET)
Cc: [email-masked]
Content-Length: 2314
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

David G. Durand wrote:

[Sorry: In an earlier mail, I attributed a quote to Mark Fischer when
it indeed came from David G. Durand.]

> UTF-8, with
>%encoding for characters over 127, is a unique transcribable byte sequence
>capable of grandfathering all of the namespaces we have discussed. As long
>as we require naming authorities to use well-defined Unicode names, we can
>even handle non-Unicode characters, by making authorities that need them
>define a policy for their application of the private-use area. consistent
>use of private use characters will guarantee uniqueness, so we are all set!

The mentioning of the private-use area tuches the following problems:

- What to do with characters not in ISO 10646/Unicode.
- What to do with namespaces not defined in terms of characters.
- What to do with URNs that are not valid %HH encoded UTF-8 sequences.

As for characters not in Unicode, this is really a case that should appear
extremely rarely. Unicode already contains an enormous amount of characters
from all kinds of international, national, and corporate standards. And
new scripts and characters are still being added. The use of the private
area(s) should definitely not be openly suggested, but be downplayed as
much as possible.

As for namespaces not defined in terms of characters, we can either
require that they define a solution in terms of ISO 10646 characters,
or we can allow them to define their own solution in terms of octets.
For space and other considerations, they ideally will choose something
similar to the data: URL, but we have to clearly specify what we
tolerate and what not.

If we tolerate direct encoding of arbitrary octets with %HH, then we
have to address the issue of URNs where the %HH ecodings do not reperesent
a correct UTF-8 sequence. Mainly for reasons of cross/backwards compatibility
with URLs, I would suggest that we clearly specify that software
transporting, storing, and manipulating URNs should take them as they
are, even if they are not interpretable as UTF-8. In user-friendly
environments, octets that do not form a valid UTF-8 sequence, as well as
UTF-8 combinations that do not represent characters (the Unicode code
position is undefined) or that cannot be displayed (lack of fonts,...)
should be displayed in %HH notation.

Regards,	Martin.

Subject: Re: [URN] Re: I18N does (somehow) belong in URNs
To: [email-masked]
Date: Fri, 15 Nov 1996 11:44:34 +0100 (MET)
Cc: [email-masked], [email-masked]
Content-Length: 759
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Keith Moore answered Mark Fisher:

>>    We can define the standard as %-encoded UTF-8, and if people implement
>> this other ways, they are implementing convenience features in the
>> interface: the software will always have the %-encoded URN available. This
>> might hurt me in typing in Japanese URNs from a Japanese-language paper
>> publication, but the scenarios where non-Japanese speakers will be doing
>> such tasks are pretty contrived.
>
>This all sounds reasonable to me.  Maybe we've arrived at the best
>possible compromise.

I sounds very reasonable to me too. I hope with can go forward with
this solution. I also think it can serve as a guideline for other,
similar problems, in particular the internationalization of URLs.

Regards,	Martin.

From: Keith Moore <[email-masked]>
To: [email-masked] (David G. Durand)
Cc: [email-masked], [email-masked]
Subject: [URN] Re: I18N does not belong in URNs 
Date: Thu, 14 Nov 1996 22:06:36 -0500
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> This means the human meaningfulness is not a requirement of URNs. This is
> probably good. But it is _not_ as you have claimed, a requirement that URNs
> _not_ be human-readable.

I agree, the charter does not prevent the existence of human-readable URNs.

>     As I have repeatedly pointed out, compatibility with existing
> persistent namespaces will require that at least some human-meaningful
> names be included. The notion of requiring users of FPIs (for instance) to
> hex-encode 50+ character ascii strings stil strikes me a ludicrous. But
> once we allow ASCII, we have to meet the questions of the international
> community. My feeling is that transcribability is a more serious problem
> than the UTF-8 advocates are admitting. On the other hand, if the reference
> string is the %-encoded UTF-8 value, then we should be OK for
> transcribability. The issue of user-friendly software that hides %-encoding
> is not part of the protocol, so its _possibility_ shouldn't unduly
> influence us.
> 
>    We can define the standard as %-encoded UTF-8, and if people implement
> this other ways, they are implementing convenience features in the
> interface: the software will always have the %-encoded URN available. This
> might hurt me in typing in Japanese URNs from a Japanese-language paper
> publication, but the scenarios where non-Japanese speakers will be doing
> such tasks are pretty contrived.

This all sounds reasonable to me.  Maybe we've arrived at the best
possible compromise.

-Keith

Date: Thu, 14 Nov 1996 12:15:35 -0700
To: [email-masked]
From: Ron Daniel <[email-masked]>
Subject: [URN] text/uri-list registration
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Hi,

One of the changes to the "conventions" draft was using text/uri-list
instead of text/plain as the media type for lists of URIs that would
be returned by requests such as N2Ls. Here is my first stab at the info
required to register that type. Any comments before I send it in?

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

1. MIME type name: text

2. MIME subtype name: uri-list

3. Required Parameters: None

4. Optional Parameters: charset

   Charset handling for URIs is currently being discussed. This
   registration shall be updated with a discussion of the interaction
   of the charset parameter and the upcoming URI charset rules once
   that interaction is understood.

5. Encoding Considerations:
  URI encodings are already specified in RFC 1630, ... The URIs
  in the text/uri-list shall conform to those documents. The URI
  encoding rules allow for URIs to be made mail-safe, so additional
  encoding should not be necessary. 

6. Security Considerations:
  Client software should be aware of the security considerations of URIs.
  For example, accessing some URIs can result in sending a death threat to
  a head of state, perhaps spurring a visit from the relevant protective
  service.  Accessing other URIs may result in financial obligations.

  While the legitimate provider of a uri-list can exploit these properties
  for good or ill, they make uri-lists an attractive target for spoofing.
  Further, the lookup and reverse lookup potential of the uri-list may be
  attractive to traffic analysts. URI lists may also reveal confidential
  information, such as the location of sensitive information.

  Because of these considerations, external confidentiality measures should
  be available to protect uri-list responses when appropriate.

7. Interoperability considerations:

   none?

8. Published Specification:

Uniform Resource Locators (URLs) and Uniform Resource Names (URNs) are
two instances of the more general class of identifiers known as
Uniform Resource Identifiers (URIs). URN resolution methods typically
wish to return lists of URLs for a resource so that fault-tolerance and
load balancing can be achieved. The text/uri-list format is intended to
be a very simple format for communicating such lists of URLs (and URNs)
in a form suitable for automatic processing.

The format of text/uri-list resources is:
1) Any lines beginning with the '#' character are comment lines
   and are ignored during processing.
2) The first non-comment line shall be an integer giving the number of
   URIs in the list.
3) The remaining non-comment lines shall be URIs (URNs or URLs), encoded
   according to the URI specification (RFC 1630). Each URI shall appear on
   one and only one line.
4) As for all text/* formats, lines are terminated with a CRLF pair.

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

An example of the format is given below:

     # 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

9. Applications which use this media type:

URN resolvers are the initial applications. Web clients and
proxies are applications that are likely to support this format
in the future.

10. Additional Information:
a) magic number(s)
   none presently

b) file extension(s)
   .uris or .uri recommended

c) Macintish File Type Code(s)
   none presently - "URIs" recommended if no conflict with existing codes?

d) Object Identifier(s) or OID(s)
   none presently  (Should we try to get one or blow it off for now?)

11. Person to contact for further information:
 Name) Ron Daniel  [Of course if someone else wants this...]
 email) [email-masked]

12. Intended usage:
 Common?  Limited use?  [I'm asking for advice here]

13. Author/change controller
  Ron Daniel, [email-masked]  [Of course if someone else wants this...]

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

From: Fisher Mark <[email-masked]>
To: "[email-masked]" <[email-masked]>, Martin J Duerst <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [URN] Re: I18N does not belong in URNs
Date: Thu, 14 Nov 96 14:05:00 EST
Encoding: 48 TEXT
Sender: [email-masked]
Reply-To: Fisher Mark <[email-masked]>

Martin J Duerst writes:
>I have stopped proposing adding i18n support for meaningfulness.
>This argument is not necessary. But I think it is necessary that
>the same amount of meaningfulness is allowed or disallowed to
>users of any language around the globe. This is only guaranteed
>by either radically restricting the character set or completely
>opening it up.

I would further propose that if "meaninglessness" is a requirement, only 
random identifiers will do.  If there is a meaning present, people will use 
it.  I do not, however, think that URNs must necessarily have no meaning to 
humans -- they may, or they may not.  It is up to namespace designer.  (And 
there may be a _lot_ of those!)

Meanwhile, David Durand writes:
>At 5:17 PM 11/13/96, Keith Moore wrote:
>>was imprecise and possibly misleading.  A better statement is:
>>
>>   "URNs aren't intended to serve as human meaningful names".
>>
>>Keith
>
>This means the human meaningfulness is not a requirement of URNs. This is
>probably good. But it is _not_ as you have claimed, a requirement that URNs
>_not_ be human-readable.
>
>    As I have repeatedly pointed out, compatibility with existing
>persistent namespaces will require that at least some human-meaningful
>names be included. The notion of requiring users of FPIs (for instance) to
>hex-encode 50+ character ascii strings stil strikes me a ludicrous. But
>once we allow ASCII, we have to meet the questions of the international
>community. My feeling is that transcribability is a more serious problem
>than the UTF-8 advocates are admitting. On the other hand, if the reference
>string is the %-encoded UTF-8 value, then we should be OK for
>transcribability. The issue of user-friendly software that hides %-encoding
>is not part of the protocol, so its _possibility_ shouldn't unduly
>influence us.

Although UTF-8 is not perfect, it is by far the closest system now existing 
that represents most characters in use today.  If we are to permit but not 
require that URNs have human meanings, and we are not going to force 
grandfathered namespaces to translate their IDs, then UTF-8 is likely the 
best choice for a character encoding scheme, with the reference string as 
the %-encoded UTF-8 value.
======================================================================
Mark Leighton Fisher                   Thomson Consumer Electronics
[email-masked]                   Indianapolis, IN

Date: Thu, 14 Nov 1996 12:13:21 -0500
To: [email-masked]
From: [email-masked] (David G. Durand)
Subject: Re: [URN] Re: I18N does not belong in URNs
Sender: [email-masked]
Reply-To: [email-masked] (David G. Durand)

At 5:17 PM 11/13/96, Keith Moore wrote:
>was imprecise and possibly misleading.  A better statement is:
>
>	"URNs aren't intended to serve as human meaningful names".
>
>Keith

This means the human meaningfulness is not a requirement of URNs. This is
probably good. But it is _not_ as you have claimed, a requirement that URNs
_not_ be human-readable.

    As I have repeatedly pointed out, compatibility with existing
persistent namespaces will require that at least some human-meaningful
names be included. The notion of requiring users of FPIs (for instance) to
hex-encode 50+ character ascii strings stil strikes me a ludicrous. But
once we allow ASCII, we have to meet the questions of the international
community. My feeling is that transcribability is a more serious problem
than the UTF-8 advocates are admitting. On the other hand, if the reference
string is the %-encoded UTF-8 value, then we should be OK for
transcribability. The issue of user-friendly software that hides %-encoding
is not part of the protocol, so its _possibility_ shouldn't unduly
influence us.

   We can define the standard as %-encoded UTF-8, and if people implement
this other ways, they are implementing convenience features in the
interface: the software will always have the %-encoded URN available. This
might hurt me in typing in Japanese URNs from a Japanese-language paper
publication, but the scenarios where non-Japanese speakers will be doing
such tasks are pretty contrived.

   I think Martin's argument that if we let in ASCII, we have let the rest
in, has a lot of merit. And I _know_ that one of the best candidates for
initial URN namespace (FPIs) is ASCII-subset based. So we need to find a
harmless way of having a unique, 7-bit clean bytesequence. UTF-8, with
%encoding for characters over 127, is a unique transcribable byte sequence
capable of grandfathering all of the namespaces we have discussed. As long
as we require naming authorities to use well-defined Unicode names, we can
even handle non-Unicode characters, by making authorities that need them
define a policy for their application of the private-use area. consistent
use of private use characters will guarantee uniqueness, so we are all set!

   -- David

_________________________________________
David Durand              [email-masked]  \  [email-masked]
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

From: "Ryan Moats" <[email-masked]>
To: "Ron Daniel" <[email-masked]>, "Toby Speight" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Thu, 14 Nov 96 11:02:05 
Priority: Normal
Subject: Re: [URN] UTF encodings - why UTF-8? (was: I18N does not belong ...)
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Thu, 14 Nov 1996 08:37:03 -0700, Ron Daniel wrote:

>Thus spoke Toby Speight (at least at 02:48 PM 11/14/96 +0000)
>
>>Would somebody care to explain to me why this double encoding is
>>preferable to, say, UTF-7, 
>
>We looked at UTF-7 awhile back. Our conclusion at that time was that
>UTF-8 would be preferable since UTF-7 would make us add '+' to the list
>of reserved characters and, depending on the context, would affect the
>handling of the '-' character as well.
>

Ron is correct.  We will probably already have % encoding and it didn't
seem to net us much to add '+' encoding as well.

Sorry to be lagging, but keeping up with mail and my real job is starting
to be difficult...

Ryan

Subject: Re: [URN] Re: I18N does not belong in URNs
To: [email-masked]
Date: Thu, 14 Nov 1996 17:30:27 +0100 (MET)
Cc: [email-masked], [email-masked]
Content-Length: 2997
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Keith Moore writes:

>But when people propose adding I18N support to URNs to make them human
>meaningful, I view this as adding a great deal of extra complexity in
>an attempt to make URNs solve a completely different problem than they
>were designed to solve.  (And given the history of various "information 
>infrastructure" groups at failing to narrow their scope to a problem that's 
>solvable in finite time, I get very nervous.)

I have stopped proposing adding i18n support for meaningfulness.
This argument is not necessary. But I think it is necessary that
the same amount of meaningfulness is allowed or disallowed to
users of any language around the globe. This is only guaranteed
by either radically restricting the character set or completely
opening it up.

>By contrast, when people propose adding I18N support to URNs to allow them
>to incorporate URN-like names that happen to include one or two non-universal 
>characters, I wonder things like "Is it really worth the complexity?"

The complexity is low. The only thing you are required to do in
the present proposal is convert between 8-bit and %HH form of URNs
(or normalize mixed forms to one or the other). 8-bit and %HH forms
can easily be distinguished. Conversion is easy. Comparison is easy.
If we change the proposal to say that we only have the %HH form,
then everything is even much more easy.

Presentation as a Unicode string with nice characters is an
user interface issue. Either the browser or the OS/Window system
will implement it anyway (to some degree), or you won't do it.

>and 
>"Which is more important, global scope and transcribability and single 
>encoding or the ability to easily grandfather all URN-like systems?"

If we restrict URNs to the %HH form (disallow 8-bit), but still define
how the %HH-encoded octets represent characters, we indeed would get
both. Existing namespaces could easily be grandfathered in a straight-
forward way, and we would have a single, transcribable encoding.

Even if we stay with the current syntax proposal, the encoding issue
only gets slightly more complex (see above), and average transcribability
will probably be improved. As I have explained in a previous message,
transcribability is a relative issue. If we look at examples such
as transcribing a Japanese account number on a payment slip to an
URN and type it in, allowing the majority of Japanese users to
do it the way they are used and not forcing them to do namespace-
specific calculations on paper is a big win. This win won't in
any way disadvantage a Western user in this case; it will still
be easier for him/her to try to select the character printed on
the payment slip directly with an point-and-click interface than
to try to figure out its namespace-specific coding.

Global scope, of course, depends on the interpretation of the word
"global". I would prefer if this would be done in the sense of
Global Diversity and not in the sense of Global Common Denominator :-).

Regards,	Martin.

Subject: Re: [URN] UTF encodings - why UTF-8? (was: I18N does not belong ...)
To: [email-masked] (Toby Speight)
Date: Thu, 14 Nov 1996 16:50:14 +0100 (MET)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Content-Length: 3165
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Toby Speight wrote:

>Martin> The mapping from the large character set in (2) to the small
>Martin> character set in (1) has to be defined. The one and only
>Martin> existing and reasonable proposal for this is to use UTF-8 and
>Martin> combined with some octet encoding such as %HH.
>
>Would somebody care to explain to me why this double encoding is
>preferable to, say, UTF-7, whose motivation
><URL:http://www.stonehand.com/unicode/standard/utf7.html#x3> says:
>
>UTF-7> ... using UTF-FSS together with the Quoted-Printable content
>UTF-7> transfer encoding of MIME represents US-ASCII characters in one
>UTF-7> octet, but other characters may require up to nine octets.
>
>[MIME Q-P is almost the same as %HH, only with a different escape
>char.  UTF-7 also has the advantage of leaving %HH free for encoding
>reserved characters, if they exist]

Sorry, I was maybe a little too definitive when I said "only existing
and reasonable". And the main disadvantage of using UTF-8 is indeed
that URNs may expand in length. This issue was discussed in this list
before. I have also discussed the issue of UTF-7 vs. UTF-8 (for URLs
in that case) with the creator of UTF-7, David Goldsmith, recently.

Under the premise that we would prefer URN syntax to be reasonably
compatible with URL syntax (not reinvent the weel, reuse code
and functionality, not confuse implementors and users), UTF-7
has serious problems:

- A "+", the character introducing an UTF-7 sequence, is allowed
	in scheme names and some URLs (in particular Gopher+).
	I also seemed to remember a convention that it was used
	to escape a space, but I didn't find that in RFC 1738.
- A "/", used in UTF-7, is a very significant character in
	URLs, and would probably have to be replaced,
	creating a UTF-7 variant.
The basic problem is that UTF-8 is fully compatible with ASCII,
whereas UTF-7 is not.

An additional problem is that UTF-7 can only represent characters
of UCS-4 up to 0x10FFFF, using UTF-16. The full set goes up to
0x7FFFFFFF. Currently, this is a theoretical difference, but
one never knows.

As for size, the difference may not be that large:

max hex		UTF-7		UTF-8		UTF-8		
value		length		length		length
				raw		%HH
0x0000007F	1 or more	1		1
0x000007FF	8/3 +		2		6
0x0000FFFF	8/3 +		3		9
0x0010FFFF	16/3 +		4		12
0x001FFFFF	--		4		12
0x03FFFFFF	--		5		15
0x7FFFFFFF	--		5		15

As an example, to encode a single character from extended Latin
(Latin-1,...), Cyrillic, Greek, Arabic, Hebrew, or Armenian,
one needs a "+", three positions for Base64, and usually
a "-" at the end, which makes 5 positions as long as
we don't have to escape "+". If "+" has to be escaped
in its "start UTF-7" meaning, it will be more. UTF-8
needs 6 positions in %HH form.

For URNs in particular (not for URLs), we can assume
that the occurrence of characters outside ASCII is
rather low. This helps making UTF-8 look somewhat better.

Even if we decide that an URN always has to be in %HH
form, and that anything else would just be GUI sugar,
they can alwasy be transparently converted to raw form
e.g. for storage in a database or for transmission in
a suitably designed protocol.

Regards,	Martin.

Date: Thu, 14 Nov 1996 08:37:03 -0700
To: Toby Speight <[email-masked]>
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] UTF encodings - why UTF-8? (was: I18N does not belong ...)
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke Toby Speight (at least at 02:48 PM 11/14/96 +0000)

>Would somebody care to explain to me why this double encoding is
>preferable to, say, UTF-7, 

We looked at UTF-7 awhile back. Our conclusion at that time was that
UTF-8 would be preferable since UTF-7 would make us add '+' to the list
of reserved characters and, depending on the context, would affect the
handling of the '-' character as well.

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: Martin J Duerst <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: [URN] UTF encodings - why UTF-8? (was: I18N does not belong ...)
From: Toby Speight <[email-masked]>
Date: 14 Nov 1996 14:48:03 +0000
Lines: 42
Organization: ANSA - APM Ltd.
Sender: [email-masked]
Reply-To: Toby Speight <[email-masked]>

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

Martin> Martin J Duerst <URL:mailto:[email-masked]>

>>>>> In article <"josef.ifi..786:14.10.96.13.51.59"@ifi.unizh.ch>,
>>>>> Martin wrote:

Martin> What we need for URNs is at least:

Martin> (1) URNs are represented by characters (on paper, in ASCII,...)
Martin>     from the same set as used in URLs.
Martin> (2) URNs (in general) represent characters (from UCS-4).

Martin> The mapping from the large character set in (2) to the small
Martin> character set in (1) has to be defined. The one and only
Martin> existing and reasonable proposal for this is to use UTF-8 and
Martin> combined with some octet encoding such as %HH.

Would somebody care to explain to me why this double encoding is
preferable to, say, UTF-7, whose motivation
<URL:http://www.stonehand.com/unicode/standard/utf7.html#x3> says:

UTF-7> ... using UTF-FSS together with the Quoted-Printable content
UTF-7> transfer encoding of MIME represents US-ASCII characters in one
UTF-7> octet, but other characters may require up to nine octets.

[MIME Q-P is almost the same as %HH, only with a different escape
char.  UTF-7 also has the advantage of leaving %HH free for encoding
reserved characters, if they exist]



Subject: Re: [URN] I18N does not belong in URNs
To: [email-masked]
Date: Thu, 14 Nov 1996 14:51:52 +0100 (MET)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Content-Length: 10713
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Dirk.vanGulik wrote:

>> Dirk.vanGulik wrote:
> 
>> >Or they use a naming scheme dependent interpretation. You could for
>> >example simply limit the representation of the URN to the glyphs
>> >A-Z, 0-9 and say the dot, dash, and colon. 
>> 
>> Too much in favor of English users (+Hawaiian and Suwaheli)!
>
>Well as a dutch person working in italy in a swiss building; I
>can quite live with it :-) No just kidding, but seriously why
>does this 'favour' ? And where does it come in ?

This has been mentionned before: name spaces in the English-speaking
world usually contain letters and numbers, and their mapping to
the URN syntax you propose above would be straightforward.
Neither the designer of an URN namespace nor the actual users
would have to think much about it.
Name spaces in countries that use other scripts quite often
contain letters in these scripts. Mapping to the URN syntax
you propose above would not directly be possible. Namespace
designers would invent their own schemes, and namespace users
would have to learn all kinds of different conventions for
different namespaces.

I hope that you see that this favors English-speaking users
(and to a lesser extent other users of the Latin script).

>> > I recently came across a specific scheme, say 'crdis' which has a lot of
>> > LocalControlIdentfiers which can (only be fully) expressed in 2-byte octets. 
>> > This obviously gave problems as some of our z39.50 servers and HTTP/URN 
>> > resolving code did not quite like this. A pragmatic solution was to simply
>> > base64 encode the identfication string.
>
>> > A specialist GUI could now base64-decode the string to arrive 
>> > at something meaningfull for a human. But it does not have to. 
>> > And it does keep things simple.
> 
>> I have mentionned earlier the possibility that some namespaces may
>> contain arbitrary data, as opposed to characters, and I have therefore
>
>Hold on, I was trying to convey that these strings did _INDEED_ contain
>meaningfull text;

You only said they contained 2-byte octets. This could be the resource
number of a system icon, or whatever.

>auctually the various 'strings' where short 
>titles in the 19 european languages; carefully protected.

Probably you have to explain more details for us to get the full
picture of this example. Anyway, if they originally were short
titles, i.e. character strings, why invent a complicated name
space specific mapping to URNs? Why not just define a default
mapping (i.e. UTF-8 + %HH) for all possible characters (i.e.
the full ISO 10646 UCS-4)?

>The same could be said of my phone number
>
>	+39 332 78 0014
>
>Which tells a local here that it is me, living in Ispra(78), near Varse
>(33*)in italy(39). But for most people those digits make no sense all,
>nor have to. And my local phone technician might even tell me more by
>just looking at it.

We are not really talking about meaning here. What we are talking
about is the mapping of existing namespaces (however meaningful
or meaningless they are to whoever) to URNs.

>> >I really would like to roll up the charset discussion; I agree that for a lot
>> >of scheme's, in particular those to be grandfathered in, one will need very
>> >flexible encodings.
> 
>> They need to be very flexible in the sense that they have to be
>> able to accomodate a very large set of characters, and something
>> else than characters in some cases.
>
>Well, that is a requirement I do not find in the functional RQ RFC at
>all. Should that be re-written ? I agree that publishers and maintainers
>might like to 'overload' the content; but that is a different issue.

The RQ RFC clearly states that we have to be able to grandfather
existing namespaces. We can do this mainly in two ways:

- Not defining a mapping from arbitrary characters of the
	universal character set to our URN syntax, and just
	tell namespace designers: Solve the problem for yourself.
	In theory, the grandfathering requirement is satisfied
	(even if we restrict syntax to only two different characters).
	The problem is that namespace implementors have to come
	up with their own ideas of how to map characters to URNs,
	resulting in chaos and inconvenience for everybody.
	With this, we get rid of the grandfathering requirement
	by delegating it, but we do not really do our job.

- Defining a mapping from the characters of the universal
	character set (UCS) to URN syntax. This will make
	implementing existing namespaces in URNs much easier.
	We really deal with the grandfathering requirement,
	we don't just pass it around like a hot potato
	(it's not hot and quite easy to handle anyway).
	We seriously do our job as well as we are possibly
	able to do it. We avoid chaos where there is absolutely
	no need for chaos.

>Hmm, I think we have a slight terminology clash; much like the problems
>we have had with the URL rfc. There are several layers, which their
>own dimensions. In URLs (correct me if I am wrong Larry) this is solved
>by saying that the acutal URL is an octet-stream. These 8-bit encoded
>values are all there is. However by 'pure coincidence' they can be
>treated as indexes into a charset such as US-Asicc or latin-1 and
>actually yeild something which humans can interpret quite easily.
>
>But for example the first 5 values (say http:) are not the glyph
>'h', 't', p'p and ':' but the values 68747470 or 4854545. (Upper/
>lowercase),

You got it the wrong way round; please reread RFC 1738 if you don't
believe me. URLs are defined as strings of characters that can
exist on paper or iside a computer (in ASCII or EBCDIC or whatever).
This means that in the URL RFC, the "is" is used for the representING
side. The representED side are indeed octets that appear in a protocol.

The fact that you got terminology wrong while you did not say
much that was actually wrong (if one is restricted to ASCII,
which is the case more often than not) shows that writing
what URL/Ns "are" can lead to a lot of confusion.

The fact that you mention several layers also indicates that
it is dangerous to make one of these layers special by using
the verb "to be". Different people tend to identify different
layers as the most important one.

In my terminology, RFC 1738 says:

(1) URLs are represented by characters (on paper, in ASCII, in
	EBCDIC, or whatever).
(2) URLs represent octets of some protocols.

RFC 1738 also defines the mapping from the octets in (2)
to the characters in (1).

What we need for URNs is at least:

(1) URNs are represented by characters (on paper, in ASCII,...)
	from the same set as used in URLs.
(2) URNs (in general) represent characters (from UCS-4).

The mapping from the large character set in (2) to the small
character set in (1) has to be defined. The one and only
existing and reasonable proposal for this is to use UTF-8
and combined with some octet encoding such as %HH.

>So what I was saying is that the URN is an octet stream; and the
>allowed values are from ox30 to 0x39, 0x41--0x5a etc. Which happen
>to represent indexes into latin-1, UTF-8 or ascii.

But not EBCDIC. For those that have difficulties separating the
different layers, and have difficulties immagining something such
as Japanese, there is an easy trick: Think about EBCDIC. If you
don't at least think about how to handle things in EBCDIC, the
chances are big that you will forget some important aspect of
the problem.

>Now a clever administrator (and a clever GUI) can use something like
>base64 to get a nice UniCode string in.

We don't want the administrator to have to come up with such a mapping,
and we don't want or need to have many different mappings. By just
a little bit of effort from our side, we don't need administrators
to be overly 'clever', and we need GUIs to only support exactly one
kind of presentation conversion (which will really soon be available
in the average Web browser) instead of dozens, hundreds, or thousands
of them (which no Web browser will ever support).

I could live with the definition that an URN "is" an octet stream
if we add (as we have in the current version of the syntax draft)
a specification for how characters from the universal character
set (UCS) should be encoded into URN octets.

>> >	3. And keep a few chars (say the %) in stock, for the future.
>
>> >	4. And remember, one can always make something like a next generation
>> >	   URN+:das:asd which can only be transcribed properly using say UTF8.
> 
>> There is absolutely no need to wait any longer for UTF-8.
> 
>Well, I can agree; but not for the premisse; I do not see the need 
>for the charset flexibilit. I know people can get quite religious about
>their names; so you have a point that we should be flexible to accomodate,
>but on the other hand it does make implementation harder whilst the
>functionality does not increase a bit.

It's not about peoples' names, unless you consider that a namespace
suitable for URNs. It's about actually existing namespaces that contain
characters beyond the set you are proposing.
As for implementation, you are free to provide your browser with a %HH
interface only. For the current syntax draft, you would have to add
a routine that checks for the occurrence of 8-bit bytes, and you
would have to convert them to %HH before comparison. That's about
five lines of C code, not really a hard thing to do.
As for implementing a user interface that allows input and rendering
of the full universal character set (UCS), that indeed is quite
some work, but (1) there is no need to provide full implementation
of all characters, (2) as far as it is needed, it will be done
anyway in the average browser because of requirements from other
protocols and formats (such as HTML), and (3) implementing this
is still tremendously simpler than implementing GUIs for all the
'clever' encoding systems that all those 'clever' administrators
have come up with.

>> All your requirements can be fulfilled by:
> 
>> - Allowing non-character namespaces to create their own non UTF-8 encodings
>> 	(as I have suggested previously).
>> - Require that internally, all 8-bit octets resulting from UTF-8 encoding
>> 	of characters beyond ASCII (+some in ASCII) be encoded with
>> 	%HH, so that there is no 8-bit from of URNs.
> 
>> Although I have good reasons to think that the second point is not needed,
>> I could live with it. But giving up a convention such as UTF-8 to map
>> arbitrary characters in namespaces to URNs would be a great loss.
>
>Well I think I do not see those requirements; but perhaps we should look
>at the RQ RFC again, to see what possibly is missing.

The above requirements are possible refinements of the general requirements
for grandfathering and transcribability.

Regards,	Martin.

Date: Thu, 14 Nov 1996 11:38:37 +0100
From: Dirk vanGulik <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [URN] I18N does not belong in URNs
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Dirk vanGulik <[email-masked]>

> Dirk.vanGulik wrote:
 
> >Or they use a naming scheme dependent interpretation. You could for
> >example simply limit the representation of the URN to the glyphs
> >A-Z, 0-9 and say the dot, dash, and colon. 
> 
> Too much in favor of English users (+Hawaiian and Suwaheli)!

Well as a dutch person working in italy in a swiss building; I
can quite live with it :-) No just kidding, but seriously why
does this 'favour' ? And where does it come in ?
  
> > I recently came across a specific scheme, say 'crdis' which has a lot of
> > LocalControlIdentfiers which can (only be fully) expressed in 2-byte octets. 
> > This obviously gave problems as some of our z39.50 servers and HTTP/URN 
> > resolving code did not quite like this. A pragmatic solution was to simply
> > base64 encode the identfication string.

> > A specialist GUI could now base64-decode the string to arrive 
> > at something meaningfull for a human. But it does not have to. 
> > And it does keep things simple.
 
> I have mentionned earlier the possibility that some namespaces may
> contain arbitrary data, as opposed to characters, and I have therefore

Hold on, I was trying to convey that these strings did _INDEED_ contain
meaningfull text; auctually the various 'strings' where short 
titles in the 19 european languages; carefully protected. So we are
not talking arbitrary strings here; although they *function* as an
arbritary handle. But for the expert their actual content conveys
more than just a number.

The same could be said of my phone number

	+39 332 78 0014

Which tells a local here that it is me, living in Ispra(78), near Varse
(33*)in italy(39). But for most people those digits make no sense all,
nor have to. And my local phone technician might even tell me more by
just looking at it.

> suggested that the requirement that all URNs be UTF-8 should be
> relaxed. I have given the data: URL as an example. Here we have
> an obvious second examlpe.
>  
> >I really would like to roll up the charset discussion; I agree that for a lot
> >of scheme's, in particular those to be grandfathered in, one will need very
> >flexible encodings.
 
> They need to be very flexible in the sense that they have to be
> able to accomodate a very large set of characters, and something
> else than characters in some cases.

Well, that is a requirement I do not find in the functional RQ RFC at
all. Should that be re-written ? I agree that publishers and maintainers
might like to 'overload' the content; but that is a different issue.
 
> But there is absolutely no reason to have arbitrary flexibility
> for those cases where indeed characters have to be represented.
> For this case, it is much easier to specify that UTF-8 be used
> (optionally or even mandatorily with %HH encoding).
 
> >But the internet transfer mechanisms are not quite up to 
> >that yet. So I would suggest:

> >	1. Limit the URNs to just a few chars (along the lines of DNS) This
> >	   also makes comparing URNs easy.
 
> As for the character set *representing* URNs, I can agree. This would
> basically mean that everything has to be %HH encoded.
  
Hmm, I think we have a slight terminology clash; much like the problems
we have had with the URL rfc. There are several layers, which their
own dimensions. In URLs (correct me if I am wrong Larry) this is solved
by saying that the acutal URL is an octet-stream. These 8-bit encoded
values are all there is. However by 'pure coincidence' they can be
treated as indexes into a charset such as US-Asicc or latin-1 and
actually yeild something which humans can interpret quite easily.

But for example the first 5 values (say http:) are not the glyph
'h', 't', p'p and ':' but the values 68747470 or 4854545. (Upper/
lowercase),

So what I was saying is that the URN is an octet stream; and the
allowed values are from ox30 to 0x39, 0x41--0x5a etc. Which happen
to represent indexes into latin-1, UTF-8 or ascii.

Now a clever administrator (and a clever GUI) can use something like
base64 to get a nice UniCode string in.
 
> >	2. Allow, or perhaps even force, each registered naming scheme
> >	   to suggest a possible encoding/escape sequencing to derive
> >	   nice human names from the URN. This can be used by the more
> >	   advanced GUIs.
 
> The greatest majority of naming schemes will have identical problems,
> namely how to represent characters in namespaces. And a single and
> very simple GUI can provide nice human representations for these
> cases (modulo available fonts). And a single and widely applicable
> convention should be used by all naming schemes dealing with
> characters.
 
> >	3. And keep a few chars (say the %) in stock, for the future.

> >	4. And remember, one can always make something like a next generation
> >	   URN+:das:asd which can only be transcribed properly using say UTF8.
 
> There is absolutely no need to wait any longer for UTF-8.
 
Well, I can agree; but not for the premisse; I do not see the need 
for the charset flexibilit. I know people can get quite religious about
their names; so you have a point that we should be flexible to accomodate,
but on the other hand it does make implementation harder whilst the
functionality does not increase a bit.

> >I know that such an encoding essentially wastes space; but that is a tradeoff
> >I am willing to make for simplfied storage, encoding and comparing. 
 
> All your requirements can be fulfilled by:
 
> - Allowing non-character namespaces to create their own non UTF-8 encodings
> 	(as I have suggested previously).
> - Require that internally, all 8-bit octets resulting from UTF-8 encoding
> 	of characters beyond ASCII (+some in ASCII) be encoded with
> 	%HH, so that there is no 8-bit from of URNs.
 
> Although I have good reasons to think that the second point is not needed,
> I could live with it. But giving up a convention such as UTF-8 to map
> arbitrary characters in namespaces to URNs would be a great loss.

Well I think I do not see those requirements; but perhaps we should look
at the RQ RFC again, to see what possibly is missing.

Dw.

From: [email-masked]
To: Martin J Duerst <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Please avoid "URNs are"
Date: Wed, 13 Nov 1996 23:42:34 +0100
Sender: [email-masked]
Reply-To: [email-masked]

Martin,
I very deliberately used "URNs are".

IMHO, we *have* to have agreement on what the basic element of
an URN is; then we can encode to our hearts' content.

The phrase "X is represented by" presupposes (in my mind) that
X *is* something ("das ding an sich") that can be represented
by something else ("das ding f=FCr mich") (apologies to Kant
for mutilating his philosophy!); the representation of the object
presupposes the existence in some "space of ideas" of that object.

For URNs, I believe that we want all representations of an URN
to be such that a computer can check them for equality; this,
I believe, is best achieved by saying that there has to exist
some "ideal URN" in a form that is representable inside a computer,
and that all representations can be turned back into this
"ideal representation", whatever that is.

So yes, I believe that the URN syntax document has to say "URNs are".

         Harald A (for Amateur-philosopher :-)

From: Keith Moore <[email-masked]>
To: Terry Allen <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: I18N does not belong in URNs 
Date: Wed, 13 Nov 1996 17:17:16 -0500
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> Keith writes:
> | As to the former statement, in case there's any doubt as to "URNs aren't 
> | supposed to be human meaningful", I refer interested parties to the group's 
> | charter
> | (http://www.ietf.org/html.charters/urn-charter.html) and to RFC 1737,
> | the requirements of which the charter incorporates by reference.  
> 
> Please cite specific passages in support of your position.

In writing my response to this note (which was just sent to Terry and
Stu, but I'll send a copy to anyone who asks), I realized that my
statement

	"URNs aren't supposed to be human meaningful"

was imprecise and possibly misleading.  A better statement is:

	"URNs aren't intended to serve as human meaningful names".

Keith

From: Keith Moore <[email-masked]>
To: Terry Allen <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Re: I18N does not belong in URNs 
Date: Wed, 13 Nov 1996 16:53:22 -0500
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> Keith writes:
> | As to the former statement, in case there's any doubt as to "URNs aren't 
> | supposed to be human meaningful", I refer interested parties to the group's 
> | charter
> | (http://www.ietf.org/html.charters/urn-charter.html) and to RFC 1737,
> | the requirements of which the charter incorporates by reference.  
> 
> Please cite specific passages in support of your position.

I'll cite them in private mail.  I think the list has seen enough of
this.

Keith

From: "Ronald E. Daniel" <[email-masked]>
Date: Wed, 13 Nov 1996 14:32:11 -0700 (MST)
To: [email-masked]
Subject: [URN] next version of HTTP Conventions draft
Sender: [email-masked]
Reply-To: "Ronald E. Daniel" <[email-masked]>

Here is the revised version of the draft on "Conventions for the Use
of HTTP for URN Resolution". It changes the convention from
   GET <service>/<uri> HTTP/1.x
to
   GET /uri-res/<service>/<uri> HTTP/1.x
Some other changes have been made as a result of feedback from the
list. I'll send it to the ID editors next week after people on this list
have had another chance to comment on it.

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

         Conventions for the Use of HTTP for URN Resolution

[Edits made since last version was sent to the list:
1) Initial "/" 
2) Additional info on status codes.
3) Accept header may limit N2Rs results
4) multipart/alternative as type for N2Rs results
5) text/uri-list instead of text/plain, use Accept: to allow text/http
6) GET /uri-res/<service>/<uri> 
]

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 15 May, 1997.

Abstract:
=========

The URN-WG was formed to specify persistent, location-independent names
for network accessible resources, and resolution mechanisms to retrive
the resources given such a name. At this time the URN-WG is considering
one particular resolution mechanism, the NAPTR proposal. That proposal
does not get the client software all the way from the URN to the resource.
Instead, it gets the client from a URN to a "resolver", which is a system
that can then tell the client where the resource is. The NAPTR draft
defines a "resolution protocol" to be the protocol used to speak to a
resolver in order to obtain the resource, its location(s), or other
information about the resource. The NAPTR proposal allows different
resolution protocols to be used for commuicating with resolvers.

This draft establishes conventions for encoding URN resolution requests
and responses in HTTP 1.0 (and 1.1) requests and responses. The primary
goal of this draft is to define a convention that is simple to implement
and will allow existing HTTP servers to easily add support for URN
resolution. We expect that the resolution databases that arise will be
useful when more sophisticated resolution protocols are developed later.

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 /uri-res/<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 /uri-res/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 /uri-res/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 /uri-res/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 /uri-res/N2L/cid:foo%40huh.com HTTP/1.0
    GET /uri-res/N2L/urn:cid:foo%40huh.com HTTP/1.0

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

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 any special status codes that
are likely to arise.

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

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

The request is encoded as above. The URL MUST be returned in a Location:
header for the convienience of the 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. The Internet Media Type (aka ContentType) of the result
may be negotiated using standard HTTP mechanisms if desired. At a
minimum the resolver should support the text/uri-list media type.
(See Appendix A for the definition of this media type). That media
type is suitable for machine-processing of the list of URLs. Resolvers
may also return the results as text/html, text/plain, or any other
media type they deem suitable.

No matter what the particular media type, the result SHOULD contain
the following information:
 1) An optional comment giving the original URN
 2) An integer giving the number of URLs in the response
 3) The URLs in the response, one per line. These shall be encoded
    according to the URI specification [5].

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 B. 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 /uri-res/N2L http://urn.acl.lanl.gov/cgi-bin/n2l.pl
Redirect /uri-res/L2N http://urn.acl.lanl.gov/cgi-bin/l2n.pl

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

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

The format of text/uri-list resources is:
1) Any lines beginning with the '#' character are comment lines
   and are ignored during processing.
2) The first non-comment line MUST be an integer giving the number of
   URIs in the list.
3) The remaining non-comment lines MUST be URIs (URNs or URLs), encoded
   according to the URI specification RFC[5]. Each URI shall appear on
   one and only one line.
4) As for all text/* formats, lines are terminated with a CR LF pair.

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

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

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

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

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

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

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

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

Ron Daniel
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 15 May, 1997.
Ron Daniel Jr.                   email: [email-masked]
Advanced Computing Lab           voice: (505) 665-0597
MS B-287  TA-3  Bldg. 2011         fax: (505) 665-4939
Los Alamos National Lab           http://www.acl.lanl.gov/~rdaniel/
Los Alamos, NM,  87545    obscure_term: "hypernym"

Date: Wed, 13 Nov 1996 13:30:23 -0800 (PST)
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [URN] Re: I18N does not belong in URNs
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

Keith writes:
| As to the former statement, in case there's any doubt as to "URNs aren't 
| supposed to be human meaningful", I refer interested parties to the group's 
| charter
| (http://www.ietf.org/html.charters/urn-charter.html) and to RFC 1737,
| the requirements of which the charter incorporates by reference.  

Please cite specific passages in support of your position.

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] Please avoid "URNs are"
To: [email-masked] (Keith Moore)
Date: Wed, 13 Nov 1996 22:24:53 +0100 (MET)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Content-Length: 4775
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Keith Moore wrote:

>> >Also, we can't assume that the transcription of a URN from paper to
>> >keyboard will be through an intelligent tool that understands how to
>> >translate URNs from display format to some other format.
>> 
>> You need a reasonably intelligent human user, of course. As for
>> keyboarding tools, in the worst case you would need a Unicode
>> book (cheaper than most keyboards themselves, but unfortunately
>> heavy), a piece of paper, and a code table for the 16 hex digits.
>> As an alternative, I suggest some nice site programmed in Java,
>> or whatever.
>
>Sorry, I just don't buy it.
>
>People aren't going to carry around Unicode books, and they're not
>going to be willing to poke through several pages or screenfuls of
>glphys to find the one matching a particular character in a URN.

The Unicode book was of course meant more as a joke. But it
shows that the minimal requirement, in terms of software, is
really very low. I don't say that it should be done that way.

On the other hand, what are you going to do if you get a
traditional payment slip with a Japanese postal transfer
account number on it, and are requested to send some
money electronically to that account? If you have nothing
but a US keyboard and lynx for Web access, would you prefer
to look up the relevant character in an Unicode book and
do the UCS-2 => UTF-8 => %HH calculations according to a
well-established convention, or would you prefer to have
to search for a document defining how the Japanese postal
transfer account number namespace is mapped to the GCD
character set, and then to get whatever specific standard
you need to determine the encoding of that character,
and then go through a similar encoding procedure?

As another example, if you go to a library in China that
uses some ideographs in their catalog numbers, do you want
to require that the thousands of daily Chinese users learn how
to convert from their traditional catalog numbering system to
what the library has arbitrarily decided to use for encoding
it into URNs (other than some straightforward prefixing),
just that in the rare case that such an URN finds its way to
some Western ignorant, he is able to type it in without
even the slightest effort?

By defining UTF-8 to be used in URNs, we can make life easier
for all Japanese typing in postal transfer account numbers,
and all Chinese users of such catalogs, and many others in
large numbers, while not giving the accidental outside
user much more work than what he might have had anyway.
And we still can rest assured that when you get an URN
from a friend in Japan or China, and that friend is indeed
aware of your ignorance about ideographs, (s)he can send
it in a form (namely %HH) that you will feel sure will not
get mutilated.
[In general, an integrated browser/mail handling system
will not have problems to handle the URN even if it is
Japanese characters (assumed the encoding is correctly
labeled, a requirement which we need anyway). But your
friend may be so kind and take into account your disbelief
in these matters.]

>Pen-style PDAs have enough trouble analyzing latin letters; they
>aren't going to support the ability to enter arbitrary Unicode
>characters anytime soon -- especially not from people who aren't used
>to writing those characters.**

Arbitrary Unicode contains lots of similar-looking instances,
and indeed would be difficult. But if characters from the
usual subsets are used in context, pen input covering pretty
much full Unicode is not so difficult. Please note that for
writers knowing how to write the characters, pen input actually
works better for ideographs than for English.

>From reading RFC 1737, URNs were obviously intended to be composed of
>a small set of characters.  Trying to incorporate all of Unicode into
>URNs is just too big a stretch.

>From reading some parts for RFC 1737, one may definitely get that
impression, in particular if one has never really imagined that
something else could be possible.

But there is nothing in RFC 1737 that requires that we do not
define how other characters are represented in case they need
to be represented. We do not "incorporate all of Unicode" in
the sense that we require every URN to contain at least an
Arabic and a Hebrew character and a CJK Ideograph and so on.
We just make it possible that such characters can be represented
by URLs for those namespaces that have such a requirement.

We also make it possible for namespaces that contain characters
from the base Latin alphabet to be represented in URLs. To be
fair to (almost) all really existing namespaces, we have to
either restrict ourselves to just the digits or so, or to
allow for any character from the universal character set to
be representable.

Regards,	Martin.

From: Keith Moore <[email-masked]>
To: Martin J Duerst <[email-masked]>
Cc: [email-masked] (Keith Moore), [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Please avoid "URNs are" 
Date: Wed, 13 Nov 1996 15:31:47 -0500
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> >> >   o Single encoding: The encoding for presentation for people in clear
> >> >     text, electronic mail and the like is the same as the encoding in
> >> >     other transmissions.
> >> 
> >> This requirement makes sense in the sense that the number of different
> >> representations and encoding should be as low as possible.
> >
> >I hope that "as low as possible" is equivalent to "one".
> 
> Well, with EBCDIC and ASCII, you will certainly have two :-).

Not if we think of URNs as being composed of characters :)

> >> But it does not say anything about how URNs are noted on paper. 
> >
> >No it doesn't.  But it seems reasonable to expect that people will
> >transcribe URNs from their screens to paper, and from that paper to
> >keyboard.  The result of doing so had better produce the same URN.
> 
> Of course. Modulo some problems of the kind of O/0 and l/1/I, it
> will, for all of i18n.

Not if my keyboard doesn't support the characters in the URN.

> >Also, we can't assume that the transcription of a URN from paper to
> >keyboard will be through an intelligent tool that understands how to
> >translate URNs from display format to some other format.
> 
> You need a reasonably intelligent human user, of course. As for
> keyboarding tools, in the worst case you would need a Unicode
> book (cheaper than most keyboards themselves, but unfortunately
> heavy), a piece of paper, and a code table for the 16 hex digits.
> As an alternative, I suggest some nice site programmed in Java,
> or whatever.

Sorry, I just don't buy it.

People aren't going to carry around Unicode books, and they're not
going to be willing to poke through several pages or screenfuls of
glphys to find the one matching a particular character in a URN.
Pen-style PDAs have enough trouble analyzing latin letters; they
aren't going to support the ability to enter arbitrary Unicode
characters anytime soon -- especially not from people who aren't used
to writing those characters.**

>From reading RFC 1737, URNs were obviously intended to be composed of
a small set of characters.  Trying to incorporate all of Unicode into
URNs is just too big a stretch.

Keith

**(And while voice-recognition technology is already good enough to
distinguish latin letters and digits pronounced by random people in
random dialects, it will never be good enough to let people "speak in"
random characters that they've never seen before and don't know how to
prononuce.  I mention this because it seems obvious to me that
personal computers, especially portable ones, are going to support
voice recognition -- a microphone is a lot more portable than either a
keyboard or a writing surface.)

To: apps-working-group-list:;
Subject: [URN] reminder of Internet-Draft cutoff date
Date: Wed, 13 Nov 1996 15:16:58 -0500
From: Keith Moore <[email-masked]>
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

This is just a reminder that the cutoff for Internet-Draft submissions
prior to the San Jose IETF meeting is Tuesday, November 26, 1996 at
1700 Eastern Standard US time.  (I think that's 2200 UTC)

Proposals to be discussed at IETF WG meetings must be submitted
as Internet-Drafts prior to discussion.  So if you want to have 
a proposal discussed at the San Jose IETF, you need to get it 
in before this deadline.  

Please also note that due to the the large number of last-minute 
internet-draft submissions, last-minute drafts require more time 
to appear in the Internet-Drafts repositories.  Given the US 
Thanksgiving holidays on 28-29 November, I wouldn't expect last-minute
drafts to be generally available before 2-3 December or so.

So to give other working group members more time to review drafts,
I encourage people to submit their drafts a few days before the deadline.

For information on how to submit an Internet-Draft, look at
ftp://ftp.ietf.org/ietf/1id-guidelines.txt

Keith Moore
APPS AD 

From: Keith Moore <[email-masked]>
To: [email-masked] (Stu Weibel)
Cc: [email-masked], [email-masked]
Subject: [URN] Re: I18N does not belong in URNs 
Date: Wed, 13 Nov 1996 15:12:48 -0500
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

Stu writes:

> Keith Moore writes:
> 
> > URNs aren't supposed to be human-meaningful.  Making them human-meaningful
> > defeats the purpose of having them be long-term stable.
>  
> This reflects a philosophy, an attitude, a point of view that is NOT
> shared in anything like a consensus in this group.  

As to the latter statement, I agree with you.  Many people do not
believe (or are not yet convinced) that human-meaningful URNs are
inherently nonpersistent over the long term.

Even I will concede that there might be a way out.  Tim Berners-Lee
and others have suggested adding low-precision dates to URNs.  So
(e.g.) the "199610" in the URN urn:inet:kodak.com/199610/gibberish
would fix the meaning of "kodak.com" and any other human-readable
strings within the URN to "the meaning of these words in the tenth
month of 1996".  Maybe that would be sufficient.  There's no way to
know for sure, since it depends on what people do in the future.

As to the former statement, in case there's any doubt as to "URNs aren't 
supposed to be human meaningful", I refer interested parties to the group's 
charter
(http://www.ietf.org/html.charters/urn-charter.html) and to RFC 1737,
the requirements of which the charter incorporates by reference.  

Actually, I recommend that everyone here re-read RFC 1737, with
particular emphasis on the Introduction.  It is a good description
of the problem that this group was created to solve.

> I say again...
> this WG should adopt the *least restrictive* solution that is technologically
> sound and let people do with it what their communities choose.  

That sounds reasonable, but by itself, it's not good engineering sense.

Here's an alternative view for consideration:

	This WG should adopt the *least complex* solution which meets the
	various requirements of its charter, and which does not impose
	unnecessary restrictions beyond those inherent in the problem space.

Of course, both of these positions are extreme.  Usually we want a
solution that is not too complex to implement, but still has some
extra flexibility to allow the solution, once deployed, to adapt to
unanticipated uses.

But when people propose adding I18N support to URNs to make them human
meaningful, I view this as adding a great deal of extra complexity in
an attempt to make URNs solve a completely different problem than they
were designed to solve.  (And given the history of various "information 
infrastructure" groups at failing to narrow their scope to a problem that's 
solvable in finite time, I get very nervous.)

By contrast, when people propose adding I18N support to URNs to allow them
to incorporate URN-like names that happen to include one or two non-universal 
characters, I wonder things like "Is it really worth the complexity?" and 
"Which is more important, global scope and transcribability and single 
encoding or the ability to easily grandfather all URN-like systems?"

Keith

Subject: Re: [URN] Please avoid "URNs are"
To: [email-masked] (Keith Moore)
Date: Wed, 13 Nov 1996 20:54:21 +0100 (MET)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Content-Length: 4344
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Keith Moore wrote:

>> >> PLEASE avoid saying "URNs are XXX". Please use wording such
>> >> as "URNs are noted on paper as XXX", "URNs are represented
>> >> on computers in the following forms...", or "URNs represent
>> >> characters from the following set..." or whatever.
>> >
>> >I'm not sure how much difference it makes.  RFC 1737 requires
>> >the following:
>> >
>> >   o Single encoding: The encoding for presentation for people in clear
>> >     text, electronic mail and the like is the same as the encoding in
>> >     other transmissions.
>> 
>> This requirement makes sense in the sense that the number of different
>> representations and encoding should be as low as possible.
>
>I hope that "as low as possible" is equivalent to "one".

Well, with EBCDIC and ASCII, you will certainly have two :-).

>> But it does not say anything about how URNs are noted on paper. 
>
>No it doesn't.  But it seems reasonable to expect that people will
>transcribe URNs from their screens to paper, and from that paper to
>keyboard.  The result of doing so had better produce the same URN.

Of course. Modulo some problems of the kind of O/0 and l/1/I, it
will, for all of i18n.

>Also, we can't assume that the transcription of a URN from paper to
>keyboard will be through an intelligent tool that understands how to
>translate URNs from display format to some other format.

You need a reasonably intelligent human user, of course. As for
keyboarding tools, in the worst case you would need a Unicode
book (cheaper than most keyboards themselves, but unfortunately
heavy), a piece of paper, and a code table for the 16 hex digits.
As an alternative, I suggest some nice site programmed in Java,
or whatever.

>A URN could
>certainly be sent via email, transcribed to paper, and typed back into
>plain text email by someone else.

For Japanese postal transfer accounts, that would work without
problems, even if the Kanji character appears as such, and not
mutilated to some ASCII-compatible form.
The only thing you have to make sure is that if you cut/paste
something from/to your URN field in a browser, the underlying
encoding is changed appropriately (from ISO-2022-JP in the case
of email to UTF-8, with or without the additional %HH depending
on what is needed). Browsers such as Netscape do conversions
correctly in other instances, so I have no doubt they would
get it right as soon as they know what to do.

>For grandfathering other URN schemes, non-universal characters will
>need to be converted into sequences of universal characters.

International standards use the term "universal character set"
to denote an encompassing set of characters. In order to avoid
misunderstanding by less informed readers, why not use
"greatest-common-denominator characters" or GCD characters
for short.

>That way
>there can be a well-defined conversion from {j.random.naming.scheme}
>to URN, but only one format for the URN once it's converted.  It's
>fine if smart software recognizes certain types of URNs and undoes the
>conversion, so long as the unconverted form is displayed as an
>identifier from {j.random.naming.scheme} and NOT as a URN.

We have been at this point before. It is mainly a naming issue,
and to some extent a protocol encoding issue. You are requesting
that things that don't appear %HH-encoded, but with the origina
characters they represent, are not called URNs. You are also
requesting that there be no 8-bit transfer form.

>As for URNs encoded in EBCDIC: we should probably define URNs as
>sequences of characters,

Here wording really matters. To be clear, it is best to say that
URNs are *represented by* sequences of characters. They *are*
abstract, permanent identifiers or something along these lines.

>which can be represented in any character
>encoding scheme, so long as:
>
>+ that encoding scheme is clearly labeled (e.g. MIME charset) whenever
>multiple encodings can appear in the same context, and
>
>+ there is a unique encoding in that scheme for each character that 
>can appear in a URN.
>
>So URN character sequences could be encoded in ASCII or EBCDIC or
>UCS-32 or whatever and still be URNs.

A small detail: What you mean by UCS-32 is called UCS-4. It might have
been called UCS-31, but not UCS-32, because in the 4-byte form, the
uppermost bit (sign bit) is not used.

Regards,	Martin.

Subject: Re: [URN] I18N does not belong in URNs
To: [email-masked] (Dirk.vanGulik)
Date: Wed, 13 Nov 1996 20:16:12 +0100 (MET)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Content-Length: 3530
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Dirk.vanGulik wrote:

>Or they use a naming scheme dependent interpretation. You could for
>example simply limit the representation of the URN to the glyphs
>A-Z, 0-9 and say the dot, dash, and colon. 

Too much in favor of English users (+Hawaiian and Suwaheli)!

>I recently came across a specific scheme, say 'crdis' which has a lot of
>LocalControlIdentfiers which can (only be fully) expressed in 2-byte octets. 
>This obviously gave problems as some of our z39.50 servers and HTTP/URN resolving
>code did not quite like this. A pragmatic solution was to simply base64
>encode the identfication string.
>
>A specialist GUI could now base64-decode the string to arrive 
>at something meaningfull for a human. But it does not have to. 
>And it does keep things simple.

I have mentionned earlier the possibility that some namespaces may
contain arbitrary data, as opposed to characters, and I have therefore
suggested that the requirement that all URNs be UTF-8 should be
relaxed. I have given the data: URL as an example. Here we have
an obvious second examlpe.

>I really would like to roll up the charset discussion; I agree that for a lot
>of scheme's, in particular those to be grandfathered in, one will need very
>flexible encodings.

They need to be very flexible in the sense that they have to be
able to accomodate a very large set of characters, and something
else than characters in some cases.

But there is absolutely no reason to have arbitrary flexibility
for those cases where indeed characters have to be represented.
For this case, it is much easier to specify that UTF-8 be used
(optionally or even mandatorily with %HH encoding).

>But the internet transfer mechanisms are not quite up to 
>that yet. So I would suggest:
>
>	1. Limit the URNs to just a few chars (along the lines of DNS) This
>	   also makes comparing URNs easy.

As for the character set *representing* URNs, I can agree. This would
basically mean that everything has to be %HH encoded.

>	2. Allow, or perhaps even force, each registered naming scheme
>	   to suggest a possible encoding/escape sequencing to derive
>	   nice human names from the URN. This can be used by the more
>	   advanced GUIs.

The greatest majority of naming schemes will have identical problems,
namely how to represent characters in namespaces. And a single and
very simple GUI can provide nice human representations for these
cases (modulo available fonts). And a single and widely applicable
convention should be used by all naming schemes dealing with
characters.

>	3. And keep a few chars (say the %) in stock, for the future.
>
>	4. And remember, one can always make something like a next generation
>	   URN+:das:asd which can only be transcribed properly using say UTF8.

There is absolutely no need to wait any longer for UTF-8.

>I know that such an encoding essentially wastes space; but that is a tradeoff
>I am willing to make for simplfied storage, encoding and comparing. 

All your requirements can be fulfilled by:

- Allowing non-character namespaces to create their own non UTF-8 encodings
	(as I have suggested previously).
- Require that internally, all 8-bit octets resulting from UTF-8 encoding
	of characters beyond ASCII (+some in ASCII) be encoded with
	%HH, so that there is no 8-bit from of URNs.

Although I have good reasons to think that the second point is not needed,
I could live with it. But giving up a convention such as UTF-8 to map
arbitrary characters in namespaces to URNs would be a great loss.

Regards,	Martin.

From: Keith Moore <[email-masked]>
To: Martin J Duerst <[email-masked]>
Cc: [email-masked] (Keith Moore), [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Please avoid "URNs are" 
Date: Wed, 13 Nov 1996 14:05:06 -0500
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> >> PLEASE avoid saying "URNs are XXX". Please use wording such
> >> as "URNs are noted on paper as XXX", "URNs are represented
> >> on computers in the following forms...", or "URNs represent
> >> characters from the following set..." or whatever.
> >
> >I'm not sure how much difference it makes.  RFC 1737 requires
> >the following:
> >
> >   o Single encoding: The encoding for presentation for people in clear
> >     text, electronic mail and the like is the same as the encoding in
> >     other transmissions.
> 
> This requirement makes sense in the sense that the number of different
> representations and encoding should be as low as possible.

I hope that "as low as possible" is equivalent to "one".

> But it does not say anything about how URNs are noted on paper. 

No it doesn't.  But it seems reasonable to expect that people will
transcribe URNs from their screens to paper, and from that paper to
keyboard.  The result of doing so had better produce the same URN.

Also, we can't assume that the transcription of a URN from paper to
keyboard will be through an intelligent tool that understands how to
translate URNs from display format to some other format.  A URN could
certainly be sent via email, transcribed to paper, and typed back into
plain text email by someone else.

For grandfathering other URN schemes, non-universal characters will
need to be converted into sequences of universal characters.  That way
there can be a well-defined conversion from {j.random.naming.scheme}
to URN, but only one format for the URN once it's converted.  It's
fine if smart software recognizes certain types of URNs and undoes the
conversion, so long as the unconverted form is displayed as an
identifier from {j.random.naming.scheme} and NOT as a URN.

As for URNs encoded in EBCDIC: we should probably define URNs as
sequences of characters, which can be represented in any character
encoding scheme, so long as:

+ that encoding scheme is clearly labeled (e.g. MIME charset) whenever
multiple encodings can appear in the same context, and

+ there is a unique encoding in that scheme for each character that 
can appear in a URN.

So URN character sequences could be encoded in ASCII or EBCDIC or
UCS-32 or whatever and still be URNs.

Keith

Subject: Re: [URN] Please avoid "URNs are"
To: [email-masked] (Keith Moore)
Date: Wed, 13 Nov 1996 19:41:54 +0100 (MET)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Content-Length: 1086
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Keith Moore wrote:

>> PLEASE avoid saying "URNs are XXX". Please use wording such
>> as "URNs are noted on paper as XXX", "URNs are represented
>> on computers in the following forms...", or "URNs represent
>> characters from the following set..." or whatever.
>
>I'm not sure how much difference it makes.  RFC 1737 requires
>the following:
>
>   o Single encoding: The encoding for presentation for people in clear
>     text, electronic mail and the like is the same as the encoding in
>     other transmissions.

This requirement makes sense in the sense that the number of different
representations and encoding should be as low as possible.

But it does not say anything about how URNs are noted on paper. It also
does not say something about how people may finally see it (the encoding
used for presentation could well be %HH, with an intelligent tool
showing Chinese or whatever). In addition, when considering EBCDIC,
it would either forbid URNs to be transmitted with EBCDIC, or would
garble URNs encoded in EBCDIC for the sake of preserving the encoding.

Regards,	Martin.

Subject: Re: [URN] I18N does not belong in URNs
To: [email-masked] (Jim Conklin)
Date: Wed, 13 Nov 1996 19:27:48 +0100 (MET)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Content-Length: 2020
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Jim Conklin wrote:

>  I've been trying to decide how one might allow human-meaningful URNs for
>multiple languages and encodings, and it seems to me that this would be
>possible if and only if the URN identifier itself includes character-set
>information.

Jim - The current proposal implicitly includes character-set information.
This is done by choosing the Universal Character Set (ISO 10646), which
assures that any character in any existing and reasonably used character
set can be used. If you don't know about ISO 10646, also known under
the name Unicode, I can point you to additional information.

Including character set information explicitly would make the URNs
more clumsy, would require applications to handle more and more
character sets, and would have some other disadvantages.

This is independent of whether URNs should/could/should not be
meaningful.

>  Would it make sense to include in the definition of the URN format (yes,
>I know, this is past history!) an optional language and encoding
>specification which could then be used by sufficiently intelligent clients
>to display the URN in the specified language using the specified character
>encoding?

As for encoding, I have given you the answer above.

You now also mention language. I do not think that language
information is necessary for URNs. If you think it is necessary,
can you please explain your reasons, so that I can answer specifically?

>Even the language and encoding could, in that way, be rendered
>in the specified language and, with a (relatively) small number of
>predefined languages and encodings, those could be specified in a small,
>universal symbol set, since they'd normally not be seen by the end user
>with a smart client.

As for "small number of encodings", we have a solution with only
one encoding. That should be small enough a number. As for
"small number of languages", if language information should indeed
be needed, restricting the number of languages would be very
unfair indeed.

Regards,	Martin.

From: Keith Moore <[email-masked]>
To: Martin J Duerst <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] Please avoid "URNs are" 
Date: Wed, 13 Nov 1996 13:25:05 -0500
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> PLEASE avoid saying "URNs are XXX". Please use wording such
> as "URNs are noted on paper as XXX", "URNs are represented
> on computers in the following forms...", or "URNs represent
> characters from the following set..." or whatever.

I'm not sure how much difference it makes.  RFC 1737 requires
the following:

   o Single encoding: The encoding for presentation for people in clear
     text, electronic mail and the like is the same as the encoding in
     other transmissions.

Keith

Subject: Re: [URN] Please avoid "URNs are"
To: [email-masked]
Date: Wed, 13 Nov 1996 19:16:55 +0100 (MET)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Content-Length: 1535
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Harald Alvestran wrote:

>There are about 3 alternatives I can see:
>
>- The URN syntax doc says that URNs are sequences of ASCII
>  characters (or some subset thereof)
>- The URN syntax doc says that URNs are sequences of OCTETS,
>  with no meaning assigned by the URN syntax doc after the
>  second :
>- The URN syntax doc says that URNs are sequences of CHARACTERS,
>  drawn from the ISO 10646 set.
>
>The tradeoffs are different for the 3 cases.

I have followed the followups to this message, but only
have been confused more.

PLEASE avoid saying "URNs are XXX". Please use wording such
as "URNs are noted on paper as XXX", "URNs are represented
on computers in the following forms...", or "URNs represent
characters from the following set..." or whatever.

Except for octet values coinciding with encoded ASCII characters
coinciding with the notation of these same characters on paper
and actually representing these same characters, the distinctions
made above matter very much both to have a clear and working
proposal, and to have this proposal being understood by those
that will need to do so.

When you start to think about i18n issues, it is difficult to
get avay from the simple ASCII world where "representing"
and "represented" are just fillers because everything looks
the same. As Ryan Moats has said earlier, changing your
thinking to accomodate the complexities outside ASCII
can be painful. He at least understands that it has to
be done.

So in future messages, please avoid saying "URNs are".

Regards,	Martin.

Subject: Re: [URN] I18N does not belong in URNs
To: [email-masked] (Larry Masinter)
Date: Wed, 13 Nov 1996 19:02:02 +0100 (MET)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Content-Length: 799
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Larry Masinter wrote:

>#  If (as an example) a Chinese information provider wished to make
>#  available their resources to English speakers as URNs, I would
>#  suspect they would want to provide "English-compatible" URNs,
>#  rather than long, seemingly random %XX-encoded strings.
>
>So the library of China should assign chinese URNs to the information
>they think only Chinese readers will want to read, and ASCII URNs to
>the texts they think might also be of interest to people who don't
>read Chinese?

Probably they shouldn't, but they might. They indeed might already
have some naming scheme for their complete library that includes
Chinese characters and that they want to grandfather.

And there is no rule that for a given resource, there can only
be one single URN.

Regards,	Martin.

Subject: Re: [URN] I18N does not belong in URNs
To: [email-masked] (Larry Masinter)
Date: Wed, 13 Nov 1996 19:06:05 +0100 (MET)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Content-Length: 792
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Larry Masinter wrote:

>So the library of China should assign chinese URNs to the information
>they think only Chinese readers will want to read, and ASCII URNs to
>the texts they think might also be of interest to people who don't
>read Chinese?

Just some additional comment: In case they decide to assign anything
meaningful (which we will tell them not to do, but they still might do),
please note that for many classic texts (as well as for many other
things such as place names, countries, names of persons) there
are established conventions that differ from language to language.
This means that it could be very difficult for a Chinese to identify
a hint to some text in an ASCII URN, although he/she might know
the name of the text, and the text itself, very well.

Regards,	Martin.

Date: Tue, 12 Nov 1996 11:32:38 -0700
To: [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]>

I'm revising the "Conventions for the Use of HTTP for URN Resolution"
draft that I sent to the list awhile back. Before I do so I wanted to
ask the list about one point in Harald's last message on the subject.

Thus spoke [email-masked] (at least at 02:44 PM 11/4/96 +0100)
>(Warning: I'm coming into this without reading the entire debate...)
>
>I like the idea that HTTP GET is an URI to MIME object resolution
>protocol. It either fails or returns a MIME object.
>
>But the scheme of service:/uri would IMHO require registering
>N2L, N2Ls, N2C and so on as URI types; this sounds wrong to me.

Agreed.

>
>If we want a resolution CONVENTION, it seems to me that the right
>convention is "GET /resolve/N2L/<uri>" (mimicking a CGI-BIN script).
>If we want a resolution STANDARD, it seems to me that the right
>thing is "N2L <uri> HTTP/1.1"

I tend to agree that a true resolution STANDARD should define the
new HTTP Methods. However, I was shooting for a simple CONVENTION
for people to follow. The primary goal was to make it easy to retrofit
URN resolution onto existing web servers.

That is the tack that I will continue to follow if there is not a
massive outpouring of derision from the list.

I will change Harald's suggestion from GET /resolve/<service>/<uri>
to GET /uri-res/<service>/<uri> because an Alta Vista search turned
up some instances of /resolve in existing URLs, but no instances of
/uri-res.

>For handing back lists of things, mimic the responses that were put
>into HTTP/1.1 for content negotiation (putting up a header for thte
>machine processible version and HTML for the human-readable version).

Will do.

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], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] I18N does not belong in URNs
From: Larry Masinter <[email-masked]>
Date: Tue, 12 Nov 1996 09:08:44 PST
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

#  If (as an example) a Chinese information provider wished to make
#  available their resources to English speakers as URNs, I would
#  suspect they would want to provide "English-compatible" URNs,
#  rather than long, seemingly random %XX-encoded strings.

So the library of China should assign chinese URNs to the information
they think only Chinese readers will want to read, and ASCII URNs to
the texts they think might also be of interest to people who don't
read Chinese?

Larry

From: Keith Moore <[email-masked]>
To: Fisher Mark <[email-masked]>
Cc: "Dirk.vanGulik" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [URN] I18N does not belong in URNs 
Date: Tue, 12 Nov 1996 11:57:43 -0500
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> >The reason for _not_ allowing any octet in the string after urn: is to
> >avoid entering into the dark realm of having to retrive MIB like display
> >strings whenever you encounter a URN you've not seen before; and which
> >you would like to display to a human in such a way he/she can still
> >transcribe it. Just showing a list of two digit hex numbers would not do.
> 
> Realistically, how often should we expect a resource that we _can_ read to 
> be expressed by a URN that we can't read (i.e. the URN needs the %XX 
> encoding convention)?  I would maintain that this would be the
> unusual case. 

I disagree, for several reasons:

1. many resources don't require a particular language.

2. even if you can read the language, you might not be able to type in
the characters on your keyboard.

3. machines are getting better at automatic language translation.
it's entirely possible, perhaps likely, that in a few years your web
browser will have plugins that let it translate from other languages
to the one you read best.  it might not be as good as being able to
read the original language, but it will be good enough to understand
most of what's being said.

URNs are defined to have global scope.  A name that is usable only by
a Chinese speaker (or for that matter, an English speaker) isn't a
URN.

The reason you assign a URN to something is to make it usable by a
potentially global audience for a potentially long time.  (That
doesn't mean that it's usable by anybody -- there can always be access
controls-- but it does mean that who can use the resource isn't
pre-determined when the name is assigned.)

If you don't want your resource to be globally usable, don't give it a
URN.  Or conversely, if you want to prevent someone who doesn't speak
your language from trying to read your resources, URNs aren't the
right mechanism for doing this.

>  Otherwise, we might as well go with sequences of random digits.

Yes, that's much closer to what URNs are (IMHO) supposed to be.
It also has the advantage of being much easier to implement.

Keith

Date: Tue, 12 Nov 1996 09:58:34 -0700
To: [email-masked] (Stu Weibel), [email-masked]
From: Ron Daniel <[email-masked]>
Subject: Re: [URN] I18N does not belong in URNs
Sender: [email-masked]
Reply-To: Ron Daniel <[email-masked]>

Thus spoke Stu Weibel (at least at 01:56 PM 11/11/96 -0500)
>I say again...
>this WG should adopt the *least restrictive* solution that is technologically
>sound and let people do with it what their communities choose.  

Amen.

I recommend:
 1) New namespace proposals get standards-track review (or at least
    come out as experimental RFCs). This will allow namespaces that
    are obviously bad to be weeded out.
 2) We develop an informational RFC on recommended practices for namespaces.
    This can discuss the problems that arise with persistence for friendly
    names. Namespaces that want to allow friendly, persistent names can then
    look to this guide for the questions they will have to answer when their
    namespace proposal comes up for standards-track review. (Someone else
    suggested this earlier).

Issues of allowed characters are essentially orthogonal to friendliness.
We have the example of the Japanese bank account. We also have the example
of things like Library of Congress call numbers, which contain a subset
of the Latin letters, digits, and some punctuation. (LCCNs are probably not
going to make a good URN namespace, but its not due to issues of friendliness).

I'm not at all thrilled by proposals to restrict URNs to digits. That
seems overly restrictive. The place to prevent crappy namespaces is when
they come up for review, not (IMHO) trying to forestall their appearance
by restricting the character set.

This still leaves us with the ASCII-only vs. 10646-only vs. multiple charset
positions. I'll take that up in another message.

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, 12 Nov 1996 17:41:34 +0100
From: "Dirk.vanGulik" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: [URN] Re: Harald's syntax proposals [Somewhat Long] (was I18N does not belong in URNs)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "Dirk.vanGulik" <[email-masked]>

"Ryan Moats" <[email-masked]> wrote

> On Tue, 12 Nov 1996 16:50:36 +0100, Dirk.vanGulik wrote:
> 
> >> To me, the extension (as written) has a couple of holes.  The URN has to have
> >> information about the namespace so that the resolver can resolve the URN
> >> correctly (it took me a while to realize that the proper parsing of option B is
> >> the second ":").  Therefore, having no meaning after the optional "urn:"
> >> doesn't work.
> >
> >I realized this as well; but was (and still am) unsure how to effectuate this;
> >because is implies that the bit between the first to ':' is really limited in
> >encoding. Something which has bothered me in the syntax document. But I have
> >no immediate solution for it.
> 
> This is on purpose.  The more you free up the NID encoding, the more you restrict
> potential implementations.
> 
> >Well: (Which each char actualy being an octet, etc..)
> >
> >	[<] urn:NS:OPS [>]
> >
> >	NS consists of A..Z, 0..9
> >	OPS consists of A..Z, 0..9, '-', '_' and '.'
> >
> >	The '-','_','.' are kept in reserve for the NS
> >
> >	Whitespace is allowed
> >
> >Would be kind of simple.
> 
> Yes, and we may reach something like this eventually (there would
> have to be more characters added to the NSS to support grandfathered
> spaces.  There are just some tradeoffs that we would have to agree upon.

Well the whole point was to 'fudge' this grandfathering; and force (almost)
all of it to use an encoding scheme of some kind; but naturally they _ONLY_
have to know about this encoding when they want to go in- or out- to the
old grandfathered in scheme; and then quite naturally they know what the
secret encoding trick is.

One of the main points I would like to get across is that all this grand-
fathering only matters on the interface between the grandfather and this
new born URN daughter; and exactly on that interface there is all the room
in the world to do say a base64 to XYZ decoding.

> >> >A
> >> >> - The URN syntax doc says that URNs are sequences of ASCII
> >> >>   characters (or some subset thereof)
> >> 
> >> This is of course, the simplest.  A minimum of transport encoding would be
> >> involved.  There may be some reserved characters that would be need to be
> >> encoded on a namespace specific basis but those could be done with
> >> %HH encoding.
> >
> >Which would imply namespace specific encapsulation needs; which kind of imposes
> >external NS knowledge on arbritary clients.
> 
> Somebody will have to know this anyway.  I'm not saying that all the reserved characters
> have to be in the syntax document (in fact I'm saying they can't).  I'm saying that any
> reserved character should be encoded with %HH, which is slightly different.

Yes; and I woudl really like to argue that there should be NO encoding on this level
at all; the syntax document should be entirely free of it. It might be that in a document
which details how some kind of differnt scheme is grandfathered into a certain NS, one
will have to detail all this; but that is completely outside the URN syntax document
I hope.
 
As a conclusion; I think we quite agree; but compared to you I would prefer the encoding
to be pushed away further from the URN, and actually not be a part of it; whereas you would
actually allow the URN to consist of arbitrary octets which are encoded with a limited set ?
Or am I wrong again ?

> >> >B
> >> >> - The URN syntax doc says that URNs are sequences of OCTETS,
> >> >>   with no meaning assigned by the URN syntax doc after the
> >> >>   second  ':'
> >> 
> >> I've modified the above to point up the ':' character.  This is the "opaque string"
> >> option.  This option would require some transport encoding for 8-bit unclean pipes.
> >> I see presentation as the major trade-off here.  For 8-bit unfriendly schemes,
> >> something like the %HH scheme would be needed.  For others, the %HH scheme
> >> could be mixed with actual glyphs that are representation of that octet (or sequence
> >> of octets) in that presentation scheme.  However, THIS IS ONLY FOR THE
> >> CONVIENCE OF THE PRESENTATION SCHEME, NOT THE USER!!!!
> >> The other difficulty is that reserved characters have to be limited to
> >> a subset of ASCII or there is the possibility for encoding collisions that would require
> >> the syntax doc to specify its own encoding scheme.

> >Somehow not very practical ? IMHO.
 
> I didn't say it was practical, just tried to state what the tradeoffs are.

Point taken. I was trying to state a point as well :-)

Dw.

From: "Ryan Moats" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 12 Nov 96 10:19:43 
Priority: Normal
Subject: [URN] Re: Harald's syntax proposals [Somewhat Long] (was I18N does not belong in URNs)
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Tue, 12 Nov 1996 16:50:36 +0100, Dirk.vanGulik wrote:

>> To me, the extension (as written) has a couple of holes.  The URN has to have
>> information about the namespace so that the resolver can resolve the URN
>> correctly (it took me a while to realize that the proper parsing of option B is
>> the second ":").  Therefore, having no meaning after the optional "urn:"
>> doesn't work.
>
>I realized this as well; but was (and still am) unsure how to effectuate this;
>because is implies that the bit between the first to ':' is really limited in
>encoding. Something which has bothered me in the syntax document. But I have
>no immediate solution for it.

This is on purpose.  The more you free up the NID encoding, the more you restrict
potential implementations.

>Well: (Which each char actualy being an octet, etc..)
>
>	[<] urn:NS:OPS [>]
>
>	NS consists of A..Z, 0..9
>	OPS consists of A..Z, 0..9, '-', '_' and '.'
>
>	The '-','_','.' are kept in reserve for the NS
>
>	Whitespace is allowed
>
>Would be kind of simple.

Yes, and we may reach something like this eventually (there would
have to be more characters added to the NSS to support grandfathered
spaces.  There are just some tradeoffs that we would have to agree upon.

>> >A
>> >> - The URN syntax doc says that URNs are sequences of ASCII
>> >>   characters (or some subset thereof)
>> 
>> This is of course, the simplest.  A minimum of transport encoding would be
>> involved.  There may be some reserved characters that would be need to be
>> encoded on a namespace specific basis but those could be done with
>> %HH encoding.
>
>Which would imply namespace specific encapsulation needs; which kind of imposes
>external NS knowledge on arbritary clients.

Somebody will have to know this anyway.  I'm not saying that all the reserved characters
have to be in the syntax document (in fact I'm saying they can't).  I'm saying that any
reserved character should be encoded with %HH, which is slightly different.

>> >B
>> >> - The URN syntax doc says that URNs are sequences of OCTETS,
>> >>   with no meaning assigned by the URN syntax doc after the
>> >>   second  ':'
>> 
>> I've modified the above to point up the ':' character.  This is the "opaque string"
>> option.  This option would require some transport encoding for 8-bit unclean pipes.
>> I see presentation as the major trade-off here.  For 8-bit unfriendly schemes,
>> something like the %HH scheme would be needed.  For others, the %HH scheme
>> could be mixed with actual glyphs that are representation of that octet (or sequence
>> of octets) in that presentation scheme.  However, THIS IS ONLY FOR THE
>> CONVIENCE OF THE PRESENTATION SCHEME, NOT THE USER!!!!
>> The other difficulty is that reserved characters have to be limited to
>> a subset of ASCII or there is the possibility for encoding collisions that would require
>> the syntax doc to specify its own encoding scheme.
>> 
>
>Somehow not very practical ? IMHO.

I didn't say it was practical, just tried to state what the tradeoffs are.

Ryan

P.S.  Sorry folks, I think I was in such a hurry to send the last comment off that I
didn't admit who wrote it.

Date: Tue, 12 Nov 1996 16:50:36 +0100
From: "Dirk.vanGulik" <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: [URN] Re: Harald's syntax proposals [Somewhat Long] (was I18N does not belong in URNs)
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "Dirk.vanGulik" <[email-masked]>

> To me, the extension (as written) has a couple of holes.  The URN has to have
> information about the namespace so that the resolver can resolve the URN
> correctly (it took me a while to realize that the proper parsing of option B is
> the second ":").  Therefore, having no meaning after the optional "urn:"
> doesn't work.

I realized this as well; but was (and still am) unsure how to effectuate this;
because is implies that the bit between the first to ':' is really limited in
encoding. Something which has bothered me in the syntax document. But I have
no immediate solution for it.

> The second hole is that while having an interpretation for a specific namespace
> defined in a separate namespace document is reasonable (in fact I don't see
> how to avoid it) defining general castings in external documents doesn't

No, the MIB refernce was meant half in yest; and in fact I hope it will not
come to this; i.e. that most generic clients using URNs will simply hardly
ever show them to the user. However for very specialist (and also for practical
reasons) people close to the data might like specific castings a lot; especialy
when the keys in your mother database are easily derivable. But the rest of the
world should not care; and the references in external document  to the display
encoding is really only there to satisfy the curiosity and the very specialist
users of that NS.

> strike me as a big win.  I still believe we can keep the syntax doc reasonably
> short while solving the small problem in front of us.

Well: (Which each char actualy being an octet, etc..)

	[<] urn:NS:OPS [>]

	NS consists of A..Z, 0..9
	OPS consists of A..Z, 0..9, '-', '_' and '.'

	The '-','_','.' are kept in reserve for the NS

	Whitespace is allowed

Would be kind of simple.

> This being said, if the holes are plugged up, option D could be a reasonable
> alternative
> 
> Now, back to Harald's proposals, I'll try to synopsize them with my thoughts 
> on the tradeoffs
> 
> >A
> >> - The URN syntax doc says that URNs are sequences of ASCII
> >>   characters (or some subset thereof)
> 
> This is of course, the simplest.  A minimum of transport encoding would be
> involved.  There may be some reserved characters that would be need to be
> encoded on a namespace specific basis but those could be done with
> %HH encoding.

Which would imply namespace specific encapsulation needs; which kind of imposes
external NS knowledge on arbritary clients.

> >B
> >> - The URN syntax doc says that URNs are sequences of OCTETS,
> >>   with no meaning assigned by the URN syntax doc after the
> >>   second  ':'
> 
> I've modified the above to point up the ':' character.  This is the "opaque string"
> option.  This option would require some transport encoding for 8-bit unclean pipes.
> I see presentation as the major trade-off here.  For 8-bit unfriendly schemes,
> something like the %HH scheme would be needed.  For others, the %HH scheme
> could be mixed with actual glyphs that are representation of that octet (or sequence
> of octets) in that presentation scheme.  However, THIS IS ONLY FOR THE
> CONVIENCE OF THE PRESENTATION SCHEME, NOT THE USER!!!!
> The other difficulty is that reserved characters have to be limited to
> a subset of ASCII or there is the possibility for encoding collisions that would require
> the syntax doc to specify its own encoding scheme.
> 

Somehow not very practical ? IMHO.

Dw.

From: "Ryan Moats" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Tue, 12 Nov 96 09:22:43 
Priority: Normal
Subject: [URN] Re: Harald's syntax proposals [Somewhat Long] (was I18N does not belong in URNs)
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Tue, 12 Nov 1996 14:09:34 +0100, Dirk.vanGulik wrote:

>Harald wrote:
>> There are about 3 alternatives I can see:
> 
>A
>> - The URN syntax doc says that URNs are sequences of ASCII
>>   characters (or some subset thereof)
>
>B
>> - The URN syntax doc says that URNs are sequences of OCTETS,
>>   with no meaning assigned by the URN syntax doc after the
>>   second :
>
>C
>> - The URN syntax doc says that URNs are sequences of CHARACTERS,
>>   drawn from the ISO 10646 set.
> 
>> The tradeoffs are different for the 3 cases.
>
>To extend on this, IMHO very sensible, concept: as it gives room
>to sensible wire definitions:
>
>D. Augmenting, case 'B'; 
>
>The URN syntax docs says the URNs are sequences of
>OCTETS, whose value comes from a specific range '*' with no meaning 
>assigned by the URN sysntax doc after the first four octets (which 
>are the indexes of the glyphs 'u','r','n' and ':' in charset-XYZ.)
>
>Where the range '*' is; when each octed is taken as in index  into
>charset-XYZ, is from the range (say) A-Z, 0-9, '_', '-', ":' and '.'
>
>I'd suggest ISO-8859, US-ASCII, NISO, etc for charset-XYZ.
>
>For each naming scheme an interpretation/casting can be defined for 
>the part of the URN after the name-scheme-identifier.
>
>For the 'inet' (or x-dns-2) name-schme; the suggested interpretation is
>as indexes into 8 bit encoded 7bit ASCII (or ISO-8859-1 or whatever).
>
>Would that be of (some) use?
>
>The reason for _not_ allowing any octet in the string after urn: is to
>avoid entering into the dark realm of having to retrive MIB like display
>strings whenever you encounter a URN you've not seen before; and which
>you would like to display to a human in such a way he/she can still
>transcribe it. Just showing a list of two digit hex numbers would not do.
>
>Although overloading yet another DNS query type to get the display string
>could be fun on the 'display-string'.name-scheme.urn.net level :-)
>
>Dw.

To me, the extension (as written) has a couple of holes.  The URN has to have
information about the namespace so that the resolver can resolve the URN
correctly (it took me a while to realize that the proper parsing of option B is
the second ":").  Therefore, having no meaning after the optional "urn:"
doesn't work.

The second hole is that while having an interpretation for a specific namespace
defined in a separate namespace document is reasonable (in fact I don't see
how to avoid it) defining general castings in external documents doesn't
strike me as a big win.  I still believe we can keep the syntax doc reasonably
short while solving the small problem in front of us.

This being said, if the holes are plugged up, option D could be a reasonable
alternative

Now, back to Harald's proposals, I'll try to synopsize them with my thoughts 
on the tradeoffs

>A
>> - The URN syntax doc says that URNs are sequences of ASCII
>>   characters (or some subset thereof)

This is of course, the simplest.  A minimum of transport encoding would be
involved.  There may be some reserved characters that would be need to be
encoded on a namespace specific basis but those could be done with
%HH encoding.

>B
>> - The URN syntax doc says that URNs are sequences of OCTETS,
>>   with no meaning assigned by the URN syntax doc after the
>>   second  ':'

I've modified the above to point up the ':' character.  This is the "opaque string"
option.  This option would require some transport encoding for 8-bit unclean pipes.
I see presentation as the major trade-off here.  For 8-bit unfriendly schemes,
something like the %HH scheme would be needed.  For others, the %HH scheme
could be mixed with actual glyphs that are representation of that octet (or sequence
of octets) in that presentation scheme.  However, THIS IS ONLY FOR THE
CONVIENCE OF THE PRESENTATION SCHEME, NOT THE USER!!!!
The other difficulty is that reserved characters have to be limited to
a subset of ASCII or there is the possibility for encoding collisions that would require
the syntax doc to specify its own encoding scheme.

>C
>> - The URN syntax doc says that URNs are sequences of CHARACTERS,
>>   drawn from the ISO 10646 set.
> 
>> The tradeoffs are different for the 3 cases.

This last one has most of the issues above. There are probably others that I
haven't thought of, mainly because I don't claim to be an expert in the ins and outs
of 7-bit and 8-bit friendliness.

Having synopsized the plusses and minuses of these, there are some common issues:

If we restrict the range of octets for the NSS (this is option A and option D) then
a lot of the trasnport encoding, reserved character encoding and related issues go away.

If we allow any octet (option B and C) then transport encoding becomes a minor issue
and reserved character encoding must be considered.  

Everything else (to me right now at least) is related to presentation and meta-interpretation
(by humans) of the NSS.  I'm not sure if these should intrude into the syntax doc.

Date: Tue, 12 Nov 1996 15:49:40 +0100
From: "Dirk.vanGulik" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [URN] I18N does not belong in URNs
Cc: [email-masked]
Sender: [email-masked]
Reply-To: "Dirk.vanGulik" <[email-masked]>

> >The reason for _not_ allowing any octet in the string after urn: is to
> >avoid entering into the dark realm of having to retrive MIB like display
> >strings whenever you encounter a URN you've not seen before; and which
> >you would like to display to a human in such a way he/she can still
> >transcribe it. Just showing a list of two digit hex numbers would not do.
 
> Realistically, how often should we expect a resource that we _can_ read to 
> be expressed by a URN that we can't read (i.e. the URN needs the %XX 
> encoding convention)?  I would maintain that this would be the unusual case. 
 
> If (as an example) a Chinese information provider wished to make available 
> their resources to English speakers as URNs, I would suspect they would want 
> to provide "English-compatible" URNs, rather than long, seemingly random 
> %XX-encoded strings.  Conversely (and for example), an Austrailian 
> information provider that wants to market their information to native Arabic 
> speakers (who are not necessarily English speakers) would want to provide 
> their URNs in an "Arabic-compatible" form, rather than the foreign-looking 
> English alphabet.
 
Well, that would be an expectation of something which resembles 'URL's on steroids;
my, personal, take on this is a bit different. We are seeing all sorts of collections
being opened up; each with some kind of local identifier or control number; often
closely tied to the language and habits of the -original- maintainers. A lot of the
'objects' in these collections have different views, depending on who you are, what
you have paid, what your preferences and access permisisons are.

So quite quickly you end up with the identifier of say a Technical Maintenance
document of a, say, phillips KT52 TV frame or a the left wing SPL bolt installation
a manual of a MD123 aeroplane. Which just happens to be avaible in quite a few
languages. Although for the original maintainers there might be a language in 
which the local control identifier beared some relevance, but for most users
that relation is gone (and it was based on obsuce 8 char abbreviattions anyway).

> Although I would expect content-negotiation to be used on URNs, if the URN 
> resource is to be used widely by the native speaker of a language, it would 
> be better expressed in a form compatible with their native language. 

Yes; that is a common human desire; worth allowing for. Which means some kind
of transcription of a reasonable number of languages and charset. Which still
are compatible with all others. Hence my simplified (and optional) Base64 kind 
of encoding for name-schemes which need this.

> Otherwise, we might as well go with sequences of random digits.

Well; that is certainly what they conceptually could be to an 'alien' from
Mars; or a native japanese only speaker. And there is nothign wrong with that.

Dw.

From: Fisher Mark <[email-masked]>
To: "Dirk.vanGulik" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [URN] I18N does not belong in URNs
Date: Tue, 12 Nov 96 09:37:00 EST
Encoding: 26 TEXT
Sender: [email-masked]
Reply-To: Fisher Mark <[email-masked]>

>The reason for _not_ allowing any octet in the string after urn: is to
>avoid entering into the dark realm of having to retrive MIB like display
>strings whenever you encounter a URN you've not seen before; and which
>you would like to display to a human in such a way he/she can still
>transcribe it. Just showing a list of two digit hex numbers would not do.

Realistically, how often should we expect a resource that we _can_ read to 
be expressed by a URN that we can't read (i.e. the URN needs the %XX 
encoding convention)?  I would maintain that this would be the unusual case. 
 If (as an example) a Chinese information provider wished to make available 
their resources to English speakers as URNs, I would suspect they would want 
to provide "English-compatible" URNs, rather than long, seemingly random 
%XX-encoded strings.  Conversely (and for example), an Austrailian 
information provider that wants to market their information to native Arabic 
speakers (who are not necessarily English speakers) would want to provide 
their URNs in an "Arabic-compatible" form, rather than the foreign-looking 
English alphabet.

Although I would expect content-negotiation to be used on URNs, if the URN 
resource is to be used widely by the native speaker of a language, it would 
be better expressed in a form compatible with their native language. 
 Otherwise, we might as well go with sequences of random digits.
======================================================================
Mark Leighton Fisher                   Thomson Consumer Electronics
[email-masked]                   Indianapolis, IN

Date: Tue, 12 Nov 1996 14:09:34 +0100
From: "Dirk.vanGulik" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [URN] I18N does not belong in URNs
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "Dirk.vanGulik" <[email-masked]>

Harald wrote:
> There are about 3 alternatives I can see:
 
A
> - The URN syntax doc says that URNs are sequences of ASCII
>   characters (or some subset thereof)

B
> - The URN syntax doc says that URNs are sequences of OCTETS,
>   with no meaning assigned by the URN syntax doc after the
>   second :

C
> - The URN syntax doc says that URNs are sequences of CHARACTERS,
>   drawn from the ISO 10646 set.
 
> The tradeoffs are different for the 3 cases.

To extend on this, IMHO very sensible, concept: as it gives room
to sensible wire definitions:

D. Augmenting, case 'B'; 

The URN syntax docs says the URNs are sequences of
OCTETS, whose value comes from a specific range '*' with no meaning 
assigned by the URN sysntax doc after the first four octets (which 
are the indexes of the glyphs 'u','r','n' and ':' in charset-XYZ.)

Where the range '*' is; when each octed is taken as in index  into
charset-XYZ, is from the range (say) A-Z, 0-9, '_', '-', ":' and '.'

I'd suggest ISO-8859, US-ASCII, NISO, etc for charset-XYZ.

For each naming scheme an interpretation/casting can be defined for 
the part of the URN after the name-scheme-identifier.

For the 'inet' (or x-dns-2) name-schme; the suggested interpretation is
as indexes into 8 bit encoded 7bit ASCII (or ISO-8859-1 or whatever).

Would that be of (some) use?

The reason for _not_ allowing any octet in the string after urn: is to
avoid entering into the dark realm of having to retrive MIB like display
strings whenever you encounter a URN you've not seen before; and which
you would like to display to a human in such a way he/she can still
transcribe it. Just showing a list of two digit hex numbers would not do.

Although overloading yet another DNS query type to get the display string
could be fun on the 'display-string'.name-scheme.urn.net level :-)

Dw.

From: "James K. Tauber" <[email-masked]>
To: "David G. Durand" <[email-masked]>, <[email-masked]>
Subject: Re: [URN] Readable Names (was: I18N does not belong in URNs)
Date: Tue, 12 Nov 1996 11:55:20 +0800
Sender: [email-masked]
Reply-To: "James K. Tauber" <[email-masked]>

>    I think James Tauber (of Sun?) already has an FPI resolution 
> prototype operating.

Formerly of Sun. Now back at the University of Western Australia.

The fact that SP supports FPI resolution means that we now have a robust
(human readable) namespace that is widely deployed, has a registration
procedure (that's also widely deployed if you count ISBN owner identifiers)
AND is resolvable here and now.

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: Mon, 11 Nov 1996 21:54:29 -0500
To: [email-masked]
From: [email-masked] (David G. Durand)
Subject: [URN] Readable Names (was: I18N does not belong in URNs)
Sender: [email-masked]
Reply-To: [email-masked] (David G. Durand)

>Jim,
>
>URNs aren't supposed to be human-meaningful.  Making them human-meaningful
>defeats the purpose of having them be long-term stable.
>
>Keith

  Please,  stop saying this. Repeating the same thing over and over again
does not make it true. Read ISO 9070, or any book on SGML, for an example,
of a namespace that falsifies your claim. You may prefer another style of
URN, and no one will stop you from doing so, but the repeated _false_
assertion that such a namespace cannot exist is annoying. The fact that
there is a namespace already deployed with reasonable social mechanisms to
guarantee uniqueness and persistence is what really bugs me about this
repeated assertion.

   The argument that typing the meaningful ASCII-subset string in FPIs as a
hex-encoded byte sequence will improve reliability falls on its own merits,
as far as I can see.

   I think James Tauber (of Sun?) already has an FPI resolution prototype
operating.

   You have shown one thing in your previous arguments: that long-term
persistence may impair long-term human-friendliness.  Since this problem is
as old as recorded history (Cuneiform was reader-friendly, once), I'm
neither excited, surprised, or worried, about it.

   -- David

_________________________________________
David Durand              [email-masked]  \  [email-masked]
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

From: [email-masked]
To: "Dirk.vanGulik" <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] I18N does not belong in URNs
Date: Mon, 11 Nov 1996 18:40:44 +0100
Sender: [email-masked]
Reply-To: [email-masked]

There are about 3 alternatives I can see:

- The URN syntax doc says that URNs are sequences of ASCII
  characters (or some subset thereof)
- The URN syntax doc says that URNs are sequences of OCTETS,
  with no meaning assigned by the URN syntax doc after the
  second :
- The URN syntax doc says that URNs are sequences of CHARACTERS,
  drawn from the ISO 10646 set.

The tradeoffs are different for the 3 cases.

                Harald

Date: Mon, 11 Nov 1996 16:46:28 -0500
To: Keith Moore <[email-masked]>, [email-masked]
From: [email-masked] (Jim Conklin)
Subject: Re: [URN] I18N does not belong in URNs
Sender: [email-masked]
Reply-To: [email-masked] (Jim Conklin)

At 1:05 PM 11/11/96, Keith Moore wrote:
>Jim,
>
>URNs aren't supposed to be human-meaningful.  Making them human-meaningful
>defeats the purpose of having them be long-term stable.
>
>Keith

Keith,
  It may be just my slowness, but you haven't convinced me of that yet.

Jim

Date: Mon, 11 Nov 1996 13:56:14 -0500
From: [email-masked] (Stu Weibel)
To: [email-masked]
Subject: Re: [URN] I18N does not belong in URNs
Sender: [email-masked]
Reply-To: [email-masked] (Stu Weibel)

> From [email-masked] Mon Nov 11 13:22:32 1996
> Errors-To: [email-masked]
> Errors-To: [email-masked]
Keith Moore writes:

> URNs aren't supposed to be human-meaningful.  Making them human-meaningful
> defeats the purpose of having them be long-term stable.
 
This reflects a philosophy, an attitude, a point of view that is NOT
shared in anything like a consensus in this group.  I say again...
this WG should adopt the *least restrictive* solution that is technologically
sound and let people do with it what their communities choose.  

This group has no business enforcing naming philosophy on the applications
or systems that will deploy URN solutions.

stu

From: Keith Moore <[email-masked]>
To: [email-masked] (Jim Conklin)
Cc: "Dirk.vanGulik" <[email-masked]>, [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] I18N does not belong in URNs 
Date: Mon, 11 Nov 1996 13:05:41 -0500
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

Jim,

URNs aren't supposed to be human-meaningful.  Making them human-meaningful
defeats the purpose of having them be long-term stable.

Keith

Date: Mon, 11 Nov 1996 11:59:15 -0500
To: "Dirk.vanGulik" <[email-masked]>, [email-masked], [email-masked]
From: [email-masked] (Jim Conklin)
Subject: Re: [URN] I18N does not belong in URNs
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: [email-masked] (Jim Conklin)

multiple languages and encodings, and it seems to me that this would be
possible if and only if the URN identifier itself includes character-set
information.
  Would it make sense to include in the definition of the URN format (yes,
I know, this is past history!) an optional language and encoding
specification which could then be used by sufficiently intelligent clients
to display the URN in the specified language using the specified character
encoding?  Even the language and encoding could, in that way, be rendered
in the specified language and, with a (relatively) small number of
predefined languages and encodings, those could be specified in a small,
universal symbol set, since they'd normally not be seen by the end user
with a smart client.

Jim

Date: Mon, 11 Nov 1996 14:13:30 +0100
From: "Dirk.vanGulik" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [URN] I18N does not belong in URNs
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: "Dirk.vanGulik" <[email-masked]>

>
> > So, I see only 2 basic directions URN identifiers can go:
> > 
> >      1) Totally opaque, random numeric strings; or
> > 
> >      2) I18N character strings with appropriate encoding,
> >      preferably (IMHO) as UTF-8.
> >
> > There really is no middle ground -- if there is a pattern there, people will 
> > make use of it and screw up the system.
> 
> As an example that there *is* middle ground, I suggest:
> 
> 3) URNs are assigned by the "system" without regard to the content
> that they name. (in other words, totally opaque, but not restricted to
> numerals)
> 
> This way, they can be composed of a larger character set without being
> human meaningful.
> 
> We can't restrict character sets too much because of the need to
> grandfather existing URN spaces.
> 

Or they use a naming scheme dependent interpretation. You could for
example simply limit the representation of the URN to the glyphs
A-Z, 0-9 and say the dot, dash, and colon. 

I recently came across a specific scheme, say 'crdis' which has a lot of
LocalControlIdentfiers which can (only be fully) expressed in 2-byte octets. 
This obviously gave problems as some of our z39.50 servers and HTTP/URN resolving
code did not quite like this. A pragmatic solution was to simply base64
encode the identfication string.

A specialist GUI could now base64-decode the string to arrive 
at something meaningfull for a human. But it does not have to. 
And it does keep things simple.

I really would like to roll up the charset discussion; I agree that for a lot
of scheme's, in particular those to be grandfathered in, one will need very
flexible encodings. But the internet transfer mechanisms are not quite up to 
that yet. So I would suggest:

	1. Limit the URNs to just a few chars (along the lines of DNS) This
	   also makes comparing URNs easy.

	2. Allow, or perhaps even force, each registered naming scheme
	   to suggest a possible encoding/escape sequencing to derive
	   nice human names from the URN. This can be used by the more
	   advanced GUIs.

	3. And keep a few chars (say the %) in stock, for the future.

	4. And remember, one can always make something like a next generation
	   URN+:das:asd which can only be transcribed properly using say UTF8.
	   or has its own charset/encoding/language triple.

I know that such an encoding essentially wastes space; but that is a tradeoff
I am willing to make for simplfied storage, encoding and comparing. 

Just my twohundred lires worth.

Dw.

From: "Ryan Moats" <[email-masked]>
To: "Martin J Duerst" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 08 Nov 96 08:26:17 
Priority: Normal
Subject: Re: [URN] Almost an encoding agreement?! (was: I18N does not belong in
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Fri, 8 Nov 1996 15:18:59 +0100 (MET), Martin J Duerst wrote:

>Ryan Moats wrote:
>
>>This look very similar to what is in the syntax draft now, with one exception
>>(i.e. I like it but I see one "small" problem)
>>
>>If you go down this path, you need to ensure that if the namespace uses
>>some octet in a reserved fasion, the character corresponding to the octet
>>in ASCII would need to be %XX escaped when used in a literal sense.
>>Further, unless you want real problems, we need to restrict the set of 
>>reserved characters to printable ASCII (minus some exceptions that get
>>escaped already).
>
>We have been speaking about escaping characters before. Now you
>speak about escaping octets. For ASCII, this may be the same,
>but for UTF-8, it isn't.

Oops, it looks like this was sloppy wording/thinking on my part...
Octet == character above, but I got momentarily confused (so what else
is new?)

Ryan

Subject: Re: [URN] Almost an encoding agreement?! (was: I18N does not belong in
To: [email-masked]
Date: Fri, 8 Nov 1996 15:18:59 +0100 (MET)
Cc: [email-masked], [email-masked], [email-masked]
Content-Length: 1049
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Ryan Moats wrote:

>This look very similar to what is in the syntax draft now, with one exception
>(i.e. I like it but I see one "small" problem)
>
>If you go down this path, you need to ensure that if the namespace uses
>some octet in a reserved fasion, the character corresponding to the octet
>in ASCII would need to be %XX escaped when used in a literal sense.
>Further, unless you want real problems, we need to restrict the set of 
>reserved characters to printable ASCII (minus some exceptions that get
>escaped already).

We have been speaking about escaping characters before. Now you
speak about escaping octets. For ASCII, this may be the same,
but for UTF-8, it isn't.

Anyway, I guess it is okay to restrict reserved characters to an
ASCII subset plus those characters that don't appear in the namespace
in question and therefore don't have to be escaped. As an example
for the later, "-" might be called a reserved character for
ISBNs, but there is no need to escape it, because it doesn't
appear in the ISBN proper.

Regards,	Martin.

Subject: Re: [URN] I18N does not belong in URNs
To: [email-masked]
Date: Fri, 8 Nov 1996 14:20:16 +0100 (MET)
Cc: [email-masked], [email-masked]
Content-Length: 5560
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Keith Moore wrote:

>> >> So for grandfathering, we have two choices.
>> >> 
>> >> 1) We interpret it as "direct grandfathering of characters",
>> >> 	in which case we have to allow a really wide range
>> >> 	of characters (i.e. ISO 10646).
>> >> 2) We interpret it as "indirect grandfathering", in which
>> >> 	case the digits, or whatever small set, will be
>> >> 	enough.
>> >
>> >I suspect there will be some of each.
>> 
>> I wouldn't mind "some of each", if this means "about the same
>> amount for everybody on the world". If it comes to mean "a lot
>> for English-speaking, but very little for the rest of the world",
>> I would have to strongly disagree.
>
>Martin,
>
>Please accept that I agree with you here.  I don't want Internet
>information access protocols to be significantly biased in favor of
>English speakers (or anybody else).
>
>I say "please accept" because if you accept that we substantially
>agree on the above, it's a lot easier to understand the rest of what
>I'm saying.

I have no problems if you agree, of course :-). I just wanted to make
sure that there was no misunderstanding.

As for the rest of your mail, I agree to much of it. I am indifferent
on the point of meaningfulness, but I leave the decision on that to
those that care about it either way.

>> You may agree with the above point, or you may disagree. But
>> either way, ASCII only is unfair. If you think that naming
>> schemes, protocols, standards, some review board, or whatever,
>> can assure that no meaningful stuff is created, then there
>> is no reason to restrict to ASCII. 
>
>The working group needs to decide which is more important -- being
>able to grandfather in existing URN-like name spaces from everywhere
>on the planet, or having all URNs be transcribable by anyone on the
>planet.  I could certainly make a case for a subset of ASCII-only
>based on the latter consideration.

As I said, I would be ready to accept that, if it is a tight
restriction of ASCII. The most of letters I would probably
be ready to accept is A-F if we are going Hex.

Of course, I would prefer it, for the benefit of everyone,
if direct grandfathering would be choosen.

>Perhaps the right thing to do is to define a mapping to be used when
>grandfathering existing non-ASCII namespaces to URNs, i.e. to encode
>the non-ASCII characters as UTF-8 and then encode each octet not
>printable in ASCII using %XX notation.  That way, people could still
>type in resource names like they're accustomed to doing, but the
>program they type them in to would convert them to canonical URN
>format (by prepending URN:namespace: and doing the UTF-8 and %XX
>encoding).  For purposes of resolution, URNs would always be
>transmitted in canonical format, but programs could decode the %XX and
>UTF-8 for the purposes of display to humans.

"always transmitted in canonical format" is a bit frightening,
because it can make URNs unduely long in some cases.
But in principle, I agree, and as Ryan has said, your proposal
is just about the same as what the syntaxt draft currently says.

>There's probably more than one organization in the world named ICRC.
>The one your brother works for got ICRC.COM first, but the name is
>still ambiguous.  You could have as easily found the a different ICRC
>than the one you were looking for.

It's icrc.ORG. It is a true organization, not a company. Its name and
especially its "logo", the red cross, are protected by special
international treaties. It may be less known in the more peaceful
regions of the world, though.

Anyway, there was a chance that I would hit something else. But
if I estimate that the chance is lower than 10%, and that it takes
me 10 times more time to go through a search service, I will take
the bet easily. For 10 things I look at, I will spend 20 time
units that way. If I start with a search service just because
I *might* be wrong, I will spend 100 time units for 10 lookups.

>> If it can be that human-friendly, and that unambiguous, I don't know why
>> I should go to a search service to find the ICRC. And I don't know
>> why people that use other scripts should go though a serach service,
>> while English speaking users don't have to do so.
>
>All names are unambiguous only within a limited context.  When the net
>was small, the context was inherently limited, so it didn't cause a
>problem to have only one host for any given name.  But now that the
>net is much larger, it is a big problem.  
>
>The whole huge mess over ownership of domain names, the InterNIC's
>capriciousness in deciding who gets what domain within .COM, and all
>of the hair-brained proposals to add tons of vanity-plate top-level
>domains -- ALL of this is caused by the lack of support for
>human-friendly names in the Internet infrastructure, and the resulting
>misuse of DNS to do a job it wasn't designed to do.  We're not going
>to misuse URNs in the same way.

I don't want URNs to be misused that way. But I, and many others,
want something that can be used that way, without having to go
through a search service when I see something on a cardboard box.

>> No, but English can be used in URLs, and I get an unambigous
>> result if there is one, in due time. In Japanese, even if the
>> result would be unambiguous, I currently can't get it fast and
>> easily.
>
>Which is better - an ambiguous result which is usually correct, or an
>unambiguous result which is often incorrect?

An unambiguous result which is often correct. This is what we have
now. And I have made the calculations above.

Regards,	Martin.

From: [email-masked]
To: Daniel LaLiberte <[email-masked]>
Cc: [email-masked] (Leslie Daigle), "Karen R. Sollins" <[email-masked]>, [email-masked]
Subject: Re: [URN] some comments
Date: Fri, 08 Nov 1996 10:08:31 +0100
Sender: [email-masked]
Reply-To: [email-masked]

[email-masked] said:
> Had I known we were going to be held to the details of the charter, I 
> would have spoken up at that time.  But, honestly, would it have 
> mattered? 
You would certainly have gotten feedback, which might have led you
to not bringing up this question now. I don't know if the charter would
have changed.

[email-masked] said:
> But my whole point is that *because* the supposed difference between 
> URLs and URNs (the identifiers, not the resolution mechanisms) does 
> not exist, it is irrelevant to creating a solution, except for syntax 
> and other arbitrary constraints. 

The status quo is that unless the URN WG is able to do something about it,
URLs are all that exist, and people will do what they have to do with them.
So if you're right, you win by default.

[email-masked] said:
> >One of the things that we have to do, unfortunately, to get a 
> >solution to that limited problem, is to ask those who want to work on 
> >a different problem to leave.

> So it has come to that, eh?  As I've stated, we'll continue the 
> discussion off-line.  But are you saying we shouldn't bother? 

No reason to go off-line; I suggest the former URI WG's list as a nice
place to discuss the meta-issue of whether URNs are the right thing or not.

If, in some other forum, the participants in this forum agree that what
they are doing here won't work - fine; I'm sure I'll hear about it.

But here - we are discussing how to make them work, and discussions on
whether they are the right thing or not are not appropriate.

[email-masked] said:
> You should know that many experiments turn into standard practice.  
> If you want it to really be "just an experiment", perhaps you should 
> consider finding a way to kill it off afterwards so it doesn't escape 
> from the lab. :-) 

In the case of NAPTR, there's a simple way: Remove the urn.net domain
from the root nameservers :-)
But if it becomes standard practice, the experiment kind of succeeded,
didn't it?

                 Harald A

From: [email-masked]
To: Bob Briscoe <[email-masked]>
Cc: Fisher Mark <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [URN] Persistence as part of URN framework
Date: Fri, 08 Nov 1996 09:46:46 +0100
Sender: [email-masked]
Reply-To: [email-masked]

OK - I see what you mean.
Five roles, all different:

- URN assigner (guarantees uniqueness of URNs)
- URN buyer (gets an URN to apply to his work)
- URN referer (puts references to others' work using URN)
- URN user (clicks on the URN reference)
- URN resolver (makes magic happen for the URN user)

The assigner and the buyer have to have some agreement; if the buyer
assigns his own URL, the agreement should be easy :-)
The resolver may be the assigner, or someone the assigner has an
agreement with, or it may be someone (reference.com? archive.org? oclc?)
that does the resolution without bothering to ask anyone about it.

What you're looking for is some kind of "minimum guarantee" from the
assigner/buyer to the referer about the quality of resolution services
that will be present in the future.

Right?

                        Harald A

From: Renato Iannella <[email-masked]>
Date: Fri, 8 Nov 1996 09:40:50 +1000 (EST)
To: [email-masked]
Cc: [email-masked]
Subject: Re[4]: [URN] Resolution Services (N2L etc)
Sender: [email-masked]
Reply-To: Renato Iannella <[email-masked]>

Bob Briscoe <[email-masked]> wrote:
> 
> So now, the URN resolution service is doing authentication of metadata too!

You seem to have made the assumption that a URC is a big massive
set of metadata (authenticated, secure etc) when in reality,  a URC
can be whatever _your_ organisation decides (ie BT = Happy)

The URN stuff will support its resolution - the client will then do
all the hard work.

> 
> What I was complaining about is the apparent assumption that the same URN
> would be used for both URN and URC and one would have to say N2C if you
> wanted the former, and N2L for the latter.

If you have a URC - which only has a URL in it - then doing either
N2C or N2L will return that single URL. This will enable you to have
a URN pointing directly to the resource (albeit, via a small URC), then
a trusted-third party can provide the full descriptions etc...

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: Thu, 7 Nov 1996 18:02:24 -0500
To: [email-masked]
From: [email-masked] (David G. Durand)
Subject: Re: [URN] I18N does not belong in URNs
Sender: [email-masked]
Reply-To: [email-masked] (David G. Durand)

At 4:09 PM 11/7/96, Keith Moore wrote:
>Please accept that I agree with you here.  I don't want Internet
>information access protocols to be significantly biased in favor of
>English speakers (or anybody else).
>
>I say "please accept" because if you accept that we substantially
>agree on the above, it's a lot easier to understand the rest of what
>I'm saying.
>
>For the case of URNs, I have no problem with the idea that they should
>not be friendly to English speakers -- because they really shouldn't
>be freindly to anybody, except to be transcribable!
>
>On the other hand, we can hardly prohibit some rare and occasional
>misuse of URNs such that human-friendly meaning creeps in.  And we've
>long since established the need to grandfather in existing name spaces
>that have the characteristics of URNs.  Some of those name spaces are
>going to have some minimal human-friendliness, some degree of meaning
>exposed in the names.  But there won't be much human-friendliness in
>any name space that gets grandfathered in, as any naming scheme which
>tries to embed lots of meaning in the names will inherently have poor
>persistence and thus be unsuitable for URNs.

I am tired of your repeating this. I have pointed out that the URN space of
ISO Formal public identifiers is human-friendly (to English speakers, and
you can bet the revision will be to the rest of the world). Those
identifiers are assigned according to rules that are supposed to guarantee
uniqueness. As they are in common productive use in the SGML world (which
certainly has a significant relationship to the WWW) is a reason that they
will be grandfathered in.

So your assertion is simply _false_. So, now given that FPIs will be
English-speaker friendly, and grandfathered into URN-space, what do you
propose to do about it? I have worries about I18N becuase it seems to fail
the transcribability test (for arbitrary transcribers) -- but I don't want
to be a cultural imperialist, and I don't see any special virtue in ASCII
other than omnipresence.

   Creating "unfriendly" namespaces may seem good practice to you, but I
don't see how it can be mandatory, no matter how much you wish it to be so.

>I agree that it may be difficult to get most people to understand that
>URNs are not human-friendly names (since it's been difficult to do
>even within this WG).

I think it's an unreasonable requirement. That's why it's so hard to
convince people of it.

>Perhaps the right thing to do is to define a mapping to be used when
>grandfathering existing non-ASCII namespaces to URNs, i.e. to encode
>the non-ASCII characters as UTF-8 and then encode each octet not
>printable in ASCII using %XX notation.  That way, people could still
>type in resource names like they're accustomed to doing, but the
>program they type them in to would convert them to canonical URN
>format (by prepending URN:namespace: and doing the UTF-8 and %XX
>encoding).  For purposes of resolution, URNs would always be
>transmitted in canonical format, but programs could decode the %XX and
>UTF-8 for the purposes of display to humans.

So what does this get other than harder-to-debug network protocols? If we
define a standard translation, and make sure that it's an equivalence
relation (as seems to be required), then why not just transmit it the
normal way. Once it can be seen in meaningful form, it _will_ be
transmitted that way from human to human, regardless of any
numericalization we try to impose.

>
>There's probably more than one organization in the world named ICRC.
>The one your brother works for got ICRC.COM first, but the name is
>still ambiguous.  You could have as easily found the a different ICRC
>than the one you were looking for.

But once the name is assigned, you will never get the other ICRC.COM, so it
doesn't matter. Even if one of the ICRCs goes out of business, ICRC.COM
will not be reassigned. So no problem! The ISO naming rules (simple
hierarchy, with well known roots) already can ensure this.

>All names are unambiguous only within a limited context.  When the net
>was small, the context was inherently limited, so it didn't cause a
>problem to have only one host for any given name.  But now that the
>net is much larger, it is a big problem.

The only context that matters is the policies that we set up of URN
management. Once a subset of the namespace is assigned it can't be
reassigned.

>Part of this is because you'll already be restricting the context of
>the search -- if you're looking for the name of a business
>organization, you'll go to a service that matches user-friendly names
>against names of businesses.  If you're looking for a person's name,
>you'll use a different service.
If URNs are assigned to have the properties of URNs they will still be
persistent. No-one is arguing that URNs should be designed to be
meaningfully searched, just that they may be designed to be meaningfully
remembered. If your memory fails or your attempt to deduce things from
other names you have seen fails, then you just have to find the right name
(maybe via some kind of directory search).

Obscure names are obscure, but they are not any more reliable for that.

   -- David

_________________________________________
David Durand              [email-masked]  \  [email-masked]
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

From: [email-masked] (Leslie Daigle)
Date: Thu, 7 Nov 1996 17:48:33 -0500
To: [email-masked]
Subject: [URN] Enough, already.
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked] (Leslie Daigle)

Okay, all else has failed...

I would like ot request that anyone who has the interests of seeing this
work move forward take a BREATHER from this topic -- call it an early
weekend.

There is much left to be discussed about a number of different issues --
of the things that have been discussed, some bear relevance to the work of this
group and should be dealt with in an orderly fashion.  As Karen mentioned, 
she is working on revised framework and requirements material, and that should
provide a good focus for meaty discussions, when it is available.  Let's
wait a bit, rather than just chasing the theoretical around in circles --
that does not do justice to the opinions and viewpoints of anyone.

Leslie.
URN WG Co-Chair.

-- 

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

  "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: "Ryan Moats" <[email-masked]>
To: "Keith Moore" <[email-masked]>, "Martin J Duerst" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 07 Nov 96 15:50:23 
Priority: Normal
Subject: [URN] Almost an encoding agreement?! (was: I18N does not belong in URNs)
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Thu, 07 Nov 1996 16:09:28 -0500, Keith Moore wrote:

>Perhaps the right thing to do is to define a mapping to be used when
>grandfathering existing non-ASCII namespaces to URNs, i.e. to encode
>the non-ASCII characters as UTF-8 and then encode each octet not
>printable in ASCII using %XX notation.  That way, people could still
>type in resource names like they're accustomed to doing, but the
>program they type them in to would convert them to canonical URN
>format (by prepending URN:namespace: and doing the UTF-8 and %XX
>encoding).  For purposes of resolution, URNs would always be
>transmitted in canonical format, but programs could decode the %XX and
>UTF-8 for the purposes of display to humans.

Keith-

This look very similar to what is in the syntax draft now, with one exception
(i.e. I like it but I see one "small" problem)

If you go down this path, you need to ensure that if the namespace uses
some octet in a reserved fasion, the character corresponding to the octet
in ASCII would need to be %XX escaped when used in a literal sense.
Further, unless you want real problems, we need to restrict the set of 
reserved characters to printable ASCII (minus some exceptions that get
escaped already).

Is this acceptable?

Ryan

From: Keith Moore <[email-masked]>
To: Daniel LaLiberte <[email-masked]>
Cc: Keith Moore <[email-masked]>, "Gregory J. Woodhouse" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Names and Locations (was [URN] some comments) 
Date: Thu, 07 Nov 1996 16:43:31 -0500
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

>  > I believe the URN: prefix is essential, but not for this reason.  As
>  > I've said before, the difference between URNs and URLs should have
>  > more to do with the properties of each name space than how they are
>  > resolved.
> 
> But the properties of an identifier that are visible to a client (from
> the user's perspective, that's all that matters) really come from the
> properties of the resolution service.  

No, the properties of URNs have more to do with the way the name 
is *assigned* and the discipline that's used to bind the name 
to the resource, than with how the name is resolved.

The resolution services can be substantially the same for URNs and URLs.

> Declared properties don't
> matter if they end up being untrue.  If a URL can be made to behave
> persistently by using the URI resolution service as you described (not
> me this time!), then is it not behaving like a name (at least
> regarding persistence)?

Yes.  You can have URLs that happen to be persistent.  But you can't
define a part of URL-space to be persistent.  You can have a resolution
service that returns a "persistence" bit, but that's not the same thing,
because that bit could be turned on or off at any time.

The persistence property of a URN cannot be changed; that's why the
fact that the name is persistent is encoded in the name itself.

To some degree, all of these are social conventions.  We want to 
visually distinguish URNs from URLs because we want humans to use
them differently.  This requires that they realize that they are 
(at least in how they are used) very different things.

> But if a URL has been made to behave persistently by using the URI
> resolution service, isn't it just as good as a URN?  Furthermore, I
> would think it would be advantageous for everyone to start registering
> their http URLs (or servers) in the URI tree, so eventually there
> would no longer be a question about whether http URLs are persistent -
> they all would be.  

No, there will always be resources and resource names that aren't 
guaranteed to be persistent.  URNs are the special case, not the
general case.

Keith

Date: Thu, 7 Nov 1996 15:25:35 -0600 (CST)
From: Daniel LaLiberte <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: "Gregory J. Woodhouse" <[email-masked]>, Daniel LaLiberte <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Names and Locations (was [URN] some comments) 
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Hey, you guys are still at it.  I don't mind, but apparently others
do.  I'll be brief and again refer the reader to
http://union.ncsa.uiuc.edu/HyperNews/get/www/URIs.html.

Keith Moore writes:
 > I think there's a problem with terminology here.  

A glossary would help, but here is my standard warning: don't let
definitions box you in a corner conceptually.

 > I believe the URN: prefix is essential, but not for this reason.  As
 > I've said before, the difference between URNs and URLs should have
 > more to do with the properties of each name space than how they are
 > resolved.

But the properties of an identifier that are visible to a client (from
the user's perspective, that's all that matters) really come from the
properties of the resolution service.  Declared properties don't
matter if they end up being untrue.  If a URL can be made to behave
persistently by using the URI resolution service as you described (not
me this time!), then is it not behaving like a name (at least
regarding persistence)?

 > But human beings need to be able to distinguish between a URN and a
 > URL.  That way, they can tell a stable, persistent resource identifier
 > from a resource location.

But if a URL has been made to behave persistently by using the URI
resolution service, isn't it just as good as a URN?  Furthermore, I
would think it would be advantageous for everyone to start registering
their http URLs (or servers) in the URI tree, so eventually there
would no longer be a question about whether http URLs are persistent -
they all would be.  But during the transition, how hard would it be
for the user-author of a document referencing another document to
find out if one URL is persistent whereas another one is not?

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

From: Keith Moore <[email-masked]>
To: Fisher Mark <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Martin J Duerst <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [URN] I18N does not belong in URNs 
Date: Thu, 07 Nov 1996 16:16:56 -0500
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> So, I see only 2 basic directions URN identifiers can go:
> 
>      1) Totally opaque, random numeric strings; or
> 
>      2) I18N character strings with appropriate encoding,
>      preferably (IMHO) as UTF-8.
>
> There really is no middle ground -- if there is a pattern there, people will 
> make use of it and screw up the system.

As an example that there *is* middle ground, I suggest:

3) URNs are assigned by the "system" without regard to the content
that they name. (in other words, totally opaque, but not restricted to
numerals)

This way, they can be composed of a larger character set without being
human meaningful.

And there are other ways of providng the same feature.

We can't restrict character sets too much because of the need to
grandfather existing URN spaces.

Keith

From: Keith Moore <[email-masked]>
To: Martin J Duerst <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] I18N does not belong in URNs 
Date: Thu, 07 Nov 1996 16:09:28 -0500
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> >> So for grandfathering, we have two choices.
> >> 
> >> 1) We interpret it as "direct grandfathering of characters",
> >> 	in which case we have to allow a really wide range
> >> 	of characters (i.e. ISO 10646).
> >> 2) We interpret it as "indirect grandfathering", in which
> >> 	case the digits, or whatever small set, will be
> >> 	enough.
> >
> >I suspect there will be some of each.
> 
> I wouldn't mind "some of each", if this means "about the same
> amount for everybody on the world". If it comes to mean "a lot
> for English-speaking, but very little for the rest of the world",
> I would have to strongly disagree.

Martin,

Please accept that I agree with you here.  I don't want Internet
information access protocols to be significantly biased in favor of
English speakers (or anybody else).

I say "please accept" because if you accept that we substantially
agree on the above, it's a lot easier to understand the rest of what
I'm saying.

For the case of URNs, I have no problem with the idea that they should
not be friendly to English speakers -- because they really shouldn't
be freindly to anybody, except to be transcribable!

On the other hand, we can hardly prohibit some rare and occasional
misuse of URNs such that human-friendly meaning creeps in.  And we've
long since established the need to grandfather in existing name spaces
that have the characteristics of URNs.  Some of those name spaces are
going to have some minimal human-friendliness, some degree of meaning
exposed in the names.  But there won't be much human-friendliness in
any name space that gets grandfathered in, as any naming scheme which
tries to embed lots of meaning in the names will inherently have poor
persistence and thus be unsuitable for URNs.

Still, it's a judgement call as to whether a particular name space
fits in URN space.  In making such a judgement, what matters is the
overall characteristics of the name space, not which characters are
and aren't allowed.

> >> Choosing ASCII only as for URLs would be very unfair cheating.
> >
> >If the names aren't human meaningful, I don't see what you're
> >complaining about.
> 
> If I were sure the names would not be meaningful, I would not
> have much reason to complain. But the URL example shows that
> restricting people from becomming meaningful is very hard if
> not impossible.

A lot of people "publish" things on the web by simply editing files in
a particular directory; the URLs for those files are derived from
their filenames.  We can hardly expect people to assign meaningless
names to files that they edit, and few people (outside the information
sciences world) understand the virtue in using meaningless resource
names.

I agree that it may be difficult to get most people to understand that
URNs are not human-friendly names (since it's been difficult to do
even within this WG).  This is part of why I think the URN: prefix is
important (so that URNs are easily distinguished from URLs).  It's
also important to promote early use of the URN: prefix for existing
non-friendly name spaces (so people get used to seeing URN: followed
by gibberish).  Finally, new URN spaces are going to require some
restrictions about how those URNs are defined.  (In both RCDS and the
CNRI handle system, resource names aren't chosen by users -- you ask
the system to create one and it gives it back to you.)  Despite all of
this, I'm sure that a few human-friendly URNs will creep in somewhere.
But what's important is that URNs won't be generally useful as a means
to define human-friendly names -- the case where a URN is
human-friendly will be the odd exception rather than the rule.

(I'm reminded of RFC numbers which are generally assigned in sequence,
but occasionally are chosen to be easily remembered -- so RFC XX00 is
often an "assigned numbers" RFC.  My favorite example is RFC 1984.)

> You may agree with the above point, or you may disagree. But
> either way, ASCII only is unfair. If you think that naming
> schemes, protocols, standards, some review board, or whatever,
> can assure that no meaningful stuff is created, then there
> is no reason to restrict to ASCII. 

The working group needs to decide which is more important -- being
able to grandfather in existing URN-like name spaces from everywhere
on the planet, or having all URNs be transcribable by anyone on the
planet.  I could certainly make a case for a subset of ASCII-only
based on the latter consideration.

Perhaps the right thing to do is to define a mapping to be used when
grandfathering existing non-ASCII namespaces to URNs, i.e. to encode
the non-ASCII characters as UTF-8 and then encode each octet not
printable in ASCII using %XX notation.  That way, people could still
type in resource names like they're accustomed to doing, but the
program they type them in to would convert them to canonical URN
format (by prepending URN:namespace: and doing the UTF-8 and %XX
encoding).  For purposes of resolution, URNs would always be
transmitted in canonical format, but programs could decode the %XX and
UTF-8 for the purposes of display to humans.

> One should assume that Japanese, Russians, Chinese, or whoever, can
> be as disciplined, or as tighly controlled, as the English-speaking
> part of the world. On the other hand, if you think that namespaces
> will get meaningful because of people's nature, and you think it is
> a bad thing that has to be avoided, there is no other choice but to
> limit ourselves to the decimal digits and maybe two or three other
> characters.

We can discourage putting human-friendly names in URNs by the methods
I mentioned above.  Also, since URI resolution will work for either
URNs or URLs, there will be no reason to insist that a name be in URN
space just so it can have resolution.  So the only people who will
assign URNs will be those who really want long-term persistent and
ugly resource names.  (At least this is what I hope will happen.)

> But there can be a great deal of human-friendliness,
> without any need for ambiguity. URLs such as http://www.ibm.com
> or http://www.icrc.org are examples.  My brother, who works at ICRC in
> Geneva, recently called me. Before he was able to tell me how I could
> reach him by email, I had the ICRC home page on my browser, and had
> found the generic email address explanations, and had sent him a mail.

There's probably more than one organization in the world named ICRC.
The one your brother works for got ICRC.COM first, but the name is
still ambiguous.  You could have as easily found the a different ICRC
than the one you were looking for.

(I keep getting tripped up when I visit the web page of Global
Business Network -- which is www.gbn.ORG.  www.GBN.COM is somebody
else.)

This is only going to get worse as more companies get on the Internet.

> If it can be that human-friendly, and that unambiguous, I don't know why
> I should go to a search service to find the ICRC. And I don't know
> why people that use other scripts should go though a serach service,
> while English speaking users don't have to do so.

All names are unambiguous only within a limited context.  When the net
was small, the context was inherently limited, so it didn't cause a
problem to have only one host for any given name.  But now that the
net is much larger, it is a big problem.  

The whole huge mess over ownership of domain names, the InterNIC's
capriciousness in deciding who gets what domain within .COM, and all
of the hair-brained proposals to add tons of vanity-plate top-level
domains -- ALL of this is caused by the lack of support for
human-friendly names in the Internet infrastructure, and the resulting
misuse of DNS to do a job it wasn't designed to do.  We're not going
to misuse URNs in the same way.

> 
> >> And I don't want to have to search through long lists
> >> of possible answers just because I use Japanese, whereas
> >> I will get one immediate answer for English.
> >
> >The point is that you will often get multiple answers for English.
> >English names are no more precise than names in other languages.
> 
> No, but English can be used in URLs, and I get an unambigous
> result if there is one, in due time. In Japanese, even if the
> result would be unambiguous, I currently can't get it fast and
> easily.

Which is better - an ambiguous result which is usually correct, or an
unambiguous result which is often incorrect?

The number of names you get back from a search of a user-friendly name
is related to how ambiguous the name is.  If the name you give is
relatively unambiguous, you'll only get a few names back.  "Kodak" (a
name explicitly chosen to be globally unique) will give you relatively
few hits, while "Acme" (a very common brand name) will give you far more.  

Part of this is because you'll already be restricting the context of
the search -- if you're looking for the name of a business
organization, you'll go to a service that matches user-friendly names
against names of businesses.  If you're looking for a person's name,
you'll use a different service.

Keith

From: Keith Moore <[email-masked]>
To: "Gregory J. Woodhouse" <[email-masked]>
Cc: Daniel LaLiberte <[email-masked]>, Keith Moore <[email-masked]>, [email-masked]
Subject: Re: Names and Locations (was [URN] some comments) 
Date: Thu, 07 Nov 1996 14:56:33 -0500
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> It still seems to me that the issues is one of mechanics. It seems fine to
> specify that the namespaces http:, ftp:, gopher:, etc. are reserved for
> URLs so that a client knows a priori that when it sees
> 
> http://foo.bar.com/
> 
> it knows it only need  connect to foo.bar.com and retrieve the resource.
> But without doing such a check, the client would have to assume the above
> URI *could* be a URN and attempt to resolve it. 

I think there's a problem with terminology here.  We have essentially
two separate efforts going on here: (1) defining what URNs look like
and how they are used, and (2) defining a mechanism for URI
resolution.

1. URNs are a name space with the properties defined in RFC 1737.
Strictly speaking, an http URL can never be a URN, since http as a
name space isn't constrained to have those properties.

2. The URI resolution mechanism isn't limited to URNs -- it can also
be used to resolve many types of URLs.

So in the example above, the client doesn't have to know whether
http://foo.bar.com/ is a URN or not to know if it can resolve the
name.  The client can simply attempt to apply URI resolution to the
URL. If it succeeds, it can use any of the services returned by the
resolution process.  If the URI resolution fails, it can fall back to
talking to the http server at foo.bar.com.

> A separate issue is whether the above URI could represent different
> resources when interpereted as a URL or a URN. 

A URI is either a URL or URN or something; it cannot be both a URL or
a URN.  As for "interpretation" of an http URL under URI resolution,
this isn't a problem: a URL beginning with "http:" will always be
resolved the same way.

Of course it is "possible" for the resource pointed to by a URL and
the resource you get from resolving that URL with URI resolution will
be different.  But this is no different from the situation we have
today -- if the domain in a URL has multiple IP addresses pointing to
multiple servers and those servers are not in synch.

> Finally, a possible design is to have the above URI be both a URL and a
> URN. By this, I mean that whatever service is responsible for resolving URNs
> will recognize and deal appropriately with namespaces such as http:. But it
> is obviously desirable not to have to go through the process of resolving a
> URN just to get back a URL that is identical to the original URN. 

Well, this seems wasteful, but I submit that it really is desirable.

The client doesn't know in advance whether resolution is available for
a particular URL; it has to do a DNS lookup (or consult some other
resolution service) to find out.  As long as the client is attempting
to do resolution anyway, it doesn't hurt for the resolution server to
return a single URL - even one that matches the original.  And there
is a major win here -- if the demand for the resource named by the URL
increases, the provider can simply replicate the resource on
additional servers, tell the resolution server about it, and clients
will find them.

> Now, if I'm missing something fundamental, by all means tell me, but this
> seems like a real issue to me. It seems that omitting the urn: prefix would
> not break anything (unless of course a URI is allowed to have different
> referents depending upon whether or not it is a URN), but it may still be
> useful, just as it may be useful to have a url: prefix for URIs that are in
> fact URLs.

I believe the URN: prefix is essential, but not for this reason.  As
I've said before, the difference between URNs and URLs should have
more to do with the properties of each name space than how they are
resolved.  That is, we need similar resolution mechanisms for URNs (to
provide persistence, longevity, global scope) as for URLs (to provide
redundancy, scalability, and fault-tolerance...which are desirable for
URNs as well).  

But human beings need to be able to distinguish between a URN and a
URL.  That way, they can tell a stable, persistent resource identifier
from a resource location.  For instance, if you're writing a paper and
you need to put references to other works, those references should be
URNs, rather than URLs, whenever possible.  Advertising a URL for a
resource says nothing about its longevity or persistence; advertising
a URN for a resource is an indication that the URN will always point
to that resource (if the resource is available).

Keith

Subject: [URN] Re: Comments on "I18N does not belong in URNs"
To: [email-masked] (Ryan Moats)
Date: Thu, 7 Nov 1996 20:04:03 +0100 (MET)
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Content-Length: 1982
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Ryan Moats wrote:

>Terry Allen commented (|):
>
>|That's an argument specifically against using UTF-8 at all.  I'd
>|like to hear more on this point from the UTF-8 proponents. 
>
>Martin Duerst replied (@):
>
>@Also, the URN syntax draft clearly specifies how URNs are
>@transported over 7-bit channels (using %HH). This works for
>@URLs, there is no reason it shouldn't work for URNs.
>@ 
>@So I really wonder where there should be a problem.
>
>Well, this is not exactly the way I interpret the syntax draft.
>Section 3 of the draft states that encoding URNs for transport
>is the responsibility of the transport protocol.  The implied statement
>is that the transport protocol is responsible for undoing the
>encoding.

I guess you should better make this more explicit. Anyway,
%HH escaping is always available, and will work with email
and other 7-bit-challenged protocols.

>The encoding section is there in the case of encoding
>that the URN resolver has to undo itself.  What I wonder (and
>am looking for some consesus on) is: "Is this necessary?"

>Also, the %HH escaping technique does have some problems with UTF-8
>as Martin has pointed out on another thread...

If we really want to focus on non-meaningful, ISBN-like stuff,
then there is no problem, because the namespace itself will
always be restricted to a fairly small character set, even
if this is drawn from full Unicode/ISO 10646.

This point can be slightly extended: Because Unicode/ISO 10646
is such a huge collection of characters, the chances that a
namespace has to use all of them PLUS some more for structure
are much smaller than with ASCII. They will only occur in those
cases that we already have with ASCII, i.e. when we speak
about devices (computers) that represent characters with Unicode.
Real-world namespaces, such as the names of emperors or plays,
or whatever, even in native notation for each of these, never
will use such oddities as Zapf Dingbats in their names.

Regards,	Martin.

Date: Thu, 7 Nov 1996 13:36:37 -0500
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [URN] some comments
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

Let me follow up Harald's comment with a note about the IRTF.  Abel
Weinrib is the chair of the IRTF and is very open to suggestions for
new WGs in that context that want to explore more open ended
questions.  In fact there were 2 WGs formed last year on related
topics.  The one I chair is on an Internet Information Architecture.
It is a closed group at present, but one of our threads of discussion
is about how to open up the process to a wider community.  I will
certainly report further on that as we make progress.

The other group is chaired by Cecilia Preston and my recollection is
that the focus of that is metadata.  I have no idea about the nature
of their work.

But, let me urge you, if you would like to form a group to work on
something related to IETF activities, but more open-ended, to talk
with Abel about it.  I also recommend to you the recent RFC 2014 on
the subject of the IRTF.

			Karen

From: "Ryan Moats" <[email-masked]>
To: "Daniel LaLiberte" <[email-masked]>, "[email-masked]" <[email-masked]>, "Peter Deutsch" <[email-masked]>
Cc: "Karen R. Sollins" <[email-masked]>, "Leslie Daigle" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 07 Nov 96 12:29:08 
Priority: Normal
Subject: Re: [URN] some comments
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Thu, 7 Nov 1996 11:50:05 -0500, Peter Deutsch wrote:

>I think I understand the thrust of your argument, and if
>not for the past four or five years of history, I'd agree
>wholeheartedly that we need to remain open to change.
>
>Unfortunately, as someone who has been monitoring and
>(before I was called away by my accountants) participating
>in this debate pretty much since its inception, I'd have
>to echo Karen's concerns.
>
>You are right - if bits or pieces turn out to be broken in
>RFC 1737, then they should to be fixed. That's simply good
>engineering. The problem I see, and I suspect that Karen
>was attempting to address, is that there exist the danger
>that in leaving open the possibility of modifying RFC
>1737, at least some people will take it a mandate to fix
>not just broken specifics, but the conceptual model
>itself. This has been happening since the beginning of
>this work and it's getting old.

I fully agree with this.  It was not my intent to break the whole
structure, just fiddle with bits of it if necssary as we move forward.

Ryan

Date: Thu, 7 Nov 1996 13:12:14 -0500
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Subject: [URN] requirements - see draft-girod-urn-res-req-00.txt
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

I suggest that you consider draft-girod-urn-res-req-00.txt, in which
we identify a number of requirments for URN resolution services.  For
some reason it didn't make it onto the web page for the URN WG set up
by the IETF.  In addition, the framework paper suggests a few
requirements, but is not explicit enough.  I am now working a
requirements/framework paper based on both of these, plus what I can
cull from the discussions since the group has been set up.  The
requirements paper is the one we presented at the BOF in Montreal.
The later sections of the paper discuss particular resolution schemes
and are at this point outdated, but I believe that what we said in the
requirements section is important for this group and must be said in
some document we publish.  Without stating explicitly the requirements
for URN resolution services it is impossible to evaluate whether or
not any particular scheme is what is needed.

(Bob Briscoe you seem to be asking for this especially.) 

In addition to its being available from internet drafts it is also
available from our anonymous ftp server
(mercury.lcs.mit.edu:/pub/sollins/draft-girod-urn-res-req-00.txt).
			Karen

Date: Thu, 7 Nov 1996 09:47:38 -0800 (PST)
From: "Gregory J. Woodhouse" <[email-masked]>
To: Daniel LaLiberte <[email-masked]>
Cc: Keith Moore <[email-masked]>, [email-masked]
Subject: Re: Names and Locations (was [URN] some comments) 
Sender: [email-masked]
Reply-To: "Gregory J. Woodhouse" <[email-masked]>

It still seems to me that the issues is one of mechanics. It seems fine to
specify that the namespaces http:, ftp:, gopher:, etc. are reserved for
URLs so that a client knows a priori that when it sees

http://foo.bar.com/

it knows it only need  connect to foo.bar.com and retrieve the resource.
But without doing such a check, the client would have to assume the above
URI *could* be a URN and attempt to resolve it. In a sense, this isn't a
huge restriction because the client needs to know how to retrieve resources
specified by a URL, anyway, so it must know which namespaces are possible.

A separate issue is whether the above URI could represent different
resources when interpereted as a URL or a URN. This is, of course, only
possible if the same namespace can have multiple semantics, and my
understanding is that this is not the case, but to be honest, I don't see
where this is spelled out.

Finally, a possible design is to have the above URI be both a URL and a
URN. By this, I mean that whatever service is responsible for resolving URNs
will recognize and deal appropriately with namespaces such as http:. But it
is obviously desirable not to have to go through the process of resolving a
URN just to get back a URL that is identical to the original URN. (In the
case of NAPTR we could have an N2R resolution, but then scalability issues
come to mind.)

Now, if I'm missing something fundamental, by all means tell me, but this
seems like a real issue to me. It seems that omitting the urn: prefix would
not break anything (unless of course a URI is allowed to have different
referents depending upon whether or not it is a URN), but it may still be
useful, just as it may be useful to have a url: prefix for URIs that are in
fact URLs.

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

Subject: Re: [URN] I18N does not belong in URNs
To: [email-masked]
Date: Thu, 7 Nov 1996 18:15:34 +0100 (MET)
Cc: [email-masked], [email-masked]
Content-Length: 5192
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Keith Moore wrote:

>Perhaps.  I don't have as big a problem with this, as long as
>there's a discipline about how they are assigned that prevents
>URNs from being used as search strings.  That's my main worry.
>(URNs are also supposed to be transcribable, but I recognize that
>only a very small set of characters is transcribable by everyone
>on the planet.)

For "everyone", you might have to limit it to X and O, or even
X and XX :-).

Just an additional example: Think about number plates of cars.
Lots of non-ASCII characters there all over Asia.

>> So for grandfathering, we have two choices.
>> 
>> 1) We interpret it as "direct grandfathering of characters",
>> 	in which case we have to allow a really wide range
>> 	of characters (i.e. ISO 10646).
>> 2) We interpret it as "indirect grandfathering", in which
>> 	case the digits, or whatever small set, will be
>> 	enough.
>
>I suspect there will be some of each.

I wouldn't mind "some of each", if this means "about the same
amount for everybody on the world". If it comes to mean "a lot
for English-speaking, but very little for the rest of the world",
I would have to strongly disagree.
In theory, I could immagine making a worldwide search of
suitable namespaces, and limiting the characters to those
appearing in such namespaces. But I guess we would quickly
end up with all the major alphabets completed, and the work
deciding which of the ~20,000 CJK ideographs is used in a
naming scheme, and which not, would not be very rewarding.

>But we want the transformations
>from "old identifier" to URN to be simple and easy to remember.

Back to user-friendliness, in some sense. I have no problems
about this. But again, I wouldn't like it if "simple and easy
to remember" means that English speaking people just have to
type them in, whereas people in the rest of the world, for
namespaces that are currently in use there, need list of
correspondences they have to look up or remember constantly.

>> Choosing ASCII only as for URLs would be very unfair cheating.
>
>If the names aren't human meaningful, I don't see what you're
>complaining about.

If I were sure the names would not be meaningful, I would not
have much reason to complain. But the URL example shows that
restricting people from becomming meaningful is very hard if
not impossible.

You may agree with the above point, or you may disagree. But
either way, ASCII only is unfair. If you think that naming
schemes, protocols, standards, some review board, or whatever,
can assure that no meaningful stuff is created, then there
is no reason to restrict to ASCII. One should assume that
Japanese, Russians, Chinese, or whoever, can be as disciplined,
or as tighly controlled, as the English-speaking part of the
world. On the other hand, if you think that namespaces
will get meaningful because of people's nature, and you
think it is a bad thing that has to be avoided, there is
no other choice but to limit ourselves to the decimal digits
and maybe two or three other characters.

>> >> I definitely hate to see i18n just being moved around and delayed
>> >> by some people. With UTF-8 in URNs, we have made great progress.
>> >
>> >No, this is a big step backward.  Just because there is a new layer
>> >being defined doesn't mean that I18N belongs there.  
>> >
>> >I18N *is* important  -- and I'd be happy to see a draft document or 
>> >draft charter for a working group to define a protocol (say an extension
>> >of http/html) to resolve human-friendly names into URNs or URLs.
>> 
>> Why is there a need for an additional protocol layer?
>> There is no need currently for English, is it?
>
>Yes, there is.  Human-friendly names are inherently ambiguous,
>and have ambiguous meanings which require a human being to untangle.
[examples removed]

>URNs should be precise enough that a human isn't required to
>disambiguate the result.

I know your examples. But there can be a great deal of human-friendliness,
without any need for ambiguity. URLs such as http://www.ibm.com
or http://www.icrc.org are examples. My brother, who works at ICRC in
Geneva, recently called me. Before he was able to tell me how I could
reach him by email, I had the ICRC home page on my browser, and had
found the generic email address explanations, and had sent him a mail.
Of course, I'm an expert, but there are many people with less Web
experience and technical expertise who could do that.

If it can be that human-friendly, and that unambiguous, I don't know why
I should go to a search service to find the ICRC. And I don't know
why people that use other scripts should go though a serach service,
while English speaking users don't have to do so.

>> And I don't want to have to search through long lists
>> of possible answers just because I use Japanese, whereas
>> I will get one immediate answer for English.
>
>The point is that you will often get multiple answers for English.
>English names are no more precise than names in other languages.

No, but English can be used in URLs, and I get an unambigous
result if there is one, in due time. In Japanese, even if the
result would be unambiguous, I currently can't get it fast and
easily.

Regards,	Martin.

Date: Thu, 7 Nov 1996 10:46:58 -0600 (CST)
From: Daniel LaLiberte <[email-masked]>
To: Keith Moore <[email-masked]>
Cc: [email-masked]
Subject: Re: Names and Locations (was [URN] some comments) 
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Keith Moore writes:
 > [...]  But the difference between URNs and URLs has
 > almost nothing to do with how they are resolved (indeed, I hope they
 > use the same resolution mechanisms), and a lot to do with how the
 > names are assigned and maintained.

This is at least a different view, especially regarding URLs, than
other people hold.  But I am under a restraining order :-) not to
pursue this here, so I've created a new list [email-masked].
To subscribe (this is not Majordomo), see the web page at:

  http://union.ncsa.uiuc.edu/HyperNews/get/www/URIs.html

 > This is why URNs need a URN: prefix -- because a lot of the value in
 > having a URN name space with those properties is so *humans* can
 > recognize a URN when they see it.

The issue of whether the "urn:" prefix should be optional or required
is still open.  Since this issue relates directly to whether URNs can
or should be distinguished from URLs, I'm open to having it discussed
on [email-masked].

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

From: Peter Deutsch <[email-masked]>
Date: Thu, 7 Nov 1996 11:50:05 -0500
To: Daniel LaLiberte <[email-masked]>, [email-masked]
Subject: Re: [URN] some comments
Cc: [email-masked] (Leslie Daigle), "Karen R. Sollins" <[email-masked]>, [email-masked]
Sender: [email-masked]
Reply-To: Peter Deutsch <[email-masked]>

Hi all,

It's been some time since I posted in this forum
(actually, I think my last shout in this problem space was
back during the lifetime of the previous URI list). I've
been busy, other people have been carrying the flag and
I've tried to let sleeping dogs lie.

This morning, I composed a reply to a message opening the
possibility of reworking RFC1737. I then had the good
sense to shelve the posting until I'd had time to view the
rest of the thread, and was about to congratulate myself
on the wisdom of my advancing years when I reached the
subsequent exchange between Dan and Harald.

Now, that exchange may be enough to close this debate, but
given past history, I suspect it will instead open again
the meta-discussion about conceptual models, process and so
on. Because of Dan's specific concerns about process, I've
decided to go ahead and send my missive.

Harald obviously speaks with the weight of the Area
Director and I applaud his remarks. I offer my
complemetary message as someone who was a founding
co-chair of the original URI working group and as someone
who has been watching similar exchanges for something like
five years now. There is no offense intended for any
specific indvidual. I hope none is taken.

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

[* WARNING CONTAINS FREE DIATRIBES AND MEASURABLE RANTINGS.  *]
[* SOME EXPERTS BELIEVE THAT CONSUMING SUCH DIATRIBES AND    *]
[* RANTINGS LEADS TO IRRITABILITY, CROSS-POSTING AND FLAMES. *]
[*              CONSUME AT YOUR OWN RISK.....                *]

[ jayhawk@@dsm0.ds.internic.net wrote: ]
.  .  .
} First I have to apologize, because I should have added an indication that
} that wasn't an entirely serious remark.
} 
} <MINOR SOAPBOX>
} Having said that, I still claim that as we move forward, we have the right
} to realize that something in 1737 isn't optimal or doesn't work etc.  My
} opinion is that if there is rough consensus in the WG, then saying "but
} 1737 says that's a no-no" doesn't cut it.
} </MINOR SOAPBOX>

I think I understand the thrust of your argument, and if
not for the past four or five years of history, I'd agree
wholeheartedly that we need to remain open to change.

Unfortunately, as someone who has been monitoring and
(before I was called away by my accountants) participating
in this debate pretty much since its inception, I'd have
to echo Karen's concerns.

You are right - if bits or pieces turn out to be broken in
RFC 1737, then they should to be fixed. That's simply good
engineering. The problem I see, and I suspect that Karen
was attempting to address, is that there exist the danger
that in leaving open the possibility of modifying RFC
1737, at least some people will take it a mandate to fix
not just broken specifics, but the conceptual model
itself. This has been happening since the beginning of
this work and it's getting old.

I believe that this debate has been struggling on for so
long because we have two basic belief systems (okay, two
engineering models), and rather than divide into two
groups to pursue alternate development paths, adherents of
the two models have remained together and continued to
debate essentially the same arguments and beliefs
continuously for years.

Yes, we've probably made some progress (there is a
requirement document, there are some experimental systems
deployed, the terminology seems to have stabilized, etc)
but I'm really rather concerned that we don't yet have
that essential working consensus on the underlying
conceptual model. I'm seeing postings go by that echo
pretty much exactly what was being posted several years
ago in earlier forums (fora?).

Because of that, I think leaving open the possibility of
going back to rejig RFC 1737 sends the wrong message at
this time.

Yes, if you think something specific is broken, it's
responsible to say so. But if someone's problem is with
the conceptual model, then you should probably unsubscribe
and leave the rest of us to our misconceptions.

Please understand that I'm not taking a shot at your
posting and I hope I don't offend you. From your tone you
seem aware of the possibilities I'm warning against. It's
just that I'm a little tired of the continual debate on
questions which have been "asked and answered" and I fear
that others may misconstrue your comments to mean that
it's okay to continue fighting the good fight to "fix" the
model.

I'd like to remind people who have joined this debate
within the past year or two that when we first formed the
URI working group way back when, we had two camps. One
camp thought everything could be done with URLs, and
didn't accept that the semantics of URNs were different,
or if they were, that meant we could or should implement
them. The basic thrust seems to be "they're not real, or
not needed. We can do the same things with URLs and
building these other things would be harmful."

The other camp believed that the differing semantics
indicated the existance of a different class of
identifiers and these should be designed, standardized and
used separately from URLs. Such people believed that in
doing so, URNs would prove useful in ways that URLs are
not, and if some people didn't see this, that's fine as it
would become clear who was right as URNs became widely
deployed. Darwinian selection would do its thing.

Since then a conceptual model was proposed (I think Karen
captured its broad outlines well), URN requirements were
teased out and written down, the framework document was
promulgated and a few experimental systems were designed
and deployed. Yes, that's measurable progress. But gosh,
it's been a slog.

And we still see people arguing against the model, or the
necessity, or the functional requirements as already
agreed. That was probably appropriate back in the URI
group, when the conceptual model was being hammered out.
Today, I personally believe that the model-related debates
are hurting us all, as it's having a chilling effect on
the testing, deployment and eventual acceptance of URNs. I
think URNs are real and are badly needed, and we're
running way behind schedule.

We have a model and this group has a specific mandate to
implement a component of that model. If you disagree with
that model, please take your concerns to the Area
Directors, the plenary sessions, the IETF mailing list or
simply ignore the workings of this group. If you're right
we will do no harm. If you're wrong you're holding up
progress.

If you agree with the model and disagree with the
implementation, then that's fair game, but folks, life's
too short. If you don't buy the model, please leave this
work to those who do.

					- peterd

-- 

Date: Thu, 7 Nov 1996 08:43:01 -0800 (PST)
From: "Gregory J. Woodhouse" <[email-masked]>
To: Jim Conklin <[email-masked]>
Cc: Terry Allen <[email-masked]>, [email-masked]
Subject: Re: [URN] Re meaningful names
Sender: [email-masked]
Reply-To: "Gregory J. Woodhouse" <[email-masked]>

Much of the software we release is in source code form. If someone werwe to
argue that the code should not be commnted or well structured, perhaps even
arguing tht algorithms should specifically be chosen because they are hard
to follow, and then claim tht woul enhance software quality in that it
would make it less tempting for customers to modify the code and possibly
break it, I would say they were quite wrong. Software quality is enhanced
by having clean, understandable and maintainable code. Now, why should URNs
be any different?

On Thu, 7 Nov 1996, Jim Conklin wrote:

> Like Terry Allen, and for the same reasons, I will (again, as I did months
> ago when we previously had this discussion) enter my vote for the ability
> to use meaningful names.
> 
> Jim
> 
> 

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

Subject: Re: [URN] I18N does not belong in URNs
To: [email-masked]
Date: Thu, 7 Nov 1996 17:30:37 +0100 (MET)
Cc: [email-masked], [email-masked], [email-masked]
Content-Length: 2326
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Lewis Girod wrote:

>   this group seriously would agree to restrict URNs to digits
>   only for this reason, I would understand.
>   But with ASCII as a "restricted" character set, we will definitely
>   get cruftiness, and I see no reason to allow cruftiness for
>   English, but to deny it for most other languages.
>
>One idea we were experimenting with here was to use a subset of ASCII
>that included only numerals, punctuation and consonants, which would
>make most words hard to express (at least in some languages).

There are some languages that use mostly consonants, esp. some
of the Slavic languages. Arabic and Hebrew in principle write only
consonants. But I am less worried about these aspects.

What I am worried about is that we just exclude 5 letters from 26.
This may not be noticed by some people, who happily will use
AEIOU also. We have this now, as for example "~" seems to be
unsafe or excluded, but still is used all the time.

Also, many accronyms contain only consonants (e.g. HTML and HTTP),
and if somebody wants to use words with vowels stripped, it
will unduely give advantages to some and disadvantages to others.
For example, compare mcrsft, ppl, bm, dgtl, hp, sn, and so on.

So just cutting out the vowels is not enough if we want to go
that way; for a small set, my preference would still be for
0123456789#* (phone keys). Of course, my general preference is
for full i18n with UTF-8.

>   The interesting thing is that we already have that, in the current
>   syntax draft. Just call the readable form of it UFNs, and call
>   the encoded form, %HH-escaped, URNs. I have proposed similar
>   names for these things, namely IRNs (internationalized ...).
>
>True, those strings are hard to read but it doesn't solve the problem
>because the URN and the UFN are tightly coupled -- the whole point of
>UFNs is that they are nicknames with a short lifespan.  A UFN should
>be allowed to change over time without ever changing the aliased URN.

I didn't want to stress that the %HH strings are difficult to read.
What I a looking for in UFNs is that they are user friendly, i.e.
easy to understand and type in by somebody e.g. in Japan or so,
and that they are tightly coupled to something else, e.g. URNs
or URLs, so that they can be resolved quickly and deterministically.

Regards,	Martin.

Date: Thu, 7 Nov 1996 11:24:09 -0500
To: Terry Allen <[email-masked]>, [email-masked]
From: [email-masked] (Jim Conklin)
Subject: Re: [URN] Re meaningful names
Sender: [email-masked]
Reply-To: [email-masked] (Jim Conklin)

Like Terry Allen, and for the same reasons, I will (again, as I did months
ago when we previously had this discussion) enter my vote for the ability
to use meaningful names.

Jim

Date: Thu, 7 Nov 1996 09:18:17 -0600 (CST)
From: Daniel LaLiberte <[email-masked]>
To: [email-masked]
Cc: Daniel LaLiberte <[email-masked]>, [email-masked] (Leslie Daigle), "Karen R. Sollins" <[email-masked]>, [email-masked]
Subject: Re: [URN] some comments
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Harald T. Alvestrand writes:
 > [email-masked] said:
 > > Standing on premise and charter as an argument is legalistic and 
 > > dogmatic.  That's dangerous, although it may lead to short term 
 > > productivity.
 > 
 > Actually, I asked for the WG to be run in exactly this fashion.

Had I known we were going to be held to the details of the charter, I
would have spoken up at that time.  But, honestly, would it have
mattered?

 > One reason why we wrote a rather narrow charter for this working
 > group, which DID include assumptions like "there is a difference
 > between URLs and URNs", was that we wanted to see if it was
 > possible to create a solution to a limited problem.

But my whole point is that *because* the supposed difference between
URLs and URNs (the identifiers, not the resolution mechanisms) does
not exist, it is irrelevant to creating a solution, except for syntax
and other arbitrary constraints.

 > One of the things that we have to do, unfortunately, to get a
 > solution to that limited problem, is to ask those who want to work
 > on a different problem to leave.

So it has come to that, eh?  As I've stated, we'll continue the
discussion off-line.  But are you saying we shouldn't bother?

 > The output of this working group is supposed to be a set of
 > Experimental documents. These don't form the be-all and end-all
 > of the Internet information architecture; they're just an experiment.

You should know that many experiments turn into standard practice.  If
you want it to really be "just an experiment", perhaps you should
consider finding a way to kill it off afterwards so it doesn't escape
from the lab. :-)

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

From: Fisher Mark <[email-masked]>
To: Bob Briscoe <[email-masked]>, Terry Allen <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: RE: [URN] Persistence as part of URN framework
Date: Thu, 07 Nov 96 10:05:00 EST
Encoding: 19 TEXT
Sender: [email-masked]
Reply-To: Fisher Mark <[email-masked]>

>Final comment:
>If you accept that pragmatically, URNs don't exist for ever (because they
>only exist as long as anyone can prove they exist), you can still have the
>"no reassignment" rule for people to keep to on best effort. IOW, just
>because urn:duns:001234567:Dunn&Bradstreet_Collapse.report stops being
>resolvable, anyone who knew of broken references to it well into the
>future,
>shouldn't deliberately re-use it for something else.

Well, unless they can somehow take over resolution of the "duns" namespace, 
they _can't_ re-use it.  That is why URNs were partitioned into namespaces 
 -- so that each namespace resolver could control their namespace.  If any 
party can perform the resolutions for a particular namespace (rather than 
the assigned resolution party), then a whole big can of worms is opened up 
 -- security issues, reliability, liability, etc.
======================================================================
Mark Leighton Fisher                   Thomson Consumer Electronics
[email-masked]                   Indianapolis, IN

From: Fisher Mark <[email-masked]>
To: "[email-masked]" <[email-masked]>, Martin J Duerst <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [URN] I18N does not belong in URNs
Date: Thu, 07 Nov 96 10:00:00 EST
Encoding: 26 TEXT
Sender: [email-masked]
Reply-To: Fisher Mark <[email-masked]>

>But with ASCII as a "restricted" character set, we will definitely
>get cruftiness, and I see no reason to allow cruftiness for
>English, but to deny it for most other languages.

Even purely numeric schemes can be crufty.  Here at TCE we are transitioning 
from a meaningful component naming scheme to one where the only meaningful 
part is a prefix indicating the site where the number was assigned -- the 
rest of the number is random.  If there is some way for people to assign a 
meaning or pattern to a character sequence, this meaning will be used. 
 Sometimes patterns will be detected even when there is no actual pattern 
(this is how some optical illusions work) -- humans are pattern-detecting 
animals.

So, I see only 2 basic directions URN identifiers can go:

     1) Totally opaque, random numeric strings; or

     2) I18N character strings with appropriate encoding,
     preferably (IMHO) as UTF-8.

There really is no middle ground -- if there is a pattern there, people will 
make use of it and screw up the system.
======================================================================
Mark Leighton Fisher                   Thomson Consumer Electronics
[email-masked]                   Indianapolis, IN

From: Fisher Mark <[email-masked]>
To: "[email-masked]" <[email-masked]>, Bob Briscoe <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [URN] Persistence as part of URN framework
Date: Thu, 07 Nov 96 09:53:00 EST
Encoding: 42 TEXT
Sender: [email-masked]
Reply-To: Fisher Mark <[email-masked]>

>Using DNS TTL records for this is just broken; DNS TTLs are used
>to limit caching of name->address mapping, and in the NAPTR proposal,
>they should be a fraction of the time one expects to have advance
>warning of a server relocation or mapping restructure.
>Normal TTLs are on the order of 3 days, and are usually reduced to less
>than 1 day before serious network reorganizations.

And if you are changing your resolution services faster than that, you are 
changing them too fast (IMHO).  Perhaps the key idea TimBL came up with in 
devising the Web was that, unlike other hypertext systems (including the 
Dexter model), links could be broken, i.e. nonfunctional.  This single idea 
was perhaps above all others important in spreading the Web far and wide, as 
perfectly reliable systems as difficult to construct (even for an 
appropriately low value of "perfect").  Under the Dexter model, an 
application will die or limp on after reporting an internal error upon 
encountering a broken hyperlink.  In the Web, the UA just keeps surfing on 
to the next link.

All that URNs can do is assist in persistence; persistence itself must be 
maintained outside the URN architecture, as persistence is ultimately a 
political/economic quality, not a technical quality.  We would expect a BT 
URN to persist because of our trust in BT, not because there is some 
technical solution to persistence.  Persistence is assisted in URNs by the 
ability to hand off resolution duties automagically to successor resolution 
entities.  I would regard measures of persistence to be an optional but 
necessary part of the metadata for a URN, not as mandatory metadata.  It is 
quite possible that URN will see incredibly wide use, as much or more as 
URLs are now ("every person a URN namespace owner").  Many of these 
namespaces may just persist for a few years or months, with the owner not 
caring about measures of persistence.  Persistence is ultimately up to the 
creating/resolving entity(s).

Uniqueness is an easier problem than persistence, although uniqueness has a 
strong political/economic component.  One can certainly imagine the case of 
URNs for government materials that, after they are first created for public 
consumption, are found to be embarrassing to that government and the URNs 
are silently, suddenly changed to refer to much more innocuous materials. 
 Uniqueness, also, is ultimately up to the creating/resolving entity.
======================================================================
Mark Leighton Fisher                   Thomson Consumer Electronics
[email-masked]                   Indianapolis, IN

Subject: Re: [URN] Re meaningful names
To: [email-masked]
Date: Thu, 7 Nov 1996 15:33:11 +0100 (MET)
Cc: [email-masked], [email-masked]
Content-Length: 2002
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Lewis Girod wrote:

>   Date: Wed, 6 Nov 1996 16:35:41 -0800 (PST)
>   From: Terry Allen <[email-masked]>

>   | Of course, as you point out there is no way to stop people from
>   | putting semantics into names; the most effective way to deal with the
>   | issue is to implement a system of user friendly names over the top of
>   | URNs; 99% of the time the user would see and type only a UFN, and
>   | these UFNs would be resolved to the URNs that could then be used as
>   | long-lived references.
>
>   Twice the work or more, doesn't deal with grandfathering, prone
>   to error; the most effective way to deal with the issue is to
>   drop your objection to meaningful names.
>
>It is more work (though how much more is hard to say), but it might
>prove really useful.  I don't think it would impact grandfathering at
>all; grandfathered names could have a UFN alias or they might just be
>typed in as URNs.  Prone to error?  UFNs wouldn't have the longevity
>characteristics that URNs hopefully would have, if that's what you
>mean -- that's why you don't use them in published links.

If you look at what is currently published in terms of URLs,
most of them try to be as user-friendly as possible.
Non-userfriendlyness may be okay for some official publications,
but for publishing things in newspapers and on cardboard boxes,
user-friendliness is on great demand.
Another aspect of user-friendliness is deterministic behaviour
(maybe only shorttime): If you read something in a newspaper,
you want to go to that site/document directly, and not have to
go through search lists, and so on. The side which publishes
a reference likewise wants you to go there directly, and not
be detracted.

This may not affect URN internationalization, but it definitely
affects URL internationalization, because for all of the above,
URLs are currently used, with the only restriction that the
advantages the users look for are limited to English plus a
few other rare languages.

Regards,	Martin.

Date: Thu, 7 Nov 1996 09:32:24 -0500
From: [email-masked] (Stu Weibel)
To: [email-masked]
Subject: [URN] Semantically meaningful URNs 
Sender: [email-masked]
Reply-To: [email-masked] (Stu Weibel)

The philosophical debate about whether URNs will be human
transcribable, semantically meaningful, etc., is unproductive.

This group should take no stand on this issue.  Some naming authorities
will choose one approach, others will choose another.  The only
constraint that is relevant here is that the Locally-Unique-Identifier
assigned by a naming authority is not reassigned.

There is a technical issue involved having to do with character
encodings, of course.

The mandate of this group should be to adopt the least restrictive
approach that is supportable technically.

stu

From: [email-masked]
To: Daniel LaLiberte <[email-masked]>
Cc: [email-masked] (Leslie Daigle), "Karen R. Sollins" <[email-masked]>, [email-masked]
Subject: Re: [URN] some comments
Date: Thu, 07 Nov 1996 15:20:43 +0100
Sender: [email-masked]
Reply-To: [email-masked]

--==!Exmh_1839892962P
Content-Type: text/plain; charset=us-ascii

Daniel,
some words about process.

[email-masked] said:
> Standing on premise and charter as an argument is legalistic and 
> dogmatic.  That's dangerous, although it may lead to short term 
> productivity.

Actually, I asked for the WG to be run in exactly this fashion.

One reason why we wrote a rather narrow charter for this
working group, which DID include assumptions like "there is a difference 
between URLs and URNs", was that we wanted to see if it was possible to create 
a solution to a limited problem.

One of the things that we have to do, unfortunately, to get a solution to that 
limited problem, is to ask those who want to work on a different problem to 
leave.

We've got a process in place for forming working groups that are not about 
solving limited problems, called the Internet Research Task Force, and Karen 
Sollins is, I believe, chairing a group there that
is chartered to look at wider problems; my mailbox is always open
to suggestions for chartering other WGs for attacking concrete
problems that need concrete solutions.

The output of this working group is supposed to be a set of
Experimental documents. These don't form the be-all and end-all
of the Internet information architecture; they're just an experiment.
But we need to get these documents out, and to get an experiment
going; to that end, I've specifically asked the WG chair to make
sure the WG sticks to its charter, and does NOT try to investigate
other problems.

Then this WG closes, and we have the chance to create a new
one, with a new charter, with or without a new name, to revise
the solution or to create a new one.
But with THIS WG, I've asked it to stick to its charter.

           Harald T. Alvestrand
           Applications AD

--==!Exmh_1839892962P
Content-Type: application/pgp-signature

--==!Exmh_1839892962P--

From: "Ryan Moats" <[email-masked]>
To: "Karen R. Sollins" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Thu, 07 Nov 96 08:18:09 
Priority: Normal
Subject: Re: [URN] Comments on "I18N does not belong in URNs"
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Wed, 6 Nov 1996 20:46:17 -0500, Karen R. Sollins wrote:

>
>   First I have to apologize, because I should have added an indication that
>   that wasn't an entirely serious remark.
>
>Apology accepted.  Truthfully, I was at least as concerned that the
>group as a whole not take your comment seriously:-)
>
>   In a more directed vein, syntax draft already breaks 1737. Specifically, I'm
>   refering to the "case insensitivity" requirement (the draft current
>   has the NSS being case sensitive). "Case-insensitivity" is itself
>   tied up in what character set we use.  If we treat the NSS as a series of 
>   octets, then we can't have case insensitivity, because we haven't set
>   a character set (ho boy am I digressing...)
>
>We ALSO spent many hours arguing over this one.  There were three
>camps, those who thought case sensitivity was important, those who
>thought that case insensitivity was important and those who thought we
>just needed a single decision on it.  As I remember it, the consensus
>really went with the third group and we just had to go one way or the
>other.  So, although I'd really like not to have those discussions
>again, I believe that the majority didn't feel strongly one way or the
>other (unlike many of the other issue in that document:-)

Sorry to be delayed in answering this, but I finally got the code I was working
on last night to work, so I went back to my real life...

Thanks for the information, it's useful for a historical (hysterical? ;-) ) perspective.

Ryan

Subject: Re: [URN] I18N does not belong in URNs
To: [email-masked]
Date: Thu, 7 Nov 1996 14:34:52 +0100 (MET)
Cc: [email-masked]
Content-Length: 1008
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

David Durand wrote:

>   I am not advocating either side at the moment -- I tend to agree that
>transcribability of I18N names will be hellish and error prone. On the
>other hand, eliminating almost all languages in the world from URNs is a
>big hit.

Every script or language has some characters that are easily confused.
In ASCII, this is 0 and O, and l and I and 1. After some time of learning,
such characters get eliminated where necessary, or used only where
they are clearly identifiable from context. Foreign users tend to
be more confused, for example it is customary in Japan to add a
horizontal bar to the stem of a D to distinguish it from O.

Transcribing will be a problem for those that don't know a script.
But I assume that those who designed a naming system e.g. for
Buddhist texts, made the assumption that a minimal knowledge of
the script the texts are in could be assumed. Also, if they choose
kanji, they will have choosen them so that they are easily
disambiguated.

Regards,	Martin.

Date: Thu, 7 Nov 1996 13:11:18 +0000 (GMT)
From: Andy Powell <[email-masked]>
To: Leslie Daigle <[email-masked]>
Cc: Larry Masinter <[email-masked]>, [email-masked]
Subject: Re: [URN] URN-WG home page w/references
Sender: [email-masked]
Reply-To: Andy Powell <[email-masked]>

On Tue, 5 Nov 1996, Leslie Daigle wrote:

> Yes, there is a homepage for the group, although I have not had time to
> update it since we became a working group.
> 
> It lives at:
> 
> 	http://www.bunyip.com/research/urn-ietf/
> 
> Suggestions for content are welcomed...

In a slightly wider context...

As part of a European project that we're working on here I've been
building a (somewhat unstructured) list of resources related to the
identification of 'electronic publications'.

    http://www.ukoln.ac.uk/BIBLINK/wp2/links.html

It includes pointers to information about URNs, PURLs and various schemes
either currently in use by or proposed by the publishing/library
communities (ISBN, ISSN, PII, SICI, DOI, CIS, ISWC...).

Andy.
--
UK Office for Library and Information Networking
University of Bath, Bath, BA2 7AY, UK          Voice: +44 1225 323933
http://homes.ukoln.ac.uk/~lisap/                 Fax: +44 1225 826838

Date: Thu, 7 Nov 1996 10:53:40 +0100
To: Jon Knight <[email-masked]>, Martin J Duerst <[email-masked]>
From: Patrik Faltstrom <[email-masked]>
Subject: Re: [URN] I18N does not belong in URNs
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Patrik Faltstrom <[email-masked]>

At 11.36 +0000 96-11-06, Jon Knight wrote:
>> ISBNs don't qualify. They are not persistent.
>
>Aren't they?  Crumbs, that means that the one scheme everyone is always
>going on about grandfathering in URNs can't be grandfathered.  Bummer.  I
>wonder if that will stuff up our library OPAC?  How long does an ISBN
>exist for until it gets reassigned to another publisher?

It is at least in Sweden (ISBN series that start with 91) the case
that it is the publisher that decides how persistent the ISBN is.
For most books, most publishers do keep the ISBN very long lived,
and does not reassign them. A new ISBN is given to a new version
of a book, but not a new printing. For educational materials,
pens, paper (yes, most things that a publisher or bookstore
sells can because of the billing system most easily be handled
if the "thing" have a ISBN) the ISBNs are more temporary. I know
at least one publisher in Sweden that only had one ISBN allocated
during one print of a book. I.e. assigned a new ISBN for a new
print. They also reused ISBNs after about a year.

So, to conclude, even inside the namespace of ISBNs, each organization
giving out ISBNs do decide themselves what persistence is regardless
of what rules there is globally for "global" ISBNs. This is _exactly_
why bookstores exists that have very advanced databases to be able
to handle an order of an ISBN that have been replaced 15 times with
new number because of reprints and the case that the publisher
uses the ISBN as an identifier for the specification of that
very print of the book, not the contents.

But, I am not saying that ISBNs can not be used as URNs. In most
cases, for _real_ books, an ISBN is persistent information about
a book. Probably a new ISBN for each edition, but library cards
include information about all possible ISBNs for one book, if
you know one of them. My point is that local descisions for
local parts of the namespace can have local rules for
things like persistance.

   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.

Date: Thu, 7 Nov 1996 12:03:31 +0100
From: "Dirk.vanGulik" <[email-masked]>
To: [email-masked]
Subject: [URN] Pending Messages, reboot of elec/139.191.71.138
Sender: [email-masked]
Reply-To: "Dirk.vanGulik" <[email-masked]>

Pending Message: uucp/11 days, 
	2 left; [email-masked], dirkx@elec, [email-masked]
---
Ron,
 
About the last URN HTTP-alike resoving
 
    GET <service>/<uri>  HTTP/1.0
    GET N2L/cid:foo%40huh.com HTTP/1.0
    GET N2L/cid:foo%40huh.com HTTP/1.1
 
As expressed before, I am quite unhappy with using
a 'fudged' (partial) URI in the request, rather than
a proper METHOD or a real different syntax easy
to recognize. Althoug I now agree that the META method
I was advocating in the past in nowhere near flexible
enough.
 
If you look at the way the proxy requests and current
'full' urls in http 1.1 got squeezed in, I think we have
a clear example of what a mess this gives in the long
run when new protocols are added.
 
RFC1738->
        ; HTTP
        httpurl        = "http://" hostport [ "/" hpath [ "?" search ]]
        hpath          = hsegment *[ "/" hsegment ]
        hsegment       = *[ uchar | ";" | ":" | "@" | "&" | "=" ]
        search         = *[ uchar | ";" | ":" | "@" | "&" | "=" ]
 
Looking at RFC1738 I realize that the use of the
'/'  before the colon and the absense of the initial '/'
should perhaps give enough of a  guarantee that both a partial 
is very easy, especially for proxies; and overloding such
a little 'hole' in the specification for extension seems
bad practice to me; the future will bring more and more
proxies en-route, mixed 1.0, 1.1 and 1.x server/client
combinations of different vendors. And a lot f servers are
moving away from being essential unix file based into
database retrival engines; for whom the bit after the '/' is
just a token.
 
So why not really split dimensions, and make it a separate
method:
 
        N2L, N2C or N2N, ...
 
I can assure you that, if this is the way to go; servers
like apache can be augmentated to pass on the method, and
to accept handlers for arbitrary methods. For testing
purposes, there is a copy of a module in Contrib/incoming.
 
And while on the subject; the HTTP\/(\d+)\.(\d+) string;
do we _really_ want that ? given that with the above
will need an add-on. How about URNRESOLV/version.version.
:-)
 
Dw.

Date: Thu, 07 Nov 1996 09:36:26 +0000
To: Renato Iannella <[email-masked]>
From: Bob Briscoe <[email-masked]>
Subject: Re: Re[2]: [URN] Resolution Services (N2L etc)
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Bob Briscoe <[email-masked]>

At 10:13 07/11/96 +1000, Renato Iannella wrote:
>Bob Briscoe <[email-masked]> wrote:
>> If you insist, for instance, that the URC and the resource both have the
>> same URN, you are mandating that a URC must be authored with the permission
>> of the same domain of authority as the author of the resource itself (or
>> vice versa). This stops people *independently* publishing URCs about other
>> people's resources. Now where would the Web be today if you had to get
>> someone's permission to link to them?
>
>I get a good feeling knowing that if I resolve a URN, I will
>get back a URC describing that resource, created and maintained
>by the owners (or their agents) - and not a third party
>review of the resource. If I wanted that, then I would go
>to such a service provider.
>
>If I publish a URN like <urn:inet:dstc.edu.au:rdu/tr009>
>which points to a Technical Report at the DSTC - you can 
>quote it in a Web Page - and like everything - I can only
>guarantee that it will last the lifetime of the DSTC.
>
>If you wish to provide a review of that Technical Report
>(via a URC or whatever) then you are free to, and to allocate
>you own URN, say <urn:inet:bt.co.uk:review:rdu/tr009>.
>

So now, the URN resolution service is doing authentication of metadata too!

Whoaaaa! There are so many assumptions flying around this working group that
aren't documented in the framework.

Hadn't you better look at your security if this is a goal? What if my URC
describes my payment service and says it only charges 2% commission when in
fact it charges 20%? Would the user be able to claim that this unsigned
information misled them into using your payment service on the basis that it
was the authentic metadata tied to the payment service via DNS (rather than
someone else's possibly innocently out of date information)? Would a good
lawyer be able to prove DNS could have been compromised and get the payment
service operator off the hook? Yes.

Why don't you just keep it simple. URNs are a base building block. If you
just stick to name to address mapping, it's less likely to break in the future.

If you want to authenticate metadata, the (now expired) drafts on URCs (e.g.
Ron Daniel's URC Scenarios and requirements
http://www.acl.lanl.gov/URI/Scenarios/scenarios_3.asc ) proposes signing the
metadata which would also be able to tie the resource to the URC by
reference so you could find it from the URC's name).

>I don't wish to allocate a URN _directly_ to the Technical
>Report - because I reserve the right to move it around our
>network and to change its form.

Don't see the problem - that's what URNs are for.
1. If you had a URN for the URC and an URN for the resource, the URC would
just have to refer to the resource's URN.
2. You could just have a URN for the URC which would refer to the resource
addresses directly and be the thing you update if the resources move around
3. You could just have a URN for the resources of you didn't want to bother
with URCs

What I was complaining about is the apparent assumption that the same URN
would be used for both URN and URC and one would have to say N2C if you
wanted the former, and N2L for the latter.

What if BT want to sub-contract our resource description to a trusted third
party so customers find it *more* believable than our own advertisements?
The TTP might be willing to take liability for their descriptions but don't
want the hassle of co-ordinating every URN registration with me?

Ron's proposal: DSTC happy, BT happy.
Your proposal: DSTC happy, BT sad.

I would prefer there to be as near to zero assumptions as to how people
might want to use URNs as possible.

Bob
____________________________________________________________________________
Bob Briscoe         http://www.labs.bt.com/people/briscorj/index.htm

Date: Thu, 7 Nov 1996 00:35:39 -0600 (CST)
From: Daniel LaLiberte <[email-masked]>
To: [email-masked] (Leslie Daigle)
Cc: Daniel LaLiberte <[email-masked]>, "Karen R. Sollins" <[email-masked]>, [email-masked]
Subject: Re: [URN] some comments
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

With all the activity on the URN list in just the last couple days, it
seems like ancient history to bring up the name-location issue again.
(You may have thought it was in the first place, but I think that
is the wrong perspective to take.  See below.)

Instead, I'll just clarify a couple things here (and I'll respond
briefly to a couple other postings later), and perhaps more
importantly I'll make some meta-comments on the process.  After that
Leslie and I and anyone else who wants to participate will thrash it
out off of this list and bring the result back.  Email me if you are
interested.

I do this not with resignation, but because I hope it will be more
effective.  I expect you will consider the issue "on hold" in the
meantime rather than decided by default.

Leslie Daigle writes:
 > 
 > Dan,
 > 
 > For all the words that have flown about on this mailing list in the past
 > few days, I don't really think you've made it clear what you want out
 > of this particular thread.

The issue came up when Karen expressed concern over the optional
"urn:" prefix.  Apparently, it doesn't help to make "urn:" optional
in an attempt to avoid the problems and subsequent discussion.  

 > Let me be fairly blunt in my interpretation
 > here, and you can tell me on which counts I have misunderstood you.
 > 
 > I think there are 2 separate things in what you have been saying:
 > 
 > 	. whether or not URNs are any different than URLs

Yes, that is the main thing we have been discussing.  Note: this is
equivalent to whether or not URLs are any different than URNs.

The issue also has to do with whether and how you bind an identifier
with its resolution mechanism.  So it is intimately related to (not
separate from) the second question:

 > 	. whether or not URNs can be implemented using URL mechanisms

No, not exactly. In fact, I have said several times that I believe we
need the persistence being designed into the URN mechanisms, so it is
more pertinent to ask whether URLs can be resolved with URN
mechanisms.  (But there is more to it than that.)

 > Let me say, as co-chair of this working
 > group, that this WG starts from the premise that there _is_ a difference
 > between URNs and URLs, and that our chartered purpose is ...

This is largely a meta-comment:

Standing on premise and charter as an argument is legalistic and
dogmatic.  That's dangerous, although it may lead to short term
productivity.  If the IETF actually works this way now, it is in
danger of losing the valuable process which has made it work so well
so far.  Documented consensus should not be used as a wedge on future
possibilities but as a foundation upon which to build.  If it turns
out the foundation is flawed, do we attempt to fix it or build on it
anyway?  

Even standards are revised over time, so why should a charter
be held up to be obeyed with more rigor?

 > ... To stick to our charter ... is a reflection of the fact that
 > this is a directed effort.

That has a positive ring to it.  All I'm trying to do is redirect the
effort a bit.  I wouldn't be here if I didn't think there was merit in
most of the effort.

How many people believe the "waterfall" approach to software
development should be followed strictly with never a revision or
retraction of the earlier steps along the way?  We are following the
waterfall model by establishing a charter, and similarly, by
establishing URN requirements, and then sticking to these earlier
decisions as if they were written in concrete.

I think a big part of the problem with this whole process is reflected
in partly why some IETF working groups have been dissolved.  Remember
"Rough consensus and working code".  We seem to be forgetting about
the working code part.  The value of the working code is that it
forces the issue of what makes sense in the real world.  Requirements
may crumble in the face of practical realities.  

So how do we make progress while the foundation may be shifting?  It
is done in practice all the time, so I wouldn't worry about that too
much.  We may waste more time arguing over whether we should allow a
change in the foundation than just deciding what needs to be changed.

Karen has repeatedly expressed concern about making progress, and I
share that concern, but is coming to an understanding of the issues
not making progress?  

 > > This is not a matter of just agreeing on a definition - it is a matter
 > > of having definitions that make sense.
 > 
 > A relative term -- I think the definitions make perfect sense.

I'm willing to argue with you about what makes sense.  I'm not willing
to argue legalities.  Nor do I believe this is a religious issue in
the sense that it comes down to a matter of opinions. There is very
little religion in mathematics.

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

Date: Wed, 6 Nov 1996 20:52:18 -0500
From: Lewis Girod <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [URN] Re meaningful names
Sender: [email-masked]
Reply-To: Lewis Girod <[email-masked]>

   Date: Wed, 6 Nov 1996 16:35:41 -0800 (PST)
   From: Terry Allen <[email-masked]>

   Well, no.  The name is the name; if you come to dislike it or think
   it doesn't mean the right thing you can map something else onto it
   in a new name space.  If an existing name space uses "Mainframes",
   so be it; it will still work just fine as part of an unambiguous
   identifier (even if users have to be told "what name space FOO
   calls Mainframes we now call Enterprise Systems").

Right, that was what I meant by ``overall cruftiness''.  At any given
time large portions of the namespace are providing backwards
compatibility for out-of-date semantics.

   | Of course, as you point out there is no way to stop people from
   | putting semantics into names; the most effective way to deal with the
   | issue is to implement a system of user friendly names over the top of
   | URNs; 99% of the time the user would see and type only a UFN, and
   | these UFNs would be resolved to the URNs that could then be used as
   | long-lived references.

   Twice the work or more, doesn't deal with grandfathering, prone
   to error; the most effective way to deal with the issue is to
   drop your objection to meaningful names.

It is more work (though how much more is hard to say), but it might
prove really useful.  I don't think it would impact grandfathering at
all; grandfathered names could have a UFN alias or they might just be
typed in as URNs.  Prone to error?  UFNs wouldn't have the longevity
characteristics that URNs hopefully would have, if that's what you
mean -- that's why you don't use them in published links.

   Lewis:
   | One idea we were experimenting with here was to use a subset of ASCII
   | that included only numerals, punctuation and consonants, which would
   | make most words hard to express (at least in some languages).

   I cannot imagine that such an approach would find favor in the real
   world.  

Outside of the context of a UFN infrastructure, no; but the real world
has found utility in many namespaces as unfriendly as that... as long
as people don't have to get too involved with them.  As for whether
such a scheme would ever gain real world acceptance, that probably
depends largely on the implementation of a UFN scheme, and whether the
real world finds it to be sufficient for their purposes.

This discussion of UFNs is probably getting off the topic -- the part
of this opinion that is relevant to the topic is that in the backs of
our minds we should remember that semantics in names and longevity
seem to be at cross purposes, and it would be nice if at some time in
the future most new names were free of semantics.  Given that, should
we build in additional mechanisms specifically to support semantics in
URNs?

	-lewis

Date: Wed, 6 Nov 1996 20:46:17 -0500
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [URN] Comments on "I18N does not belong in URNs"
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

   First I have to apologize, because I should have added an indication that
   that wasn't an entirely serious remark.

Apology accepted.  Truthfully, I was at least as concerned that the
group as a whole not take your comment seriously:-)

   In a more directed vein, syntax draft already breaks 1737. Specifically, I'm
   refering to the "case insensitivity" requirement (the draft current
   has the NSS being case sensitive). "Case-insensitivity" is itself
   tied up in what character set we use.  If we treat the NSS as a series of 
   octets, then we can't have case insensitivity, because we haven't set
   a character set (ho boy am I digressing...)

We ALSO spent many hours arguing over this one.  There were three
camps, those who thought case sensitivity was important, those who
thought that case insensitivity was important and those who thought we
just needed a single decision on it.  As I remember it, the consensus
really went with the third group and we just had to go one way or the
other.  So, although I'd really like not to have those discussions
again, I believe that the majority didn't feel strongly one way or the
other (unlike many of the other issue in that document:-)

			Karen

From: [email-masked]
Date: Wed, 6 Nov 96 20:35 EST
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: [URN] I18N does not belong in URNs
Content-Length: 1716
Sender: [email-masked]
Reply-To: [email-masked]

>I would like to be more specific about Keith Moore's statement:
>
>   URNs should be precise enough that a human isn't required to
>   disambiguate the result.
>
>In particular, in light of the following requirement from RFC 1737
>
>   o Global uniqueness: The same URN will never be assigned to two
>     different resources.
>
>the URN will refer to exactly one resource from the perspective of
>                                           ^^^^^^^^^^^^^^^^^^^^^^^
>that naming authority assigning the name.  This is actually a
>^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>complicated problem having to do with who believes which things are
>"the same" by what definition.  This was carefully crafted after
>lengthy and heated discussion.  Before we launch into another lengthy
>discussion about this, I recommend to all of you who were not involved
>in the first round of this that you think about it VERY hard.  Each
>naming authority is making a declaration about its own model of
>"sameness".  This is not in the eye of the beholder, but in the eye of
>the namer.  And it is that that we are expressing in URNs.  We are
>saying that if you have two URNs and they are "the same" under some
>simple rules for canonicalizing them (also mentioned in 1737), then by
>some definition known to the naming authority (although not
>necessarily known to the holder of the URN) they identify and always
>will the same resource.

Having thought about this in the specific context of the syntax draft, I am
in complete agreement with the statement as I have quoted it.  I would note
that simple here implies (in my mind) very limited knowledge (read none) of
the namespace itself.

I don't think we want to change that.

Ryan

From: [email-masked]
Date: Wed, 6 Nov 96 20:16 EST
To: [email-masked], [email-masked]
Cc: [email-masked]
Subject: Re: [URN] Comments on "I18N does not belong in URNs"
Content-Length: 2341
Sender: [email-masked]
Reply-To: [email-masked]

Karen R. Sollins said:

>Ryan Moats said:
>
>   Well, RFC 1737 is informational so we can break it IF WE HAVE GOOD
>   REASON and consensus.  (This is a null statement, but I wanted to make
>   it anyway).
>
>It is informational because it is neither the specification of a
>protocol nor the specification of protocol payload, and therefore
>cannot be standardized.  Beyond that, consider it a standard.  It is
>the base from which we are working.  We went over all much of the
>ground be rediscovered here and more and reached consensus in order to
>produce 1737.  If we are always in a state of flux where we cannot
>make assumptions based on previous consensus reached, we will NEVER
>make progress and this is a futile exercise.  I'm sure we all have
>better things to do.  So, take it as a given that RFC 1737 stands.  If
>there is consensus that it doesn't, this working group must be
>disolved.
>

First I have to apologize, because I should have added an indication that
that wasn't an entirely serious remark.

<MINOR SOAPBOX>
Having said that, I still claim that as we move forward, we have the right
to realize that something in 1737 isn't optimal or doesn't work etc.  My
opinion is that if there is rough consensus in the WG, then saying "but
1737 says that's a no-no" doesn't cut it.
</MINOR SOAPBOX>

In a more directed vein, syntax draft already breaks 1737. Specifically, I'm
refering to the "case insensitivity" requirement (the draft current
has the NSS being case sensitive). "Case-insensitivity" is itself
tied up in what character set we use.  If we treat the NSS as a series of 
octets, then we can't have case insensitivity, because we haven't set
a character set (ho boy am I digressing...)

<OPEN ISSUE>
I do have an issue that folks either haven't been thinking about or
have tabled until other things get settled, and that is the
whole escaping issue.  Will we ever want to escape octets of the URN
at the client?  Now, I discount transport encoding with the assumption
that the transport mechanism has to unencode the URN before passing it up.
The syntax draft was written assuming that we would, but that seems to
create all sorts of troubles if we allow namespaces to set up their own escape
mechanisms (and allow non restricted octets in the URN).

Does anybody have an opinion on this?
</OPEN ISSUE>

Ryan

From: Keith Moore <[email-masked]>
To: "Karen R. Sollins" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [URN] I18N does not belong in URNs 
Date: Wed, 06 Nov 1996 20:12:46 -0500
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> I would like to be more specific about Keith Moore's statement:
> 
>    URNs should be precise enough that a human isn't required to
>    disambiguate the result.
> 
> In particular, in light of the following requirement from RFC 1737
> 
>    o Global uniqueness: The same URN will never be assigned to two
>      different resources.
> 
> the URN will refer to exactly one resource from the perspective of
>                                            ^^^^^^^^^^^^^^^^^^^^^^^
> that naming authority assigning the name.  

Yes, this is exactly correct.

But what this means is that if you ask the naming authority to do
resolution on a URN, you won't get back references to multiple resources.

Contrast this with a search for matches to a user-friendly string,
which always has the potential for multiple hits.

Keith

Date: Wed, 6 Nov 1996 20:06:02 -0500
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [URN] I18N does not belong in URNs
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

I would like to be more specific about Keith Moore's statement:

   URNs should be precise enough that a human isn't required to
   disambiguate the result.

In particular, in light of the following requirement from RFC 1737

   o Global uniqueness: The same URN will never be assigned to two
     different resources.

the URN will refer to exactly one resource from the perspective of
                                           ^^^^^^^^^^^^^^^^^^^^^^^
that naming authority assigning the name.  This is actually a
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
complicated problem having to do with who believes which things are
"the same" by what definition.  This was carefully crafted after
lengthy and heated discussion.  Before we launch into another lengthy
discussion about this, I recommend to all of you who were not involved
in the first round of this that you think about it VERY hard.  Each
naming authority is making a declaration about its own model of
"sameness".  This is not in the eye of the beholder, but in the eye of
the namer.  And it is that that we are expressing in URNs.  We are
saying that if you have two URNs and they are "the same" under some
simple rules for canonicalizing them (also mentioned in 1737), then by
some definition known to the naming authority (although not
necessarily known to the holder of the URN) they identify and always
will the same resource.  For those of us who believe that semantics
and mnemonics for humans should be handled elsewhere, this is the sum
total of the semantics embodied in URNs and that is completely
intentional.

Note that this says nothing about what happens when you hold two
different URNs.  All bets are off in that case:-)

			Karen

Date: Wed, 6 Nov 1996 16:34:47 -0800 (PST)
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [URN] I18N does not belong in URNs
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

Date: Wed, 6 Nov 1996 16:35:41 -0800 (PST)
From: Terry Allen <[email-masked]>
To: [email-masked]
Subject: [URN] Re meaningful names
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

[subject line changed to decouple Unicode from meaningful naming]

I wrote:
|    Our longest-lived names actually are meaningful to humans; to support
|    your argument you have to establish that semantic drift affects
|    names specifically (Moby Dick, Julius Caesar, Assurnasirpal) and
|    that using them in the context of a defined name space does not
     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|    insulate them from semantic drift. 

Lewis Girod replied:
| The names you are using as examples are all long lived because they
| refer to conceptually immutable objects.  This is the case in which
| names are afforded some protection from semantic drift, although it
| does not necessarily protect them completely.  Out of context, I can't
| tell if you mean Julius Caesar the guy who got stabbed or Julius
| Caesar the play (and that was not an issue when JC was around!,) but
| in the context of a namespace of people or plays that problem would be
| resolved.  Either way the name refers to a piece of history that,
| whether or not it is well defined, people have an idea of what you
| mean that doesn't change too much.

Exactly.  urn:roman.emperors:julius.caesar is not ambiguous.

| However, I think what Keith was getting at was a problem that arises
| when semantics is embedded in names in an attept to structure
| hierarchical namespaces.  The sort of semantic mechanism involved with
| categorizing things is much more likely to drift over time; a
| collection of companies originally categorized under ``Mainframes''
| might want to recategorize under ``Enterprise systems''.  (Over longer
| spans of time spellings and meanings of words change -- Julius Caesar
| was originally filed under playes perhaps.)  In the context of URNs,
| every move we make we are stuck with forever... which eventually leads
| to silly results and overall cruftiness.  There is little point in 
| having semantically significant names unless you retain semantics that
| makes sense as time goes on.  

Well, no.  The name is the name; if you come to dislike it or think
it doesn't mean the right thing you can map something else onto it
in a new name space.  If an existing name space uses "Mainframes",
so be it; it will still work just fine as part of an unambiguous
identifier (even if users have to be told "what name space FOO
calls Mainframes we now call Enterprise Systems").
 
| Of course, as you point out there is no way to stop people from
| putting semantics into names; the most effective way to deal with the
| issue is to implement a system of user friendly names over the top of
| URNs; 99% of the time the user would see and type only a UFN, and
| these UFNs would be resolved to the URNs that could then be used as
| long-lived references.

Twice the work or more, doesn't deal with grandfathering, prone
to error; the most effective way to deal with the issue is to
drop your objection to meaningful names.

Keith:
| > Few people on this planet can accurately transcribe anything.  
| That's not true.  People regularly transcribe telephone numbers, 
| email addresses, ISBNs, URLs, credit card numbers, etc. with 
| sufficient accuracy for their purposes.  But ask people to 

Actually, they regularly mistranscribe them.  In the past two
weeks I have mistranscribed my VISA number and the VIN of
my newly acquired used car, precisely because they are inherently
meaningless.

Martin, I think it was, pointed out the value of meaning for
correct transcriptions.  I think he's right.  But I also think
it's an issue this group should not legislate on:  tell inventors
of new name spaces what you like in the way of good practice,
but don't prescribe.

| > Your
| > last point would have merit were it not that we absolutely must
| > be able to grandfather in existing name spaces.
| 
| Yes, we must be able to grandfather existing name spaces *that serve
| similar purposes to URNs*.  ISBNs qualify.  Handles qualify.
| Usenet message-ids qualify.  But URNs don't have to handle existing
| name spaces that don't have the characteristics that URNs have.

This is circular argument unless it's grounding in the group's
charter.  What I find in the charter as Leslie posted it is:

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

That's far from saying that URNs shall not be meaningful, legible,
or user-friendly.  And RFC 1737 (section 5) explicitly takes no
position on use of meaningful semantics.

I don't find grounding for your argument.

| I don't think this is a problem, because I don't think existing URN-like
| name spaces are likely to be human friendly in the first place.  (If someone
| knows of a counterexample, please tell us.)

Circular reasoning again.  "Human friendliness" is not a defined
property of URNs at the moment.

Lewis:
| One idea we were experimenting with here was to use a subset of ASCII
| that included only numerals, punctuation and consonants, which would
| make most words hard to express (at least in some languages).
     
I cannot imagine that such an approach would find favor in the real
world.  

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, 6 Nov 1996 19:36:27 -0500
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [URN] Comments on "I18N does not belong in URNs"
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

Ryan Moats said:

   Well, RFC 1737 is informational so we can break it IF WE HAVE GOOD
   REASON and consensus.  (This is a null statement, but I wanted to make
   it anyway).

It is informational because it is neither the specification of a
protocol nor the specification of protocol payload, and therefore
cannot be standardized.  Beyond that, consider it a standard.  It is
the base from which we are working.  We went over all much of the
ground be rediscovered here and more and reached consensus in order to
produce 1737.  If we are always in a state of flux where we cannot
make assumptions based on previous consensus reached, we will NEVER
make progress and this is a futile exercise.  I'm sure we all have
better things to do.  So, take it as a given that RFC 1737 stands.  If
there is consensus that it doesn't, this working group must be
disolved.

Just so you understand, although you are reading a great deal of
unanimity (not complete) from those involved in that earlier work,
there was a great deal of contention then also.

			Karen

From: Renato Iannella <[email-masked]>
Date: Thu, 7 Nov 1996 10:13:47 +1000 (EST)
To: [email-masked]
Cc: [email-masked]
Subject: Re[2]: [URN] Resolution Services (N2L etc)
Sender: [email-masked]
Reply-To: Renato Iannella <[email-masked]>

Bob Briscoe <[email-masked]> wrote:
> If you insist, for instance, that the URC and the resource both have the
> same URN, you are mandating that a URC must be authored with the permission
> of the same domain of authority as the author of the resource itself (or
> vice versa). This stops people *independently* publishing URCs about other
> people's resources. Now where would the Web be today if you had to get
> someone's permission to link to them?

I get a good feeling knowing that if I resolve a URN, I will
get back a URC describing that resource, created and maintained
by the owners (or their agents) - and not a third party
review of the resource. If I wanted that, then I would go
to such a service provider.

If I publish a URN like <urn:inet:dstc.edu.au:rdu/tr009>
which points to a Technical Report at the DSTC - you can 
quote it in a Web Page - and like everything - I can only
guarantee that it will last the lifetime of the DSTC.

If you wish to provide a review of that Technical Report
(via a URC or whatever) then you are free to, and to allocate
you own URN, say <urn:inet:bt.co.uk:review:rdu/tr009>.

I don't wish to allocate a URN _directly_ to the Technical
Report - because I reserve the right to move it around our
network and to change its form.

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, 6 Nov 1996 18:48:00 -0500
From: Lewis Girod <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] I18N does not belong in URNs
Sender: [email-masked]
Reply-To: Lewis Girod <[email-masked]>

   Date: Wed, 6 Nov 1996 11:21:49 +0100 (MET)
   From: Martin J Duerst <[email-masked]>

   It is very clear that you can't retain semantics as time goes on.
   "mainframe" may mean something completely different in 5 years,
   or in 100 years, and it is impossible to predict. If people on

Agreed; certainly some names will last longer than others but
on the whole ``semantic drift'' is a fact of life.

   this group seriously would agree to restrict URNs to digits
   only for this reason, I would understand.
   But with ASCII as a "restricted" character set, we will definitely
   get cruftiness, and I see no reason to allow cruftiness for
   English, but to deny it for most other languages.

One idea we were experimenting with here was to use a subset of ASCII
that included only numerals, punctuation and consonants, which would
make most words hard to express (at least in some languages).

   The interesting thing is that we already have that, in the current
   syntax draft. Just call the readable form of it UFNs, and call
   the encoded form, %HH-escaped, URNs. I have proposed similar
   names for these things, namely IRNs (internationalized ...).

True, those strings are hard to read but it doesn't solve the problem
because the URN and the UFN are tightly coupled -- the whole point of
UFNs is that they are nicknames with a short lifespan.  A UFN should
be allowed to change over time without ever changing the aliased URN.

	-lewis

From: Keith Moore <[email-masked]>
To: Martin J Duerst <[email-masked]>
Cc: [email-masked] (Keith Moore), [email-masked], [email-masked]
Subject: Re: [URN] I18N does not belong in URNs 
Date: Wed, 06 Nov 1996 15:32:28 -0500
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> >> >> Your
> >> >> last point would have merit were it not that we absolutely must
> >> >> be able to grandfather in existing name spaces.
> >> >
> >> >Yes, we must be able to grandfather existing name spaces *that serve
> >> >similar purposes to URNs*.  ISBNs qualify.  Handles qualify.
> >> >Usenet message-ids qualify.  But URNs don't have to handle existing
> >> >name spaces that don't have the characteristics that URNs have.
> 
> >> And the fact that you
> >> don't know about any such namespaces doesn't guarantee that there
> >> are no such namespaces.
> 
> I thought I didn't know any such namespaces when I wrote this mail.
> But I have become aware that my postal savings account number in
> Japan contains a kanji. The set of kanji in this case is limited
> to one each for each of the central offices that keeps track of
> postal savings accounts. I am very sure also that there are lots
> of other examlpes that fit the requirements of URNs at least as
> well as ISBNs that contain kanji or other non-ASCII characters.

Perhaps.  I don't have as big a problem with this, as long as
there's a discipline about how they are assigned that prevents
URNs from being used as search strings.  That's my main worry.
(URNs are also supposed to be transcribable, but I recognize that
only a very small set of characters is transcribable by everyone
on the planet.)

Sorry, I can't make heads or tails of this.

> So for grandfathering, we have two choices.
> 
> 1) We interpret it as "direct grandfathering of characters",
> 	in which case we have to allow a really wide range
> 	of characters (i.e. ISO 10646).
> 2) We interpret it as "indirect grandfathering", in which
> 	case the digits, or whatever small set, will be
> 	enough.

I suspect there will be some of each.  But we want the transformations
from "old identifier" to URN to be simple and easy to remember.
Ideally, you just prepend a URN:namespace: string.  In some cases
it may be necessary to remove punctuation; for instance, we might
want to remove '-' characters from ISBNs.  But that gets specified
on a per-namespace basis.

> Choosing ASCII only as for URLs would be very unfair cheating.

If the names aren't human meaningful, I don't see what you're
complaining about.

> >> I definitely hate to see i18n just being moved around and delayed
> >> by some people. With UTF-8 in URNs, we have made great progress.
> >
> >No, this is a big step backward.  Just because there is a new layer
> >being defined doesn't mean that I18N belongs there.  
> >
> >I18N *is* important  -- and I'd be happy to see a draft document or 
> >draft charter for a working group to define a protocol (say an extension
> >of http/html) to resolve human-friendly names into URNs or URLs.
> 
> Why is there a need for an additional protocol layer?
> There is no need currently for English, is it?

Yes, there is.  Human-friendly names are inherently ambiguous,
and have ambiguous meanings which require a human being to untangle.
(If I ask for "Julius Caesar", do I mean the Shakespeare play or 
the person or what?  Most people would think the name is unambiguous--
after all, they already know what they have in mind and the other 
meanings will not occur to them.  But if you feed "Julius Caesar"
to a library catalog, you will get back large numbers of hits.
By contrast, if you feed )

URNs should be precise enough that a human isn't required to
disambiguate the result.

> And I don't want to have to search through long lists
> of possible answers just because I use Japanese, whereas
> I will get one immediate answer for English.

The point is that you will often get multiple answers for English.
English names are no more precise than names in other languages.

> >> Some protocols (notably FTP) are also going in the direction of
> >> UTF-8. Ideally, we will have a uniform solution for both URLs
> >> and URNs, based on UTF-8. 
> >
> >No.  Ideally, if we figure out how to do this, we will have a 
> >uniform solution for all URLs.  I18N (and even E8H :) absolutely 
> >doesn't belong in URNs.
> 
> Well, if URLs are uniformly internationalized, I wouldn't
> mind about URNs. But I know that there are people, and
> this probably includes you, that claim that URLs also
> are not designed to be human-friendly.

They weren't *designed* to be human-friendly, and they don't do 
a very good job of it (if nothing else, they're hard to type and you 
can't easily say them out loud).  But URLs tend to reflect their 
underlying file and directory structures, which *are* (sort of)
human-friendly.  (really they're more author-friendly)

> >For URNs, human-friendliness will be excluded by design.
> 
> I18N and human-friendliness are not the same thing.
> For direct grandfathering, I18N is needed. If you are
> sure human-friendliness will not sneak into URNs
> with ASCII, it will also not sneak into URNs with
> UTF-8.

I think URNs need restrictions on human-friendliness in either case.

Keith

Date: Wed, 06 Nov 1996 17:39:57 +0000
To: [email-masked]
From: Bob Briscoe <[email-masked]>
Subject: Re: [URN] Persistence as part of URN framework
Cc: Fisher Mark <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]
Reply-To: Bob Briscoe <[email-masked]>

At 15:58 06/11/96 +0100, [email-masked] wrote:
>[email-masked] said:
>> A URN user is not just someone who clicks on one. It could also be 
>> someone who publishes one (that you have published) to refer to your 
>> work in their work. They need to know how long they should reliably 
>> use your URN. Meta-data that any party might need is a proper 
>> candidate for holding in infrastructure. 
>
>That's what I called an "URN buyer"
>When I get an URN from someone, and apply it to my resources,
>I would figure that I "own" that URN.

No, no, no. I don't mean the owner of the URN.

I mean someone who incorporates someone else's URN string in their work,
just like I could stick urn:mailto:[email-masked] in here if
you had published that as a URN.

Then you are the 'URN buyer' or 'URN owner'
I am the 'URN referrer' (inventing a word because quoter, citer etc. sound
wobbly)
And whoever clicks on the thing once they read this with a URN enabled mail
client is the 'URN user'.

If I put such an HREF to a URN in a WEB page, for instance, I might want to
know how often to check it was still resolvable.

>
>[email-masked] said:
>> Get my drift?
>No. I still think the information publisher ("URN buyer) is the one
>for which this information is vital, and that the information should
>be part of the business contract between the provider of the URN
>namespace and the information publisher.
>The URN user (the one who looks up the information) should have no
>need to know or care.

Does this extra clarity change your view?

Bob
____________________________________________________________________________
Bob Briscoe         http://www.labs.bt.com/people/briscorj/index.htm

Date: Wed, 6 Nov 1996 12:27:54 -0500
To: [email-masked]
From: [email-masked] (David G. Durand)
Subject: Re: [URN] I18N does not belong in URNs
Sender: [email-masked]
Reply-To: [email-masked] (David G. Durand)

At 9:32 PM 11/5/96, Keith Moore wrote:
>I don't think this is a problem, because I don't think existing URN-like
>name spaces are likely to be human friendly in the first place.  (If someone
>knows of a counterexample, please tell us.)

ISO Formal Public identitfiers are are semi-friendly (human-readable
strings in the roman alphabet, assigned by users according to a prescribed
organizational protocol). They are also in active, productive use in the
SGML community, even without a global resolution service.

>(Please note that assuming we can define I18N'ed URLs -- and there is
>certainly a better case to be made for these then I18N'ed URNs -- I
>would have no problem with this group defining resolution protocols that
>can be used with them.  It's just that I18N isn't appropriate for the
>URN name-space.  And I18N'ed URLs aren't in scope for this group.)

Well, FPIs don't have that problem (the character set is _very_
restrictive), but, since we have human-readable URNs and they will continue
to exist (good idea or not) the issue of I18N is relevant.

   I am not advocating either side at the moment -- I tend to agree that
transcribability of I18N names will be hellish and error prone. On the
other hand, eliminating almost all languages in the world from URNs is a
big hit.

   -- David

_________________________________________
David Durand              [email-masked]  \  [email-masked]
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

Subject: Re: [URN] I18N does not belong in URNs
To: [email-masked] (Keith Moore)
Date: Wed, 6 Nov 1996 18:02:19 +0100 (MET)
Cc: [email-masked], [email-masked], [email-masked]
Content-Length: 3407
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Keith Moore wrote:

>> >> Your
>> >> last point would have merit were it not that we absolutely must
>> >> be able to grandfather in existing name spaces.
>> >
>> >Yes, we must be able to grandfather existing name spaces *that serve
>> >similar purposes to URNs*.  ISBNs qualify.  Handles qualify.
>> >Usenet message-ids qualify.  But URNs don't have to handle existing
>> >name spaces that don't have the characteristics that URNs have.

>> And the fact that you
>> don't know about any such namespaces doesn't guarantee that there
>> are no such namespaces.

I thought I didn't know any such namespaces when I wrote this mail.
But I have become aware that my postal savings account number in
Japan contains a kanji. The set of kanji in this case is limited
to one each for each of the central offices that keeps track of
postal savings accounts. I am very sure also that there are lots
of other examlpes that fit the requirements of URNs at least as
well as ISBNs that contain kanji or other non-ASCII characters.
Think about a library that collects Buddhist texts.
For a specific bidirectionality feature, overriding, the use for
part numbers is always cited. This means that there must be
part numbers (a typical URN-like example again) that contain
Arabic or Hebrew, mixed with numbers and Latin.

So for grandfathering, we have two choices.

1) We interpret it as "direct grandfathering of characters",
	in which case we have to allow a really wide range
	of characters (i.e. ISO 10646).
2) We interpret it as "indirect grandfathering", in which
	case the digits, or whatever small set, will be
	enough.

Choosing ASCII only as for URLs would be very unfair cheating.

>> I definitely hate to see i18n just being moved around and delayed
>> by some people. With UTF-8 in URNs, we have made great progress.
>
>No, this is a big step backward.  Just because there is a new layer
>being defined doesn't mean that I18N belongs there.  
>
>I18N *is* important  -- and I'd be happy to see a draft document or 
>draft charter for a working group to define a protocol (say an extension
>of http/html) to resolve human-friendly names into URNs or URLs.

Why is there a need for an additional protocol layer?
There is no need currently for English, is it?
And I don't want to have to search through long lists
of possible answers just because I use Japanese, whereas
I will get one immediate answer for English.

>> Some protocols (notably FTP) are also going in the direction of
>> UTF-8. Ideally, we will have a uniform solution for both URLs
>> and URNs, based on UTF-8. 
>
>No.  Ideally, if we figure out how to do this, we will have a 
>uniform solution for all URLs.  I18N (and even E8H :) absolutely 
>doesn't belong in URNs.

Well, if URLs are uniformly internationalized, I wouldn't
mind about URNs. But I know that there are people, and
this probably includes you, that claim that URLs also
are not designed to be human-friendly.

>> For URNs, it will be by design, for
>> URLs, it will be more by retrofitting, because according to
>> the URL syntax document, the individual schemes have full
>> autonomy.
>
>For URNs, human-friendliness will be excluded by design.

I18N and human-friendliness are not the same thing.
For direct grandfathering, I18N is needed. If you are
sure human-friendliness will not sneak into URNs
with ASCII, it will also not sneak into URNs with
UTF-8.

Regards,	Martin.

Date: Wed, 6 Nov 1996 16:33:07 +0000 (GMT)
From: Jon Knight <[email-masked]>
To: Bob Briscoe <[email-masked]>
Cc: Terry Allen <[email-masked]>, [email-masked], [email-masked]
Subject: RE: [URN] Persistence as part of URN framework
Sender: [email-masked]
Reply-To: Jon Knight <[email-masked]>

On Wed, 6 Nov 1996, Bob Briscoe wrote:
> I'm saying the framework should require that any solution (like NAPTR)
> should allow the option of specifying the longevity of the ability to
> resolve the name.
> 
> If you don't allow this, the only people who will ever use this will be
> non-commercial organisations who think they are free to say "for ever"
> without regard to the consequences. No commercial organisation would enter
> into anything which included any commitment "for ever".

<JOKE>
Great, so this means that we can "commerce-proof" URNs from day one.
Definately a +ve feature... :-)
</JOKE>

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

Subject: Re: [URN] I18N does not belong in URNs
To: [email-masked]
Date: Wed, 6 Nov 1996 17:26:43 +0100 (MET)
Cc: [email-masked], [email-masked], [email-masked]
Content-Length: 1675
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Keith Moore wrote:

>>  If people on
>> this group seriously would agree to restrict URNs to digits
>> only for this reason, I would understand.
>
>Except for grandfathering, we could do this.  As it is, I think
>URNs can generally be restricted so that they're unlikely to be
>human-friendly.  Existing human-friendly namespaces are unlikely
>to meet the requirements for URNs.  Namespaces that do meet the
>URN requirements will have their own disciplines for assigning names,
>which URNs for those namespaces will inherit.  New URN schemes
>must have a specified discipline for assigning names.

I understand what you want. And if everybody that will go to
define namespaces and that will use URNs would understand it,
too, it might work. But I am realistic in that I don't think
things will stay restricted unless the syntax is very strictly
restricted. It may be the 10 digits only, or it may be one
or two more characters for separation and structure.
But if you make it the whole Latin alphabet, even just upper
case, people will break your intentions.
What about saying that we have the digits plus "-" and "."?
Or maybe "*" and "#", because then you can type URNs even on
some telephones (don't believe these keys are on all telephones
of the world, though).
An ISBN namespace would define that "X" is substituted by
".". Other namespaces would need more difficult substitutions.
The same types of substitutions would apply to namespaces using
latin letters as well as namespaces using characters from other
alphabets. Grandfathering would still work, although of course
it would be very clumsy. But it would be the same clumsiness
for everybody.

Regards,	Martin.

From: Keith Moore <[email-masked]>
To: Martin J Duerst <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] I18N does not belong in URNs 
Date: Wed, 06 Nov 1996 10:42:18 -0500
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> >That's not true.  People regularly transcribe telephone numbers, 
> >email addresses, ISBNs, URLs, credit card numbers, etc. with 
> >sufficient accuracy for their purposes.  But ask people to 
> >transcribe identifiers in (say) Klingon, or to type them in 
> >on a keyboard not designed for such, and you'll get much lower 
> >accuracy.
> 
> Most telephone numbers of companies are meaningful. 

Really? I don't find that to be true in practice.  Looking 
through my personal phone book, only two out of thirty-one
business phone numbers had any string or substring I could
recognize as meaningful.

> Most
> email addresses are meaningful. Many URLs are meaningful.
> Transcribability is aided by meaninfulness; there is a smaller
> chance to make a mistake if one of these things is meaninful
> than without meaningfulness.

Yes.  But long-term persistance is damaged by meaningfulness.

> And Klingon is a VERY bad example. Nobody speaks Klingon.
> Nobody grew up with Klingon. Nobody learned Klingon in
> school as we learn the Latin script, and others learn
> their traditional scripts. And Klingon isn't even in
> Unicode. Klingon is a fancy of some SF enthusiasts,
> and not a script used by millions every day to express
> and exchange their thoughts and feelings.

It's not a perfect example.  I picked it because it is
a foreign language to nearly everybody.

> >> Your
> >> last point would have merit were it not that we absolutely must
> >> be able to grandfather in existing name spaces.
> >
> >Yes, we must be able to grandfather existing name spaces *that serve
> >similar purposes to URNs*.  ISBNs qualify.  Handles qualify.
> >Usenet message-ids qualify.  But URNs don't have to handle existing
> >name spaces that don't have the characteristics that URNs have.
> >Offhand, I don't know of any name spaces that have such characteristics,
> >that attempt to be human friendly.
> 
> ISBNs don't qualify. They are not persistent. 

My understanding is that they're supposed to be persistent,
though they are not always so in practice because some countries
have too-little ISBN space so they must reassign them.  

> And the fact that you
> don't know about any such namespaces doesn't guarantee that there
> are no such namespaces.

No, it doesn't.

> About 30 years ago, some people said "I don't know of anybody
> that would want to use anything else than English on computers".
> And then they went on to design protocols :-(.
> 
> 
> >> We should be building the big tent that everyone can live under,
> >> not trying to close out name spaces we don't like.  
> >
> >Yes, and we should also be restricting the problem to something that has 
> >a hope of a reasonable solution.  They're not mutually exclusive, but 
> >over-reliance on the "one big tent" theory has caused the failure of 
> >many protocols.
> >
> >(Please note that assuming we can define I18N'ed URLs -- and there is 
> >certainly a better case to be made for these then I18N'ed URNs -- I 
> >would have no problem with this group defining resolution protocols that 
> >can be used with them.  It's just that I18N isn't appropriate for the 
> >URN name-space.  And I18N'ed URLs aren't in scope for this group.)
> 
> When I participated in several attempts and discussions to
> internationalize URLs, I was told by several people that have
> also shown up on this list that for URLs, i18n would be difficult,
> but that it would be solved for URNs.

People had different understandings of what URNs are for.

> I definitely hate to see i18n just being moved around and delayed
> by some people. With UTF-8 in URNs, we have made great progress.

No, this is a big step backward.  Just because there is a new layer
being defined doesn't mean that I18N belongs there.  

I18N *is* important  -- and I'd be happy to see a draft document or 
draft charter for a working group to define a protocol (say an extension
of http/html) to resolve human-friendly names into URNs or URLs.

> Some protocols (notably FTP) are also going in the direction of
> UTF-8. Ideally, we will have a uniform solution for both URLs
> and URNs, based on UTF-8. 

No.  Ideally, if we figure out how to do this, we will have a 
uniform solution for all URLs.  I18N (and even E8H :) absolutely 
doesn't belong in URNs.

> For URNs, it will be by design, for
> URLs, it will be more by retrofitting, because according to
> the URL syntax document, the individual schemes have full
> autonomy.

For URNs, human-friendliness will be excluded by design.

Keith

Date: Wed, 06 Nov 1996 09:38:16 -0600
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: Keith Moore <[email-masked]>, URN Mailing List <[email-masked]>
Cc: Terry Allen <[email-masked]>, Lewis Girod <[email-masked]>, Martin J Duerst <[email-masked]>
Subject: [URN] Comments on "I18N does not belong in URNs"
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

All-

I'm going to try to munge my replies together to lots of mail
that I saw this AM....

Keith Moore wrote (>):
> 
> Support for UTF-8 in URNs is a gross layering violation.  It also
> violates the requirements of RFC 1737 in several ways:

Well, RFC 1737 is informational so we can break it IF WE HAVE GOOD
REASON and consensus.  (This is a null statement, but I wanted to make
it anyway).

[Stuff snipped because I smell a rathole]

> URNs need to have global scope and to be transcribable.  Few people on
> this planet could accurately transcribe more than a small percentage
> of UTF-8.  Even those that could transcribe it could probably not type
> most UTF-8 characters on their keyboards.  It's also completely
> unacceptable to expect people to have a graphical display and hunt
> through character menus just to type in a URN.

This gets close to the encoding issue, so I postpone comments to below.

> UTF-8 cannot be transported unmodified in common Internet protocols.
> Even if some of those protocols are being upgraded to support more
> charsets, it will be many years before UTF-8 can be transported safely
> by these tools.

Terry Allen commented (|):

|That's an argument specifically against using UTF-8 at all.  I'd
|like to hear more on this point from the UTF-8 proponents. 

Martin Duerst replied (@):

@The internet as such (TCP/IP) transports any kind of octets whatsoever.
@Some of the higher level protocols fail in this respect because
@of the short-sightedness of their designers. The worst is E-Mail,
@because it works not only on the internet, but also with other
@networks. But this is known, and with MIME, it is no problem
@anymore.

@Also, the URN syntax draft clearly specifies how URNs are
@transported over 7-bit channels (using %HH). This works for
@URLs, there is no reason it shouldn't work for URNs.
@ 
@So I really wonder where there should be a problem.

Well, this is not exactly the way I interpret the syntax draft.
Section 3 of the draft states that encoding URNs for transport
is the responsibility of the transport protocol.  The implied statement
is that the transport protocol is responsible for undoing the
encoding.  The encoding section is there in the case of encoding
that the URN resolver has to undo itself.  What I wonder (and
am looking for some consesus on) is: "Is this necessary?"

Also, the %HH escaping technique does have some problems with UTF-8
as Martin has pointed out on another thread...

[more stuff snipped because I smell another rathole]

> But incorporating UTF-8 in an attempt to make URNs human-readable is
> an absolute showstopper.

Well, I'll let the folks who asked for it defend why they wanted it,
but I know I don't make any mention of human readability in the URN
syntax draft.  In fact, I view human readability as a namespace
feature/bug/design goal and independent of the decision to support
UTF-8 in the syntax doc.

Ryan

From: Keith Moore <[email-masked]>
To: Martin J Duerst <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] I18N does not belong in URNs 
Date: Wed, 06 Nov 1996 10:30:15 -0500
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

>  If people on
> this group seriously would agree to restrict URNs to digits
> only for this reason, I would understand.

Except for grandfathering, we could do this.  As it is, I think
URNs can generally be restricted so that they're unlikely to be
human-friendly.  Existing human-friendly namespaces are unlikely
to meet the requirements for URNs.  Namespaces that do meet the
URN requirements will have their own disciplines for assigning names,
which URNs for those namespaces will inherit.  New URN schemes
must have a specified discipline for assigning names.

Keith

From: Keith Moore <[email-masked]>
To: Martin J Duerst <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] I18N does not belong in URNs 
Date: Wed, 06 Nov 1996 10:18:33 -0500
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> >That's an argument specifically against using UTF-8 at all.  I'd
> >like to hear more on this point from the UTF-8 proponents.
> 
> The internet as such (TCP/IP) transports any kind of octets whatsoever.
> Some of the higher level protocols fail in this respect because
> of the short-sightedness of their designers. The worst is E-Mail,
> because it works not only on the internet, but also with other
> networks. But this is known, and with MIME, it is no problem
> anymore.

Disagree.  Many people do not have MIME mailers; many of those
who do have MIME mailers do not have the ability to send or 
receive UTF-8 in MIME.  This isn't going to change anytime soon.
Even when it does change, people still won't be able to effectively
transcribe arbitrary UTF-8 characters.  This idea is a non-starter.

> Also, the URN syntax draft clearly specifies how URNs are
> transported over 7-bit channels (using %HH). This works for
> URLs, there is no reason it shouldn't work for URNs.

It doesn't work for URLs either if people see Kanji (or whatever)
on their screens (or business cards) but can't type it in.
 
> >| URNs should not be in any language, not even English.  I would
> >| enthusiastically support requiring all URNs to be in a restricted
> >| character set or otherwise discourage human friendliness (though due
> >| to grandfathering requirements, each URN scheme would need its own
> >| rules for ensuring this).
> >
> >That's an absolute show-stopper, if you are asking that existing
> >naming schemes develop encryption methods to transform their names
> >into unreadable strings.  People just won't do it because they
> >will see it as unreasonable and unnecessary.  
> 
> Exactly. And it is also an absolute show-stopper if the "restricted
> character set" still allows to use meaningful English, or if the
> restricted character set contains characters such as ~[]{}^<>\#|`
> ("unsafe" or not) that don't appear on the average non-US keyboard,
> or the "$" that can easily be seen as a demonstration of US "superiority".

My idea is that each URN scheme should specify its own rules for
how to make its part of the name space transcribable.  Using odd
characters such as those you mention would rule it out.  And each
URN scheme would also specify the discipline to be used for 
assigning new names, such that they would not use meaningful 
English or anything else.

As for the '$' and US superiority, get real.  I realize lots of
people are sensitive about such things, but hopefully we all know
that when viewed 

> Keith, why don't you make an URN syntax proposal that only allows
> the characters "0" and "1"? It can easily be shown that with
> appropriate, protocol-or-whatever-specific encoding mechanisms,
> that will be enough to grandfather whatever has to be grandfathered.

I'm not going to dignify this with an answer.

> Or why don't you define a specific URN subspace, in which only
> numerical digits are allowed, and then see how well it gets populated
> in comparison with spaces that allow i18n?

You mean like ISBNs?   (oh sorry, they use digits '-' and 'X')

If you want long-term stable resource identifiers, you don't assign
them according to what's popular.
 
> >We should be building the big tent that everyone can live under,
> >not trying to close out name spaces we don't like.  If we were
> >to discourage readability we would find URNs ignored by
> >users of at least some name spaces, and we would no longer have
> >the unified noncolliding name space we presently contemplate.
> 
> Exactly. URLs were supposedly designed to not be human-readable,
> or so I was told by some people that are now on this group.
> Current practice shows that this design aim was failed by
> a wide margin. 

URLs inherently reflect the naming structure of their underlying
filesystems.  That design goal overrode any notions of readability
or non-readability for URLs.  But URNs should not be bound by such
constraints.

> Some people have learned something from this
> failure, namely that users want readability and meaning.

Absolutely they do.  But human-friendly identifiers are inherently
ambiguous -- if not when they are assigned, then they become ambiguous
over time.  This is inherent in the way we usually name things -- we 
borrow meaning from elsewhere and lend it to something new.  Names are 
nearly always imprecise. 

> They even put it into telephone numbers, which, by the proponents
> of non-meaningful URLs/URNs, are cited as examples for well-
> working non-meaningful schemes.
> 
> The conclusion is very clear: To deny readability and meaningfulness
> is to ignore human nature.

Except that URNs aren't really designed for human consumption. 
(other than transcribability, which isn't really consumption)
The spaces to be grandfathered under URNs aren't designed for
human consumption either.  They do turn out to be useful -- they're
just not useful for what you have in mind.

> Anyway, incorporating UTF-8 into URNs is not an absolute
> showstopper at all. It is the first attempt at recognizing
> from the beginnig that i18n is an issue that is important,
> and designing a sound solution for it from the beginning.

Agreed that I18N is important.
But putting UTF-8 in URNs is technically unsound.

The sound solution is to put I18N (and all human friendly names)
in a layer above URNs.
That way, there is a clean separation between searching and
fuzzy matching of (inherently ambiguous) human-friendly
names, and resolution of computer-friendly resource identifiers. 

> All other attempts at i18n on the internet were done as
> after-thoughts, a fact that lead to many clumsy and suboptimal
> solutions. Let's not make this mistake again.

Absolutely.  Let's therefore not put I18N in a layer where it doesn't
belong, and where it cannot work well, and concentrate on building 
a layer where it will work well.

Keith

To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] I18N does not belong in URNs
From: Larry Masinter <[email-masked]>
Date: Wed, 6 Nov 1996 07:22:15 PST
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

# But with ASCII as a "restricted" character set, we will definitely
# get cruftiness, and I see no reason to allow cruftiness for
# English, but to deny it for most other languages.

You say you see 'no reason' yet a simple reason seems compelling: The
upper-case ASCII character set is available to computer users in any
language, even when the native language does not use ASCII. For the
same reason, many otherwise useful ASCII characters were excluded from
URLs because they do not appear in some 'national' character sets:
{}|~ etc.

Regards,

Larry

From: [email-masked]
To: Bob Briscoe <[email-masked]>
Cc: Fisher Mark <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [URN] Persistence as part of URN framework
Date: Wed, 06 Nov 1996 15:58:12 +0100
Sender: [email-masked]
Reply-To: [email-masked]

[email-masked] said:
> A URN user is not just someone who clicks on one. It could also be 
> someone who publishes one (that you have published) to refer to your 
> work in their work. They need to know how long they should reliably 
> use your URN. Meta-data that any party might need is a proper 
> candidate for holding in infrastructure. 

That's what I called an "URN buyer"
When I get an URN from someone, and apply it to my resources,
I would figure that I "own" that URN.

[email-masked] said:
> Get my drift?
No. I still think the information publisher ("URN buyer) is the one
for which this information is vital, and that the information should
be part of the business contract between the provider of the URN
namespace and the information publisher.
The URN user (the one who looks up the information) should have no
need to know or care.

                               Harald A

Date: Wed, 06 Nov 1996 14:32:07 +0000
To: Terry Allen <[email-masked]>
From: Bob Briscoe <[email-masked]>
Subject: RE: [URN] Persistence as part of URN framework
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Bob Briscoe <[email-masked]>

Apologies. I had better explain myself better - I've used terminology from a
different planet (ISO Open Distributed Processing Reference Model) and been
sloppy with it. I'll stick to URN terminology, and be more strict...

I'll answer the general point at the end first.

>I don't see where you get the idea that a URN has a TTL at all.  Where
>does the NAPTR proposal say it does?  (maybe I missed something)

NAPTR doesn't. I said I was criticising the URN framework, not NAPTR, which
I just mentioned as an example of what you get if you follow the framework.

I'm saying the framework should require that any solution (like NAPTR)
should allow the option of specifying the longevity of the ability to
resolve the name.

If you don't allow this, the only people who will ever use this will be
non-commercial organisations who think they are free to say "for ever"
without regard to the consequences. No commercial organisation would enter
into anything which included any commitment "for ever".

At 11:40 05/11/96 -0800, Terry Allen wrote:
>Bob Briscoe writes:
>
>| The point I'm making is that if we (BT) sell or give away a URN (in our role
>| as an Internet Service Provider), to give our customers the ability to
>
>Your role as ISP does not mean that you have to take on the role of
>name space owner.

I meant that as an ISP we might want to also operate a name space resolver
service for a delegated portion of a scheme name space (without necessarily
owning the name space itself).

As this dual role is obviously causing confusion, lets say BT NSR are the
name space resolver and BT ISP wants to be a customer of the resolver
service because they consider it commercially advantageous to attract
customers in by proving they have a route out if they want.

> 
>| switch suppliers but keep their resource names, we will contract with them
>| to do this for a certain time. The URN service should be able to reflect
>
>You will contract with them to do what for a certain time?  Resolve
>URNs from a name space you control?  I wouldn't want to contract with
>a name space owner that promised to resolve my URNs only so long as
>I used them as my ISP.  Am I missing something?

I meant exactly the opposite. That BT ISP would be "retailing" the URN from
BT NSR (the "URN wholesaler") to BT ISP's customer, Jo Blow, so she could
switch to a different ACME ISP but still keep her URNs. Then ACME ISP might
pay the annual URN maintenance fees to BT NSR, and pass the cost on to Jo Blow.

>
>| this contractual fact so that other independent systems can know how long
>| they can rely on that person's URN (e.g. so the third party's content
>| management system can re-check HREFs as they are about to become obsolete
>| rather than by polling).
>
>What would make them obsolete?  Or do you mean nonresolvable?

Sorry, I meant unresolvable. I accept that a URN would never be obsolete if
you disallow re-use (but see below as to why this distinction is irrelevant).

>
>| Once we have contracted to do this, we will *have to* ensure the URN is
>| still accessible in terms of network infrastructure and servers. If the user
>
>And in the same way as before; if your client moves a resource to
>another URL, he has to tell you so.  What changes about that when
>your client moves his resources to another system?

Nothing. I'm just saying we need to lay down how long our commitment is
before we start. If BT NSR commit to 50 years, while the International
Chamber of Commerce NSR commits to 200 years and Dodgy NSR commits to 5
years, Jo Blow, would have a market differentiator for her to decide which
ISP she wanted, by which NSR they backed if name longevity was important to her.

All I'm saying is that for a multi-collaborative project like the Web, this
meta-data (longevity) about a resolution service for a portion of a name
scheme is the most useful characteristic to tag URNs with, so that other
services that use URNs it resolves can know when to re-check their validity
(resolvability).

I should clarify that I'm talking about the longevity of the resolution
service for a portion of the name space, not of the whole naming scheme
itself. The eventuality I envisage is that if this whole idea gets
superceded, so we've got very few resolution requests coming in for our
portion, we want to be able to wind up without jarring everyone off by
surprising them with a notice to quit. Effectively it's putting the
principles of ISO9000 (Quality and all that) into even the very long term
committments we make. By saying in advance we're going to stop at a certain
time, we can always extend it if the thing is still useful, but we have the
option not to.

This scenario assumes it is unlikely that we will be able to find someone
else to take over resolving our bit of the name space - if we don't see a
benefit in doing it ourselves, it's unlikely someone else will.

>
>| has thrown away their Web browser and got SuperCrap5 instead, that's not our
>| concern. I'm not saying we are planning doing this, I'm just laying out the
>| processes a commercial company would go through before marketing URNs.
>
>I don't get the point about the user changing browsers.

My reply was to Mark Fisher's posting, in particular his phrase:
>>>Even then, the data would only 
>>>persist as long as technical means remained to read the persistent data.

I was saying BT NSR can commit to providing service and comms infrastructure
for a set length of time, but if the user throws away the hardware or
software they used to access BT NSR's service, that's not BT NSR's problem.
The phrase "throws away" includes the them breaking it (e.g. by installing
an incompatible OS).

>
>| That's just PURLs - saying certain names are more persistent than others.
>| What I'm saying is that for URNs to mean anything, you need the *optional*
>| capability to say *how* persistent you mean when you say "pretty persistent"
>| because "for ever" is just meaningless. It must be optional because some
>
>Well, no it isn't.  URNs are not to be reassigned; is that more meaningful
>for you than "forever"?  There are no guarantees (nor can there be any)
>that a URN will be resolvable over the Internet forever.

Sorry, yes, URNs are superficially better than PURLs in this respect.
However, the "no reassignment" rule is unenforceable unless a resolver is
available to test whether the URN has already been assigned (this resolver
might be a wodge of print-out printed at the point that the on-line resolver
was shut down for ever, but this would only be useful in proving a URN had
been reassigned after the event). So pragmatically, the "no reassignment"
rule amounts to "no reassignment for the life of the resolver", which leads
back to my request for a TTL specified for the resolver.

>
>| people don't want to think about how long "persistent" means. Others might
>| not want anyone to infer how long they expect to be in business from the
>| length of their TTLs!
>| 
>| A naming service should at minimum deal with the characteristics that you
>| can hang on a name
>| - persistence of the name
>
>The *name* is persistent, period.  Resolution is another matter.

Prove it (see previous comment)!

>I don't know what you mean to refer to when you write "naming service".

Sorry, I mean "name space resolver service".

Final comment:
If you accept that pragmatically, URNs don't exist for ever (because they
only exist as long as anyone can prove they exist), you can still have the
"no reassignment" rule for people to keep to on best effort. IOW, just
because urn:duns:001234567:Dunn&Bradstreet_Collapse.report stops being
resolvable, anyone who knew of broken references to it well into the future,
shouldn't deliberately re-use it for something else.

Bob
____________________________________________________________________________
Bob Briscoe         http://www.labs.bt.com/people/briscorj/index.htm

Date: Wed, 06 Nov 1996 14:31:36 +0000
To: [email-masked]
From: Bob Briscoe <[email-masked]>
Subject: Re: [URN] Persistence as part of URN framework
Cc: Fisher Mark <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]
Reply-To: Bob Briscoe <[email-masked]>

At 10:10 06/11/96 +0100, [email-masked] wrote:
>Bob,
>your point is well made that there needs to be some mechanism
>which allows an URN buyer to make a guess at how long the resolution
>service will stay in place.
>This is, I believe, properly part of a business arrangement.
>
>For an URN *user*, this may be interesting, but not vital.

A URN user is not just someone who clicks on one. It could also be someone
who publishes one (that you have published) to refer to your work in their
work. They need to know how long they should reliably use your URN.
Meta-data that any party might need is a proper candidate for holding in
infrastructure.

>It could easily(?) be solved as part of "metadata" on an URN,
>together with properties like the changability of the resource
>(the URN for "today's weather in Trondheim" has different properties
>than the URN for "the weather in Trondheim on Nov 6, 1996 around 10:07"
>(cloudy, rainy and about 3 degrees Celsius, BTW)).
>But I don't see it as a vital part of the infrastructure.

Certainly, I agree it could be metadata held somewhere else. However,
because it is meta-data owned directly by the URN (to be precise, the
portion of the name space the URN is part of) and because it has important
utility, if it *isn't* going to be held in the infrastructure, I believe it
is the job of this working group to say how it *would* be held.

If you leave this for 'ron (later on) as you suggest, you'll end up having
to have a URC for a URN resolution when URCs get sorted, then what URN do
you give the new URC? Then you'll need to hold the longevity of the
resolution for the new URN somewhere... how about another URC?

Get my drift?

>
>Using DNS TTL records for this is just broken; DNS TTLs are used
>to limit caching of name->address mapping, and in the NAPTR proposal,
>they should be a fraction of the time one expects to have advance
>warning of a server relocation or mapping restructure.
>Normal TTLs are on the order of 3 days, and are usually reduced to less
>than 1 day before serious network reorganizations.

I didn't mean that. I used the term TTL to mean a new Time To Live (of the
resolution availability), not the specific TTL that DNS uses. Sorry again
for being sloppy with my terminology.

Bob
____________________________________________________________________________
Bob Briscoe         http://www.labs.bt.com/people/briscorj/index.htm

Date: Wed, 06 Nov 1996 14:31:06 +0000
To: Keith Moore <[email-masked]>
From: Bob Briscoe <[email-masked]>
Subject: Re: [URN] Resolution Services (N2L etc)
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Reply-To: Bob Briscoe <[email-masked]>

At 23:27 05/11/96 -0500, Keith Moore wrote:
>> 1.2 It strikes me that specifying available service requests (N2L, N2R etc)
>> should not be the job of DNS or any URN resolution mechanism. You are adding
>> metadata about the address that the name resolves to (i.e. allowed methods).
>> NAPTR should simply get you to the place you asked for by mapping names to
>> addresses.
>
>Not clear.  DNS is the place to store name-to-IP-address bindings.  If
>the different services (methods) are at different IP-addresses, the
>mappings between the names of the machines where the services reside,
>and their IP addresses will be managed by DNS.  And there's
>potentially a big efficiency win to having the name-to-service mapping
>lookup occur as a side-effect of an lookup that returns NAPTR records
>with an /s flag.

As long as everyone is clear that this is an efficiency hack, not a core
requirement, and of the potential consequential problems, the purpose of my
posting has been met.

However, I would like to propose a far cleaner alternative (backed up by a
load more words in the paper on URCs I'm about to put out) which doesn't
need any efficiency hacks because it removes the need to differentiate
between N2C, N2R etc. (and makes multi-collaborative working as easy as
single domain - I'll explain why this is a problem below)...

Lets take N2* first:

N2C: I would propose, that each address mapping you would intend to give as
a reply to an N2C or an N2L request, should each be given a different URN.
URNs are cheap. As soon as you tie any two things (that are not the same
thing) together under one name, you are doing the job of URCs not URNs.

If you insist, for instance, that the URC and the resource both have the
same URN, you are mandating that a URC must be authored with the permission
of the same domain of authority as the author of the resource itself (or
vice versa). This stops people *independently* publishing URCs about other
people's resources. Now where would the Web be today if you had to get
someone's permission to link to them?

N2R: I'm much less clear why there is a need to differentiate between N2L
and N2R in the first place. The name resolution service will give back a
location whatever. It's then up to the client to use it and the protocol it
specifies to access the resource if it wants, or not if it doesn't. Nothing
else would scale, and any protocol schemes that needed the name resolver
service to get resources for it should be killed at birth. Am I missing
something?

N2Ls & N2Rs: The plural versions are, IMHO, something that should be the
default for all clients using URNs, with singular responses just a special
case. All DNS BIND clients since some time in 1994 included round robin if
they got a list of responses back, so if your user-agent asked BIND for an
address it would get just one, but BIND would feed it another one if it
asked again. If the user-agent wanted the list directly, there would be
nothing stopping it implementing BIND internally.

I think I've now reduced all the N2* options to a singular case for each URN
- that is "N2Ls".

Moving on to the L2* options.

L2R, as I said under N2L & N2R (unless I'm missing something) is not the job
of URNs.

L2N is valid, but DNS already has a far more scalable solution by building a
reverse mapping tree topped by a well known name (in-addr.arpa). This could
be bent to do reverse NAPTR lookups. Effectively this makes and L2N into an
N2Ls.

L2L could be done with a reverse then a forward lookup.

L2C would be useful, but in practice is unattainable if you want to allow
multi-collaborative creation of URCs separate from resources. I have
resigned myself to losing this capability in my work on URCs. The only way
to do this is to rely on a harvester (like you have to do to find everyone
who links to you on the Web today - you put in the URL of your resource as a
query to the search engine).

So that's thrown out all the proposed L2* opions or reduced them to "N2Ls".

The bottom line is, you only need N2Ls or there are better ways to do this,
IMHO.

>
>> Other systems  (service discovery or navigation) should allow you to
>> determine what you *should* ask for from the address once you get it, and
>> once you have the address each protocol scheme might provide a well-known
>> method for querying what methods you *can* do if that is what the scheme
>> needs (e.g. HTTP/1.1 OPTIONS method). 
>
>Only if all possible methods for a service are available at every
>service location.  You don't want to have to ask each service location
>which methods are available at that server.

See above.

>
>> IOW, the client should already know
>> what it is going to do with the address it gets out of the URN service, or
>> if it doesn't it should be prepared to find out.
>
>The client knows what it wants to do.  But how the client does what it
>wants to do may depend on what services are available.  If there are
>multiple resolution services available for a particular chunk of name
>space, it might be that several of them will do what the client wants.
>For example, if all a client wants is a URL, N2L might be more
>efficient than N2C.

Yes, you get efficiency, but at the expense of independence of
collaboration. It would be valid to take the N2* approach to identify the
"trusted" URCs if you wanted to do this, and still allow others to
independently have other URCs.

>
>> OK, it may be *easier* to hack it this way, but that's not the point. You
>> are embedding a duplication of meta-information in DNS which will always be
>> prone to being out of date, unreliable, etc. Especially if the world moves
>> to be much more dynamic in this area in the decades you envisage this
>> lasting. More importantly, this information potentially has a different TTL
>> than the address itself, so it will break your caching.
>
>I don't see what the problem is.  DNS can specify TTLs on a
>per-resource-record basis.

The problem is that the decision on the *value* for the TTL is easy if it
only relates to the life of the mapping. If it relates to the life of the
mapping *and* the life of all the resolution services within those mappings,
any potential for the automation of the generation of the TTL value has
multiple dependencies. The more complexity you introduce, the more problems
you get with distributed two phase commits, fraud modes etc. etc.

>
>At any rate, we should view the use of DNS for resolution as a
>short-term experiment rather than a long-term solution.  Viewed in
>that context, it's not important that we get every little detail
>right.

Architecture isn't detail. I'm having to define BT's Future Commercial
Internet Service Architecture on top of whatever you folks do. If I thought
this wasn't important, I would have just kept schtumm and continued to
listen to the URN stuff in read-only mode.

Bob
____________________________________________________________________________
Bob Briscoe         http://www.labs.bt.com/people/briscorj/index.htm

Date: Wed, 6 Nov 1996 11:36:31 +0000 (GMT)
From: Jon Knight <[email-masked]>
To: Martin J Duerst <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] I18N does not belong in URNs
Sender: [email-masked]
Reply-To: Jon Knight <[email-masked]>

On Wed, 6 Nov 1996, Martin J Duerst wrote:
> Most telephone numbers of companies are meaningful.

Are they?  How are they meaningful to anything other than the telcos
switching system?  (Hint: alphabetic mappings don't work in most of the
world and increasingly "area" codes don't tell you anything about the area
that the call is destined for or its cost unless you happen to be a telco
computer).

> Most email addresses are meaningful. Many URLs are meaningful.

Granted.  And look at the hassle its caused; domain name wars, lawsuits in
the States, etc, etc.  Nasty.

> Transcribability is aided by meaninfulness; there is a smaller
> chance to make a mistake if one of these things is meaninful
> than without meaningfulness.

I disagree; transcribability would be aided by check digits and error
correcting codes.  Meaning is a red herring, especially as meaning is in
people, not in words (as one of my old school textbooks used to say). 
Other naming schemes (eg ISBNs) have the check digits and aren't
meaningful and yet work well.  I've just seen too many URLs misprinted in
books and newspapers (the UK's Guardian newspaper is the worst offender
IMHO) leading to confused and annoyed users (especially when the
misprinted URL is itself valid but for a different resource).  IMHO this
is an a priori proof that meaning does not aid transcribability.  I'd like
to see some URN schemes appear that are specifically designed to survive
mis-transcription.

Having said that, I'm easy and if people want to use broken "meaningful"
names for URNs, I think that's up to them.  Let the buyer beware, etc.

> ISBNs don't qualify. They are not persistent.

Aren't they?  Crumbs, that means that the one scheme everyone is always
going on about grandfathering in URNs can't be grandfathered.  Bummer.  I
wonder if that will stuff up our library OPAC?  How long does an ISBN
exist for until it gets reassigned to another publisher? 

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

Subject: Re: [URN] I18N does not belong in URNs
To: [email-masked]
Date: Wed, 6 Nov 1996 11:44:05 +0100 (MET)
Cc: [email-masked], [email-masked]
Content-Length: 3278
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Keith Moore answers Terry Allen:

>> Keith Moore writes:

>That's not true.  People regularly transcribe telephone numbers, 
>email addresses, ISBNs, URLs, credit card numbers, etc. with 
>sufficient accuracy for their purposes.  But ask people to 
>transcribe identifiers in (say) Klingon, or to type them in 
>on a keyboard not designed for such, and you'll get much lower 
>accuracy.

Most telephone numbers of companies are meaningful. Most
email addresses are meaningful. Many URLs are meaningful.
Transcribability is aided by meaninfulness; there is a smaller
chance to make a mistake if one of these things is meaninful
than without meaningfulness.

And Klingon is a VERY bad example. Nobody speaks Klingon.
Nobody grew up with Klingon. Nobody learned Klingon in
school as we learn the Latin script, and others learn
their traditional scripts. And Klingon isn't even in
Unicode. Klingon is a fancy of some SF enthusiasts,
and not a script used by millions every day to express
and exchange their thoughts and feelings.

>> Your
>> last point would have merit were it not that we absolutely must
>> be able to grandfather in existing name spaces.
>
>Yes, we must be able to grandfather existing name spaces *that serve
>similar purposes to URNs*.  ISBNs qualify.  Handles qualify.
>Usenet message-ids qualify.  But URNs don't have to handle existing
>name spaces that don't have the characteristics that URNs have.
>Offhand, I don't know of any name spaces that have such characteristics,
>that attempt to be human friendly.

ISBNs don't qualify. They are not persistent. And the fact that you
don't know about any such namespaces doesn't guarantee that there
are no such namespaces.
About 30 years ago, some people said "I don't know of anybody
that would want to use anything else than English on computers".
And then they went on to design protocols :-(.

>> We should be building the big tent that everyone can live under,
>> not trying to close out name spaces we don't like.  
>
>Yes, and we should also be restricting the problem to something that has 
>a hope of a reasonable solution.  They're not mutually exclusive, but 
>over-reliance on the "one big tent" theory has caused the failure of 
>many protocols.
>
>(Please note that assuming we can define I18N'ed URLs -- and there is 
>certainly a better case to be made for these then I18N'ed URNs -- I 
>would have no problem with this group defining resolution protocols that 
>can be used with them.  It's just that I18N isn't appropriate for the 
>URN name-space.  And I18N'ed URLs aren't in scope for this group.)

When I participated in several attempts and discussions to
internationalize URLs, I was told by several people that have
also shown up on this list that for URLs, i18n would be difficult,
but that it would be solved for URNs.
I definitely hate to see i18n just being moved around and delayed
by some people. With UTF-8 in URNs, we have made great progress.
Some protocols (notably FTP) are also going in the direction of
UTF-8. Ideally, we will have a uniform solution for both URLs
and URNs, based on UTF-8. For URNs, it will be by design, for
URLs, it will be more by retrofitting, because according to
the URL syntax document, the individual schemes have full
autonomy.

Regards,	Martin.

Subject: Re: [URN] I18N does not belong in URNs
To: [email-masked]
Date: Wed, 6 Nov 1996 11:21:49 +0100 (MET)
Cc: [email-masked], [email-masked], [email-masked]
Content-Length: 1929
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Lewis Girod wrote:

>However, I think what Keith was getting at was a problem that arises
>when semantics is embedded in names in an attept to structure
>hierarchical namespaces.  The sort of semantic mechanism involved with
>categorizing things is much more likely to drift over time; a
>collection of companies originally categorized under ``Mainframes''
>might want to recategorize under ``Enterprise systems''.  (Over longer
>spans of time spellings and meanings of words change -- Julius Caesar
>was originally filed under playes perhaps.)  In the context of URNs,
>every move we make we are stuck with forever... which eventually leads
>to silly results and overall cruftiness.  There is little point in 
>having semantically significant names unless you retain semantics that
>makes sense as time goes on.  

It is very clear that you can't retain semantics as time goes on.
"mainframe" may mean something completely different in 5 years,
or in 100 years, and it is impossible to predict. If people on
this group seriously would agree to restrict URNs to digits
only for this reason, I would understand.
But with ASCII as a "restricted" character set, we will definitely
get cruftiness, and I see no reason to allow cruftiness for
English, but to deny it for most other languages.

>Of course, as you point out there is no way to stop people from
>putting semantics into names; the most effective way to deal with the
>issue is to implement a system of user friendly names over the top of
>URNs; 99% of the time the user would see and type only a UFN, and
>these UFNs would be resolved to the URNs that could then be used as
>long-lived references.

The interesting thing is that we already have that, in the current
syntax draft. Just call the readable form of it UFNs, and call
the encoded form, %HH-escaped, URNs. I have proposed similar
names for these things, namely IRNs (internationalized ...).

Regards,	Martin.

Subject: Re: [URN] I18N does not belong in URNs
To: [email-masked]
Date: Wed, 6 Nov 1996 11:04:14 +0100 (MET)
Cc: [email-masked], [email-masked]
Content-Length: 4413
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Terry Allen writes:

>Keith Moore writes:

>| UTF-8 cannot be transported unmodified in common Internet protocols.
>| Even if some of those protocols are being upgraded to support more
>| charsets, it will be many years before UTF-8 can be transported safely
>| by these tools.
>
>That's an argument specifically against using UTF-8 at all.  I'd
>like to hear more on this point from the UTF-8 proponents.

The internet as such (TCP/IP) transports any kind of octets whatsoever.
Some of the higher level protocols fail in this respect because
of the short-sightedness of their designers. The worst is E-Mail,
because it works not only on the internet, but also with other
networks. But this is known, and with MIME, it is no problem
anymore.
Also, the URN syntax draft clearly specifies how URNs are
transported over 7-bit channels (using %HH). This works for
URLs, there is no reason it shouldn't work for URNs.

So I really wonder where there should be a problem.

>| URNs should not be in any language, not even English.  I would
>| enthusiastically support requiring all URNs to be in a restricted
>| character set or otherwise discourage human friendliness (though due
>| to grandfathering requirements, each URN scheme would need its own
>| rules for ensuring this).
>
>That's an absolute show-stopper, if you are asking that existing
>naming schemes develop encryption methods to transform their names
>into unreadable strings.  People just won't do it because they
>will see it as unreasonable and unnecessary.  

Exactly. And it is also an absolute show-stopper if the "restricted
character set" still allows to use meaningful English, or if the
restricted character set contains characters such as ~[]{}^<>\#|`
("unsafe" or not) that don't appear on the average non-US keyboard,
or the "$" that can easily be seen as a demonstration of US "superiority".

Keith, why don't you make an URN syntax proposal that only allows
the characters "0" and "1"? It can easily be shown that with
appropriate, protocol-or-whatever-specific encoding mechanisms,
that will be enough to grandfather whatever has to be grandfathered.

Or why don't you define a specific URN subspace, in which only
numerical digits are allowed, and then see how well it gets populated
in comparison with spaces that allow i18n?

>We should be building the big tent that everyone can live under,
>not trying to close out name spaces we don't like.  If we were
>to discourage readability we would find URNs ignored by
>users of at least some name spaces, and we would no longer have
>the unified noncolliding name space we presently contemplate.

Exactly. URLs were supposedly designed to not be human-readable,
or so I was told by some people that are now on this group.
Current practice shows that this design aim was failed by
a wide margin. Some people have learned something from this
failure, namely that users want readability and meaning.
They even put it into telephone numbers, which, by the proponents
of non-meaningful URLs/URNs, are cited as examples for well-
working non-meaningful schemes.

The conclusion is very clear: To deny readability and meaningfulness
is to ignore human nature.

>| But incorporating UTF-8 in an attempt to make URNs human-readable is
>| an absolute showstopper.
>
>I didn't understand that to be the point of it; I would agree
>that if the only reason for using Unicode were to make URNs
>readable that wouldn't be a sufficient reason for using it;
>but I'm not sure that we can't just append existing names in
>their natural coded character set as the NSS part of a URN,
>which would have mixed results for readability.  (But then 
>I feel sure I haven't understood all the implications
>of that approach.)

The problem is that for namespaces that currently only exist
on paper, there is no "natural" coded character set.
And definitely, as Terry mentionnes, mixing various character
encodings in different parts of URNs would make handling
software extremely complicated.

Anyway, incorporating UTF-8 into URNs is not an absolute
showstopper at all. It is the first attempt at recognizing
from the beginnig that i18n is an issue that is important,
and designing a sound solution for it from the beginning.

All other attempts at i18n on the internet were done as
after-thoughts, a fact that lead to many clumsy and suboptimal
solutions. Let's not make this mistake again.

Regards,	Martin.

From: [email-masked]
To: Bob Briscoe <[email-masked]>
Cc: Fisher Mark <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [URN] Persistence as part of URN framework
Date: Wed, 06 Nov 1996 10:10:11 +0100
Sender: [email-masked]
Reply-To: [email-masked]

Bob,
your point is well made that there needs to be some mechanism
which allows an URN buyer to make a guess at how long the resolution
service will stay in place.
This is, I believe, properly part of a business arrangement.

For an URN *user*, this may be interesting, but not vital.
It could easily(?) be solved as part of "metadata" on an URN,
together with properties like the changability of the resource
(the URN for "today's weather in Trondheim" has different properties
than the URN for "the weather in Trondheim on Nov 6, 1996 around 10:07"
(cloudy, rainy and about 3 degrees Celsius, BTW)).
But I don't see it as a vital part of the infrastructure.

Using DNS TTL records for this is just broken; DNS TTLs are used
to limit caching of name->address mapping, and in the NAPTR proposal,
they should be a fraction of the time one expects to have advance
warning of a server relocation or mapping restructure.
Normal TTLs are on the order of 3 days, and are usually reduced to less
than 1 day before serious network reorganizations.

              harald A

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [URN] Persistence as part of URN framework
From: Larry Masinter <[email-masked]>
Date: Tue, 5 Nov 1996 21:15:50 PST
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

# But there are no technical hooks to guarantee persistence.  On the 
# cypherpunks list a few months ago, there was a discussion of what it would 
# take to encrypt a message now, save it away for 100 years, then let the 
# recipient decrypt the message.  The conclusion I drew from that discussion 
# was that this was a hard problem without a technical solution short of 
# deploying on every desktop and in every data center a persistent OS that 
# stored copies of all persistent data.  Even then, the data would only 
# persist as long as technical means remained to read the persistent data. 
#  (How many of us could read a 600 bpi 9-track tape or punched card deck even 
# if we had to?)

Jerry Saltzer & a grad student wrote some papers about long term
document retention and the issues of system design for storage that
was to last longer than 'mean time between site failure'. (Site
failure = flood, earthquake, insurrection, war company bankruptcy,
etc.)  Their system didn't require global replication, but it was
important to be careful, and also not to be to complicated about your
replication algorithms. Look for 'Library 2000' somewhere at
www.lcs.mit.edu.

>From http://www.parc.xerox.com/masinter/www5stds.html:

> Some unsolved problems
> - stuff goes away
>   Material behind URLs disappears
> - pimples.com
>   vanity domains for billboard use
> - Apple Computer and Apple Music
>   conflicts over short names
> - urn:hdl:MTV/I_quit
>   how does authority migrate?
> - http://www.mitro.paris.fr/mitro
>   Non-ASCII names

From: Keith Moore <[email-masked]>
To: Bob Briscoe <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [URN] Resolution Services (N2L etc) 
Date: Tue, 05 Nov 1996 23:27:21 -0500
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> 1.2 It strikes me that specifying available service requests (N2L, N2R etc)
> should not be the job of DNS or any URN resolution mechanism. You are adding
> metadata about the address that the name resolves to (i.e. allowed methods).
> NAPTR should simply get you to the place you asked for by mapping names to
> addresses.

Not clear.  DNS is the place to store name-to-IP-address bindings.  If
the different services (methods) are at different IP-addresses, the
mappings between the names of the machines where the services reside,
and their IP addresses will be managed by DNS.  And there's
potentially a big efficiency win to having the name-to-service mapping
lookup occur as a side-effect of an lookup that returns NAPTR records
with an /s flag.

> Other systems  (service discovery or navigation) should allow you to
> determine what you *should* ask for from the address once you get it, and
> once you have the address each protocol scheme might provide a well-known
> method for querying what methods you *can* do if that is what the scheme
> needs (e.g. HTTP/1.1 OPTIONS method). 

Only if all possible methods for a service are available at every
service location.  You don't want to have to ask each service location
which methods are available at that server.

> IOW, the client should already know
> what it is going to do with the address it gets out of the URN service, or
> if it doesn't it should be prepared to find out.

The client knows what it wants to do.  But how the client does what it
wants to do may depend on what services are available.  If there are
multiple resolution services available for a particular chunk of name
space, it might be that several of them will do what the client wants.
For example, if all a client wants is a URL, N2L might be more
efficient than N2C.

> OK, it may be *easier* to hack it this way, but that's not the point. You
> are embedding a duplication of meta-information in DNS which will always be
> prone to being out of date, unreliable, etc. Especially if the world moves
> to be much more dynamic in this area in the decades you envisage this
> lasting. More importantly, this information potentially has a different TTL
> than the address itself, so it will break your caching.

I don't see what the problem is.  DNS can specify TTLs on a
per-resource-record basis.

At any rate, we should view the use of DNS for resolution as a
short-term experiment rather than a long-term solution.  Viewed in
that context, it's not important that we get every little detail
right.

Keith

From: Keith Moore <[email-masked]>
To: Daniel LaLiberte <[email-masked]>
Cc: Patrik Faltstrom <[email-masked]>, [email-masked], [email-masked]
Subject: Re: Names and Locations (was [URN] some comments) 
Date: Tue, 05 Nov 1996 23:16:17 -0500
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> Instead, perhaps you are trying to say that the name is not tightly
> bound to information associated with the resource, that the
> information can change and still the name is the name of the resource.
> For example, the "resolution protocol" can change.  I have no problem
> with that, and never have.  But this is still not abstractly different
> from what happens to a URL.  

You're right, it's not.  But the difference between URNs and URLs has
almost nothing to do with how they are resolved (indeed, I hope they
use the same resolution mechanisms), and a lot to do with how the
names are assigned and maintained.

That is, some people think it's very useful to have a class of names
for which certain properties (long-term persistence, global scope,
..., and the rest of those named in RFC 1737) hold.  Those names are
called URNs.  Yes, they're a lot like URLs in how they are handled.
But the whole point in having URNs as a separate name space is: if you
know that a particular name is a URN, you know that the RFC 1737
properties hold.  (Or if you prefer, an assertion that a name is a URN
implies that the RFC 1737 properties hold.)

This is why URNs need a URN: prefix -- because a lot of the value in
having a URN name space with those properties is so *humans* can
recognize a URN when they see it.

Keith

From: "James K. Tauber" <[email-masked]>
To: "Stu Weibel" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [URN] URN-WG home page w/references
Date: Wed, 6 Nov 1996 11:23:03 +0800
Sender: [email-masked]
Reply-To: "James K. Tauber" <[email-masked]>

> I think pointers to the PURL page and to the HANDLE page are 
> certainly in order as the only deployed approaches to persistent 
> naming at the present time.

James Clark's SGML parsing library, SP, and included tools do FPI
resolution via the delegating catalogue proposal. So there's another
deployed approach.

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

From: Keith Moore <[email-masked]>
To: Lewis Girod <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] I18N does not belong in URNs 
Date: Tue, 05 Nov 1996 21:47:12 -0500
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> Of course, as you point out there is no way to stop people from
> putting semantics into names; the most effective way to deal with the
> issue is to implement a system of user friendly names over the top of
> URNs; 99% of the time the user would see and type only a UFN, and
> these UFNs would be resolved to the URNs that could then be used as
> long-lived references.

Yes.  Precisely.

Keith

Date: Tue, 5 Nov 1996 21:36:55 -0500
From: Lewis Girod <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Re: [URN] I18N does not belong in URNs
Sender: [email-masked]
Reply-To: Lewis Girod <[email-masked]>

   Date: Tue, 5 Nov 1996 16:57:00 -0800 (PST)
   From: Terry Allen <[email-masked]>

   Our longest-lived names actually are meaningful to humans; to support
   your argument you have to establish that semantic drift affects
   names specifically (Moby Dick, Julius Caesar, Assurnasirpal) and
   that using them in the context of a defined name space does not
   insulate them from semantic drift. 

The names you are using as examples are all long lived because they
refer to conceptually immutable objects.  This is the case in which
names are afforded some protection from semantic drift, although it
does not necessarily protect them completely.  Out of context, I can't
tell if you mean Julius Caesar the guy who got stabbed or Julius
Caesar the play (and that was not an issue when JC was around!,) but
in the context of a namespace of people or plays that problem would be
resolved.  Either way the name refers to a piece of history that,
whether or not it is well defined, people have an idea of what you
mean that doesn't change too much.

However, I think what Keith was getting at was a problem that arises
when semantics is embedded in names in an attept to structure
hierarchical namespaces.  The sort of semantic mechanism involved with
categorizing things is much more likely to drift over time; a
collection of companies originally categorized under ``Mainframes''
might want to recategorize under ``Enterprise systems''.  (Over longer
spans of time spellings and meanings of words change -- Julius Caesar
was originally filed under playes perhaps.)  In the context of URNs,
every move we make we are stuck with forever... which eventually leads
to silly results and overall cruftiness.  There is little point in 
having semantically significant names unless you retain semantics that
makes sense as time goes on.  

Of course, as you point out there is no way to stop people from
putting semantics into names; the most effective way to deal with the
issue is to implement a system of user friendly names over the top of
URNs; 99% of the time the user would see and type only a UFN, and
these UFNs would be resolved to the URNs that could then be used as
long-lived references.

-lewis

From: Keith Moore <[email-masked]>
To: Terry Allen <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [URN] I18N does not belong in URNs 
Date: Tue, 05 Nov 1996 21:32:59 -0500
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> Keith Moore writes:
> | Support for UTF-8 in URNs is a gross layering violation.  It also
> | violates the requirements of RFC 1737 in several ways:
> | 
> | URNs are not intended to be meaningful to humans.  Rather, the desire
> | for URNs to have a long lifetime indicates that they should not be
> | human-friendly; otherwise, semantic drift will cause those names to
> | need to be changed over time.
> 
> Our longest-lived names actually are meaningful to humans; to support
> your argument you have to establish that semantic drift affects
> names specifically (Moby Dick, Julius Caesar, Assurnasirpal) and
> that using them in the context of a defined name space does not
> insulate them from semantic drift.  

Names like those you quote are ambiguous.  There are different works
named Moby Dick (not just the book by Melville; there are plays,
screen plays, radio plays, parodies) and Julius Caesar (not just 
the play by Shakespeare, but also biographies, screen plays, 
and at least one symphony).  Ambiguous names aren't suitable as URNs.

> | URNs need to have global scope and to be transcribable.  Few people on
> | this planet could accurately transcribe more than a small percentage
> | of UTF-8.  Even those that could transcribe it could probably not type
> | most UTF-8 characters on their keyboards.  It's also completely
> | unacceptable to expect people to have a graphical display and hunt
> | through character menus just to type in a URN.
> 
> Few people on this planet can accurately transcribe anything.  

That's not true.  People regularly transcribe telephone numbers, 
email addresses, ISBNs, URLs, credit card numbers, etc. with 
sufficient accuracy for their purposes.  But ask people to 
transcribe identifiers in (say) Klingon, or to type them in 
on a keyboard not designed for such, and you'll get much lower 
accuracy.

> Your
> last point would have merit were it not that we absolutely must
> be able to grandfather in existing name spaces.

Yes, we must be able to grandfather existing name spaces *that serve
similar purposes to URNs*.  ISBNs qualify.  Handles qualify.
Usenet message-ids qualify.  But URNs don't have to handle existing
name spaces that don't have the characteristics that URNs have.
Offhand, I don't know of any name spaces that have such characteristics,
that attempt to be human friendly.

> | URNs should not be in any language, not even English.  I would
> | enthusiastically support requiring all URNs to be in a restricted
> | character set or otherwise discourage human friendliness (though due
> | to grandfathering requirements, each URN scheme would need its own
> | rules for ensuring this).
> 
> That's an absolute show-stopper, if you are asking that existing
> naming schemes develop encryption methods to transform their names
> into unreadable strings.  People just won't do it because they
> will see it as unreasonable and unnecessary.  

I don't think this is a problem, because I don't think existing URN-like
name spaces are likely to be human friendly in the first place.  (If someone
knows of a counterexample, please tell us.)

> We should be building the big tent that everyone can live under,
> not trying to close out name spaces we don't like.  

Yes, and we should also be restricting the problem to something that has 
a hope of a reasonable solution.  They're not mutually exclusive, but 
over-reliance on the "one big tent" theory has caused the failure of 
many protocols.

(Please note that assuming we can define I18N'ed URLs -- and there is 
certainly a better case to be made for these then I18N'ed URNs -- I 
would have no problem with this group defining resolution protocols that 
can be used with them.  It's just that I18N isn't appropriate for the 
URN name-space.  And I18N'ed URLs aren't in scope for this group.)

Keith

Date: Tue, 5 Nov 1996 16:57:00 -0800 (PST)
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: [URN] I18N does not belong in URNs
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

Keith Moore writes:
| Support for UTF-8 in URNs is a gross layering violation.  It also
| violates the requirements of RFC 1737 in several ways:
| 
| URNs are not intended to be meaningful to humans.  Rather, the desire
| for URNs to have a long lifetime indicates that they should not be
| human-friendly; otherwise, semantic drift will cause those names to
| need to be changed over time.

Our longest-lived names actually are meaningful to humans; to support
your argument you have to establish that semantic drift affects
names specifically (Moby Dick, Julius Caesar, Assurnasirpal) and
that using them in the context of a defined name space does not
insulate them from semantic drift.  However, I'm still undecided
on using Unicode at all, as I'm sure I don't understand some of
the issues.  I'll be meeting with Ron tomorrow and will hope
to be wiser after that.

| URNs need to have global scope and to be transcribable.  Few people on
| this planet could accurately transcribe more than a small percentage
| of UTF-8.  Even those that could transcribe it could probably not type
| most UTF-8 characters on their keyboards.  It's also completely
| unacceptable to expect people to have a graphical display and hunt
| through character menus just to type in a URN.

Few people on this planet can accurately transcribe anything.  Your
last point would have merit were it not that we absolutely must
be able to grandfather in existing name spaces.

| UTF-8 cannot be transported unmodified in common Internet protocols.
| Even if some of those protocols are being upgraded to support more
| charsets, it will be many years before UTF-8 can be transported safely
| by these tools.

That's an argument specifically against using UTF-8 at all.  I'd
like to hear more on this point from the UTF-8 proponents.

| URNs should not be in any language, not even English.  I would
| enthusiastically support requiring all URNs to be in a restricted
| character set or otherwise discourage human friendliness (though due
| to grandfathering requirements, each URN scheme would need its own
| rules for ensuring this).

That's an absolute show-stopper, if you are asking that existing
naming schemes develop encryption methods to transform their names
into unreadable strings.  People just won't do it because they
will see it as unreasonable and unnecessary.  

We should be building the big tent that everyone can live under,
not trying to close out name spaces we don't like.  If we were
to discourage readability we would find URNs ignored by
users of at least some name spaces, and we would no longer have
the unified noncolliding name space we presently contemplate.

Some name spaces will turn out not to work well, whether on
the Internet, in general, or after several centuries.  Users
of those name spaces will have to cope or convert to other
name spaces with better characteristics.  That's life.

| But incorporating UTF-8 in an attempt to make URNs human-readable is
| an absolute showstopper.

I didn't understand that to be the point of it; I would agree
that if the only reason for using Unicode were to make URNs
readable that wouldn't be a sufficient reason for using it;
but I'm not sure that we can't just append existing names in
their natural coded character set as the NSS part of a URN,
which would have mixed results for readability.  (But then 
I feel sure I haven't understood all the implications
of that approach.)

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]
Subject: [URN] I18N does not belong in URNs
Cc: [email-masked]
From: Keith Moore <[email-masked]>
Date: Tue, 05 Nov 1996 18:33:21 -0500
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

Support for UTF-8 in URNs is a gross layering violation.  It also
violates the requirements of RFC 1737 in several ways:

URNs are not intended to be meaningful to humans.  Rather, the desire
for URNs to have a long lifetime indicates that they should not be
human-friendly; otherwise, semantic drift will cause those names to
need to be changed over time.

URNs need to have global scope and to be transcribable.  Few people on
this planet could accurately transcribe more than a small percentage
of UTF-8.  Even those that could transcribe it could probably not type
most UTF-8 characters on their keyboards.  It's also completely
unacceptable to expect people to have a graphical display and hunt
through character menus just to type in a URN.

UTF-8 cannot be transported unmodified in common Internet protocols.
Even if some of those protocols are being upgraded to support more
charsets, it will be many years before UTF-8 can be transported safely
by these tools.

URNs should not be in any language, not even English.  I would
enthusiastically support requiring all URNs to be in a restricted
character set or otherwise discourage human friendliness (though due
to grandfathering requirements, each URN scheme would need its own
rules for ensuring this).

But incorporating UTF-8 in an attempt to make URNs human-readable is
an absolute showstopper.

Keith

Date: Tue, 5 Nov 1996 11:40:32 -0800 (PST)
From: Terry Allen <[email-masked]>
To: [email-masked], [email-masked]
Subject: RE: [URN] Persistence as part of URN framework
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Terry Allen <[email-masked]>

Bob Briscoe writes:

| The point I'm making is that if we (BT) sell or give away a URN (in our role
| as an Internet Service Provider), to give our customers the ability to

Your role as ISP does not mean that you have to take on the role of
name space owner.
 
| switch suppliers but keep their resource names, we will contract with them
| to do this for a certain time. The URN service should be able to reflect

You will contract with them to do what for a certain time?  Resolve
URNs from a name space you control?  I wouldn't want to contract with
a name space owner that promised to resolve my URNs only so long as
I used them as my ISP.  Am I missing something?

| this contractual fact so that other independent systems can know how long
| they can rely on that person's URN (e.g. so the third party's content
| management system can re-check HREFs as they are about to become obsolete
| rather than by polling).

What would make them obsolete?  Or do you mean nonresolvable?

| Once we have contracted to do this, we will *have to* ensure the URN is
| still accessible in terms of network infrastructure and servers. If the user

And in the same way as before; if your client moves a resource to
another URL, he has to tell you so.  What changes about that when
your client moves his resources to another system?

| has thrown away their Web browser and got SuperCrap5 instead, that's not our
| concern. I'm not saying we are planning doing this, I'm just laying out the
| processes a commercial company would go through before marketing URNs.

I don't get the point about the user changing browsers.

| That's just PURLs - saying certain names are more persistent than others.
| What I'm saying is that for URNs to mean anything, you need the *optional*
| capability to say *how* persistent you mean when you say "pretty persistent"
| because "for ever" is just meaningless. It must be optional because some

Well, no it isn't.  URNs are not to be reassigned; is that more meaningful
for you than "forever"?  There are no guarantees (nor can there be any)
that a URN will be resolvable over the Internet forever.

| people don't want to think about how long "persistent" means. Others might
| not want anyone to infer how long they expect to be in business from the
| length of their TTLs!
| 
| A naming service should at minimum deal with the characteristics that you
| can hang on a name
| - persistence of the name

The *name* is persistent, period.  Resolution is another matter.  I
don't know what you mean to refer to when you write "naming service".

| - ownership
| - address mapping
| - persistence of the address mapping
| - I would say "etc." but that's about it! My complaint is that two items
| from even this minimal list of four aren't covered by the framework (whereas
| the NAPTR proposal starts introducing gratuitous characteristics that are
| owned by the resource the name points at, not the name itself).
| 
| I would be happy if we came down on a solution which just optionally
| specified the longevity of the name (not the DNS NAPTR TTL because this is
| the longevity of the mapping, not the name itself). You could potentially
| have name TTLs of 10 years (or more). So a sensible discussion could now
| ensue as to whether this is practical - to expect any descendant of DNS to
| inherit any long lived TTLs from within DNS. I would say yes.

I don't see where you get the idea that a URN has a TTL at all.  Where
does the NAPTR proposal say it does?  (maybe I missed 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, 05 Nov 1996 15:55:06 +0000
To: Fisher Mark <[email-masked]>
From: Bob Briscoe <[email-masked]>
Subject: RE: [URN] Resolution Services (N2L etc)
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]
Reply-To: Bob Briscoe <[email-masked]>

At 07:41 05/11/96 EST, Fisher Mark wrote:
>
>>1.2 It strikes me that specifying available service requests (N2L, N2R etc)
>>should not be the job of DNS or any URN resolution mechanism. You are
>>adding
>>metadata about the address that the name resolves to (i.e. allowed
>>methods).
>>NAPTR should simply get you to the place you asked for by mapping names to
>>addresses.
>[...]
>>OK, it may be *easier* to hack it this way, but that's not the point. You
>>are embedding a duplication of meta-information in DNS which will always be
>>prone to being out of date, unreliable, etc. Especially if the world moves
>>to be much more dynamic in this area in the decades you envisage this
>>lasting. More importantly, this information potentially has a different TTL
>>than the address itself, so it will break your caching.
>
>But this is meta-information that is not easy to change.  It is not like, 
>"oh, from midnight to 6am I'll support HTTP, then from 6am to 8am I'll 
>support HTTP and our experimental Z39.50-2000, then from 8am-6pm I'll only 
>support whois++", etc.  Rapidly changing what final resolution services are 
>supported is not a particularly easy task, or a desirable task even when it 
>is made easy.

I'm not throwing out the resolution service, as you appear to think I am
saying. I'm throwing out the service requests supported by that service
(N2L, N2Ls, N2R, N2Rs, N2C etc.). This is one level of indirection too far.

It's irrelevant whether they are likely to change *often*. What is important
is that they will change at potentially *different* times to the resolution
service. This is what breaks the meaning of the TTL. Once you have the
resolution service you can find the service requests it supports, so this is
unnecessary complexity.

>
>Could one (or more) of the DNS wizards on the list speak as to what the 
>average TTL tends to be?  From what Bob is saying, it sounds like he expects 
>the TTL of the NAPTR record to be a longer time than the expected time 
>between final resolution service changes.
>======================================================================
>Mark Leighton Fisher                   Thomson Consumer Electronics
>[email-masked]                   Indianapolis, IN
>
>
____________________________________________________________________________
Bob Briscoe         http://www.labs.bt.com/people/briscorj/index.htm

Date: Tue, 05 Nov 1996 15:54:31 +0000
To: Fisher Mark <[email-masked]>
From: Bob Briscoe <[email-masked]>
Subject: RE: [URN] Persistence as part of URN framework
Cc: "[email-masked]" <[email-masked]>
Sender: [email-masked]
Reply-To: Bob Briscoe <[email-masked]>

At 07:26 05/11/96 EST, Fisher Mark wrote:
>
>>Persistence is a contractual
>>thing which needs a technical hook to hang the contract on.
>
>But there are no technical hooks to guarantee persistence.  On the 
>cypherpunks list a few months ago, there was a discussion of what it would 
>take to encrypt a message now, save it away for 100 years, then let the 
>recipient decrypt the message.  The conclusion I drew from that discussion 
>was that this was a hard problem without a technical solution short of 
>deploying on every desktop and in every data center a persistent OS that 
>stored copies of all persistent data.  Even then, the data would only 
>persist as long as technical means remained to read the persistent data. 
> (How many of us could read a 600 bpi 9-track tape or punched card deck even 
>if we had to?)

The point I'm making is that if we (BT) sell or give away a URN (in our role
as an Internet Service Provider), to give our customers the ability to
switch suppliers but keep their resource names, we will contract with them
to do this for a certain time. The URN service should be able to reflect
this contractual fact so that other independent systems can know how long
they can rely on that person's URN (e.g. so the third party's content
management system can re-check HREFs as they are about to become obsolete
rather than by polling).

Once we have contracted to do this, we will *have to* ensure the URN is
still accessible in terms of network infrastructure and servers. If the user
has thrown away their Web browser and got SuperCrap5 instead, that's not our
concern. I'm not saying we are planning doing this, I'm just laying out the
processes a commercial company would go through before marketing URNs.

The same issues come up with phone number portability between suppliers.

>
>The important point about URNs is that there is an extra level of 
>indirection built into the resolution process, such that the URN -> URL -> 
>resource resolution (in the N2L case) can transparently (at the user agent 
>level) change the URL(s) associated with that URN, without changing the URN. 
> Kind of a superpowered 30x redirect, in a way.  This technical detail (the 
>extra level of indirection) is what will give URNs additional capability to 
>persist.

That's just PURLs - saying certain names are more persistent than others.
What I'm saying is that for URNs to mean anything, you need the *optional*
capability to say *how* persistent you mean when you say "pretty persistent"
because "for ever" is just meaningless. It must be optional because some
people don't want to think about how long "persistent" means. Others might
not want anyone to infer how long they expect to be in business from the
length of their TTLs!

A naming service should at minimum deal with the characteristics that you
can hang on a name
- persistence of the name
- ownership
- address mapping
- persistence of the address mapping
- I would say "etc." but that's about it! My complaint is that two items
from even this minimal list of four aren't covered by the framework (whereas
the NAPTR proposal starts introducing gratuitous characteristics that are
owned by the resource the name points at, not the name itself).

I would be happy if we came down on a solution which just optionally
specified the longevity of the name (not the DNS NAPTR TTL because this is
the longevity of the mapping, not the name itself). You could potentially
have name TTLs of 10 years (or more). So a sensible discussion could now
ensue as to whether this is practical - to expect any descendant of DNS to
inherit any long lived TTLs from within DNS. I would say yes.

Bob
____________________________________________________________________________
Bob Briscoe         http://www.labs.bt.com/people/briscorj/index.htm

Date: Tue, 5 Nov 1996 06:37:14 -0800 (PST)
From: "Gregory J. Woodhouse" <[email-masked]>
To: Bob Briscoe <[email-masked]>
Cc: [email-masked]
Subject: Re: [URN] Resolution Services (N2L etc)
Sender: [email-masked]
Reply-To: "Gregory J. Woodhouse" <[email-masked]>

I'm sure I'm saying the same thing tht others will say, but while I think
NAPTR will likely be replaced with some other mechanism, I do think the
extra layer of indirections serves several very important purposes: Most
importantly, it makes the underlying mechanism truly distributed and
scalable. It also decentralizes URN administration provides a smooth
transition path to new technologies. No other mechanism that I've seen
proposed can make these claims.

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

From: "Ryan Moats" <[email-masked]>
To: "Martin J Duerst" <[email-masked]>, "Patrik Faltstrom" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Tue, 05 Nov 96 08:37:29 
Priority: Normal
Subject: Re: [URN] %encoding for reserved UTF-8 characters (was: New syntax draft)
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Tue, 5 Nov 1996 10:46:17 +0100 (MET), Patrik Faltstrom wrote:

>
>On Mon, 4 Nov 1996, Martin J Duerst wrote:
>
>> - Specify that protocols may only reserve 1-octet UTF-8 characters
>> 	(i.e. ASCII).
>
>This is kind of stupid from my point of view. We do not win
>anything by doing this, do we?
>
>> - Specify that protocols have to define their own escaping mechanisms
>> 	for things beyond ASCII.
>
>This is better, much better. We say that native URNs are 8-bit
>following the UTF-8 specification and that the protocol have
>to come up with its own escaping mechanism.

This is ok, so long as we are talking about transport protocol escaping
which is removed before the URN is resolved.  What we are talking
about here (in my mind at least) is escaping that the URN resolver "sees" 
and has to remove before resolving a URN.

Now, there is are some folks who have commented to me that there shouldn't
be any escaping that the URN resolver should have to handle.  If so,
then the portions of the draft covering escaping can be removed.
However, if we decide that the URN resolver must handle escaping, then
I claim that the types of escaping it handles should be specified in the
syntax document, not somewhere else.

I should note that there has not been enough comment either way on the
preceding paragraph to claim "rough consensus"...

Ryan

Date: Tue, 5 Nov 1996 08:28:15 -0500
From: [email-masked] (Stu Weibel)
To: [email-masked], [email-masked]
Subject: Re: [URN] URN-WG home page w/references
Sender: [email-masked]
Reply-To: [email-masked] (Stu Weibel)

I think pointers to the PURL page and to the HANDLE page are certainly
in order as the only deployed approaches to persistent naming at the
present time.  

   http://purl.org
   http://www.handle.net
 
thanks,

stu

> Yes, there is a homepage for the group, although I have not had time to
> update it since we became a working group.
> 
> It lives at:
> 
> 	http://www.bunyip.com/research/urn-ietf/
> 
> Suggestions for content are welcomed...
> 
> Leslie.

Date: Tue, 5 Nov 1996 08:17:53 -0500
From: [email-masked] (Stu Weibel)
To: [email-masked], [email-masked]
Subject: RE: [URN] Persistence as part of URN framework
Sender: [email-masked]
Reply-To: [email-masked] (Stu Weibel)

Mark Fisher writes,

> The important point about URNs is that there is an extra level of 
> indirection built into the resolution process, such that the URN -> URL -> 
> resource resolution (in the N2L case) can transparently (at the user agent 
> level) change the URL(s) associated with that URN, without changing the URN. 
>  Kind of a superpowered 30x redirect, in a way.  This technical detail (the 
> extra level of indirection) is what will give URNs additional capability to 
> persist.
 
This is the part of the problem that PURLs address very well:  one
additional level of indirection that allows the management
(contractural or otherwise) of URLs by an organization with the
committment to maintain persistent access.  I have argued for
in the past and continue to believe that persistence is only to
a small extent a function of the underlying technology: persistence
is a function of *organizational committment*.

Another essential element of some (but not all) varieties of URN is
assurance that the object that is named is exactly the same as it was
at the time of name assignment.  PURLs do not address this issue, but
can be used as a layer in such a solution (OCLC and CNRI have,
together, demonstrated such a solution with PURL-HANDLE resolution, but
there can clearly be other solutions).

The third major element, protocol independence, is highly desirable but less 
urgent: We can live with the current protocols for the time while the
necessary infrastructure (NAPTR for example) is developed and deployed.

stu

From: Fisher Mark <[email-masked]>
To: Bob Briscoe <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [URN] Resolution Services (N2L etc)
Date: Tue, 05 Nov 96 07:41:00 EST
Encoding: 30 TEXT
Sender: [email-masked]
Reply-To: Fisher Mark <[email-masked]>

>1.2 It strikes me that specifying available service requests (N2L, N2R etc)
>should not be the job of DNS or any URN resolution mechanism. You are
>adding
>metadata about the address that the name resolves to (i.e. allowed
>methods).
>NAPTR should simply get you to the place you asked for by mapping names to
>addresses.
[...]
>OK, it may be *easier* to hack it this way, but that's not the point. You
>are embedding a duplication of meta-information in DNS which will always be
>prone to being out of date, unreliable, etc. Especially if the world moves
>to be much more dynamic in this area in the decades you envisage this
>lasting. More importantly, this information potentially has a different TTL
>than the address itself, so it will break your caching.

But this is meta-information that is not easy to change.  It is not like, 
"oh, from midnight to 6am I'll support HTTP, then from 6am to 8am I'll 
support HTTP and our experimental Z39.50-2000, then from 8am-6pm I'll only 
support whois++", etc.  Rapidly changing what final resolution services are 
supported is not a particularly easy task, or a desirable task even when it 
is made easy.

Could one (or more) of the DNS wizards on the list speak as to what the 
average TTL tends to be?  From what Bob is saying, it sounds like he expects 
the TTL of the NAPTR record to be a longer time than the expected time 
between final resolution service changes.
======================================================================
Mark Leighton Fisher                   Thomson Consumer Electronics
[email-masked]                   Indianapolis, IN

From: Fisher Mark <[email-masked]>
To: Bob Briscoe <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: RE: [URN] Persistence as part of URN framework
Date: Tue, 05 Nov 96 07:26:00 EST
Encoding: 25 TEXT
Sender: [email-masked]
Reply-To: Fisher Mark <[email-masked]>

>Persistence is a contractual
>thing which needs a technical hook to hang the contract on.

But there are no technical hooks to guarantee persistence.  On the 
cypherpunks list a few months ago, there was a discussion of what it would 
take to encrypt a message now, save it away for 100 years, then let the 
recipient decrypt the message.  The conclusion I drew from that discussion 
was that this was a hard problem without a technical solution short of 
deploying on every desktop and in every data center a persistent OS that 
stored copies of all persistent data.  Even then, the data would only 
persist as long as technical means remained to read the persistent data. 
 (How many of us could read a 600 bpi 9-track tape or punched card deck even 
if we had to?)

The important point about URNs is that there is an extra level of 
indirection built into the resolution process, such that the URN -> URL -> 
resource resolution (in the N2L case) can transparently (at the user agent 
level) change the URL(s) associated with that URN, without changing the URN. 
 Kind of a superpowered 30x redirect, in a way.  This technical detail (the 
extra level of indirection) is what will give URNs additional capability to 
persist.
======================================================================
Mark Leighton Fisher                   Thomson Consumer Electronics
[email-masked]                   Indianapolis, IN

From: [email-masked] (Leslie Daigle)
Date: Tue, 5 Nov 1996 06:40:30 -0500
To: Larry Masinter <[email-masked]>, [email-masked]
Subject: Re: [URN] URN-WG home page w/references
Sender: [email-masked]
Reply-To: [email-masked] (Leslie Daigle)

Larry,

> Is there a 'home page' for the URN working group? It would be really
> useful to collect together the references & previous work. There was a
> home page for URI that was (and still is) really useful, but lately
> I've had to search for URN & URC references.

Yes, there is a homepage for the group, although I have not had time to
update it since we became a working group.

It lives at:

	http://www.bunyip.com/research/urn-ietf/

Suggestions for content are welcomed...

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: Tue, 05 Nov 1996 10:02:28 +0000
To: [email-masked]
From: Bob Briscoe <[email-masked]>
Subject: [URN] NAPTR substitution expression grammar
Sender: [email-masked]
Reply-To: Bob Briscoe <[email-masked]>

Comments on draft-ietf-urn-naptr-00.txt (cont.):

2. Substitution expression grammar
2.1 You claim to be copying sed ERE syntax (with the caveat it may all
change to cover UTF-8). To avoid confusion for sed gits like me, could you
consider using the escaped parentheses \( and \) to do back refs, rather
than the one character ones ( and ) which simply imply grouping in POSIX
EREs by my understanding.

2.2 Also, it would be friendly to allow any delimiter, like sed does, not
just "/" (e.g. "!.*//\([^/:]+\)!\1!i" is a lot more readable than
"/.*\/\/\([^\/:]+\)/\1/i").

Bob
____________________________________________________________________________
Bob Briscoe         http://www.labs.bt.com/people/briscorj/index.htm

Date: Tue, 05 Nov 1996 10:02:13 +0000
To: [email-masked]
From: Bob Briscoe <[email-masked]>
Subject: [URN] Persistence as part of URN framework
Sender: [email-masked]
Reply-To: Bob Briscoe <[email-masked]>

Comments on draft-daigle-urnframework-00.txt:

On 12-Oct-96 in "[URN] suggestions for "A Framework for the Assignment and
Resolution ..."" Larry Masinter said:
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'.

I couldn't agree more. If the only difference between a name and a location
is persistence, can you really get away with defining a whole framework that
doesn't mention even an optional capability to define how persistent a name
is (or at least a best estimate)? You've chosen the DNS which has TTL in
there as a given, but your framework doesn't put any requirements on this.

For instance, we might want to sell persistent names, but if there's no way
of telling how persistent they are, you've got nothing to prove anything,
and the client has got nothing to buy into. Persistence is a contractual
thing which needs a technical hook to hang the contract on.

I believe defining persistence fits your charter too.

Bob
____________________________________________________________________________
Bob Briscoe         http://www.labs.bt.com/people/briscorj/index.htm

Date: Tue, 05 Nov 1996 10:01:53 +0000
To: [email-masked]
From: Bob Briscoe <[email-masked]>
Subject: [URN] Resolution Services (N2L etc)
Sender: [email-masked]
Reply-To: Bob Briscoe <[email-masked]>

Strong comments on draft-ietf-urn-naptr-00 draft below.

I've just joined this mail-list as I'm working on URCs and wanted to make
sure I was up to date on back-ground. I have read all the drafts that I
think are relevant (URN urnframework-00, urn-naptr-00, urn-syntax-00) and
the last couple of months mail archives to get up to date.

I have tried not to cover old ground, but please pull me up if I stray.

<PATRONISE>In fact it's homely to note the same old arguments about URNs are
still being re-cycled.</PATRONISE> <BUTTER UP>I admire your collective
sticking power.</BUTTER UP>

I haven't read daniel-http because it relies so heavily on the resolution
service capability of NAPTR to which I have big objections (below).

Comments on draft-ietf-urn-naptr-00.txt:
1. Resolution Services
1.1 Under Brief overview and examples, it says, "Resolution services are
operations such as N2R... These are discussed in the URN framework
document[2]..."
They aren't (and below I say why I think they shouldn't be, other than to
exclude them).

1.2 It strikes me that specifying available service requests (N2L, N2R etc)
should not be the job of DNS or any URN resolution mechanism. You are adding
metadata about the address that the name resolves to (i.e. allowed methods).
NAPTR should simply get you to the place you asked for by mapping names to
addresses.

Other systems  (service discovery or navigation) should allow you to
determine what you *should* ask for from the address once you get it, and
once you have the address each protocol scheme might provide a well-known
method for querying what methods you *can* do if that is what the scheme
needs (e.g. HTTP/1.1 OPTIONS method). IOW, the client should already know
what it is going to do with the address it gets out of the URN service, or
if it doesn't it should be prepared to find out.

OK, it may be *easier* to hack it this way, but that's not the point. You
are embedding a duplication of meta-information in DNS which will always be
prone to being out of date, unreliable, etc. Especially if the world moves
to be much more dynamic in this area in the decades you envisage this
lasting. More importantly, this information potentially has a different TTL
than the address itself, so it will break your caching.

IMHO, what you *can* do with the URN should normally be put in with the
advert for the URN (e.g. the mailing, the cereal box, the web page) that the
service provider shouts about to get the thing used, and other people pass
on in the normal way this gossip spreads. It is up to the service providers
to promulgate the URN in such a way that when the client uses it, the
correct method is invoked (e.g. if you want U2L, not U2R on a Web page, you
just type the URN, rather than HREF'ing it).

Bob
____________________________________________________________________________
Bob Briscoe         http://www.labs.bt.com/people/briscorj/index.htm

Date: Tue, 5 Nov 1996 10:46:17 +0100 (MET)
From: Patrik Faltstrom <[email-masked]>
To: Martin J Duerst <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [URN] %encoding for reserved UTF-8 characters (was: New syntax          draft)
Sender: [email-masked]
Reply-To: Patrik Faltstrom <[email-masked]>

On Mon, 4 Nov 1996, Martin J Duerst wrote:

> - Specify that protocols may only reserve 1-octet UTF-8 characters
> 	(i.e. ASCII).

This is kind of stupid from my point of view. We do not win
anything by doing this, do we?

> - Specify that protocols have to define their own escaping mechanisms
> 	for things beyond ASCII.

This is better, much better. We say that native URNs are 8-bit
following the UTF-8 specification and that the protocol have
to come up with its own escaping mechanism.

Just because the US-ASCII characters are represented by themselves
in an UTF-8 string, and these octets can not occur in any other
UTF-8 sequence, I can not see that we have problems with the
normal "dangerous" characters in for example a URL, i.e. space,
percent, plus etc. A space can only occur in a UTF-8 string as
a space, representing a space, so it has to be %encoded.

It should because of this be quite easy :-) for each protocol to
check what happens when a UTF-8 string is passed. My experience is
that UTF-8 strings behaves like ISO-8859-1 strings, if you don't
start inserting linebreaks, counting characters etc.

   Patrik

Date: Tue, 5 Nov 1996 00:16:00 -0600 (CST)
From: Daniel LaLiberte <[email-masked]>
To: Patrik Faltstrom <[email-masked]>
Cc: [email-masked]
Subject: Re: Names and Locations (was [URN] some comments)
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Patrik Faltstrom writes:
 > A URL refers to a location which though a caching mechanism, a proxy
 > cache, an interceptor with cache, multiple A-records in DNS or whatever
 > ends up refering to more than one occurance of the same resource.

But those multiple occurances of the resource are at multiple
locations, are they not?  (BTW, the point of this particular line of
argument is simply that the binding between URL and location is not as
clear as people are making it sound.  This, by itself, does not imply
that URLs are persistent, as URNs are intended to be.)

 > A URN is a _name_ of a resource which have absolutely _NOTHING_
 > to do with the resolution protocol, the different versions of
 > the resource that exist (text, postscript etc), the different
 > protocols used to locate and later fetch the resource or the
 > metadata for the resource.

I'm not sure who else would agree with you that a name is so abstract
that it has nothing to do with any of the information associated with
the resource.  If there is no association, how is that the name can
even be used as a name of the resource?    How would you ever get to
the resource?

Instead, perhaps you are trying to say that the name is not tightly
bound to information associated with the resource, that the
information can change and still the name is the name of the resource.
For example, the "resolution protocol" can change.  I have no problem
with that, and never have.  But this is still not abstractly different
from what happens to a URL.  What is happening when an HTTP server
gives you a redirect to an ftp URL?  Compare that to a DNS server for
a naming authority giving you a redirect to an http URL.

If you want to get from a URN to a resource, you must begin to look up
some information starting with the URN.  If you don't look up anything
associated with the URN, you can't continue with the resolution, so
there is something essential going on there, you must admit.  The
particular way you go about looking up the information is a process
that involves protocols itself.  (BTW, the point of this particular
line of argument is simply that if URLs have a protocol associated
with them, then so do URNs.  But in fact, different protocols can be
used to resolve either URNs or URLs.)

 > On Sun, 3 Nov 1996, Daniel LaLiberte wrote:
 > > But the very same URL was used to retrieve the resource either from a
 > > cache or from a remote server.  So what "location" is the URL
 > > identifying when the resource actually lives in multiple places - the
 > > very same URL may be used to fetch the resource from any of those
 > > places?  Notice you first say that a URL identifies (or names) the
 > > location of a resource, and then we find out that there are really
 > > multiple locations identified by the URL.  But that is supposed to be
 > > the job of URNs.  So why do we need URNs?

(BTW, my "So why do we need URNs?" is somewhat rhetorical.  I believe
we do need more persistent resolution services, in case that is not
clear.  The point of the above line of argument is, again, that the
binding between URLs and locations is not so clear.  There is more to
this argument that hasn't come out yet.)

...

 > Dan, you _have_ to start to differ between multiple locations
 > of a resource which is addressed by a URL - i.e. it's original
 > location,

Is your view that a URL *is* the "original" location of the resource
and also the URL "addresses" multiple locations of the resource?  This
is different from the definition that a URL identifies (or names) the
location of the resource.

 > and the functionality that is built into the system
 > when a _name_ is assigned to a resource. As long as you have not
 > seen this difference that many of us others have seen, it is
 > a little bit hard to have a meaningful discussion.

I see a difference, but it is not the difference you think it is.
There is a difference in the functionality that can be provided by a
new service, but it is not a difference because we call something a
"name" vs a "location".  The proof is that the things you call
"locations" (i.e. URLs) can use this new service too.

 > Sorry for being harsh and short, but I am now a little bit tired
 > of having to try to come up with exactly the same arguments we
 > have been having since the UR* discussions started. We have
 > to move forward!

I don't think these are exactly the same arguments - at least I havent
seen my arguments before.  But I didn't perceive harshness in your
words, or it didn't bother me anyway.  I am being patiently persistent
- I only hope that my readers are being persistent enough to
understand my arguments.

 > > A client can resolve
 > > "http://www.ncsa.uiuc.edu/" using HTTP or using the NAPTR protocol, or
 > > something else.  This is the very same identifier, not two identifiers
 > > with the same character representation.  Calling it two identifiers
 > > and saying one is a name and the other is [the name of] a location is
 > > missing the whole point.
 > 
 > No, _you_ are missing the point. By saying that
 > "urn:http://www.ncsa.uiuc.edu/" is a _name_, one know that this
 > namespace called HTTP can grandfather other namespaces, this
 > _name_ can stay as it is even if the resource moves, the metadata
 > for this resource can be fetched etc etc all according to the URN
 > spec that was written down years ago.

I'm not missing that point - I agree with it.  I helped create all
this, by the way, so I know what is going on here.

But I am not talking about "urn:http://www.ncsa.uiuc.edu/", I am
talking about "http://www.ncsa.uiuc.edu".  If the "urn:" prefix is
optional on URNs, then those two identifiers are equivalent.  

Answer this: do you agree with the previous statement?

 > If you have a URL, like "http://www.ncsa.uiuc.edu/", what do you do
 > if you have to move this resource from the host www.ncsa.uiuc.edu?
 > Change things in the DNS? But of course that works. But, if you move
 > the information from staying only on an http server to also stay in
 > a Z39.50 database and want the clients to be able to use both, or
 > [...]

If "http://www.ncsa.uiuc.edu/" is in the "http" branch of the urn.net
tree, then you could do any of these things.  If some other name
resolution mechanism is created in the future, then
"http://www.ncsa.uiuc.edu/" could be registered there too.

 > There are thousands of things you _can_not_do_ with the name of a
 > location of something, that you only can do with a _name_ of a
 > resource which is resolved to one or many alternative locations.

If *you* define an identifier as a location and therefore limit what
you do with it based on that definition, then that's your choice.  But
anyone else is still free to use it as a name, if they can find a
resolution service that treats it as a name, in the sense of providing
persistent resolution, or any of the other thousands of things one
might associate with names.

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

To: [email-masked]
Subject: [URN] URN-WG home page w/references
From: Larry Masinter <[email-masked]>
Date: Mon, 4 Nov 1996 16:52:43 PST
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

Is there a 'home page' for the URN working group? It would be really
useful to collect together the references & previous work. There was a
home page for URI that was (and still is) really useful, but lately
I've had to search for URN & URC references.

Regards,

Larry

Date: Mon, 4 Nov 1996 15:06:37 -0500
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Subject: Re: [URN] some comments
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

Let me try once more...

There are three core functions that are generally provided by "names":
identification, location, and mnemonics or semantics.  Let me describe
each separate.  In this context, all have meaning only with respect to
resources.

Identification allows the assigner of the name to declare the
distinctiveness of a resource from other resources, from the
perspective of the assigner of the name.  This allows someone else to
recognize this distinction or lack thereof as intended by the name
assigner.  Generally, all naming schemes provide this in some form or
other. 

Location allows the assigner to declare something about how to locate
or find the resource.  In an abstract sense it can be seen as
"location", but the meaning of location is left to the interpretation
of the supporting infrastructure.  A different way of saying this is
that it is the input to the supporting protocol elements.  Again,
generally, at least in computer systems, all naming schemes provide
this in some form or other.

Mnemonics or semantics allows the assigner to include something
"meaningful" to potential clients, such as ways to remember the name,
or perhaps something about the nature of the resource (an extension
defining the language in which the resource is encoded, an algorithm
that was used in it, it's functionality, or perhaps its relationship to
other resources, e.g. versioning).  Not all naming schemes provide
this.  Human friendly schemes tend to do much more than machine
friendly ones.

Now, let's step back and look at our environment.  We are talking
about a situation in which there are "layers of abstraction".  At
"our" layer, the entities to be named are resources.  Resources will
be supported by an infrastructural suite, including (although I may
have missed some) storage services (file systems, oodbms, object
repositories, etc.), computation engines, access methods, access
constraint methods, communications protocols, and perhaps others.  So,
for example, at the present the infrastructure may be provided by
publicly accessible unix file systems, NT file systems, etc, as well
as a collection of transport protocols such as HTTP, NNTP, FTP,
Z39.50, etc.  These are not part of our layer of abstraction, but
rather are what we use to realize them.  These things in turn are
themselves supported by lower level abstractions.  The same issues of
naming listed above apply to each of the layers.

After much more than 2 yrs we have chosen by consensus a particular
model with respect to naming within our layer.  That model for the
most part separates the three functions and realizes them separately.
In the URI architecture (not Tim B-L's idea of URIs, but that of the
URI WG consensus), these functions are separately provided by three
components of the architecture.  Identification is provided by URNs,
location by URLs, and semantics by URCs.  That is what was agreed to
by consensus of the working group.  That is what is laid out in the
introductions to both the URN and URL requirements documents that were
also agreed to by the WG.  Such a layering architecture also
recognizes that there are different layers of abstraction and that at
least abstractly one goes through the exercise repeatedly (and not
just at the layers at which we are working) of taking an identifier
and using it to either learn something about distinctions or lack
thereof in the intention of the name assigner or perhaps semantics,
and/or alternatively "resolving" or "binding" it, by translating it
into something for which the only intention is that it be handed to
some piece of the infrastructure to "do its thing" on.  For this
resolution or binding process one might use similar mechanisms at
different layers of abstraction, such as table lookup or recourse to
servers using the same query protocol in order to request resolution.
But that in no way means that the same abstractions are being
identified, learned about or resolved.  Given our choice of
separation, we, in this working group, have set about to design a
first mechanism to provide the binding of name to location.

Let me recommend to you an extremely well-written short paper on the
subject, "On the Naming and Binding of Network Destinations" by Jerry
Saltzer.  This was originally published in 1983 (yes, that was long
before the URI WG was formed :-), so its examples are
from that era.  The concepts are completely applicable to this
discussion.  This is not a new problem, nor is the model of
distinguishing between name and address a new solution.  It was issued
as RFC 1498 (informational) in 1993.

Two additional relevant references (from Saltzer's paper) that I also
recommend to you are:

Shoch, John F., "Inter-Network Naming, Addressing, and Routing,"
       IEEE Proc. COMPCON Fall 1978, pp. 72-79. Also in Thurber, K.
       (ed.), Tutorial: Distributed Processor Communication
       Architecture, IEEE Publ. #EHO 152-9, 1979, pp. 280-287.

Sunshine, Carl A., "Addressing Problems in Multi-Network
       Systems", to appear in Proc. IEEE INFOCOM 82, Las Vegas, Nevada,
       March 30 - April 1, 1982.

			Karen Sollins

Date: Mon, 4 Nov 1996 11:53:09 -0600 (CST)
From: Daniel LaLiberte <[email-masked]>
To: Leslie Daigle <[email-masked]>
Cc: [email-masked]
Subject: Re: Names and Locations (was [URN] some comments)
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Leslie Daigle writes:
 > A URL (location) is a point in 4-space, as defined by:
 > 
 > . machine (aliased through DNS mechanisms)
 > . port number (default per protocol)
 > . protocol to speak on that port and at that machine
 > . string to use within that protocol
 > 
 > A basic URN (name) has nothing to do with these 4 dimensions -- it is
 > independent of any machine identifier, port, or protocol.  The string
 > associated with it is a _label_ that is unique across the specified
 > namespace.

The URN being proposed to be resolved with the NAPTR mechanism has 
everything to do with these 4 dimensions.   Specifically:

  . machine: urn.net (or whatever is decided)
  . port: DNS protocol port
  . protocol: DNS on top of UDP or TCP
  . string:  nsi:opaque-string

Furthermore, it is an iterative protocol, making several requests to
DNS.  But similarly, HTTP is iterative.

You might respond that this is just one URN resolution mechanism and
others are possible.  Absolutely true.  But the same is true of URLs.
A URL is *not* necessarily resolved through the mechanism suggested by
its components.  An http URL can be resolved by the NAPTR mechansm,
for example.  Or it may be resolved through a cache.

 > [Dan LaLiberte wrote:]
 > > 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?
 > 
 > Caches are external to either URN or URL systems.  They may choose
 > to use the URL string as a label that identifies a particular
 > resource, and use that label to lookup contents of the cache.

Stop right there for a moment.  Note that the location of the resource
found in the cache is *not* the location you described above that is
suggested by the components of the URL.  You say that caches
are external to URIs, but the URL is in fact used to look up the
resource.  That is not external - that is part of the process of
resolving the URL.

 > But, caches break when the label does not change, but the contents
 > of the location does.

You mean "location of the contents", I presume.  

I understand what you are saying, and I believed the same once - I
couldnt figure out why Tim Berner-Lee argued that URLs could work
just fine for caching.   I thought he was missing something.

But the problem, as I understand it now, is not in the identifiers, it
is in the resolution process.  Identifiers, whether URLs or URNs, are
*always* interpreted by some resolution process.  And it is the
resolution process that provides the persistence of reference, not the
identifiers themselves.  Take out the NAPTR resolution service (and
provide no substitute resolution service) and URNs will be useless
(except for unique identification which needs no resolution service).

Yes, HTTP fails to provide persistent resolution because servers move
and there is no way to redirect a whole service.  Note that within a
still existing server, a redirect can be used to provide persistent
resolution.  The PURL idea is to just make sure the purl server
continues to exist, and people may or may not believe it will.
Abstractly, there is no difference between depending on the continued
existence of a purl server and depending on the continued existence of
the DNS root service, and NAPTR resolution will depend on that, and on
'net' and 'urn.net'.  The practical difference is that DNS probably
will continue to exist even if all the purl servers vanish.

 > If you cache based on URN, your cache will
 > not break, because the content associated with the identifier
 > does not change.

You seem to be jumping here to content-based identifiers.  That is not
in the requirements, as I understand it.  The content of a resource
may in fact change and still be identified by the same URI.

Perhaps, you are talking about the uniqueness property of URNs such
that a URN will always map to the *same* resource, as long as the
resource exists, even though it may be a dynamically changing
resource. But note that, like persistence, uniqueness is also (partly)
a property of the resolution services, not the URN itself.  The naming
authority must make sure that a URN is only used once, but the
resolution service must also behave such that it always associates a
particular URN with the same resource, otherwise the URN is
effectively *not* unique.

But URLs could have that same uniqueness property.  There is no
guarantee that all http URLs will be unique, and we will never be able
to get that guarantee, but a cache could find out from a server
whether a URL is unique for the resource that was returned.

 > > 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.
 > 
 > I'm not sure I understand the point you are making here.

Access to NAPTR records in DNS is (will be) provided by a service, a
DNS service.  This NAPTR service might be limited to just parts of the
DNS tree, under urn.net.  I am suggesting that http URLs could be
resolved through that limited service, by setting up an http branch
under urn.net.  Therefore, http URLs resolved this way could have
exactly the same persistence as any other URN.  It is the resolution
service that provides the persistence, not the identifier itself.

 > It sounds like
 > you are saying -- forget everything else about all this stuff, let's
 > do NAPTR as a service, and then people can build in persistence using
 > whichever mechansisms strike their fancy?

That is an interesting idea, if I understand what you are thinking,
but it is not what I was suggesting.  

 > I have a problem with that approach, for (at least) two reasons:
 > 
 > . implementing a persistent location means adding much overhead
 >   in systems that were not built for it.

Yes, there is overhead in providing persistent resolution services.  
But not as much as you suggest, depending on how it is done.

 > . there are then no mechanisms to distinguish between things that
 >   are meant to be persistent, and things that are expected not
 >   to be.

Time-to-live data would indicate how persistent things are.
Why should we assume that URLs are not persistent?
Why should we assume that URNs last forever?

It is resolution services and the organizations that provide them
that make URLs or URNs persist, or not.

(BTW, throughout this discussion, I've slighted the guarantees of
uniqueness of identifiers (i.e. not used for another resource), but
that is a trivially easy problem to solve, so I am not particularly
worried about it.  In addition to providing persistent resolution
services, we would need to know that particular URIs are unique, if
that is important for some particular application.  This information
can be provided by servers along with the resource or separately.  We
don't *need* to create a new kind of identifier to know that
particular identifiers are unique, although it is convenient to know
that all identifiers with the same prefix are intended to be unique.)

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

 > It is definitely interesting to look at the surface similarities in
 > mechanics between URL resolution and the NAPTR approach to URN
 > handling.

This abstraction is not a surface similarity - this is a fundamentally
deep similarity.  Both URLs and URNs have the same abstract mechanism
- it is the details of exactly which processes are used that is at the
surface.

 > What still is not clear to me is what you are suggesting
 > to _do_ with this.  If you are suggesting that there is nothing
 > more to do with URN work than to define different steps in 2 and 3,
 > I have a problem with that...

The "nothing more" involves setting up a persistent resolution service
which is not exactly trivial, especially when it hopes to be
applicable to all names, past and future.  But yes, this resolution
service fits right into this general URI resolution mechanism.  The
problem you might have with it is that it makes URLs and URNs look too
much alike, which collapses the view that they must be different.

Let me return to my claim that: It is the resolution service that
provides the persistence, not the identifier itself.  Something
similar applies to any properties of identifiers.  The only properties
that are inherent in an identifier itself are properties of its actual
representation.  Any other properties *associated* with the identifier
are derived from how it actually behaves, or is promised to behave
when used in a particular context.  But note that the same identifier
can be used in different contexts, so it can "have" different
properties in each.  This is just a mathematical truth.

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

Date: Mon, 4 Nov 1996 12:32:53 -0500
To: [email-masked]
From: "David G. Durand" <[email-masked]> (David G. Durand)
Subject: Re: Names and Locations (was [URN] some comments)
Sender: [email-masked]
Reply-To: "David G. Durand" <[email-masked]> (David G. Durand)

binding time: a URL has a resolution mechanism defined at the time that it
is created. A URN is explicitly defined to have multiple potential
resolution mechanisms, as long as they work (i.e. lead to right resource).
You can use any kind of indentifier as a URL (even one that was originally
assigned as a URL), but such use implies a contract by the name assigner,
establishes the bounds of variation on the resource (usually, that the
resource be immutable).

   URNs are supposed _not_ to have a privileged resolution mechanism, thus
allowing the identifiers to outlive URN resolutin mechanisms. Now, it is
true that we will need to have at least one mechanism for URL resolution,
but the strategy for defining identifiers and that for resolving them
should _not_ be tightly coupled because we _know_ that the mechnisms will
change, but the URNs cannot change.

   It is the point of URNs that the _client_ can decide how to resolve
them, while URLs require that the _URL creator_ prescribe how they should
be resolved. That's also why a URN prefix makes URNs more useful, since it
is a tip-off to a client that it may have a choice as to resolution
strategy. It also signals that the assigner of the name claims to meet the
contract for URN persistence. Mixing URN authorities with HTTP protocols is
technically workable, but it makes the deployment of new naming authorities
interact closely with the completely unrelated issue of protocols for HTTP
resolution. It is much simpler to ensure that there is a requirement for
syntactic differentiation of URNs _in contexts where both URLs and URNs can
occur_.

   -- David

_________________________________________
David Durand              [email-masked]  \  [email-masked]
Boston University Computer Science        \  Sr. Analyst
http://www.cs.bu.edu/students/grads/dgd/   \  Dynamic Diagrams
--------------------------------------------\  http://dynamicDiagrams.com/
MAPA: mapping for the WWW                    \__________________________

From: "Ryan Moats" <[email-masked]>
To: "Martin J Duerst" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Mon, 04 Nov 96 11:06:14 
Priority: Normal
Subject: Re: [URN] %encoding for reserved UTF-8 characters (was: New syntax
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Mon, 4 Nov 1996 17:37:06 +0100 (MET), Martin J Duerst wrote:

>Ryan Moats wrote:
>
>>>- Specify that protocols may only reserve 1-octet UTF-8 characters
>>>	(i.e. ASCII).
>>>- Specify that protocols have to define their own escaping mechanisms
>>>	for things beyond ASCII.
>>
>>Having had the weekend to mull this over some more (and seeing that my
>>mulling was in the right direction...), here are my thoughts:
>>
>>I would add a third solution to the above-- That the syntax draft defines its
>>own escaping mechanism for things beyond ASCII.  This ensures that URN
>>resolvers don't have to be re-written just because some new namespace comes
>>along that wants to reserve some character in some totally different scheme
>>then all the others currently used.
>>
>>Having said that, I currently lean strongly towards the first solution
>>that Martin has
>>proposed, as it keeps the syntax document short, doesn't add a new
>>escaping mechanism (and all the complexity that adds).  To sum up, it just
>>strikes me as being CLEANER than any other solution. Does anybody
>>have problems with it being written into the syntax draft?
>
>It looks cleaner to me, too, maybe even a subset of ASCII, as Jon
>Knight has suggested, because as I have explained, even now %7E
>is used in some parts of the world to escape a "~" that is not
>a reserved character.

I can live with a subset of ASCII, say from %20 to %7D.

>Also, I think we will never be able to fully exclude the second
>solution, and we may even say in the draft that it is allowed,
>but of course there will be no support from any generic handling
>software.

I'd word it differently, but I can add such text as well.

Ryan

Subject: Re: [URN] %encoding for reserved UTF-8 characters (was: New syntax
To: [email-masked]
Date: Mon, 4 Nov 1996 17:37:06 +0100 (MET)
Cc: [email-masked]
Content-Length: 1839
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Ryan Moats wrote:

>On Mon, 4 Nov 1996 11:50:36 +0100 (MET), Martin J Duerst wrote:

>It wasn't your explanation, it was getting my brain to stop thinking in ASCII
>mode and start thinking in more general character mode.  I'll probably still
>slip back and forth, since it isn't natural yet...

I see. I'm probably too much into i18n mode to realize such things anymore.

>>- Specify that protocols may only reserve 1-octet UTF-8 characters
>>	(i.e. ASCII).
>>- Specify that protocols have to define their own escaping mechanisms
>>	for things beyond ASCII.
>
>Having had the weekend to mull this over some more (and seeing that my
>mulling was in the right direction...), here are my thoughts:
>
>I would add a third solution to the above-- That the syntax draft defines its
>own escaping mechanism for things beyond ASCII.  This ensures that URN
>resolvers don't have to be re-written just because some new namespace comes
>along that wants to reserve some character in some totally different scheme
>then all the others currently used.
>
>Having said that, I currently lean strongly towards the first solution
>that Martin has
>proposed, as it keeps the syntax document short, doesn't add a new
>escaping mechanism (and all the complexity that adds).  To sum up, it just
>strikes me as being CLEANER than any other solution. Does anybody
>have problems with it being written into the syntax draft?

It looks cleaner to me, too, maybe even a subset of ASCII, as Jon
Knight has suggested, because as I have explained, even now %7E
is used in some parts of the world to escape a "~" that is not
a reserved character.

Also, I think we will never be able to fully exclude the second
solution, and we may even say in the draft that it is allowed,
but of course there will be no support from any generic handling
software.

Regards,	Martin.

Subject: Re: [URN] New syntax draft
To: [email-masked] (Jon Knight)
Date: Mon, 4 Nov 1996 16:22:19 +0100 (MET)
Cc: [email-masked], [email-masked]
Content-Length: 1597
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Jon Knight wrote:

>On Mon, 4 Nov 1996, Martin J Duerst wrote:
>> Yes. But now immagine that some of these French/German/Nordic/Icelandic
>> letters, or whatever else, is reserved, but that somebody was not able
>> to represent them directly, and used %-escaping. What are you going to do?
>
>But nobody is suggesting making the Nordic runes reserved characters are
>they?  I was thinking that reserved characters would be a very well
>defined, small subset of the ASCII range, just as with URLs.

Nobody is explicitly suggesting to make the Nordic runes reserved
characters at the moment. They would first have to be included in
Unicode/ISo 10646, for which work is still progressing.
But the current draft does not say reserved characters are
restricted to ASCII, or even a subset of it.

>> >And anyway, URLs don't use UTF-8 so this isn't going to be a problem
>> >(we're talking URNs here right?).
>> 
>> I just explained the problems using URL examples. Just because
>> they problems might not apply to URLs, that still does not help
>> for URNs.
>
>Which means that URLs are maybe doing something right and we should take
>notice whilst doing URNs...?  Such as only having a relatively small
>number of reserved characters.

It may well be that this is the right way to go. On the other hand,
what does "grandfathering" exactly mean? If there is a namespace
that already has e.g. some Nordic rune as reserved character,
and we limit ourselves to a subset of ASCII, then although
the namespace as such can be grandfathered, the reserved
characters will have to be changed.

Regards,	Martin.

Date: Mon, 4 Nov 1996 15:15:56 +0000 (GMT)
From: Jon Knight <[email-masked]>
To: Martin J Duerst <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [URN] New syntax draft
Sender: [email-masked]
Reply-To: Jon Knight <[email-masked]>

On Mon, 4 Nov 1996, Martin J Duerst wrote:
> Yes. But now immagine that some of these French/German/Nordic/Icelandic
> letters, or whatever else, is reserved, but that somebody was not able
> to represent them directly, and used %-escaping. What are you going to do?

But nobody is suggesting making the Nordic runes reserved characters are
they?  I was thinking that reserved characters would be a very well
defined, small subset of the ASCII range, just as with URLs.

> >And anyway, URLs don't use UTF-8 so this isn't going to be a problem
> >(we're talking URNs here right?).
> 
> I just explained the problems using URL examples. Just because
> they problems might not apply to URLs, that still does not help
> for URNs.

Which means that URLs are maybe doing something right and we should take
notice whilst doing URNs...?  Such as only having a relatively small
number of reserved characters.
 
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. *

From: "Ryan Moats" <[email-masked]>
To: "Martin J Duerst" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Mon, 04 Nov 96 09:14:28 
Priority: Normal
Subject: Re: [URN] %encoding for reserved UTF-8 characters (was: New syntax draft)
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Mon, 4 Nov 1996 11:50:36 +0100 (MET), Martin J Duerst wrote:

>Ryan Moats wrote:
>
>>
>>My brain hurts, but I think I finally understand the issue.
>
>Sorry for my long explanations.

It wasn't your explanation, it was getting my brain to stop thinking in ASCII
mode and start thinking in more general character mode.  I'll probably still
slip back and forth, since it isn't natural yet...

>>Allow me to restate it to see if I'm right:
>>
>>The problem you are talking about arrises if the reserved character has
>>a UTF-8 representation of more than 1 octet.  Then, if we use %encoding
>>to represent the character in a literal use, there is no way of determining
>>from the URN whether the character is being used as a literal character
>>or not. 
>
>Exactly.
>
>
>- Specify that protocols may only reserve 1-octet UTF-8 characters
>	(i.e. ASCII).
>- Specify that protocols have to define their own escaping mechanisms
>	for things beyond ASCII.

Having had the weekend to mull this over some more (and seeing that my
mulling was in the right direction...), here are my thoughts:

I would add a third solution to the above-- That the syntax draft defines its
own escaping mechanism for things beyond ASCII.  This ensures that URN
resolvers don't have to be re-written just because some new namespace comes
along that wants to reserve some character in some totally different scheme then
all the others currently used.

Having said that, I currently lean strongly towards the first solution that Martin has
proposed, as it keeps the syntax document short, doesn't add a new
escaping mechanism (and all the complexity that adds).  To sum up, it just
strikes me as being CLEANER than any other solution. Does anybody
have problems with it being written into the syntax draft?

Ryan

From: [email-masked]
To: Larry Masinter <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] HTTP resolution protocol
Date: Mon, 04 Nov 1996 14:44:25 +0100
Sender: [email-masked]
Reply-To: [email-masked]
(Warning: I'm coming into this without reading the entire debate...)

I like the idea that HTTP GET is an URI to MIME object resolution
protocol. It either fails or returns a MIME object.

But the scheme of service:/uri would IMHO require registering
N2L, N2Ls, N2C and so on as URI types; this sounds wrong to me.

If we want a resolution CONVENTION, it seems to me that the right
convention is "GET /resolve/N2L/<uri>" (mimicking a CGI-BIN script).
If we want a resolution STANDARD, it seems to me that the right
thing is "N2L <uri> HTTP/1.1"

For handing back lists of things, mimic the responses that were put
into HTTP/1.1 for content negotiation (putting up a header for thte
machine processible version and HTML for the human-readable version).

Just my NOK 0.50....

               Harald A

Subject: Re: [URN] %encoding for reserved UTF-8 characters (was: New syntax  draft)
To: [email-masked]
Date: Mon, 4 Nov 1996 11:50:36 +0100 (MET)
Cc: [email-masked]
Content-Length: 1322
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Ryan Moats wrote:

>>Now for UTF-8, things are quite different. 8-bit bytes will
>>on many occasions be escaped because it may be difficult to
>>represent them otherwise. Having some character beyond ASCII
>>represented with %HH (usually %HH%HH or %HH%HH%HH) can in no
>>way imply that this is a special character.
>>This means that any tools dealing with URNs in general will
>>have no clue about where to keep the escaping, and where
>>to remove it. A very exact knowledge of each NSS syntax
>>would be needed.
>
>My brain hurts, but I think I finally understand the issue.

Sorry for my long explanations.

>Allow me to restate it to see if I'm right:
>
>The problem you are talking about arrises if the reserved character has
>a UTF-8 representation of more than 1 octet.  Then, if we use %encoding
>to represent the character in a literal use, there is no way of determining
>from the URN whether the character is being used as a literal character
>or not. 

Exactly.

>I'll save a discussion of potential solution directions to this until I'm sure
>I understand the issue.

I have already mentionned two possibilities:

- Specify that protocols may only reserve 1-octet UTF-8 characters
	(i.e. ASCII).
- Specify that protocols have to define their own escaping mechanisms
	for things beyond ASCII.

Regards,	Martin.

Subject: Re: [URN] New syntax draft
To: [email-masked]
Date: Mon, 4 Nov 1996 11:46:38 +0100 (MET)
Cc: [email-masked], [email-masked]
Content-Length: 3326
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Jon Knight wrote:

>On Fri, 1 Nov 1996, Martin J Duerst wrote:
>> When going from ASCII to UTF-8, there are some new problems.
>> For ASCII, the general assumption is that only those charcters
>> that need escaping are actually escaped, and therefore that
>> escaping, e.g. for "/" or whatever, shouldn't be undone.
>> The above is not exactly true, indeed the "~" is often escaped
>> as %7E in Europe because it is difficult to type on European
>> keyboards, but still I assume there are a lot of tools around
>> working on URLs in general that work along the rule "if ASCII
>> is escaped, don't remove the escaping, because this is a special
>> character.
>
>Hmm, I don't really understand this; URL percent escaping is just away of
>dealing with characters that you can't represent directly, either because
>they're in the reserved set of characters or because they're not easy to
>type (the French/German/Nordic/Icelandic letters in ISO-8859-1 for
>example).  If you're unescaping things, one would assume that you've
>already parsed any reserved characters to extract any structuring
>information that the provide.

Yes. But now immagine that some of these French/German/Nordic/Icelandic
letters, or whatever else, is reserved, but that somebody was not able
to represent them directly, and used %-escaping. What are you going to do?

Also, according to the syntax draft, intermediate software migth
%-escape some UTF-8 part to pass the thing through a 7-bit channel.
It will %-escape reserved and unreserved characters all alike.

>Percent escaped characters aren't just
>restricted to the reserved characters that need to be escaped; you can
>percent escape your entire URL's path if you like.  Any software that just
>expects reserved characters to be percent escaped is going out of its way
>to be braindead IMHO.

The problem is with software that expects reserved charcters NOT
to be escaped.

>And anyway, URLs don't use UTF-8 so this isn't going to be a problem
>(we're talking URNs here right?).

I just explained the problems using URL examples. Just because
they problems might not apply to URLs, that still does not help
for URNs.

And URLs don't use UTF-8 YET. They don't even use ASCII, in the sense
we are proposing to use UTF-8 here. They just encode octets.
For the benefit of us all, fortunately, there are some coincidences
in most of the URL schemes, so that it actually looks as if URLs
would use ASCII.
If you currently see an URL with octets in the 8-bit range, there
is not much of a chance to guess what characters it could represent.
But steadily, the number of cases where there are chances that
you get the characters if you interpret the octests as UTF-8
will be increasing.
One example is ftp: The ftp-wg agreed on going into the direction
of using UTF-8 as the common character encoding. According to
the URL spec, that's up to ftp to decide. Because it is a very
reasonable decision, it will hopefully be followed by others.

The remaining formal difference between URL syntax and URN
syntaxt would then be that the later officially allows the
URN to be represented with characters/glyphs outside the
ASCII range (on things such as cardboard boxes), but the
former officially disallows such a behaviour. In practice,
I guess this difference will vanish rather quickly.

Regards,	Martin.

To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [URN] HTTP resolution protocol
From: Larry Masinter <[email-masked]>
Date: Mon, 4 Nov 1996 00:19:43 PST
Sender: [email-masked]
Reply-To: Larry Masinter <[email-masked]>

# GET service:/uri HTTP/1.1 is certainly valid.

Well, 

       Request-Line   = Method SP Request-URI SP HTTP-Version CRLF
       Request-URI    = "*" | absoluteURI | abs_path

and 'service:/uri' doesn't look like an 'abs_path', so it must be an
'absoluteURI'. 

While the HTTP spec doesn't explicitly limit Request-URIs to be URLs,
I think it was the intent that they be resource identifiers of some
sort. So now you're left with the idea that 'service' is really a kind
of URL/URN scheme.

You could do it, sure, and probably not break any existing HTTP
servers either, but it's really odd to think of 'N2L' as a URI
scheme, since it doesn't really locate a resource.

Larry

From: [email-masked]
To: Ron Daniel <[email-masked]>
Cc: Daniel LaLiberte <[email-masked]>, Larry Masinter <[email-masked]>, [email-masked]
Subject: Re: [URN] HTTP resolution protocol
Date: Sun, 03 Nov 1996 12:13:18 +0100
Sender: [email-masked]
Reply-To: [email-masked]

GET service:/uri HTTP/1.1 is certainly valid.

         Harald A

From: Keith Moore <[email-masked]>
To: "Gregory J. Woodhouse" <[email-masked]>
Cc: Leslie Daigle <[email-masked]>, Daniel LaLiberte <[email-masked]>, "Karen R. Sollins" <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [URN] some comments 
Date: Mon, 04 Nov 1996 01:46:45 -0500
Sender: [email-masked]
Reply-To: Keith Moore <[email-masked]>

> Look at it from the point of view of implementation: Is
> http://foo.bar.com/ a URL or a URN? Is there any conceptual reason why
> http: cannot be a valid URN scheme? 

Yes.  It's already well-established as a name space which does not
have the properties desired for URNs.

Now, if you ask a slightly different question:

"can the protocols used to resolve URNs also be used to resolve some
kinds of URLs?"

...then the answer is yes.

This group needs to solve two problems:

1) how to provide long-term stable and resolvable resource
identifiers.  These are called URNs.

2. how to resolve many kinds of resource identifiers (not just URNs)
to find multiple service locations etc.

There is a lot of overlap between the solutions of these two problems,
but they're not the same thing.  We need to be careful that we don't
confuse the two.

Once the resolution system exists, the main difference between a URL
and a URN is not the protocol used to perform resolution, but the
discipline by which the name is assigned and used.

Keith

Date: Mon, 4 Nov 1996 07:01:25 +0100 (MET)
From: Patrik Faltstrom <[email-masked]>
To: "Gregory J. Woodhouse" <[email-masked]>
Cc: Leslie Daigle <[email-masked]>, Daniel LaLiberte <[email-masked]>, "Karen R. Sollins" <[email-masked]>, [email-masked]
Subject: Re: [URN] some comments
Sender: [email-masked]
Reply-To: Patrik Faltstrom <[email-masked]>

On Sun, 3 Nov 1996, Gregory J. Woodhouse wrote:
> 
> Look at it from the point of view of implementation: Is
> http://foo.bar.com/ a URL or a URN? 

   http://foo.bar.com/      is a URL
   urn:http://foo.bar.com/  is a URN

> Is there any conceptual reason why
> http: cannot be a valid URN scheme? If it is possible for this to be a URN,
> then under the NAPTR proposal it would be first necessary to do a DNS query
> and receive and address for a service which will either resolve it for us
> or tell us that it corresponds to the URL http://foo.bar.com/. Armed with
> the information that this latter URI is a URL it is then possible to use
> HTTP to retrieve the resource.

>From an implementation standpoint the big difference is that when you
have a URN scheme, the resolution protocol have to be able to
change over time (in the NAPTR proposal from DNS to something else),
the protocol used to fetch the data have to be able to be different
between different locations of the resource (see the NAPTR and SRV
records the NAPTR proposal uses) and the namespace have to be able
to both grandfather and be grandfathered later on. All of the above
without changing the name.

One of the methods of doing a N2R, N2L, N2C etc. fetch for a
URN after resolution is to use the http URL scheme, but that
is definitely _after_ all of the URN abstraction levels have been
resolved.

    Patrik

Date: Sun, 3 Nov 1996 18:19:58 -0800 (PST)
From: "Gregory J. Woodhouse" <[email-masked]>
To: Leslie Daigle <[email-masked]>
Cc: Daniel LaLiberte <[email-masked]>, "Karen R. Sollins" <[email-masked]>, [email-masked]
Subject: Re: [URN] some comments
Sender: [email-masked]
Reply-To: "Gregory J. Woodhouse" <[email-masked]>

On Sun, 3 Nov 1996, Leslie Daigle wrote:

> Dan,
> 
> For all the words that have flown about on this mailing list in the past
> few days, I don't really think you've made it clear what you want out
> of this particular thread.    Let me be fairly blunt in my interpretation
> here, and you can tell me on which counts I have misunderstood you.
> 
> I think there are 2 separate things in what you have been saying:
> 
> 	. whether or not URNs are any different than URLs
> 	. whether or not URNs can be implemented using URL mechanisms
> 
> These are 2 very separate issues.  Let me say, as co-chair of this working
> group, that this WG starts from the premise that there _is_ a difference
> between URNs and URLs, and that our chartered purpose is to refine an
> architecture and experimental implementation that does not centre on 
> starting from URL mechanisms.
>

Look at it from the point of view of implementation: Is
http://foo.bar.com/ a URL or a URN? Is there any conceptual reason why
http: cannot be a valid URN scheme? If it is possible for this to be a URN,
then under the NAPTR proposal it would be first necessary to do a DNS query
and receive and address for a service which will either resolve it for us
or tell us that it corresponds to the URL http://foo.bar.com/. Armed with
the information that this latter URI is a URL it is then possible to use
HTTP to retrieve the resource.
 
---
Gregory Woodhouse     [email-masked]
home page:            http://www.wnetc.com/home.html
resource page:        http://www.wnetc.com/resource/

From: [email-masked] (Leslie Daigle)
Date: Sun, 3 Nov 1996 17:18:08 -0500
To: Daniel LaLiberte <[email-masked]>, "Karen R. Sollins" <[email-masked]>
Subject: Re: [URN] some comments
Cc: [email-masked]
Sender: [email-masked]
Reply-To: [email-masked] (Leslie Daigle)

Dan,

For all the words that have flown about on this mailing list in the past
few days, I don't really think you've made it clear what you want out
of this particular thread.    Let me be fairly blunt in my interpretation
here, and you can tell me on which counts I have misunderstood you.

I think there are 2 separate things in what you have been saying:

	. whether or not URNs are any different than URLs
	. whether or not URNs can be implemented using URL mechanisms

These are 2 very separate issues.  Let me say, as co-chair of this working
group, that this WG starts from the premise that there _is_ a difference
between URNs and URLs, and that our chartered purpose is to refine an
architecture and experimental implementation that does not centre on 
starting from URL mechanisms.

That purpose was selected after a process of consideration and consensus
gathering (i.e., not unanimity, but a bulk of people suggesting they thought
it had merit).  To stick to our charter need not demonstrate the dogmatism
or close-mindedness that I felt you were suggesting in your last mail
to Karen -- it is a reflection of the fact that this is a directed effort.

>From that standpoint, it is quite useful to consider other viewpoints and
implementation mechanism insofar as the contribute a positive step towards
defining, refining, explaining, or implementing the goal -- a sanity check, 
even.  But, if you want to sit back and discuss the relative merits of different
ways of how URIs could (have) be(en) implemented, you need to find a different
discussional forum.  I.e., I'm not saying it isn't valid/interesting
discussional material -- I'm saying it's not for this space.

> tomorrow.  But I want to challenge the notion that we shouldn't rethink the 
> work of the last several years.  For one thing, for the last 2 years, I 
> (and a few others) have been arguing against the split in names vs locations, 
> so why should that work be ignored?

Dan, I think your frustration is misplaced.   It is not that it "_is_"
being ignored -- it is not being discussed _here_, because the starting premise
for this WG is that it is not applicable.  If you accept the basic
premise of this working group, _and_ you still feel this is important, then
the problem is that you have not adequately communicated to the people on
this list _how_ your position is _not_ just completely at odds with everything
we're trying to do (and, by the way, I would point out that it was in one
of _your_ postings that you referred to "what you guys are doing" or some
such terminology).

> This is not a matter of just agreeing on a definition - it is a matter
> of having definitions that make sense.

A relative term -- I think the definitions make perfect sense.

> But it is something that the client gets to decide!  And the reason is
> that "identifier of resource" vs "identifier of location of resource"
> doesn't make sense.  It is the chosen resolution mechanism that
> determines how you get from an identifier to the resource.  The
> identifier does *not* determine the resolution mechanism, although
> there may be conventions and globally agreed on mechanisms available.
> The client *can* make the choice of how to resolve an identifier.  It
> is a fact of life in a free society that clients can do whatever they
> want.  (They can't always get away with it, though.)

Without talking about resolution mechanisms, let me say this:  a client
_cannot_ decide, for any given string, "I want the thing this identifies",
or "I want the thing at this location".  Quite simply, if the client has the
identifier of a location, it does not know _what_ the (intended) content
is.  This is _not_ a client decision.

Consider this completely abstract example:

	. Location identifier:  "the third thing from the right on the
	  fourth shelf down"

	. Content identifier: "Moby Dick"

If I am a client, holding the string "the third thing...", the only content
I can refer to is whatever is there now -- I have no clue about what
was there when location identifier was written down (included in an
electronic document, beamed to my Newton, _whatever_).  If the shelf has
been re-arranged since this location was made, I will get whatever is there
now.  On the other hand, if I have "Moby Dick", I don't _care_ where it is 
now, where it was before, where it will be in the future or what I might have 
to do to get hold of it.

The premise of this WG is that there is the need to be able to identify _what_
(i.e., content) one is looking for, as a separate task from identifying 
the location from which one wants content.  

If I have understood your position correctly, you are saying that there
is no need for a new mechanism for retrieving things from shelves by name --
we'll just build new URL schemes wherein  it is promised that shelves
are never re-ordered (or at least, if they are, transparent pointers are
used to continue the process to find the content that used to be located
on a particular position), and thus the location description can be used
as a unique, naming identifier.

Here's my view on what has happened:  to follow the above analogy a bit
further, URLs are used to retrieve content by instructing something
(call it a librarian in this case; in electronic terms, it is a scheme
resolution process) to retrieve the content from a particular shelf and
position.   The URN proposal says "get me Moby Dick", and identifies
a process whereby the librarian can figure out which  shelf and object
to retrieve.  Because these (currently) look like much the same process,
except for the implied longevity of the identifier, you are saying they
are the same.  I disagree.  I think the URN approach is based on fundamentally
different principles -- that it shall continue to be relevant long after
shelves and objects are no longer useful mechanisms, and therefore they
should _not_ play _any_ role in the naming process.  I don't care if
current URL and URN resolution mechanisms are isomorphic -- I am interested
in defining the baseline implementation for the first generation of 
content identification strings -- divorced from location identification.

I furthermore believe that the client (user or program) must be able to
determine by some non-network-based mechanism, whether or not the
identifier in hand is that of a location or of content.  

So, to sum up, the basic premises of this working group:

	. there is a difference between content identification and 
	  location identification

	. we have one proposed architecture for supporting the creation 
	  of effective content identifiers, and the use of these to determine
	  content/location at any given point in time (resolution), and 
	  this is what we are working to refine.

Dan, please tell me where I have missed your point...

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: Sun, 3 Nov 1996 15:49:50 +0100 (MET)
From: Patrik Faltstrom <[email-masked]>
To: Daniel LaLiberte <[email-masked]>
Cc: Terry Allen <[email-masked]>, [email-masked]
Subject: Re: Names and Locations (was [URN] some comments)
Sender: [email-masked]
Reply-To: Patrik Faltstrom <[email-masked]>

On Sun, 3 Nov 1996, Daniel LaLiberte wrote:

> and perhaps it is irrelevant semantics.  What is relevant is that you
> guys make a distinction between URLs and URNs, and it is a
> distinction founded on a misunderstanding.  I've been trying to dig
> through to get to the heart of that misunderstanding.

This is not a misunderstanding at all. There _is_ a difference between
a URN and a URL which from my point of view _you_ have not understood.

A URL refers to a location which though a caching mechanism, a proxy
cache, an interceptor with cache, multiple A-records in DNS or whatever
ends up refering to more than one occurance of the same resource.

A URN is a _name_ of a resource which have absolutely _NOTHING_
to do with the resolution protocol, the different versions of
the resource that exist (text, postscript etc), the different
protocols used to locate and later fetch the resource or the
metadata for the resource.

There are a couple of us that during all of the years so far has
only been talking about this difference being very very important.

If you don't understand this difference...well...what are _we_
supposed to do about that. The difference is needed!

> But the very same URL was used to retrieve the resource either from a
> cache or from a remote server.  So what "location" is the URL
> identifying when the resource actually lives in multiple places - the
> very same URL may be used to fetch the resource from any of those
> places?  Notice you first say that a URL identifies (or names) the
> location of a resource, and then we find out that there are really
> multiple locations identified by the URL.  But that is supposed to be
> the job of URNs.  So why do we need URNs?

Please Dan! There is a difference between having two A-records
pointing to two different IP-addresses, and when you later connect
to that hostname (which is resolved to one of the two addresses)
you will end up at one of the two locations. You can use this technique
in for example the hostname in a URL of course. You can also
use a proxy cache or an interceptor to see that you pick the
copy of the resource that is the most convinient for you.

BUT, you are still refering to _one_ location where the resource
is located. If you happen to have a local copy, well, let's use that one.
It's the same thing as if you do an lseek() in the filesystem and
want to read some bytes from a file. If the filesystem have cached those
diskblocks, and give you the copies of the bits that happened to
sit in RAM and not on the physical disk, are you not using an
lseek() anyway?

Dan, you _have_ to start to differ between multiple locations
of a resource which is addressed by a URL - i.e. it's original
location, and the functionality that is built into the system
when a _name_ is assigned to a resource. As long as you have not
seen this difference that many of us others have seen, it is
a little bit hard to have a meaningful discussion.

Sorry for being harsh and short, but I am now a little bit tired
of having to try to come up with exactly the same arguments we
have been having since the UR* discussions started. We have
to move forward!

> I used "http://www.ncsa.uiuc.edu/" for both, no "urn:" or "url:" for
> either.  (BTW, If "urn:" is optional, then
> "urn:http://www.ncsa.uiuc.edu/" has identically the same meaning - it
> is an equivalent identifier).  A client can resolve
> "http://www.ncsa.uiuc.edu/" using HTTP or using the NAPTR protocol, or
> something else.  This is the very same identifier, not two identifiers
> with the same character representation.  Calling it two identifiers
> and saying one is a name and the other is [the name of] a location is
> missing the whole point.

No, _you_ are missing the point. By saying that
"urn:http://www.ncsa.uiuc.edu/" is a _name_, one know that this
namespace called HTTP can grandfather other namespaces, this
_name_ can stay as it is even if the resource moves, the metadata
for this resource can be fetched etc etc all according to the URN
spec that was written down years ago.

If you have a URL, like "http://www.ncsa.uiuc.edu/", what do you do
if you have to move this resource from the host www.ncsa.uiuc.edu?
Change things in the DNS? But of course that works. But, if you move
the information from staying only on an http server to also stay in
a Z39.50 database and want the clients to be able to use both, or
if the resolution from www.ncsa.uiuc.edu to a hostname, which later
is turned into an IP-address in DNS is not done in DNS for some reason
in the future? What if the resource is mirrored to a different site?

There are thousands of things you _can_not_do_ with the name of a
location of something, that you only can do with a _name_ of a
resource which is resolved to one or many alternative locations.

> The point is a single identifier can, in fact, be resolved many
> different ways by clients.  Some ways are more direct (e.g. HTTP) and
> some are more indirect (e.g. NAPTR).  They are all resolution
> mechanisms.  They all result, eventually, in the resource, or whatever
> is being requested.

You _have_ to start to look at what kind of resolutions you do,
and can do. Just because you can have one A-record point to a list
of IP-addresses, that doesn't help you because the way the zones
in DNS are delegated. You _have_ to look at who owns what part
of the information used in the resolution process!
 
> I see no difference between *names* and *locations* at least
> regarding the identifiers themselves.

I can see that. There seems to, though, to be a number of people
that do, and I am one of them.

   Patrik

Date: Sun, 3 Nov 1996 01:48:05 -0600 (CST)
From: Daniel LaLiberte <[email-masked]>
To: "Karen R. Sollins" <[email-masked]>
Cc: [email-masked]
Subject: Re: [URN] some comments
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Karen R. Sollins writes:
 > This is a response to several responses to my message (each time I sit
 > down to respond I'm interrupted and by the time I get back to it there
 > has been more mail:-)

I know what you mean.  I have to wait til the quiet hours to get
real work done.

 > First, I want to echo what Leslie has been saying.  Unless we are
 > going to rethink all the work of the last 3 or more years, URNs
 > identify resources and URLs identify locations of resources and these
 > are different abstractions.  They could be chosen from the same set of
 > names, but they have different requirements on the names (see RFC1736
 > and RFC1737).  Enough said on that topic; for any more, see Leslie's
 > lucid comments.

I'll comment on Leslie's comments, perhaps tomorrow.  But I want to
challenge the notion that we shouldn't rethink the work of the last
several years.  For one thing, for the last 2 years, I (and a few
others) have been arguing against the split in names vs locations, so
why should that work be ignored?

This is not a matter of just agreeing on a definition - it is a matter
of having definitions that make sense.

For much longer, Tim Berners-Lee has argued against this name-location
split.  Most, if not all, of the W3C staff agree with this, and I don't
think it is because they were tested on this point before being hired.

I didn't agree with Tim at first, but it wasn't out of respect for him
that I changed my mind.  It takes a decision not to be dogmatic,
though, to be open to honest rethinking.

 >    From: Daniel LaLiberte <[email-masked]>
 > 
 >    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.
 > 
 > Leslie responded to most of this message, but this point surprised
 > me.  You are suggesting that in HTML we label URNs as such.

My suggestion was hypothetical.  I am *not* suggesting we do it.

 > I am left with two questions.  First, why is that only in HTML
 > should they be labelled?

Where did I say only HTML?  It was an example.

 > Second, why is it that the holder of a string (the principle
 > putting the string into the HTML document in this case) is the one
 > to decide which string is a URN and which is not?

Good point.  And this is a good reason *not* to do it.

 > Shouldn't that be decided by whoever did the name assignment?

Yes and no.  The creator of the identifier could use a name space
associated with a resolution mechanism that provides name properties.
But the author of the document containing the identifier *could* also
suggest a resolution mechanism that provides name properties. Also,
the client itself *could* use a resolution mechanism that provides
name properties.  The identifier itself does not provide name
properties - the resolution mechanism does.

 > So, my conclusion is that, if it is really important to
 > label URNs (which I happen to believe is true, and it seems you are
 > suggesting)

I am not suggesting that - to the contrary, I am arguing for the
opposite of that.  (Maybe you forgot who you were replying to.)

I raised the idea of labelling identifiers as URNs within the
context of their use precisely so it could be shot down.  Thanks.

 > and if the assigner of an identifier should be the
 > determiner of whether the identifier is identifying a resource or a
 > location for a resource, the assigner of the identifier should clarify
 > that fact by including it in the identifier for all to know.  This is
 > not something that the "client" gets to decide.

But it is something that the client gets to decide!  And the reason is
that "identifier of resource" vs "identifier of location of resource"
doesn't make sense.  It is the chosen resolution mechanism that
determines how you get from an identifier to the resource.  The
identifier does *not* determine the resolution mechanism, although
there may be conventions and globally agreed on mechanisms available.
The client *can* make the choice of how to resolve an identifier.  It
is a fact of life in a free society that clients can do whatever they
want.  (They can't always get away with it, though.)

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

Date: Sun, 3 Nov 1996 00:51:41 -0600 (CST)
From: Daniel LaLiberte <[email-masked]>
To: Terry Allen <[email-masked]>
Cc: [email-masked]
Subject: Re: Names and Locations (was [URN] some comments)
Sender: [email-masked]
Reply-To: Daniel LaLiberte <[email-masked]>

Daniel LaLiberte writes:
 > | OK, what is a location?
 > | ...  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?

Terry Allen writes:
 > 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.

On the face of it, this is sounding rather strange.  First, I agree
that the URL is not the resource itself (who would say that it is?
from your comment at the end, I think you think I said that).

Saying a URL is "the name of a location" is almost the same as "a URL
identifies a location".  The extra indirection of going from URL to
identifier to location, rather than URL to location, seems unnecessary,
and perhaps it is irrelevant semantics.  What is relevant is that you
guys make a distinction between URLs and URNs, and it is a
distinction founded on a misunderstanding.  I've been trying to dig
through to get to the heart of that misunderstanding.

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

But the very same URL was used to retrieve the resource either from a
cache or from a remote server.  So what "location" is the URL
identifying when the resource actually lives in multiple places - the
very same URL may be used to fetch the resource from any of those
places?  Notice you first say that a URL identifies (or names) the
location of a resource, and then we find out that there are really
multiple locations identified by the URL.  But that is supposed to be
the job of URNs.  So why do we need URNs?

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

I used "http://www.ncsa.uiuc.edu/" for both, no "urn:" or "url:" for
either.  (BTW, If "urn:" is optional, then
"urn:http://www.ncsa.uiuc.edu/" has identically the same meaning - it
is an equivalent identifier).  A client can resolve
"http://www.ncsa.uiuc.edu/" using HTTP or using the NAPTR protocol, or
something else.  This is the very same identifier, not two identifiers
with the same character representation.  Calling it two identifiers
and saying one is a name and the other is [the name of] a location is
missing the whole point.

The point is a single identifier can, in fact, be resolved many
different ways by clients.  Some ways are more direct (e.g. HTTP) and
some are more indirect (e.g. NAPTR).  They are all resolution
mechanisms.  They all result, eventually, in the resource, or whatever
is being requested.

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

It is so.

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

The name space is just a vehicle for resolving the identifier.
Consider how a cache creates a name space for looking up resources
given http URLs (usually it's just a hash table, but imagine it
creates a similar hierarchy to model DNS and filesystems within
servers).  Would you claim that the cache is somehow making new
identifiers?

Here is, perhaps, the missing point: The persistence of a name space
is not a property of the identifiers - it is a property of the
mechanism used to resolve the identifiers.

You seem to be saying that the persistence is a property of URNs, and
thus names are obviously different from locations.  I am saying that
the persistence of URNs is due to resolution mechanisms such as the
NAPTR mechanism.  (It is also due to the naming authorities
guaranteeing that the names will behave properly if the appropriate
resolution mechanism is used.)

Since different mechanisms can be used to resolve the very same
identifiers, and since some mechanisms might provide persistence while
others do not, there is no point in distinguishing the identifiers as
either names or locations.

There is nothing inherent in identifiers themselves that makes them have
different properties, whether name-like or location-like.  It is how
the identifiers are created and used that gives them those properties.

>From that standpoint, http URLs are different from new classes of
identifiers that will be created under the URN name space(s).
I certainly recognize that we need more persistence in the resolution
process, and that is why we created the "path" resolution mechanism.
(In fact, I believe the NAPTR mechanism doesn't go quite far enough,
and agree with Larry in that regard.)

But it is not the identifiers themselves that need to be distinguished
based on the properties of the resolution mechanism.  For one class of
identifier, there might be two resolution mechanisms available, one
supports persistence and the other does not.  So are the identifiers
names or locations?  Irrelevant question.

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

You could handle everything with "URN:" prefix with the same process,
but it is not required - you could just as well handle each URN
subscheme differently.  Or you could handle parts of a single name
space differently from the rest.

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

Not necessarily.  Each URL or URN scheme might have a different
process associated with it, or we could use just one process for
all schemes.  

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

I really don't see how you got that.  When did I talk about the
difference between objects and their locations?

I see no difference between *names* and *locations* at least
regarding the identifiers themselves.

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

Date: Fri, 1 Nov 1996 19:43:18 -0500
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Subject: Re: [URN] some comments
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

This is a response to several responses to my message (each time I sit
down to respond I'm interrupted and by the time I get back to it there
has been more mail:-)

First, I want to echo what Leslie has been saying.  Unless we are
going to rethink all the work of the last 3 or more years, URNs
identify resources and URLs identify locations of resources and these
are different abstractions.  They could be chosen from the same set of
names, but they have different requirements on the names (see RFC1736
and RFC1737).  Enough said on that topic; for any more, see Leslie's
lucid comments.

Let me respond (hopefully briefly) to various different responders to
me:

   From: Terry Allen <[email-masked]>

   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?

Let's just stick to the Internet.  I didn't realize that I needed to
qualify what I was saying with this statement, but I hope it helps.  In
fact we have even less say over what happens outside the Internet than
we do on the inside:-)

   From: Daniel LaLiberte <[email-masked]>

   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.

Leslie responded to most of this message, but this point surprised
me.  You are suggesting that in HTML we label URNs as such.  I am left
with two questions.  First, why is that only in HTML should they be
labelled?  If it is useful to label URNs as distinct from other
things, this is probably the case everywhere.  And I certainly don't
expect that everything will be in HTML.  Second, why is it that the
holder of a string (the principle putting the string into the HTML
document in this case) is the one to decide which string is a URN and
which is not?  Shouldn't that be decided by whoever did the name
assignment?  So, my conclusion is that, if it is really important to
label URNs (which I happen to believe is true, and it seems you are
suggesting) and if the assigner of an identifier should be the
determiner of whether the identifier is identifying a resource or a
location for a resource, the assigner of the identifier should clarify
that fact by including it in the identifier for all to know.  This is
not something that the "client" gets to decide.

   From: Ron Daniel <[email-masked]>

   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'm afraid you lost me in all the companies that do and don't want the
same or different things, but I think we are really having an
agreement.  Let me give you a simple example of what I had in mind.
For the sake of making things concrete, suppose we are using name
resolution scheme NS_TRANS (made up) that manages a widely distributed
core of translation information that allows for lookup of particular
URNs and provides pointers to final stage URN resolution (probably URN
to URL translation) servers managed by naming authorities.  Then also
suppose there is some naming authority NAT_SEC_CO that would like to
cause the names it is assigning to be resolved as it believes is
correct.  NAT_SEC_CO would like to be confident that the information
it provides to NS_TRANS is what will be distributed to potential
customers and no one who is not authorized can change that
information.  At the same time, another naming authority NON_SEC_CO
believes that the best way for information to be kept up to date is
for it to be updatable by anyone, because it is the customers who will
discover problems in the resolution information, and will be most
motivated to make the corrections (I've heard this position taken by a
very reputable person in a security conscious company in a slightly
different context.)  The position I take on this is that NS_TRANS had
better have security mechanisms available to protect NAT_SEC_CO
information and furthermore, anyone who wants to have access to it
including NON_SEC_CO will have to play the right security game to get
access to NAT_SEC_CO's information for modification.  At the same time
NAT_SEC_CO is given free and open access to NON_SEC_CO's information,
as is the case for anyone else.

The security infrastructure needs to be there in this case and anyone
wanting access to controlled parts will have to play the game
properly.  It does not mean that the whole infrastructure or even the
security provided for those that want it should in any way be
dependent on untrustworthy components.  That's nonsense, as you
rightly point out.  But it will depend on the infrastructure providing
some security functionality for those that want it and imposing that
on everyone who wants service in that corner of the infrastructure
space.  If we could not depend on the infrastructure for anything,
how could we depend on supposed implementations of DNSSEC either?  It
will only work if the infrastructure is playing the game.  Of course,
each peer server in the infrastructure will also need to be defensive to
protect against incorrectly behaving peers.  But that's true in the
DNS as well.

So, Ron, I believe we are on the same side of this one:-)

			Karen

PS: My apologies - I had planned to keep this short, but it got away
from me.

Date: Fri, 1 Nov 1996 16:58:41 +0100 (MET)
From: Leslie Daigle <[email-masked]>
To: Daniel LaLiberte <[email-masked]>
Cc: [email-masked]
Subject: Re: Names and Locations (was [URN] some comments)
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

[Dan LaLiberte wrote:]

> OK, what is a location?  Is it the bits on the disk that "has" the

Well, here's my perspective:

A URL (location) is a point in 4-space, as defined by:

=09. machine (aliased through DNS mechanisms)
=09. port number (default per protocol)
=09. protocol to speak on that port and at that machine
=09. string to use within that protocol

A basic URN (name) has nothing to do with these 4 dimensions -- it is=20
independent of any machine identifier, port, or protocol.  The string
associated with it is a _label_ that is unique across the specified
namespace.

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

Caches are external to either URN or URL systems.  They may choose to use
the URL string as a label that identifies a particular resource, and use
that label to lookup contents of the cache.  But, caches break when
the label does not change, but the contents of the location does.  If you
cache based on URN, your cache will not break, because the content associat=
ed
with the identifier does not change.

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

I'm not sure I understand the point you are making here.  It sounds like
you are saying -- forget everything else about all this stuff, let's=20
do NAPTR as a service, and then people can build in persistence using
whichever mechansisms strike their fancy?

I have a problem with that approach, for (at least) two reasons:

=09. implementing a persistent location means adding much overhead
=09  in systems that were not built for it.

=09. there are then no mechanisms to distinguish between things that
=09  are meant to be persistent, and things that are expected not
=09  to be. =20

> To summarize, both URLs and URNs have the following abstract
> resolution process in common:
>=20
> 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 rep=
eat.
> 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.=20
> 5. If error results, exit.
> 6. If redirected to another URI, repeat whole process with that URI.
>=20

It is definitely interesting to look at the surface similarities in mechani=
cs
between URL resolution and the NAPTR approach to URN handling.  What still
is not clear to me is what you are suggesting to _do_ with this.  If you
are suggesting that there is nothing more to do with URN work than to
define different steps in 2 and 3, I have a problem with that...

Leslie.

---------------------------------------------------------------------------=
-
                                                  Leslie Daigle
   "Min sv=E4vare =E4r full av =E5lar!"        Vice President, Research
                                                  Bunyip Information System=
s
                      -- ThinkingCat              (514) 875-8611
                                                  [email-masked]
---------------------------------------------------------------------------=
-

From: "Ryan Moats" <[email-masked]>
To: "[email-masked]" <[email-masked]>, "Martin J Duerst" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Date: Fri, 01 Nov 96 09:12:22 
Priority: Normal
Subject: [URN] %encoding for reserved UTF-8 characters (was: New syntax draft)
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

Sorry folks, but I need to keep the threads separate to keep my
sanity [at least whatever remains of it.... ;-)]

On Fri, 1 Nov 1996 12:11:37 +0100 (MET), Martin J Duerst wrote:

>When going from ASCII to UTF-8, there are some new problems.
>For ASCII, the general assumption is that only those charcters
>that need escaping are actually escaped, and therefore that
>escaping, e.g. for "/" or whatever, shouldn't be undone.
>The above is not exactly true, indeed the "~" is often escaped
>as %7E in Europe because it is difficult to type on European
>keyboards, but still I assume there are a lot of tools around
>working on URLs in general that work along the rule "if ASCII
>is escaped, don't remove the escaping, because this is a special
>character.
>Now for UTF-8, things are quite different. 8-bit bytes will
>on many occasions be escaped because it may be difficult to
>represent them otherwise. Having some character beyond ASCII
>represented with %HH (usually %HH%HH or %HH%HH%HH) can in no
>way imply that this is a special character.
>This means that any tools dealing with URNs in general will
>have no clue about where to keep the escaping, and where
>to remove it. A very exact knowledge of each NSS syntax
>would be needed.

My brain hurts, but I think I finally understand the issue.  Allow me to
restate it to see if I'm right:

The problem you are talking about arrises if the reserved character has
a UTF-8 representation of more than 1 octet.  Then, if we use %encoding
to represent the character in a literal use, there is no way of determining
from the URN whether the character is being used as a literal character
or not. 

I'll save a discussion of potential solution directions to this until I'm sure
I understand the issue.

Ryan

Date: Fri, 1 Nov 1996 13:44:31 +0000 (GMT)
From: Jon Knight <[email-masked]>
To: Martin J Duerst <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [URN] New syntax draft
Sender: [email-masked]
Reply-To: Jon Knight <[email-masked]>

On Fri, 1 Nov 1996, Martin J Duerst wrote:
> When going from ASCII to UTF-8, there are some new problems.
> For ASCII, the general assumption is that only those charcters
> that need escaping are actually escaped, and therefore that
> escaping, e.g. for "/" or whatever, shouldn't be undone.
> The above is not exactly true, indeed the "~" is often escaped
> as %7E in Europe because it is difficult to type on European
> keyboards, but still I assume there are a lot of tools around
> working on URLs in general that work along the rule "if ASCII
> is escaped, don't remove the escaping, because this is a special
> character.

Hmm, I don't really understand this; URL percent escaping is just away of
dealing with characters that you can't represent directly, either because
they're in the reserved set of characters or because they're not easy to
type (the French/German/Nordic/Icelandic letters in ISO-8859-1 for
example).  If you're unescaping things, one would assume that you've
already parsed any reserved characters to extract any structuring
information that the provide.  Percent escaped characters aren't just
restricted to the reserved characters that need to be escaped; you can
percent escape your entire URL's path if you like.  Any software that just
expects reserved characters to be percent escaped is going out of its way
to be braindead IMHO.

And anyway, URLs don't use UTF-8 so this isn't going to be a problem
(we're talking URNs here right?).

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

Subject: Re: [URN] New syntax draft
To: [email-masked]
Date: Fri, 1 Nov 1996 12:11:37 +0100 (MET)
Cc: [email-masked]
Content-Length: 1952
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Ryan Moats wrote:

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

When going from ASCII to UTF-8, there are some new problems.
For ASCII, the general assumption is that only those charcters
that need escaping are actually escaped, and therefore that
escaping, e.g. for "/" or whatever, shouldn't be undone.
The above is not exactly true, indeed the "~" is often escaped
as %7E in Europe because it is difficult to type on European
keyboards, but still I assume there are a lot of tools around
working on URLs in general that work along the rule "if ASCII
is escaped, don't remove the escaping, because this is a special
character.
Now for UTF-8, things are quite different. 8-bit bytes will
on many occasions be escaped because it may be difficult to
represent them otherwise. Having some character beyond ASCII
represented with %HH (usually %HH%HH or %HH%HH%HH) can in no
way imply that this is a special character.
This means that any tools dealing with URNs in general will
have no clue about where to keep the escaping, and where
to remove it. A very exact knowledge of each NSS syntax
would be needed.

Regards,	Martin.

Subject: Re: [URN] More on UTF-8 Decoding (was: New syntax draft)
To: [email-masked]
Date: Fri, 1 Nov 1996 11:40:57 +0100 (MET)
Cc: [email-masked], [email-masked]
Content-Length: 775
From: Martin J Duerst <[email-masked]>
Sender: [email-masked]
Reply-To: Martin J Duerst <[email-masked]>

Ryan Moats wrote:

>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 think this is a good argument for taking UTF-8 decoding out
>of the syntax document.  Any reasons to leave it in?

No, because if you "decode" UTF-8, you get characters, without saying
of how exactly they are represented, and so "decode" is definitely the
wrong name. You might consider replacing it with "interpretation",
but this is only necessary in some cases (e.g. when trying to
represent these things on sceen), and not in others.

Regards,	Martin.