[URN] draft-urn-resolution-services-01.txt

[Michael Mealling <[e-mail]>]

URN Working Group                                                  
M.Mealling
INTERNET-DRAFT                                         Network
Solutions, Inc.
Expires six months from March 1997                              Ron
Daniel Jr.
Intended category: Standards Track              Los Alamos National
Laboratory
 
                           URN Resolution Services
 
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, was one of a client needing to convey to a
service some idea of the desired operation on a URI that the client is
currently talking about. The problem was also that the server needed to
convey to a client which network entity could perform which of the
operations that were allowed for that particular URI.
 
This problem requires we specify some well understood set of identifiers
that could identify the operation that a particular network entity
either
desired or could perform. But it was also realized that an exhaustive
set
would both be impossible and not very necessary. Thus, while this
document
will list several operations, it will also lay out the requirments for
specifying new operations.
 
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
and algorithm was seen as sufficient to meet the requirements. Thus, as
with
most things simple the simple set of design criteria ended up being:
simple,
extensible, generic and short.
 
As with most design requirements there are several that are at cross
purposes. Thus for anyone adding to this list these design criteria
should
be kept in mind and balanced against each other.
 
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 and its output.
 
   * 2.1 Operands
 
     Must contain the following pieces of information:
        o name of the operation
        o mnemonic for the operation
        o number of operands
        o type of each operand
        o format of each operand
 
   * 2.2 Algorithm Must either specify the exact algorithm for the
operation
     or must specify that the algorithm is opaque and defined by the
server.
 
 
   * 2.3 Output Must either specify one of the following:
        o there is no output
        o the output is undefined
        o the output itself and its content
        o the fact that the output is an object and that objects type
and
          format.
 
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 N2L 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
   * what the output format is
 
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 N2L (URN to URL)
 
   * name: URN to URL
   * mnemonic: N2L
   * 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: 1 and only one URL encoded in a text/uri-list
 
This operation is used to map a single URN 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 URN namespace.
 
4.2 N2Ls (URN to URLs)
 
   * name: URN to URLs
   * mnemonic: N2LS
   * 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: a list of 0 or more URLs encoded in a text/uri-list
 
This operation is used to map a single URN 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 URN. All URIs shall be encoded according to the URI specification
[6].
 
4.3 N2R (URN to Resource)
 
   * name: URN to Resource
   * mnemonic: N2R
   * 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
   * specified. instance of the resource named by the URN. Encoding is
not
 
This operation is used to return a single instance of the resource that
is
named by the URN. The format of the output is dependent on the resource
itself.
 
4.4 N2Rs (URN to Resources)
 
   * name: URN to Resources
   * mnemonic: N2Rs
   * 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
   * is not specified. instances of the resource named by the URN.
Encoding
 
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 URN.
 
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 N2C (URN to URC)
 
   * name: URN to URC
   * mnemonic: N2C
   * 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: A Uniform Resource Characteristic. Encoding is not
specified.
 
URCs (Uniform Resource Characteristics) are descriptions of other
resources.
This request allows the client to obtain a description of the resource
identified by a URN, 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 N2Ns (URN to URNs)
 
   * name: URN to URNs
   * mnemonic: N2Ns
   * 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: A list of URNs encoded in a text/uri-list IMT.
 
While URNs are supposed to identify one and only one resource, that does
not
mean that a resource may have one and only one URN. For example,
consider a
resource that has something like "current-weather-map" for one URN and
"weather-map-for-datetime-x" for another URN. The N2Ns service request
lets
the client obtain lists of URNs that are believed equivalent at the time
of
the request. As the weathermap example shows, some of the equivalences
will
be transitory, so the the server should convey the length of time for
which
the mapping is valid. The result is a list of all the URNs, known to the
server, which identify the same resource as the input URN. The result
shall
be encoded in a text/uri-list IMT.
 
4.7 L2Ns (URL to URNs)
 
   * name: URN to URNs
   * mnemonic: N2Ns
   * 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: A list of URNs encoded in a text/uri-list IMT.
 
This operation is used to discover the URN associated with a particular
URL.
As with all operations dealing with URNs how that URN is mapped is
completely dependent on the rules specified by the namespace.
 
4.8 L2Ls (URL to URLs)
 
   * name: URL to URLs
   * mnemonic: L2Ls
   * 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 list of URLs encoded in a text/uri-list IMT.
 
This operation is used to discover URLs that are considered equal to
each
other. As with the N2N operation "equality" is defined by the server and
is
opaque to the client.
 
4.9 L2C (URL to URC):
 
   * name: URL to URC
   * mnemonic: L2C
   * 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 URC.
 
This operation is used to retrieve the URC for a given URL. As with most
other URI mappings the mapping function is opaque. As with any other
operation that returns a URC, the output format is unspecified.
 
4.10 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.
 
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.11 N2I (URI to URI):
 
   * name: URN to URI
   * mnemonic: N2I
   * 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.
 
This operation is used to map a URN to any other arbitary URI. No other
assertions are made about whether or not the URI exhibits
characteristics of
URNs or URLs.
 
4.11 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
 
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 N2Ls, N2Ns, L2Ns,
L2Ls,
result in a list of URIs being returned to the client. The text/uri-list
Internet Media Type is defined to provide a simple format for the
automatic
processing of such lists of URIs.
 
The format of text/uri-list resources is:
 
  1. Any lines beginning with the '#' character are comment lines and
are
     ignored during processing. (Note that '#' is a character that may
     appear in URIs, so it only denotes a comment when it is the first
     character on a line).
  2. The remaining non-comment lines MUST be URIs (URNs or URLs),
encoded
     according to the URI specification RFC[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 N2Ls request, the first line of the text/uri-list
response
SHOULD be a comment giving the original URI.
 
An example of such a result for the N2L request is shown below in figure
1.
             --------------------------------------------------
 
     # urn:cid:[e-mail]
     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", draft-ietf-urn-syntax-02, 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: [phone]
fax: [phone]
email: [e-mail]
 
Ron Daniel
Advanced Computing Lab, MS B287
Los Alamos National Laboratory
Los Alamos, NM, USA, 87545
voice: [phone]
fax: [phone]
email: [e-mail]