From: ccoprmm@oit.gatech.edu (Michael Mealling)
Message-Id: <199403182121.AA22417@oit.gatech.edu>
Subject: URC functional requirements list is ready...
To: uri@bunyip.com
Date: Fri, 18 Mar 94 16:21:29 EST
Here is the URC spec I promised in Houston. An html version is available
via <URL:http://www.gatech.edu/urc.spec.html>. I still don't know
if I'll be able to make it to Seattle or not but if not I hope to be available
via the mbone....
P.S. Thanks to Karen and Larry for the boilerplate intro!
Enjoy:
Specification of Uniform Resource Citations
Michael Mealling
Introduction by Karen R. Sollins and Larry Masinter
February 8, 1994
DRAFT
Presented here are the requirements and functional specification for
_uniform resource citations_ (URCs) within the overall architecture of
_Uniform Resource Identification_. In order to build applications
in the most general case, the user must be able to discover and
identify the information, objects, or what we will call in this
architecture resources, on which the application is to operate. As
the network and interconnectivity grows, the ability to make use of
remote, perhaps independently managed, resources will become more and
more important. This activity of discovering and utilizing resources
can be broken down into those activities where one of the primary
constraints is human utility and facility and those in which human
involvement is small or nonexistent. Human naming must have such
characteristics as being both mnemonic and short. Humans, in contrast
with computers, are good at heuristic disambiguation and wide
variability in structure. In order for computer and network based
systems to support global naming and access to resources that have
perhaps an indeterminate lifetime, the flexibility and attendent
unreliability of human-friendly names should be translated into a
naming infrastructure more appropriate for the underlying support
system. It is this underlying support system that the Internet
Information Infrastructure Architecture (IIIA) is addressing.
Within the IIIA, several sorts of information about resources are
specified and divided among different sorts structures, along
functional lines. In order to access information, one must be able to
discover or identify the particular information desired, determined
both how and where it might be used or accessed. The partitioning of
the functionality in this architecture is into _uniform resource names_
(URN), _uniform resource citations_ (URC), and _uniform resource
locators_ (URL). A URN identifies a resource or unit of information.
It may identify, for example, intellectual content, a particular
presentation of intellectual content, or whatever a name assignment
authority determines is a uniquely namable entity. A URL identifies
the location or a container for an instance of a resource identified
by a URN. The resource identified by a URN may reside in one or more
locations at any given time, and may move. Of course, not all
resources will move during their lifetimes, and not all resources,
although identifiable and identified by a URN will be instantiated at
any given time. As such a URL is identifying a place where a resource
may reside, or a container, as distinct from the resource itself
identified by the URN. A URC is a set of meta-level information about a
resource. Examples of such meta-information are: owner, encoding,
access restrictions (perhaps for particular instances), and location.
With this in mind, we can make the following statement:
The purpose or function of a URC is to provide a vehicle or structure
for the representation of URIs and their associated meta-information.
As with URNs, the requirements on URCs fall into two categories: functional
requirements and encoding requirements. The following functional requirements
specify what roles URCs will be expected to fulfill
* Encapsulation: In the most basic sense, a URC must be able to contain
ANY conceivable type of meta-information or URI.
* Structure: In order to be useful, a URC must contain information
regarding which element a piece of meta-information pertains too.
* Scalability: URCs must be able to encapsulate any resource that can
conceivably be available on the network as well as any extraneous
information about that resource that may be deemed necessary by the
user. Since URCs may contain URNs, the URN scalability function applies
here as well.
* Grandfathering: Current meta-information schemes should be allowed to
work within the URC structure.
* Caching: Caching should be possible for any URC regardless of whether
or not any of its specific elements are not cacheable.
* Resolution: A URC is meant to be the format that URNs and URLs are
transported in, therefore a given URN or URL may be resolved into a URC.
Nothing within a URC should cause it to not be the solution to a URN
or URL resolution.
In addition, the following are requirements for URCs as they are
encoded:
* Human readability: A URC must be able to be typed by a user on a keyboard.
Some meta-information items are meant for humans only while others are
only meant to be machine consumable. One requirement should not
preclude the other from being encoded.
* Transport friendliness: A URC can be transported unmodified in
the common Internet protocols, such as TCP, SMTP, FTP, Telnet, etc.,
as well as printed paper.
* Machine consumption: A URC can be parsed by a computer.
Several important characteristics of URCs come about as a result of
fulfilling the above requirements. Some of these characteristics are
a result of requirements on URNs and URLs that make up some of the
elements of a URC:
* Time To Live: Since a URC contains transient information such as
timestamps, access privileges, etc they can not be guaranteed to have
a Time To Live greater than 0. While this does not preclude the
user from attempting to trust a URC for a longer amount of time it
should not be something to depend on.
* Character Sets: Since the encapsulation and scalability requirements
force the inclusion of alternate character sets, some common
scheme must be found that accommodates all character sets in a way
that fulfills the transport friendly encoding requirement. This
precludes any restrictions on allowable character sets.
* Data Naming: the fulfillment of the grandfathering requirement will
make it nearly impossible to specify the numerous ways extremely
similar pieces of information can be represented. Thus one consideration
should be a central authority that makes suggestions as to the consolidation
of the names used to identify specific pieces of meta-information.
-- ------------------------------------------------------------------------------ Michael Mealling ! Hypermedia WWW, WAIS, and gopher will be Georgia Institute of Technology ! here soon via MIME. Your view of the Michael.Mealling@oit.gatech.edu ! internet is about to change completely!