Subject: [URN] comments on guidelines draft
From: "Ron Daniel, Jr." <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Thu, 19 Jun 1997 13:26:38 -0600

Hi Karen (and members of the URN list)

A few comments on the -02 version of the guidelines draft. Sorry not to
have gotten them out earlier, have had some other stuff going on.

First, I don't have any major technical problems with the draft. There
are some minor points I will get to in a bit, but they are pretty minor.

Second, I actually have a LOT of suggested editorial changes. Aside from
some spelling and grammatical errors, the draft is simply too long (>60 kB),
which may be part of the reason for the lack of comments on it. I think
there is a lot of opportunity to tighten up the draft, which I would like
to see done before asking the rest of the IETF to look at it. I'll
communicate with Karen off-list about the editorial comments.

The technical points I had are:

R1.2 says that "a hint resolution mechanism must support evolution of
     mechanisms, especially for a growing set of URN schemes [...]."
What it does not talk about is the ability to deal with finer and finer
subdivisions of any one URN scheme over time. If a namespace becomes popular,
people will end up creating more and more subdivisions of that namespace,
and resources in those subdivisions will be sold from one place to another.
This might result in a more and more complex set of rules for finding
resolvers. This is an area where I have concerns about NAPTR due to the
limited response size of DNS records. I think that it is worth mentioning
this as another form of scalability to be on the lookout for.

Second, R.2.1.4 talks about publishers needing to be able to provide both
short and long-term hints. I don't think this should be interpreted as a
requirement that RDSs make an architectural distinction between short and
long-term hints. If they have TTLs, expiry mechanisms, etc. that should
be more than good enough.

Section 3.2.1 talks about publishers switching resolver services, and states
that changing from one resolver service to another should not be an
expensive operation. At other places in the draft you talk about using pricing
as a means of controlling behavior to meet goals that advance the good of the
many. Why is changing resolvers exempted from control by pricing? (Especially
since I think it has far more impact on the NAPTR RDS than the number of
URNs inside any particular namespace).

In section 3.3 you state that "Because updates to hint information are
idempotent, at least within short periods of time, we will set aside the
problem of ordering for this analysis". Is this really true for all possible
RDS designs? I'm skeptical.

That's about it. Like I said, not a lot of technical objections.

Later,

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

From: "Arun Manchanda" <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: [URN] Re: RFC 2141 on URN Syntax
Date: Thu, 12 Jun 1997 07:14:05 PDT
Sender: [email-masked]
Reply-To: "Arun Manchanda" <[email-masked]>

>From [email-masked] Fri May  9 09:27:02 1997
>Received: by www19.w3.org (8.6.12/8.6.12) id MAA00043; Fri, 9 May 1997 
12:10:42 -0400
>Resent-Date: Fri, 9 May 1997 12:10:42 -0400
>Resent-Message-Id: <[email-masked]>
>Message-Id: <[email-masked]>
>X-Sender: [email-masked]
>X-Mailer: Windows Eudora Pro Version 3.0 (32)
>Date: Fri, 09 May 1997 10:08:42 -0600
>To: Sukanta Ganguly <[email-masked]>
>From: "Ron Daniel, Jr." <[email-masked]>
>Subject: Re: RFC 2141 on URN Syntax
>Cc: [email-masked], [email-masked]
>Mime-Version: 1.0
>Content-Type: text/plain; charset="us-ascii"
>X-List-URL: http://www.w3.org/pub/WWW/Archives/Public/w3c-dist-auth/
>X-See-Also: http://www.ics.uci.edu/~ejw/authoring
>Resent-From: [email-masked]
>X-Mailing-List: <[email-masked]> archive/latest/776
>X-Loop: [email-masked]
>Sender: [email-masked]
>Resent-Sender: [email-masked]
>Precedence: list
>
>At 08:54 AM 5/9/97 -0600, Sukanta Ganguly wrote:
>>Hi,
>>  I wanted to mention some things about the rfc 2141 that I found 
confusing.
>
>You should bring these questions up on the URN-WG list, not the
>Web DAV list. The URN list is [email-masked]. I have added it
>to the CC list on this reply.
>
>>The syntax for a URN is specified as
>><URN> ::= "urn:" <NID> ":" <NSS>
>>and NSS also has ":" as a characters recognized within the <others> 
rule.
>>Based on this
>>    URN:foo::      -> Is this a valid URN ??
>
>That will depend on the rules for the namespace foo. The URN syntax
>is an attempt to be as liberal as possible so as to allow many
>different namespaces to exist. The rules for particular namespaces
>are intended to be much stricter. As an example, take a look at
>the URN-WG's internet draft on using bibliographic identifiers as URNs.
>Two of the namespaces in that document (ISBN and ISSN) disallow the use
>of ':' and many other characters. The third (SICI) has much more
>liberal rules because SICIs use lots of funny characters.
>
>>I feel that is ":" is used as a reserved terminator of a subsection of 
a
>>rule then it should not be used in the recognized character sets for 
the
>>other sub-sections of the rule. So I would imagine that ":" is not 
present
>>as a recognizable character within the <other> rule of NSS subsection.
>
>The URN sytnax RFC takes a strong position on the first two occurances
>of ':'. After that, it is up to particular namespaces how ':' is or is 
not
>used.
>
>>It just adds an extra amount of parsing effort for the applications to 
have
>>this feature in their parsing mechanisms. I don't say that it is 
impossible
>>to have it, but as a application developer, it  would be a much messy
>>approach for me to write code that has this feature in it. I hope this 
not
>>taken as a negative criticism. 
>
>No, it is not taken as a negative criticism. However, one of the 
requirements
>on URNs was the ability to grandfather legacy naming systems (such as 
SICIs).
>If allowing ':' makes it easier to accomodate some naming schemes, then 
we
>thought it would be worth some additional implementation difficulty. 
The
>additional difficulty seems very small. The first two ':' characters 
are
>required, so once one has stripped off the "urn:" prefix and the NID
>field with its colon, no more special treatment of ':' is required for
>a general URN parser. You will probably want to use the NID to lookup
>special parsing rules for the namespace, but that is another story.
>
>
>>I have a similar concern regarding the usage of "%" character within 
the
>><NSS> subsection. This is what the rule resolution says 
>><NSS> ::= 1*<URN chars>
>><URN chars> ::= <trans> | "%" <hex> <hex>
>><trans> ::= <upper> | <lower> | <number> | <other> | <reserved>
>><reserved> ::= '%" | "/" | "?" | "#"
>>
>>Here we observe that 
>>
>>  <NSS> ::= %    could be a valid rule according to the  rule 
definition. At
>>the same time the system has another defination that says wheneever 
"%" is
>>used two  <hex> characters should be used.
>>
>>  <NSS> ::=%%12  -> could also be a valid syntax for NSS.  
>>
>>My suggestion here is to remove "%" from the <reserved> subsection of 
<NSS>
>>rules.
>>
>>Please let me know if my thinking is along the lines of what the group 
has
>>in mind or am I way out of wack.
>
>Single occurances of '%' are disallowed. '%' is supposed to ALWAYS mean
>that the next two characters will be hex digits that are taken to
>form an octet.
>
>
>>I appreciate your acceptance of my
>>participation in the group.
>>
>>Thank You
>>Sukanta Ganguly
>>
>>>>> Jim Whitehead <[email-masked]> 05/06/97 12:07PM >>>
>>
>>Of potential interest to participants of this WG.
>>
>>- Jim
>>
>>>To: IETF-Announce: ;
>>>Subject: RFC 2141 on URN Syntax
>>>Cc: [email-masked] 
>>>Mime-Version: 1.0
>>>Date: Mon, 05 May 97 13:53:28 PDT
>>>Sender:[email-masked] 
>>>From: RFC Editor <[email-masked]>
>>>
>>>
>>>A new Request for Comments is now available in online RFC libraries.
>>>
>>>
>>>        RFC 2141:
>>>
>>>        Title:      URN Syntax
>>>        Author:     R. Moats
>>>        Date:       May 1997
>>>        Mailbox:    [email-masked] 
>>>        Pages:      8
>>>        Characters: 14077
>>>        Updates/Obsoletes: None
>>>
>>>        URL:        ftp://ds.internic.net/rfc/rfc2141.txt 
>>>
>>>
>>>Uniform Resource Names (URNs) are intended to serve as persistent,
>>>location-independent, resource identifiers. This document sets
>>>forward the canonical syntax for URNs.  A discussion of both existing
>>>legacy and new namespaces and requirements for URN presentation and
>>>transmission are presented.  Finally, there is a discussion of URN
>>>equivalence and how to determine it. This document is the product of
>>>the Uniform Resource Names Working Group of the IETF.
>>>
>>>This is now a Proposed Standard Protocol.
>>>
>>>This document specifies an Internet standards track protocol for the
>>>Internet community, and requests discussion and suggestions for
>>>improvements.  Please refer to the current edition of the "Internet
>>>Official Protocol Standards" (STD 1) for the standardization state 
and
>>>status of this protocol.  Distribution of this memo is unlimited.
>>>
>>>This announcement is sent to the IETF list and the RFC-DIST list.
>>>Requests to be added to or deleted from the IETF distribution list
>>>should be sent to [email-masked].  Requests to be
>>>added to or deleted from the RFC-DIST distribution list should
>>>be sent to [email-masked].
>>>
>>>Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
>>>an EMAIL message to [email-masked] with the message body
>>>help: ways_to_get_rfcs.  For example:
>>>
>>>        To: [email-masked] 
>>>        Subject: getting rfcs
>>>
>>>        help: ways_to_get_rfcs
>>>
>>>Requests for special distribution should be addressed to either the
>>>author of the RFC in question, or to [email-masked].  Unless
>>>specifically noted otherwise on the RFC itself, all RFCs are for
>>>unlimited distribution.
>>>
>>>Submissions for Requests for Comments should be sent to
>>>[email-masked].  Please consult RFC 1543, Instructions to RFC
>>>Authors, for further information.
>>>
>>>
>>>Joyce K. Reynolds and Mary Kennedy
>>>USC/Information Sciences Institute
>>>
>>
>>
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                                                            
>>                                               
>>
>>
>>
>Ron Daniel Jr.              voice:+1 505 665 0597
>Advanced Computing Lab        fax:+1 505 665 4939
>MS B287                     email:[email-masked]
>Los Alamos National Lab      http://www.acl.lanl.gov/~rdaniel
>Los Alamos, NM, USA, 87545  
>
>

---------------------------------------------------------
Get Your *Web-Based* Free Email at http://www.hotmail.com
---------------------------------------------------------

To: [email-masked]
cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-resolution-services-01.txt
Date: Thu, 12 Jun 1997 09:33:37 -0400
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     : URI Resolution Services Necessary for URN Resolution    
       Author(s) : M. Mealling, R. Daniel
       Filename  : draft-ietf-urn-resolution-services-01.txt
       Pages     : 8
       Date      : 06/11/1997

Fetching the resource identified by a Uniform Resource Identifier (URI) [3]
is only one of the operations that can be performed on a URI. We might ask 
for a list of other identifiers that are aliases for the original URI, a 
bibliographic description of the resource the URI denotes, etc. Because of 
the diverse nature of resources on the network, it may be difficult (or 
impossible) to offer all those operations, therefore a means of indicating 
what services are and are not supported by a given resolver must be 
specified. This memo gives an initial set of those operations, and the 
requirements that must be met when those operations are encoded in a 
protocol.                                                                  

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-resolution-services-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-resolution-services-01.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  ftp.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  [email-masked]. In the body type: 
     "FILE /internet-drafts/draft-ietf-urn-resolution-services-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-resolution-services-01.txt

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

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

--OtherAccess--

--NextPart--

From: Michael Mealling <[email-masked]>
Subject: [URN] URI Resolution Services Necessary for URN Resolution
To: [email-masked]
Date: Wed, 11 Jun 1997 01:52:12 -0400 (EDT)
Sender: [email-masked]
Reply-To: Michael Mealling <[email-masked]>

Here's the draft that I just sent to the repository. Comments as usual are
welcome. Enjoy....

URN Working Group                                                   M.Mealling
INTERNET-DRAFT                                         Network Solutions, Inc.
Expires six months from June 1997                               Ron Daniel Jr.
Intended category: Standards Track              Los Alamos National Laboratory
draft-ietf-urn-resolution-services-01.txt

                           URI Resolution Services
                        Necessary 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 ds.internic.net (US East Coast), nic.nordu.net
     (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).

Abstract

Fetching the resource identified by a Uniform Resource Identifier (URI) [3]
is only one of the operations that can be performed on a URI. We might ask
for a list of other identifiers that are aliases for the original URI, a
bibliographic description of the resource the URI denotes, etc. Because of
the diverse nature of resources on the network, it may be difficult (or
impossible) to offer all those operations, therefore a means of indicating
what services are and are not supported by a given resolver must be
specified. This memo gives an initial set of those operations, and the
requirements that must be met when those operations are encoded in a
protocol.

1. Introduction

In the course of formulating current proposals [1] regarding Uniform
Resource Names [2] it became apparent that requiring servers to deal with
all desired functions or requiring clients to deal with complicated
information returned by a server was unrealistic and a barrier to adoption.
There needed to be some way for a client to be able to pick between a server
that specialized in the complex and another that specialized in the simple
(but fast). Also, in subsequent conversations it became obvious that, in
most cases, some of the operations were inappropriate or difficult for
certain identifiers. For example, ISSNs identify books or magazines that are
serial in nature. An operation to return the resource for an ISSN pointing
to "Time" magazine would result in dumping hundreds of thousands of pages of
"Time" onto a user's machine. This does not seem like a reasonable thing to
do in the normal case.

The Problem

The problem, stated simply, is one of a client needing to convey to a
service the desired operation that the client wishes to have done on a given
URI. The converse of this problem was that the server needed some way to
convey to a client which services a network entity supported.

This problem requires some well understood set of identifiers that identify
those operations. But it was also realized that an exhaustive set would both
be impossible and not very necessary. Thus, this document will list several
operations as well as lay out requirments for specifying new operations.

Historical Note: Since these services originated with the discussions
surrounding URN resolution, there needs to be a clarification about at which
point in the resoulution process these services reside. The URN resolution
framework [] uses a two step process. The first step is called a Resolution
Discovery Services or RDS. The second part is called a local resolver. The
RDS uses hints to point a client toward a local resolver which actually
answers the questions about the URI. The services described here reside at
the level of the local resolver. The identifiers are used in the RDS to
specify which local resolvers handle which services.

Also, previous versions of this document referred to services where the
arguments were specific types of URIs such as URNs or URLs. These services
were called "N2L", "L2L", etc. Their use has been deprecated here in favor
of the more general URI form.

Design Criteria

The design criteria used to meet these requirements were fairly simple. The
need to simply identify the operation with some token and know its operands,
algorithm and errors was seen as sufficient to meet the requirements.

2. General Specification

In order to provide a framework both for the specifications in this document
and for new ones to be written by others, the following requirments are
placed on any documents that seek to specify new operations.

Any specification of a member of this set of operations MUST contain at
least the following pieces of information with respect to its operands, its
algorithm, output and errors.

2.1 Operands

Must contain the following pieces of information:

   * name of the operation
   * mnemonic for the operation
   * number of operands
   * type of each operand
   * format of each operand

2.2 Algorithm

Must either specify the exact algorithm for the operation or that the
algorithm is opaque and defined by the server.

2.3 Output

Must specify one of the following:

   * there is no output
   * the output is undefined
   * the output itself and its content
   * the fact that the output is an object and the object's type and format.

2.4 Error Conditions

Must include all errors that are considered applicable across all
implementations and application environments. Errors that depend on the
system conveying the service are not included. Thus, many of the expected
errors such as syntax errors or service availability are not included in
this document since they are implementation dependent.

2.5 Security Considerations

Must specify any security considerations relating to the serivce provided.
This does NOT include considerations dealing with the protocol used to
convey the service or to those that normally accompany the results of the
service. For example, an I2L service would need to discuss the situation
where someone maliciously inserts an incorrect URL into the resolver but NOT
the case where someone sends personal information across the Internet to the
resource identified by the correct URL.

3. Encoding The Operations

To be useful these operations have to be used within some system or
protocol. In many cases these systems and protocols will place restrictions
on which operations make sense and how those that do are syntactically
represented.

Also, a given system or protocol will have its own output formats that will
restrict the output formats of a given operation. Additionally, a given
protocol may have better solution for output than the ones given here. For
example, the I2L result may be encoded in a protocol specific manner that
causes the client to treat it as special.

Thus, the requirements on encoding these operations within a given system
are the following:

   * which subset of the operations are allowed
   * how the operator is encoded
   * how the operands are encoded
   * how the error codes are returned

For those system that can use it, MIME [4] is the suggested output format.
The operations listed here use the text/uri-list Internet Media Type or IMT
[4] that is specified in Appendix A. Other system are strongly encouraged to
use this IMT. In the case where a system does not use an IMT a justification
should be given.

4. The Incomplete Set

4.1 I2L (URI to URL)

   * name: URI to URL
   * mnemonic: I2L
   * number of operands: 1
   * type of each operand: 1st operand is a URI
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * output: 1 and only one URL encoded in a text/uri-list
   * Errors Conditions:
        o No such URI
        o No URL to return
   * Security Considerations:

        o Malicious Redirection
          One of the fundamental dangers related to any service such as this
          is that a malicious entry in a resolver's database will cause
          clients to resolve the URI into the wrong URL. The intent may be
          to cause the client to retrieve a resource possibly containing
          fradulent or damaging material.
        o Denial of Service
          By removing the URL that the URI maps to, a malicious intruder may
          remove the clients ability to retrieve the resource.

This operation is used to map a single URI to a single URL. It is used by
light weight clients that do not have the ability to select from a list of
URLs or understand a Uniform Resource Characteristic (URC). The algorithm
for this mapping is dependent on the URI scheme.

4.2 I2Ls (URI to URLs)

   * name: URI to URLs
   * mnemonic: I2LS
   * number of operands: 1
   * type of each operand: 1st operand is a URI
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * output: a list of 0 or more URLs encoded in a text/uri-list
   * Errors:
        o No such URI
        o No URLs to return
   * Security Considerations:

        o Malicious Redirection (see I2L)
        o Denial of Service (see I2L)

This operation is used to map a single URI to 0 or more URLs. It is used by
a client that can pick from a list of URLs based on some criteria that is
important to the client. The client should not make any assumptions about
the order of the URLs returned.

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

4.3 I2R (URI to Resource)

   * name: URI to Resource
   * mnemonic: I2R
   * number of operands: 1
   * type of each operand: 1st operand is a URI
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * output: an instance of the resource named by the URI. Encoding is not
     specified.
   * Errors:
        o No such URI.
        o No resource available.
   * Security Considerations:

        o Malicious Redirection (see I2L)
        o Denial of Service (see I2L)

This operation is used to return a single instance of the resource that is
named by the URI. The format of the output is dependent on the resource
itself.

4.4 I2Rs (URI to Resources)

   * name: URI to Resources
   * mnemonic: I2Rs
   * number of operands: 1
   * type of each operand: 1st operand is a URI
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * output: 0 or more instances of the resource named by the URI. Encoding
     is not specified.
   * Errors:
        o No such URI.
        o No resource available.
   * Security Considerations:

        o Malicious Redirection (see I2L)
        o Denial of Service (see I2L)

This operation is used to return 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 URI.

The output shall be a MIME multipart/alternative [4] message with the
alternative versions of the resource in separate body parts. If there is
only one version of the resource identified by the URN, it MAY be returned
without the multipart/alternative wrapper.

4.5 I2C (URI to URC)

   * name: URI to URC
   * mnemonic: I2C
   * number of operands: 1
   * type of each operand: 1st operand is a URI
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * output: A Uniform Resource Characteristic. Encoding is not specified.
   * Errors:
        o No such URI.
        o URC not available.
   * Security Considerations:

        o Malicious Redirection (see I2L)
        o Denial of Service (see I2L)

URCs (Uniform Resource Characteristics) are descriptions of other resources.
This request allows the client to obtain a description of the resource
identified by a URI, as opposed to the resource itself or simply the
resources URLs. 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
server to another.

4.6 I2CS (URI to URCs)

   * name: URI to URCs
   * mnemonic: I2CS
   * number of operands: 1
   * type of each operand: 1st operand is a URI
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * output: 0 or more Uniform Resource Characteristic. Encoding is not
     specified.
   * Errors:
        o No such URI.
        o URCs not available.
   * Security Considerations:

        o Malicious Redirection (see I2L)
        o Denial of Service (see I2L)

URCs can come in different formats and types. This operation returns 0 or
more URCs that are appropriate for the given URI.

4.7 I2N (URI to URN)

   * name: URI to URN
   * mnemonic: I2N
   * number of operands: 1
   * type of each operand: 1st operand is a URN
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * output: One URN encoded in a text/uri-list IMT.
   * Errors:
        o No such URI.
        o No URN considered equivalent at this time.
   * Security Considerations:

        o Malicious Redirection (see I2L)
        o Denial of Service (see I2L)

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 one organization wishes to name 'foo'. Another organization,
in agreement with the first, wants to call the resource 'bar'. Both
organizations can agree that both names 'name' the same resource and that
the URNs 'foo' and 'bar' are equivalent.

The result a URN, known to the server, which identifies the same resource as
the input URN. The result shall be encoded in a text/uri-list IMT.

Extreme care should be taken with this service as it toys with the idea of
equality with respect to URNs. As mentioned in several URN documents the
idea of equality is very domain specific. For example, a URN pointing to a
weather map for a particular day and a URN pointing to the the map as it
changes from day to day would NOT by returned in this example because they
point to do different resources. Some other concept of equality is at work.
This service instead deals with resources that have two different names
where the binding between the names and resources is permanent.

4.8 I2Ns (URI to URNs)

   * name: URI to URNs
   * mnemonic: I2NS
   * number of operands: 1
   * type of each operand: 1st operand is a URI
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * output: A list of URNs encoded in a text/uri-list IMT.
   * Errors:
        o No such URI.
        o No URNs considered equivalent at this time.
   * Security Considerations:

        o Malicious Redirection (see I2L)
        o Denial of Service (see I2L)

This operation simply returns 0 or more URNs following the same criteria and
cautions as the I2N operation.

4.9 I2I (URI to URI):

   * name: URI to URI
   * mnemonic: I2I
   * number of operands: 1
   * type of each operand: 1st operand is a URL
   * format of each operand: 1st operand is encoded as a URI
   * algorithm: opaque
   * output: A URI.
   * Errors:
        o No such URI.
        o No URIs considered equivalent at this time.
   * Security Considerations:

        o Malicious Redirection (see I2L)
        o Denial of Service (see I2L)

This operation is used to map any arbitrary URI to any other arbitrary URI.
No other assertions are made about whether or not the URI exhibits
characteristics of URNs or URLs.

4.10 I=I (Is URI equal to URI):

   * name: URI = URI
   * mnemonic: I=I
   * number of operands: 2
   * type of each operand: Both operands are URIs
   * format of each operand: both operands are encoded as a URIs
   * algorithm: opaque
   * output: TRUE or FALSE
   * Errors:
        o No such URI.
        o No URIs considered equivalent at this time.
   * Security Considerations:

        o Malicious Redirection (see I2L)
        o Denial of Service (see I2L)

This operation is used to determine whether two given URIs are considered to
be equal by the server being asked the question. The algorithm used to
determine equality is opaque. No assertions are made about whether or not
the URIs exhibits characteristics of URNs or URLs.

6. The text/uri-list Internet Media Type

     [This section 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 I2Ls, I2Ns, result in a
list of URIs being returned to the client. The text/uri-list Internet Media
Type is defined to provide a simple format for the automatic processing of
such lists of URIs.

The format of text/uri-list resources is:

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

In applications where one URI has been mapped to a list of URIs, such as in
response to the I2Ls 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 I2L 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
             --------------------------------------------------

7. References

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

[2] R. Moats, "URN Syntax", RFC2141, Jan. 1997.

[3] RFC 1630, "Universal Resource Identifiers in WWW: A Unifying Syntax for
    the Expression of Names and Addresses of Objects on the Network as
    used in the World-Wide Web", T. Berners-Lee, June 1994.

[4] RFC 1521, "MIME (Multipurpose Internet Mail Extensions) Part One:
    Mechanisms for Specifying and Describing the Format of Internet Message
    Bodies", Borenstein, N. and and N. Freed, Bellcore, Innosoft,
    September 1993.

8. Security Considerations

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

9. Author Contact Information

Michael Mealling
Network Solutions
505 Huntmar Park Drive
Herndon, VA 22070
voice: (703)742-0400
fax: (703)742-9552
email: [email-masked]

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

Date: Tue, 10 Jun 1997 16:43:38 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: Ryan Moats <[email-masked]>
cc: [email-masked]
Subject: Re: [URN] Second draft (-01) of IETF namespace document
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

One point of confusion that someone related to me about this document
was the fact that it refers to RFCs and FYIs, etc, but not I-D's.

It would perhaps be worth adding a paragraph, as an overview, indicating
that because URNs are meant to be persistent identifiers, to persistent
resources, I-D's are not included because they expire after 6 months...

Leslie.

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

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

Date: Tue, 10 Jun 1997 16:39:18 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: [email-masked]
Subject: [URN] WG Last Call:  Guidelines & Framework document
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

Karen Sollins' "Guidelines and a Framework for URN Resolution Systems"
document  has now been circulated for almost a week without comment
on this mailing list.

Pursuant to what was agreed at the Memphis meeting, if there are no
further issues with this document, we should put it forward as an
informational RFC.

So, if there are no further comments by the end of next week (June 20),
I'll forward it to the Area Directors for movement.

Thanks,
Leslie.

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

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

To: [email-masked]
cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-ietf-01.txt
Date: Tue, 10 Jun 1997 10:30:16 -0400
Sender: [email-masked]
Reply-To: [email-masked]

--NextPart

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

       Title     : A URN Namespace for IETF Documents                      
       Author(s) : R. Moats
       Filename  : draft-ietf-urn-ietf-01.txt
       Pages     : 4
       Date      : 06/09/1997

A system for Uniform Resource Names (URNs) must be capable of supporting 
new naming systems.  As an example of the sort of information that needs to
be supplied when proposing new namepsaces, this document presents a naming 
system based on the RFC family of documents (RFCs, STDs, and FYIs) 
developed by the IETF and published by the RFC editor and the minutes of 
working groups (WG) and birds of a feather (BOF) meetings that occur during
IETF conferences.  This namespace can be supported within the URN framework
and the currently proposed syntax for URNs.                                

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-ietf-01.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-ietf-01.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  ftp.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  [email-masked]. In the body type: 
     "FILE /internet-drafts/draft-ietf-urn-ietf-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-ietf-01.txt

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

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

--OtherAccess--

--NextPart--

Date: Mon, 9 Jun 1997 13:11:20 -0400
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
CC: [email-masked], [email-masked]
Subject: Re: [URN] Second draft (-01) of IETF namespace document
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

Hi Ryan,

Your draft does exactly what we've said in the past, but it suggests
to me a topic that I think ought to be addressed.  You address the
issue of equivalent urns, but there is the other side of this.  The
issue is the determination of when a urn is assigned (when is a new
document created vs. an old one being modified).  For RFCs there are
two things.  First, the documents are immutable, so if one wants to
modify the document, it will need a new urn.  Second, the decision
about when an id and therefore urn is allocated is in the hands of
some combination of the IESG and the RFC editor.  So, these are things
it would probably be useful to say about this namespace.

In the URN requirements RFC we were clear about not being able to say
anything thing specific about these issues of equality, because we
couldn't say anything applicable to all of them.  But hopefully for
each we should be able to be specific.

I don't think this is a major addition to your paper, just a brief
paragraph somewhere appropriate.

			Karen

Date: Mon, 09 Jun 1997 08:48:03 -0500
From: Ryan Moats <[email-masked]>
Organization: InterNIC Directory and Database Services
To: [email-masked]
CC: [email-masked]
Subject: [URN] Second draft (-01) of IETF namespace document
Sender: [email-masked]
Reply-To: Ryan Moats <[email-masked]>

Internet-Draft                                                Ryan Moats
draft-ietf-urn-ietf-01.txt                                          AT&T
Expires in six months                                          June 1997

                   A URN Namespace for IETF Documents
                  Filename: draft-ietf-urn-ietf-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

   A system for Uniform Resource Names (URNs) must be capable of
   supporting new naming systems.  As an example of the sort of
   information that needs to be supplied when proposing new namepsaces,
   this document presents a naming system based on the RFC family of
   documents (RFCs, STDs, and FYIs) developed by the IETF and published
   by the RFC editor and the minutes of working groups (WG) and birds of
   a feather (BOF) meetings that occur during IETF conferences.  This
   namespace can be supported within the URN framework and the currently
   proposed syntax for URNs.

1. Namespace Syntax

   Consistent with the URN syntax specification [1], each namespace must
   specify syntax related information that is specific to that
   namespace.  This section covers these specifications.

Expires 12/31/97                                                [Page 1]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1997

1.1. Namespace Identifier (NID)

   The namespace identifier for this namespace is "ietf".

1.2. Namespace Specific String (NSS)

   The Namespace Specific String has the following ABNF [2]
   specification:
           NSS = (family ":" number) / ("mtg-" number "-" wgbofname)

           family = "rfc" / "std" / "fyi"

           number = 1*DIGIT

           wgbofname = 1*LETDIGIT

           LETDIGIT = DIGIT / %x41..%x5a / %x61..%x7a

           DIGIT = %x30..%x39

   The ABNF specification for "family" is based on the current documents
   in the RFC family.  As new document series are added to the IETF
   family by the IESG (or its successor), this ABNF specification will
   need to be updated.  Any system intended to resolve names for this
   namespace should be written with the awareness that a new document
   series may be introduced at any time.

   The ABNF specification for "wgbofname" is based on the current and
   past abbreviations for working groups and BOFs in the IETF.  If a
   working group or BOF is created that used characters outside the
   range of this ABNF specification, this specification will need to be
   update. Any system intended to resolve names for this namespace
   should be written with the awareness that this could occur at any
   time.
1.3. Additional Reserved Characters

   No characters in addition to those specified in [1] are reserved by
   this namespace.

1.4. Additional Lexical Equivalence Relations

   Note that the entire URN is case-insensitive, because of the
   definition of the NSS.

1.5. Functional Equivalence Relations

   Rules for equivalence in this namespace are embedded in the document
   mappings maintained by the RFC Editor (the index files "rfc-

Expires 12/31/97                                                [Page 2]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1997

   index.txt", "fyi-index.txt", "std-index.txt").  A resource is
   equivalent to the set of resources implied by the "(Also...)"
   construct in these mappings.  As an example, the URN
   "urn:ietf:rfc:1661" is equivalent to th URN "urn:ietf:std:51" because
   the "rfc-index.txt" map shows that RFC 1661 is also STD 51.  However,
   the URN "urn:ietf:std:51" is equivalent to the SET of URNs
   "urn:ietf:rfc:1661" and "urn:ietf:rfc:1662" since the "std-index.txt"
   shows that STD 51 is also RFC 1661 and RFC 1662.  Therefore, a
   resolver receiving a N2R request for "urn:ietf:std:51" MUST return
   either STD 51 or BOTH RFC 1661 and RFC 1662.

2. Security Considerations

   Because this namespace defines no additional reserved characters, it
   does not add any security considerations beyond those inherent from
   the existence of the reserved characters from [1].  Further, the
   definition of the NSS above does not use any of the reserved
   characters from [1], which means that resolvers for this namespace
   may be considered "secure" in the sense that any escaping of
   characters in the NSS MUST result in the resolver indicating that the
   URN has incorrect syntax.

3. Acknowledgments

   Thanks to various members of the URN working group for comments on
   earlier drafts of this document.  The work described in this document
   is partially supported by the National Science Foundation,
   Cooperative Agreement NCR-9218179.

4. References

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

         [1]         R. Moats, "URN Syntax," RFC 2141, May 5, 1997.

         [2]         D. Crocker, P. Overell, "Augmented BNF for Syntax
                     Specifications: ABNF," Internet Draft (work in pro-
                     gress), January 1997.

5. Author's Address

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

Expires 12/31/97                                                [Page 3]

INTERNET DRAFT     A URN Namespace for IETF Documents          June 1997

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

              This Internet Draft expires December 31, 1997.

Expires 12/31/97                                                [Page 4]

To: [email-masked]
cc: [email-masked]
From: [email-masked]
Subject: [URN] I-D ACTION:draft-ietf-urn-req-frame-02.txt
Date: Thu, 05 Jun 1997 09:59:08 -0400
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     : Guidelines and a Framework for URN Resolution Systems   
       Author(s) : K. Sollins
       Filename  : draft-ietf-urn-req-frame-02.txt
       Pages     : 19
       Date      : 06/04/1997

This document addresses the issues of the discovery of URN resolver 
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 guidelines in order to be a viable Resolver Discovery Service or RDS to
help in finding URN resolvers, and a framework for designing RDSs.  The 
guidelines fall into three major areas: evolvability, usability, and 
security and privacy.  An RDS that is compliant with the framework will not
necessarily be compliant with the guidelines.  Compliance with the 
guidelines 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-02.txt".
A URL for the Internet-Draft is:
ftp://ds.internic.net/internet-drafts/draft-ietf-urn-req-frame-02.txt
 
Internet-Drafts directories are located at:	
	                                                
     o  Africa:  ftp.is.co.za                    
	                                                
     o  Europe:  ftp.nordu.net            	
                 ftp.nis.garr.it                 
	                                                
     o  Pacific Rim: munnari.oz.au               
	                                                
     o  US East Coast: ds.internic.net           
	                                                
     o  US West Coast: ftp.isi.edu               
	                                                
Internet-Drafts are also available by mail.	
	                                                
Send a message to:  [email-masked]. In the body type: 
     "FILE /internet-drafts/draft-ietf-urn-req-frame-02.txt".
							
NOTE: The mail server at ds.internic.net can return the document in
      MIME-encoded form by using the "mpack" utility.  To use this
      feature, insert the command "ENCODING mime" before the "FILE"
      command.  To decode the response(s), you will need "munpack" or
      a MIME-compliant mail reader.  Different MIME-compliant mail readers
      exhibit different behavior, especially when dealing with
      "multipart" MIME messages (i.e., documents which have been split
      up into multiple messages), so check your local documentation on
      how to manipulate these messages.

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

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

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

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

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

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

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

--OtherAccess--

--NextPart--

Date: Wed, 04 Jun 1997 18:42:09 +0200
From: Pierre Fernique <[email-masked]>
To: [email-masked]
Subject: [URN] URN resolver and GLU system
Sender: [email-masked]
Reply-To: Pierre Fernique <[email-masked]>

Dear IETF-WG URN members,

I read with a great interest the recent documents about the scheme  of
an URN resolution system and I think our work could be of some interest
for you about the functionalities and capabilities we have implemented
for such a system.

Since one year, our laboratory (the CDS - Centre de Donnees
astronomiques de Strasbourg) has been developping a URL resolver for the
interoperability  between its own and partner httpd servers. I think
it's certainly quite similar to ``a RDS'' in the recent IETF-URN
documents.

This system has been called: the GLU for (Generateur de Liens
Uniformes). If you want to see how it works, you can try the URL:
http://simbad.u-strasbg.fr/demo/glu.html

We have just implemented a GLU RDS according to your concepts. You can
try this ``mini-glurds'':
http://simbad.u-strasbg.fr/demo/cgi-bin/glurds.pl?urn:glu:ADS'adsmgr'ads.fullpaper+1995PASP..107...22H
which resolve this URN prototype:
urn:glu:ADS'adsmgr'ads.fullpaper+1995PASP..107...22H.
In practise, for higher performances, we use it quite differently, not
in a way of a HTTP-Browser urn resolution (like above), but in terms of
urn resolutions between cooperated httpd servers, at the level of cgi
programs.

If you are interest by the mechanism of the GLU system, send me a mail.
We would also be interest if you know of other efforts in implementing
such tools.

-- 

Pierre Fernique

Observatoire Astronomique de Strasbourg
11 rue de l'Universite
67000 STRASBOURG
Tel : +33 3 88.15.07.66
Email : [email-masked]

Date: Wed, 4 Jun 1997 10:12:09 -0400 (EDT)
From: Leslie Daigle <[email-masked]>
To: [email-masked], [email-masked], "Ron Daniel, Jr." <[email-masked]>
cc: [email-masked]
Subject: Re: [URN] URN resolution services question
Sender: [email-masked]
Reply-To: Leslie Daigle <[email-masked]>

On Tue, 3 Jun 1997, Ron Daniel, Jr. wrote:

> Harald, Leslie - any comments on redoing THTTP before it actually
> appears as an RFC?

Yeah, Harald used Strong Terminology when we had some edits to the Syntax
document.  Things are turning around off the RFC-editor plate pretty
quickly these days, and it is _not_ appreciated when documents go through
last call (and THTTP has gotten at least that far).

Unless there are different rules because this is an "experimental" RFC
and not Standards Track (as the Syntax document was), I believe we
have to wait until we have a document that is meant to "obsolete" the
existing one.  I think there are better ways of handling this situation,
just now.

Any comments, Harald?

Leslie.

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

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

Date: Tue, 3 Jun 1997 18:59:43 -0400
From: "Karen R. Sollins" <[email-masked]>
To: [email-masked]
Subject: [URN] new version of guidelines
Sender: [email-masked]
Reply-To: "Karen R. Sollins" <[email-masked]>

Attached is the draft of what used to be "requirements", but is now
called "guidelines", as agreed in Memphis.  It should show up on
Internet Drafts some day very soon.  Has been submitted.

			Karen

__________

Internet Draft                                          Karen R. Sollins
draft-ietf-urn-req-frame-02.txt                                  MIT/LCS
Expires December 4, 1997                                    June 4, 1997

	Guidelines 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 URN resolver
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 guidelines in order to be a viable Resolver Discovery
Service or RDS to help in finding URN resolvers, and a framework for
designing RDSs.  The guidelines fall into three major areas:
evolvability, usability, and security and privacy.  An RDS that is
compliant with the framework will not necessarily be compliant with the
guidelines.  Compliance with the guidelines 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 Resolver Discovery Service (RDS), a service to
help in the learning about URN resolvers.  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],

                               - 1 -

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.  By location, we
mean fully-qualified Domain Names or IP addresses.  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 HFNs 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.

URNs as described in RFC 1737 are defined globally; they are ubiquitous
in that a URN anywhere in any context identifies the same resource.
With respect to an RDS we must ask what URN ubiquity implies for the RDS
and for resolution in general.  But in terms of Internet services and
accessibility, there can be no systematic guarantees.  In addition, it
is quite possible that the resolution of a URN to an instance of a
resource may reach different instances or copies under different
conditions.  Thus, although a URN anywhere refers to the same resource,
in some locations under some conditions, and at different times, due to
either the vagueries of network conditions or policy controls a URN may
sometimes be resolvable and other times or places not.  Ubiquitous
resolution cannot be assumed simply because naming is ubiquitous.  On
the other hand wide deployment and usage will be an important feature of
any RDS design.

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; we map URNs to hints as an
interim stage in accessing a resource.  A hint may also have
meta-information associated with it, such as an expiration_time or
certification of authenticity.  We expect that these will stay with a
hint rather than being managed elsewhere.  We will assume in all further
discussion of hints that they include any necessary meta-information as
well as the hint information itself.  Examples of hints are: 1) the name
of a resolver service that may further resolve the URN, 2) the address
of such a service, 3) a location at which the resource was previously

                               - 2 -

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.  We must 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 resolver service has taken over the 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, an RDS, 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, an RDS 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.  There are
three general assumptions:
   * URNs are persistant;
   * URN assignment can be delegated;
   * Decisions can be made independently, enabling isolation from decisions 
     of one's peers.

The next section lays out the guidelines for a Resolver 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 n RDS is adequate or not.  To summarize, there are
three core rubrics, each of which is refined and subdivided below:
   R1) An RDS must allow for evolution and evolvability;
   R2) Usability of an RDS with regard to each of the sets of constituents 
       involved in the identification and location or resources is paramount;
   R3) It is centrally important that the security and privacy needs of all 
       consituents be feasibly supported, to the degree possible.
       
It is important to note that the origins of this document were as a
requirements document.  Therefore it retains its flavor of a requirments
documents including the use of "must" and "should".  The consensus of
the working group currently is that more experience is needed before it
can have the confidence necessary to be explicit about requirements for
RDSs.  Hence the document is worded in terms of "guidelines" and
"rubrics", with the understanding that anyone any proposal for an RDS
design should still measure up to the statements in this document, based
on the accrued knowledge and experience of a group that has been working
in this area for a number of years.  Any RDS proposal should document
how it addresses each of the rubrics.  If it does not adequately address
any of them, it should document the reasoning behind it, so that the
community can learn from that experience, with the intention of defining
a set of requirements in the future.

                               - 3 -

For the reader short on time, each of the three major subsections of the
guidelines section begins with a summary list of the more detailed
guidelines identified in that section.  The final section of the
document lays out a framework for such RDSs.  The purpose of this last
section is to bound the search space for RDS schemes.  One must be
careful not to assume that because an RDS scheme fits within the
framework that it necessarily meets the guidelines.  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 guidelines 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.  "Evolution" 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 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 RDS, meaning that hint discovery and resolution will be
partitioned and delegated.  In some RDS schemes, the delegation of
naming authority will form a basis for delegating the management and
dispensing of location information.

                               - 4 -

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 resolver services, independently of choices made by others.
At any given time, the owner of a namespace may choose a particular URN
resolver service for that delegated namespace.  Such a URN resolver
service may be outside the RDS service model, and just identified or
located by the RDS service.  Second, it must be possible to make a
choice among RDS 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 RDS
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 RDSs.  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 RDS
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.

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 guidelines for a Resolver Discovery Service.

3. Guidelines

The guidelines or rubrics applying to a Resolver Discovery Service or
RDS center around three important design goals: evolvability, usability,
and security and privacy.  At its core the function of an RDS 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

                               - 5 -

initial implementations support every guideline, every implementation
must support evolution to systems that do support every rubric.

It is important to note that there are requirements, not applicable
specifically to an RDS 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 guidelines
below because they are not guidelines or requirements for an RDS, but
rather are requirements for naming schemes themselves.

Each section below begins with a summary of the points made and
discussed in the following discussion.  It is worth noting here that
there is some degree of overlap among the areas, such as in allowing for
the evolution of security mechanisms, etc.  Issues may appear in more
than one place.  It is also important to recognize that conformance with
the rubrics may often be subjective.  Most of these rubrics are not
quantifiable and hence conformance is a judgment call and a matter of
degree.  Lastly, the reader may find that some of them are those of
general applicability to distributed systems and some are specific to
URN resolution.  Those of general applicability are included for
completeness and are not distinguished as such.

3.1 Evolution

The issues in the area of evolvability are:

   R1.1) An RDS must be able to support scaling updwards both in terms
         of the number of resources for which URNs will be required and
         in terms of the number of publishers and users of those
         resources;

   R1.2) A hint resolution environment must support evolution of 
         mechanisms, specifically for:
         * a growing set of URN schemes;
         * new kinds local URN resolver services;
         * new authentication schemes;
         * alternative RDS schemes active simultaneously;
   R1.3) An RDS must be capable of supporting the separation of global 
         identification from location information; 
   R1.4) An RDS must allow the development and deployment of
         administrative control mechanisms to manage human behavior with
         respect to limited resources. 

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

                               - 6 -

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, scaling is a primary issue in conjunction with evolution.  The
number of users and publishers is certainly on an increasing trajectory.
One might consider that it has an upper limit based on the population,
but that assumes that resources are only published by and for the use of
humans.  As our world becomes more automated, more "users" will be
electronic.  In addition, clearly the number of resources will grow by
orders of magnitude.  Hence the number of URNs will also increase
similarly.  These facts mean that an RDS design must be prepared to
handle increasing numbers of requests for inclusion, update and
resolution.  This is not to say that there will necessarily be more
updates or resolutions per URN; we cannot predict that at this time.
Any design is likely to perform less well above some set of limits, so
it is worth considering the growth limitations of each design
alternative.

Second, 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
structure of the URN. The intention is that URN schemes can be 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 kinds of resolver services may evolve.
For example, one can imagine a specialized resolver 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 resolver 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, for example.  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

                               - 7 -

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 RDS scheme initially, we must be prepared for that top level
model to evolve.  Thus, if the RDS 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 location information 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.
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 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. Location
information was embedded in the identifier, and the resolution system
was designed to depend on that location information being correct.
There are few cases in which we can expect such information 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.  To the extent that an RDS scheme supports the separation of
global identification from location information it will be encouraging
the longer utility of the identities.

A third evolutionary issue 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 use of 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

                               - 8 -

be in short supply, some form of policy controls will always be
necessary.  Some policy controls may be realized as mechanisms within
the servers or in the details of protocols, while others may only be
realized externally to the system.  For example, suppose hint entries
are being submitted in such volume that the hint servers are using up
their excess 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.  We can also imagine administrative policy controls with
the force of laws or other social pressures behind them, but with no
technical mechanism enforcing or enabling them.  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.

3.2 Usability and Feature Set Issues

To summarize, the usability rubrics fall into three areas based on
participation in hint management and discovery:

   R2.1) The publisher
      R2.1.1) URN to hint resolution must be correct and efficient with
              very high probability;
      R2.1.2) Publishers must be able to select and move among URN 
              resolver services to locate their resources;
      R2.1.3) Publishers must be able to arrange for multiple access
              points for their location information;
      R2.1.4) Publishers should be able to provide for both long-lived
              and short-lived hints;
      R2.1.5) It must be relatively easy for publishers to specify to
              the management and observe their hint information as well
              as any security constraints they need for their hints.
   R2.2) The client
      R2.2.1) The interface to the RDS must be simple, effective, and
              efficient;
      R2.2.2) The client and client applications must be able to
              understand the information stored in and provided by the
              RDS easily, in order to be able to make informed choices.
   R2.3) The management
      R2.3.1) The management of hints must be as unobtrusive as
              possible, avoiding using too many network resources;
      R2.3.2) The management of hints must allow for administrative
              controls that encourage certain sorts of behavior deemed
              necessary to meet other requirements;
      R2.3.3) The configuration and verification of configuration of
              individual RDS servers must be simple enough not to
              discourage configuration and verification.

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

                               - 9 -

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 an RDS 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 with
very high probability.  Publishers 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 resolver services, the
architecture for resolver services specified within the IETF should not
result in a scenario in which changing from one resolver service to
another is an expensive operation.

The publisher must be able to arrange for multiple access points to a
published resource.  For this to be useful, resolver 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
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
location information about accessing the resource.  Long term
information is likely to be such information as the long term or the
location or identity of a resolver service with which the publisher has
a long term relationship.  One can imagine that the arrangement with
such a long term "authoritative" resolver 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 RDS
mechanism, it must be easy and straightforward for them 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 with them easily.

                               - 10 -

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 RDS 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
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 an RDS.  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 an RDS.  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 in Section 3.3 below.

The management of hints must be as unobtrusive as possible. First, its
infrastructure (hint storage servers and distribution protocols) must
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 may need to be
a system for administrative incentives and disincentives such as pricing
or legal restrictions.  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, any

                               - 11 -

administrative 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,
behavior benefitting the community as a whole 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 issue 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 RDS.  For example, it should be straightforward to
bring up a server and verify that the data it is managing is correct.
Although this is not a rubric, it is worth nothing that since we are
discussing a global and probably growing service, encouraging volunteer
participants suggests 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.

3.3 Security and Privacy Issues

In summary, security and privacy rubrics can be identified as some
degree of protection from threats.  These rubrics are all stated in
terms of possibilities or options for users of the service to require
and utilize.  Hence they address the availability of functionality, but
not for the use of it.  We recognize that all security is a matter of
degree and compromise.  These may not satisfy all potential customers,
and there is no intention here to prevent the building of more secure
servers with more secure protocols to suit their needs.  These are
intended to satisfy the needs of the general public.

   R3.1) It must be possible to create authoritative versions of a hint
         with access-to-modification privileges controlled;
   R3.2) It must be possible to determine the identity of servers or
         avoid contact with unauthenticated servers;
   R3.3) It must be possible to reduce the threat of denial of service
         by broad distribution of information across servers.
   R3.4) It must be possible within the bounds of organization policy
         criteria to provide at least some degree of privacy for
         traffic. 
   R3.5) It must be possible for publishers to keep private certain
         information such as an overall picture of the resources they
         are publishing and the identity of their clients;
   R3.6) It must be possible for publishers to be able to restrict
         access to the resolution of the URNs for the resources they
         publish, if they wish. 

When one discusses security, one of the primary issues is an enumeration
of the threats being considered for mitigation.  The tradeoffs often

                               - 12 -

include cost in money and computational and communications resources,
ease of use, likelihood of use, and effectiveness of the mechanisms
proposed.  With this in mind, let us consider a set of threats.

A good place to begin is with the early work of Voydock and Kent [VK83].
They identify unauthorized release of information as a passive attack.
On the other hand, unauthorized modification of information, denial of
service, and spurious association initiation are labelled as active
attacks.  An intruder at any protocol layer can attack at any of the
links or computational elements (hosts, routers, etc.)  at that layer.
Attacks at one layer can be achieved by subverting or attacking the
lower layers.  An unauthorized release of information is a violation of
privacy or confidentiality.  This may be achieved by a release of the
information itself.  Additional passive threats are from secondary
information through traffic analysis or other violations of transmission
security, such as noticing lengths and/or sources and destinations of
traffic.  Moving to the active threats, unauthorized modification of
information can be partitioned into problems with authenticity,
integrity and ordering.  Denial of service may take the form of
discarding information before it reaches its destination or some degree
of delay in delivering information.  Finally, spurious association may
occur when a previous legitimate association initiation is played back
or an initiation is made under false identity.  Security measures may
take the form of either detection or prevention of each of these
threats.  Within the scope of this work, we must identify those threats
that are both of concern and that we expect to be able to mediate.

Of these threats, the passive threats to privacy or confidentiality and
the active threats of authenticity and integrity are probably the most
important to consider here.  To the extent that spurious association
causes threats to the privacy, authenticity, or integrity with respect
to information within servers managing data, it is also important.
Because updates to hint information are idempotent, at least within
short periods of time, we will set aside the problems of ordering for
this analysis.  Denial of service is probably the most difficult of
these areas of threats both to detect and to prevent, and we will
therefore set it aside for the present as well, although it will be seen
that solutions to other problems will also mitigate some of the problems
of denial of service.  Furthermore, because this is intended to be
provide a global service to meet the needs of a variety of communities,
the engineering tradeoffs will be different for different clients.
Hence the rubrics are stated in terms of, "It must be possible..."  It
is important to note that the information of concern here is hint
information, which by nature is not guaranteed to be correct or
up-to-date; therefore, it is unlikely to be worth putting too much
expense into the correctness of hints, because there is no guarantee
that they are still correct anyway.  But the exact choice of degree of
privacy, authenticity, and integrity must be determined by the needs of
the client and the availability of services from the server.

To avoid confusion it is valuable to highlight the meanings of temrs
that have different meanings in other contexts.  In this case, the term
"authoritative" as it is used here connotes the taking of an action or
stamp of approval by a principal (again in the security sense) that has
the right to perform such an act of approval.  It has no implication of
correctness of information, but only perhaps an implication of who

                               - 13 -

claimed it to be correct.  In contrast, the term is often also used
simply to refer to a primary copy of a piece of information for which
there may also be secondary or cached copies available.  In this
discussion of security we use the former meaning, although it may also
be important to be able to learn about whether a piece of information is
from a primary source or not and request that it be primary.

It is also important to distinguish various possible meanings for
"access control."  There are two areas in which distinctions can be
made.  First, there is the question of the kind of access control that
is being addressed, for example, in terms of hints whether it is read
access, read and modify access, or read with verification for
authenticity.  Second, there is the question of to what access is being
controlled.  In the context of naming it might be the names themselves
(not the case for URNs), the mapping of URNs to hints (the business of
an RDS), the mapping of URNs to addresses (not the business of an RDS as
will be discussed below in terms of privacy), or the resource itself
(unrelated to naming or name resolution at all).  We attempt to be clear
about what is meant when using "access control."

There is one further issue to address at this point, the distinction
between mechanism and policy.  In general, a policy is realized by means
of a set of mechanisms.  In the case of an RDS there may be policies
internal to the RDS that it needs to have supported in order to do its
business as it sees fit.  Since, in general it is in the business of
storing and distributing information, most of its security policies may
have to do with maintaining its own integrity, and are rather limited.
Beyond that, to the degree possible, it should impose no policy on its
customers, the publishers and users.  It is they that may have policies
that they would like supported by the RDS.  To that end, an RDS should
provide a spectrum of "tools" or mechanisms that the customers can cause
to be deployed on their behalf to realize policies.  An RDS may not
provide all that is needed by a customer.  A customer may have different
requirements within his or her administrative bounds than outside.
Thus, "it must be possible..."  captures the idea that the RDS must
generally provide the tools to implement policies as needed by the
customers.

The first approach to URN resolution is to discover local hints.  In
order for hints to be discovered locally, they will be as widely
distributed to what is considered to be local for every locale.  The
drawback of such wide distribution is the wide distribution of updates,
causing network traffic problems or delays in delivering updates.  An
alternative model would concentrate hint information in servers, thus
requiring that update information only be distributed to these servers.
In such a model the vulnerable points are the sources of the information
and the distribution network among them.  Attackers on the integrity of
the information stored in a server may come in the form of other a fake
owner of the information or a fake server to the extent that servers
exchange updates with each other.  Wide replication of information among
servers increases the difficult of masquerading at all the locations of
the information as well as reducing the threat of denial service.  These
lead us to three identifiable goals for our security model:

                               - 14 -

* ACCESS CONTROL ON HINTS: It must be possible to create an
  authoritative version of each hint with 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 should 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 unvalidated information, the client should assume that the hint
  may be inaccurate and confirmation of the data might be sought from
  more reliable but less accessible sources.

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

Privacy is a more difficult problem to address.  It may be a
double-edged sword; for example, an organization may consider it
critically important that its competitors not be able to read its
traffic, while it may also consider it important to be able to monitor
exactly what its employees are transmitting to and from whom, for a
variety of reasons such as reducing the probability that its employees
are giving or selling the company's secrets to verifying that employees
are not using company resources for private endeavor.  Thus, although
there are likely to be needs for privacy and confidentiality, what they
are, who controls them and how, and by what mechanisms vary widely
enough that it is difficult to say anything concrete about them here.

The privacy of publishers is much easier to safeguard.  Since they are
trying to publish something, in general 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 would 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 (in the sense of "primary) URN resolver
server.  URN resolver 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

                               - 15 -

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).  Thus, access control over URN resolution can and
should be provided by resolver servers rather than an RDS.

4. The Framework

With these assumptions and guidelines in mind, we can conclude with a
general framework within which RDS designs can fall.  As stated earlier,
although this framework is put forth as a suggested guide for RDS
designers, compliance with it will in no way guarantee compliance with
the rubrics.  Such an evaluation must be performed separately.  It is
also understood that there may be RDS services that do not meet the
guidelines 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 issues 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 a documented in RFC-2141[RFC2141].  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 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 RDS 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) is to be used to identify the first

                               - 16 -

level server to be contacted.  At each stage of the lookup either a new
rule for generating the strings used in yet another lookup (the strings
being the identity of another RDS server and possibly a string to be
resolved if it is different than the original URN) or a reference
outside the RDS to a URN resolver service, sidestepping any further use
of the RDS scheme.  Figure 1 depicts this process.

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

        Figure 1: An RDS framework

There are several points worth noting about the RDS framework.  First,
it leaves open the determination of the protocols, data organization,
distribution and replication needed to support a particular RDS scheme.
Second, it leaves open the location of the computations engendered by
the rules.  Third, it leaves open the possibility that partitioning
(distribution) of the RDS database need not be on the same boundaries as

                               - 17 -

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 (see
[Sl97]).  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 RDS 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 RDS scheme

If we are to support more than one co-existing RDS 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 RDS scheme.  One cannot expect potential
publishers to submit updates to more than one RDS scheme.  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 RDS 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, as is often done
with library catalogs.

This framework is presented in order to suggest to RDS scheme designers
a direction in which to start designing.  It should be obvious to the
reader that adherence to this framework will in no way guarantee
compliance with the guidelines or even the assumptions 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 conform to
these guidelines.  Furthermore, it is assumed that preliminary proposals
may not meet all the guidelines, but should be expected to itemized and
justify any lack of compliance.

                               - 18 -

5. Acknowledgments

Foremost acknowledgment for this document goes to Lewis Girod, as my
co-author on a preliminary 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.

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

[RFC2141] Moats, Ryan, "URN Syntax", RFC 2141, May 1997.

[Sl97] Slottow, E.G., "Engineering a Global Resolution Service," 
MIT-LCS-TR712, June, 1997.  Currently available as 
<http://ana.lcs.mit.edu/anaweb/ps-papers/tr-712.ps> or 
<http://ana.lcs.mit.edu/anaweb/pdf-papers/tr712.pdf>.

[VK83] Voydock, V. L., and Kent, S. T., "Security Mechanisms in
High-Level Protocols", ACM Computing Surveys, v. 15, No. 2, June,
1983, pp. 135-171.

7. Contact information:

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

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

This Internet Draft expires on December 4, 1997.

                               - 19 -

Date: Tue, 03 Jun 1997 15:44:40 -0600
To: Michael Mealling <[email-masked]>
From: "Ron Daniel, Jr." <[email-masked]>
Subject: Re: [URN] URN resolution services question
Cc: [email-masked]
Sender: [email-masked]
Reply-To: "Ron Daniel, Jr." <[email-masked]>

>If I don't hear anything else from anyone by tomorrow I'm going to go ahead
>and make the changes....

OK.

You might add some statements that N2* and L2* showed up
in an earlier draft but are being deprecated. I'll use that
when I redo the THTTP paper.

Harald, Leslie - any comments on redoing THTTP before it actually
appears as an RFC?

Regards,

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

From: Michael Mealling <[email-masked]>
Subject: Re: [URN] URN resolution services question
To: [email-masked]
Date: Tue, 3 Jun 1997 17:21:26 -0400 (EDT)
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Michael Mealling <[email-masked]>

Ryan Moats said this:
> 
> Hmm, maybe I'd better wake up and think about this :-)
> 

If I don't hear anything else from anyone by tomorrow I'm going to go ahead
and make the changes....

-MM

-- 
------------------------------------------------------------------------------
Michael Mealling	| 505 Huntmar Park Drive       | Phone:  (703)742-0400
Software Engineer	| Herndon, VA 22070	       | Fax:    (703)742-9552
Network Solutions	| <URL:http://www.netsol.com>  | [email-masked]

From: Michael Mealling <[email-masked]>
Subject: Re: [URN] URN resolution services question
To: [email-masked]
Date: Mon, 2 Jun 1997 16:45:19 -0400 (EDT)
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Michael Mealling <[email-masked]>

> On Mon, 2 Jun 1997 13:28:35 -0400 (EDT), Michael Mealling wrote:
> >The current list of operations is:
> >N2L (URN to URL)
> >N2Ls (URN to URLs)
> >N2R (URN to Resource)
> >N2Rs (URN to Resources)
> >N2C (URN to URC)
> >N2Ns (URN to URNs)
> >L2Ns (URL to URNs)
> >L2Ls (URL to URLs)
> >L2C (URL to URC):
> >I2I (URI to URI):
> >N2I (URN to URI):
> >I=I (Is URI equal to URI):
> >
> >The change would end up with this list:
> >I2L
> >I2Ls
> >I2R
> >I2Rs
> >I2C
> >I2Cs
> >I2N
> >I2Ns
> >I2I
> >I2Is
> >
> >The issue is basically do we want to explicitly say what a given service
> >will expect as its input?
> 
> 
> First thought:  If we go to I2* have we gone outside of the WG charter?  
> Do we care?

I don't think it matters that much since these are experimental anyway.

> 
> Second thought: If we go to I2*, I'm not sure that there is ever a situation 
> where we have to specify what the input to a given service is.  So long as 
> the resolver is able to report that the URI type specified at the input is 
> not supported, I think things are o.k.

Right. Ron and I were talking about this and the only way a service would
be specified would be if the client had been sent down a particular 
resolution path for given URI. That is, lets say that a resolver specifies that
a particular server supports I2L. The only way for a client to find that 
out would be for it resolve a specific URI. Then the client knows that
since it started out looking for a URN resolver and the RDS sent it to
this resolver that it should be able to ask it I2L questions about a URN.
It could also probably ask it about URLs but the client didn't learn that
from the RDS.

> Side thought: how do such changes impact the THTTP RFC?

Ron talked to Keith about that one and said we could really do whatever
we wanted (I think). Keith? Ron?

-MM

-- 
------------------------------------------------------------------------------
Michael Mealling	| 505 Huntmar Park Drive       | Phone:  (703)742-0400
Software Engineer	| Herndon, VA 22070	       | Fax:    (703)742-9552
Network Solutions	| <URL:http://www.netsol.com>  | [email-masked]

Date: Mon, 02 Jun 1997 14:43:52 -0600
To: [email-masked] (Jul,Erik), [email-masked] (Michael Mealling), [email-masked] (urn-ietf)
From: "Ron Daniel, Jr." <[email-masked]>
Subject: RE: [URN] URN resolution services questi
Sender: [email-masked]
Reply-To: "Ron Daniel, Jr." <[email-masked]>

At 03:52 PM 6/2/97 -0400, Jul,Erik wrote:
>Michael:
>
>Can we talk about I2Cs when the meaning of "C" is not determined?

I think the status of "C" is better off than you indicate, but
I'm not sure just how far this WG can go with them without
exceeding its charter.

If you take a look at the THTTP draft it says something to the effect
that an N2C request will return a resource that describes the resource
named by the given URN. The format of the URC returned may be dependent
on format negotiation. I'm actually pretty happy with that. It will let
us return a MARC record (assuming someone eventually gets around to
defining application/usmarc), a SOIF template, a Dublin Core record
(in some format), a PICS-NG record, etc. We can also use it to return
a Warwick Framework container of several different packages if we
use the I2Cs request.

Regards,

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

Date: Mon, 02 Jun 1997 14:37:14 -0600
To: "Ryan Moats" <[email-masked]>, "Michael Mealling" <[email-masked]>, "[email-masked]" <[email-masked]>
From: "Ron Daniel, Jr." <[email-masked]>
Subject: Re: [URN] URN resolution services question
Sender: [email-masked]
Reply-To: "Ron Daniel, Jr." <[email-masked]>

At 03:19 PM 6/2/97, Ryan Moats wrote:
[On the subject of using I2* instead of N2* and L2*]
>Side thought: how do such changes impact the THTTP RFC?

I don't think we should let that slow us down. If we decide the change
is the right thing to do, we can come up with a new version of the
THTTP document that will obsolete the old one. But if we are going to
do it we should do it ASAP.

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

From: "Ryan Moats" <[email-masked]>
To: "Michael Mealling" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 02 Jun 97 15:19:15 
Priority: Normal
Subject: Re: [URN] URN resolution services question
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Mon, 2 Jun 1997 13:28:35 -0400 (EDT), Michael Mealling wrote:

>I'm about ready to send out the next iteration of the URN Resolutions
>Services draft. One thread that circulated quite a bit the last time was
>whether or not the UR{N,L}2* operations should collapse into simply 
>I2* operations. I.e. the argument to the initial set of operations was
>any URI and that it was up to the resolver to look at the type of URI to
>determine what it was.
>
>The current list of operations is:
>N2L (URN to URL)
>N2Ls (URN to URLs)
>N2R (URN to Resource)
>N2Rs (URN to Resources)
>N2C (URN to URC)
>N2Ns (URN to URNs)
>L2Ns (URL to URNs)
>L2Ls (URL to URLs)
>L2C (URL to URC):
>I2I (URI to URI):
>N2I (URN to URI):
>I=I (Is URI equal to URI):
>
>The change would end up with this list:
>I2L
>I2Ls
>I2R
>I2Rs
>I2C
>I2Cs
>I2N
>I2Ns
>I2I
>I2Is
>
>I'm removing I=I because I just don't want to get into other operations
>right now....
>
>The issue is basically do we want to explicitly say what a given service
>will expect as its input?

Hmm, maybe I'd better wake up and think about this :-)

First thought:  If we go to I2* have we gone outside of the WG charter?  Do we care?

Second thought: If we go to I2*, I'm not sure that there is ever a situation where we have
to specify what the input to a given service is.  So long as the resolver is able
to report that the URI type specified at the input is not supported, I think things are
o.k.

Ryan

Side thought: how do such changes impact the THTTP RFC?

From: "Ryan Moats" <[email-masked]>
To: "Jul,Erik" <[email-masked]>, "Michael Mealling" <[email-masked]>, "urn-ietf" <[email-masked]>
Date: Mon, 02 Jun 97 15:14:10 
Priority: Normal
Subject: RE: [URN] URN resolution services questi
Sender: [email-masked]
Reply-To: "Ryan Moats" <[email-masked]>

On Mon, 02 Jun 1997 15:52:29 -0400, Jul,Erik wrote:

>Michael:
>
>Can we talk about I2Cs when the meaning of "C" is not determined?
>
> --Erik
>
>Erik Jul
>[email-masked]

Given that there is an existing implementation of N2C already, it
probably makes sense to talk about it.

Ryan Moats
[email-masked]
> ----------
>From: Michael Mealling
>To: urn-ietf
>Subject: [URN] URN resolution services question
>Date: Monday, June 02, 1997 1:42PM
>
>I'm about ready to send out the next iteration of the URN Resolutions
>Services draft. One thread that circulated quite a bit the last time was
>whether or not the UR{N,L}2* operations should collapse into simply
>I2* operations. I.e. the argument to the initial set of operations was
>any URI and that it was up to the resolver to look at the type of URI to
>determine what it was.
>
>The current list of operations is:
>N2L (URN to URL)
>N2Ls (URN to URLs)
>N2R (URN to Resource)
>N2Rs (URN to Resources)
>N2C (URN to URC)
>N2Ns (URN to URNs)
>L2Ns (URL to URNs)
>L2Ls (URL to URLs)
>L2C (URL to URC):
>I2I (URI to URI):
>N2I (URN to URI):
>I=I (Is URI equal to URI):
>
>The change would end up with this list:
>I2L
>I2Ls
>I2R
>I2Rs
>I2C
>I2Cs
>I2N
>I2Ns
>I2I
>I2Is
>
>I'm removing I=I because I just don't want to get into other operations
>right now....
>
>The issue is basically do we want to explicitly say what a given service
>will expect as its input?
>
>As soon as I get some idea of the concensys surrounding this topic I'll
>send out the draft....
>
>
>
> -MM
>
>
> --
> ----------------------------------------------------------------------------  
> --
>Michael Mealling | 505 Huntmar Park Drive       | Phone:  (703)742-0400
>Software Engineer | Herndon, VA 22070        | Fax:    (703)742-9552
>Network Solutions | <URL:http://www.netsol.com>  | [email-masked]
>
> ------ Message Header Follows ------
>Received: from mailer.oclc.org by msunion.dev.oclc.org
>  (PostalUnion/SMTP(tm) v2.1.9a for Windows NT(tm))
>  id AA-1997Jun02.134003.1083.991150; Mon, 02 Jun 1997 13:40:03 -0400
>Received: from services.bunyip.com by mailer.oclc.org (5.0/SMI-4.1)
> id AA14965; Mon, 2 Jun 1997 13:40:00 +0500
>Errors-To: [email-masked]
>Received: (from daemon@localhost)
> by services.bunyip.com (8.8.5/8.8.5) id NAA28344
> for urn-ietf-out; Mon, 2 Jun 1997 13:29:29 -0400 (EDT)
>Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
> by services.bunyip.com (8.8.5/8.8.5) with ESMTP id NAA28336
> for <[email-masked]>; Mon, 2 Jun 1997 13:29:18 -0400 (EDT)
>Received: from bailey.dscga.com (bailey.dscga.com [198.78.9.11])
> by mocha.bunyip.com (8.8.5/8.8.5) with ESMTP id NAA07829
> for <[email-masked]>; Mon, 2 Jun 1997 13:29:15 -0400 (EDT)
>Received: (from michael@localhost) by bailey.dscga.com (8.8.2/8.8.2) id
>NAA13917 for [email-masked]; Mon, 2 Jun 1997 13:28:35 -0400 (EDT)
>From: Michael Mealling <[email-masked]>
>Message-Id: <[email-masked]>
>Subject: [URN] URN resolution services question
>To: [email-masked]
>Date: Mon, 2 Jun 1997 13:28:35 -0400 (EDT)
>X-Mailer: ELM [version 2.4ME+ PL31H (25)]
>Mime-Version: 1.0
>Content-Type: text/plain; charset=US-ASCII
>Content-Transfer-Encoding: 7bit
>Sender: [email-masked]
>Precedence: bulk
>Reply-To: Michael Mealling <[email-masked]>
>Errors-To: [email-masked]
>content-length: 1325
>
>
>

From: Michael Mealling <[email-masked]>
Subject: Re: [URN] URN resolution services questi
To: [email-masked] (Jul Erik)
Date: Mon, 2 Jun 1997 15:57:33 -0400 (EDT)
Cc: [email-masked]
Sender: [email-masked]
Reply-To: Michael Mealling <[email-masked]>

> Michael:
> 
> Can we talk about I2Cs when the meaning of "C" is not determined?
> 
> <snip>
> N2C (URN to URC)
> L2C (URL to URC):
> <snip>

Good question. I felt kind of odd myself putting those in there. These
are experimental documents and aren't really specifying any standard  so 
I didn't feel to odd.  They will probably be reviewed after about a 
year or so. I think I am going to add a note to the effect of what a 
URC is from a historical perspective and leave it at that.

I do agree that we need to talk about URCs more, define what they
are and how you identify one....

-MM

-- 
------------------------------------------------------------------------------
Michael Mealling	| 505 Huntmar Park Drive       | Phone:  (703)742-0400
Software Engineer	| Herndon, VA 22070	       | Fax:    (703)742-9552
Network Solutions	| <URL:http://www.netsol.com>  | [email-masked]

From: [email-masked] (Jul,Erik)
To: [email-masked] (Michael Mealling), [email-masked] (urn-ietf)
Organization: OCLC Inc, Dublin, Ohio USA (614)764-6000
Date: Mon, 02 Jun 1997 15:52:29 -0400
Subject: RE: [URN] URN resolution services questi
Sender: [email-masked]
Reply-To: [email-masked] (Jul,Erik)

Michael:

Can we talk about I2Cs when the meaning of "C" is not determined?

 --Erik

Erik Jul
[email-masked]
 ----------
From: Michael Mealling
To: urn-ietf
Subject: [URN] URN resolution services question
Date: Monday, June 02, 1997 1:42PM

I'm about ready to send out the next iteration of the URN Resolutions
Services draft. One thread that circulated quite a bit the last time was
whether or not the UR{N,L}2* operations should collapse into simply
I2* operations. I.e. the argument to the initial set of operations was
any URI and that it was up to the resolver to look at the type of URI to
determine what it was.

The current list of operations is:
N2L (URN to URL)
N2Ls (URN to URLs)
N2R (URN to Resource)
N2Rs (URN to Resources)
N2C (URN to URC)
N2Ns (URN to URNs)
L2Ns (URL to URNs)
L2Ls (URL to URLs)
L2C (URL to URC):
I2I (URI to URI):
N2I (URN to URI):
I=I (Is URI equal to URI):

The change would end up with this list:
I2L
I2Ls
I2R
I2Rs
I2C
I2Cs
I2N
I2Ns
I2I
I2Is

I'm removing I=I because I just don't want to get into other operations
right now....

The issue is basically do we want to explicitly say what a given service
will expect as its input?

As soon as I get some idea of the concensys surrounding this topic I'll
send out the draft....

 -MM

 --
 ----------------------------------------------------------------------------  
 --
Michael Mealling | 505 Huntmar Park Drive       | Phone:  (703)742-0400
Software Engineer | Herndon, VA 22070        | Fax:    (703)742-9552
Network Solutions | <URL:http://www.netsol.com>  | [email-masked]

 ------ Message Header Follows ------
NAA13917 for [email-masked]; Mon, 2 Jun 1997 13:28:35 -0400 (EDT)
From: Michael Mealling <[email-masked]>
Message-Id: <[email-masked]>
Subject: [URN] URN resolution services question
To: [email-masked]
Date: Mon, 2 Jun 1997 13:28:35 -0400 (EDT)
X-Mailer: ELM [version 2.4ME+ PL31H (25)]
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: [email-masked]
Precedence: bulk
Reply-To: Michael Mealling <[email-masked]>
Errors-To: [email-masked]
content-length: 1325

From: Michael Mealling <[email-masked]>
Subject: [URN] URN resolution services question
To: [email-masked]
Date: Mon, 2 Jun 1997 13:28:35 -0400 (EDT)
Sender: [email-masked]
Reply-To: Michael Mealling <[email-masked]>

I'm about ready to send out the next iteration of the URN Resolutions
Services draft. One thread that circulated quite a bit the last time was
whether or not the UR{N,L}2* operations should collapse into simply 
I2* operations. I.e. the argument to the initial set of operations was
any URI and that it was up to the resolver to look at the type of URI to
determine what it was.

The current list of operations is:
N2L (URN to URL)
N2Ls (URN to URLs)
N2R (URN to Resource)
N2Rs (URN to Resources)
N2C (URN to URC)
N2Ns (URN to URNs)
L2Ns (URL to URNs)
L2Ls (URL to URLs)
L2C (URL to URC):
I2I (URI to URI):
N2I (URN to URI):
I=I (Is URI equal to URI):

The change would end up with this list:
I2L
I2Ls
I2R
I2Rs
I2C
I2Cs
I2N
I2Ns
I2I
I2Is

I'm removing I=I because I just don't want to get into other operations
right now....

The issue is basically do we want to explicitly say what a given service
will expect as its input?

As soon as I get some idea of the concensys surrounding this topic I'll
send out the draft....

-MM

-- 
------------------------------------------------------------------------------
Michael Mealling	| 505 Huntmar Park Drive       | Phone:  (703)742-0400
Software Engineer	| Herndon, VA 22070	       | Fax:    (703)742-9552
Network Solutions	| <URL:http://www.netsol.com>  | [email-masked]