[Search] [pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
Internet Engineering Task Force                         Ron Daniel Jr.
INTERNET-DRAFT                          Los Alamos National Laboratory
draft-ietf-uri-urc-req-00.txt                         Michael Mealling
                                       Georgia Institute of Technology
                                                     November 21, 1994


                    URC Scenarios and Requirements





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.    Internet-Drafts may  be updated,  replaced,  or
    obsoleted by  other  documents  at  any  time.     It  is  not
    appropriate to use  Internet-Drafts as  reference material  or
    to cite them other  than as a  ``working draft'' or ``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,  nic.nordu.net,
    ftp.isi.edu, or munnari.oz.au.

    This Internet Draft expires May 25, 1995.


Abstract


This draft describes the place of the Uniform  Resource Characteristic
(URC)  service  within  the   overall  context  of  Uniform   Resource
Identification on  the  Internet.     It  presents  several  scenarios
illustrating how the  URC service  might be  used.   From these  usage
scenarios, we  derive a  set  of requirements  that  any proposed  URC
services must meet.


INTERNET-DRAFT     URC Scenarios and Requirements    November 21, 1994

Contents


1 Introduction                                                       3


2 User Scenarios                                                     3

  2.1 URN to URL resolution . . . . . . . . . . . . . . . . . . . .  4

  2.2 Meta-data for its own sake  . . . . . . . . . . . . . . . . .  5

  2.3 Ensuring the veracity of the resource . . . . . . . . . . . .  6

  2.4 Ensuring the veracity of the URC  . . . . . . . . . . . . . .  7

  2.5 Bibliographic Search  . . . . . . . . . . . . . . . . . . . .  8

  2.6 Filtering by Seals of Approval  . . . . . . . . . . . . . . . 10

3 Provider Scenarios                                                11

  3.1 Publishing a new resource . . . . . . . . . . . . . . . . . . 11

  3.2 Publishing a new version of a resource  . . . . . . . . . . . 12

  3.3 Providing an additional location for a resource . . . . . . . 12

    3.3.1Mirroring of free information  . . . . . . . . . . . . . . 13

    3.3.2Mirroring of information that is for sale  . . . . . . . . 13

    3.3.3Mirroring on a regular basis . . . . . . . . . . . . . . . 14

  3.4 Removing a location for a resource  . . . . . . . . . . . . . 14

  3.5 Establishing a new publishing authority . . . . . . . . . . . 15

  3.6 Dealing with the demise of a publisher  . . . . . . . . . . . 15


4 Requirements                                                      16

  4.1 Requirements on the URC . . . . . . . . . . . . . . . . . . . 16

  4.2 Requirements on the URC Service . . . . . . . . . . . . . . . 17

5 Characteristics                                                   19





Daniel and Mealling                                           [Page 2]


INTERNET-DRAFT     URC Scenarios and Requirements    November 21, 1994

1 Introduction


As Joe Jackson says, ``You can't get what you want 'till you know what
you want''.  This applies  to software development just as much  as it
applies to affairs of the heart.   In order for the URI  working group
to design an architecture that does what we want, we need to know what
we want it to do.   This paper presents a wide range of  scenarios for
how we would like the URC  service to operate.  From  those scenarios,
we derive requirements for the  functionality and encoding of  Uniform
Resource Characteristics  (URCs) within  the  overall architecture  of
Uniform Resource Identification.

The URI architecture  is concerned  with resources and  how they  will
be used in  applications.   Resources are the  objects, services,  and
information that  applications will  make  use of.    In  order to  be
used, applications must have  means for discovering, identifying,  and
retrieving resources.  Resouces  are named by a URN  (Uniform Resource
Name), and are retrieved by means of a URL (Uniform Resource Locator).
Describing the resource for purposes  of discovery, as well  as making
the binding between a resource's name and its location(s) is  the role
of the URC (Uniform  Resource Characteristic).   The URI  architecture
is described in other working drafts  of the URI working group  of the
Internet Engineering Task Force,  particularly in [1].   With the  URI
architecture in mind, we can say that:



    The purpose or function  of a URC is  to provide a vehicle  or
    structure for the representation of URIs and  their associated
    meta-information.


The next  few sections  present concrete  examples of  how we  foresee
URCs being used.   We also  describe the operation  of the service  in
which URCs reside - the URC  service.  From those  concrete scenarios,
we derive a set of  requirements on the functionality and  encoding of
URCs.  Any proposals for the URC service will be expected  to show how
they meet the requirements  set forth in this  paper, or to point  out
the error of our ways.


2 User Scenarios


This section  of the  paper presents  several scenarios  of how  users
might interact  with the  URC service.    In these  scenarios we  have
attempted to show how the system will be used,  without specifying how
the system will accomplish its tasks.




Daniel and Mealling                                           [Page 3]


INTERNET-DRAFT     URC Scenarios and Requirements    November 21, 1994

2.1 URN to URL resolution


The fundamental purpose of the URC  service is to map URNs to  URLs so
that a resource can  be retrieved if  its name is  known.  We  believe
that the most frequent operation  will be to take  a URN and return  a
(possibly empty) list of URLs where the resource named by  the URN can
be found.  This  is the primary use of  the service and its  speed and
fault-tolerance are paramount.



 o  User provides a URN to the browser by clicking on an  anchor or by
    entering text into a dialog box.

 o  Browser connects to the URC service and gives it the URN.

 o  Service returns  a  (possibly  empty)  list of  locations  to  the
    browser.  Each  location must contain a  URL. It may also  contain
    information on Content-Type, Price, Signatures, Version, etc.  The
    list of locations  unordered.   Note that  if a location  contains
    information in addition to  the the URL,  ordering may be used  to
    associate the additional information with a particualr URL, but no
    importance should be placed on one URL appearing before another in
    the list of  locations sent  back to the  browser.   The means  by
    which the URC service determines this list is outside the scope of
    this scenario.

 o  The browser uses user-configurable preferences to order  the list.
    For example, a user might prefer HTML to PostScript to text.   One
    user might prefer  locations that  carried signature  information,
    another might not care.   Most  would prefer the cheapest  version
    of a resource,  and the most  recent version.   Estimated  network
    distance is  another  means  for  ordering the  selections.     If
    multiple locations tie, the browser randomizes them in the list to
    prevent overload of any one server.

 o  Once the list of locations  has been sorted, the  browser attempts
    to retrieve the resource from the first location.   If that fails,
    the next  location is  tried.   This  continues until  one of  the
    following is true:


    --  The browser successfully retrieves the resource

    --  The list is exhausted

    --  The user tells the browser to cancel the retrieval


 o  The browser displays the  resource to the  user, perhaps with  the
    aid of an external viewer.

Daniel and Mealling                                           [Page 4]


INTERNET-DRAFT     URC Scenarios and Requirements    November 21, 1994

Note that  the  list of  termination  conditions  given above  is  not
complete.   The URC  service will  undoubtably make  extensive use  of
caching for  speed.    If the  list was  obtained  from a  cache,  the
possibility exists that  the resolution  failed because  of the  cache
being stale.   A  reasonable fix  is to  allow the  user to  configure
the browser  to  retry  the query,  this  time  getting  authoritative
information to fill the list of locations.

This scenario provides us  with several requirements  for the URC  and
the URC service.    First, we  must be  able to  locate a  URC from  a
URN. We must be  able to transport a  URC without errors using  normal
Internet protocols.   The URC  must be parseable  by a  computer.   It
may have a hierarchical structure, and we should be  able to rearrange
elements of the URC within the same hierarchical level.   The URC must
be able to  contain a wide  variety of information.   Furthermore,  we
must be able to distinguish  queries answered over cached  information
from those answered over authoritative information.



2.2 Meta-data for its own sake


The scenario above assumed  that the user  really and truly wanted  to
retrieve the  resource on  the  other end  of the  anchor.    However,
sometimes the user will not be sure if they want to  get the resource.
This is already the  case in WWW  browsing where users will  sometimes
decide, by  inferring  size and  speed  from the  URL, not  to  access
particular resources.  As  the WWW starts to encompass  resources that
will require payment for  their access, users  will want to know  just
what they about to get themselves into.


 o  User is browsing and comes across a moderately interesting link.

 o  User does a right-mouse-button over the link, presenting  a pop-up
    menu.

 o  User selects ``More info...''   from  the pop-up and releases  the
    mouse button.

 o  Browser fetches the  URC for  the resource  and displays  it in  a
    nicely formatted dialog box.

 o  The user decides that they don't mind paying $1  for the resource,
    and selects ``OK'' in the dialog.

 o  The browser fetches the resource and displays it to the user.


To support  this scenario,  the service  must  be able  to provide  an
entire URC, not  just the list  of locations that  it returned in  the

Daniel and Mealling                                           [Page 5]


INTERNET-DRAFT     URC Scenarios and Requirements    November 21, 1994

previous scenario.  Second, URCs must have a  printable representation
that can  be understood  and transcribed  by humans.    This does  not
mean that all  elements must  be easily  understood, or  even that  we
have to transmit URCs in  a readable form.   It merely means that,  in
addition to any other representation, fields must have have  a printed
representation that does not intentionally obfuscate the  URC, barring
the presence of encryption.



2.3 Ensuring the veracity of the resource


An  important  concern  voiced  over  the  URI  mailing  list  and  in
discussions with different communities of users has been how to ensure
the veracity of  a resource.   This  concern has  been raised on  both
the user  and provider  side.    Users  want to  make sure  that  they
are getting  the real  resource,  especially if  they  are paying  for
it.  Providers want  to make sure that  they are not haunted by  bogus
versions of a resource.   To  ensure the veracity  of a resource,  the
location information provided by the URC service could carry a digital
signature of the resource.


 o  The user  starts to  retrieve a  resource according  to the  first
    scenario.

 o  As the browser is going through its list of locations, it notes if
    the current location has signature information.  The  rest of this
    scenario assumes that  we successfully  retrieve a resource  which
    has signature info.

 o  When the browser  retrieves the  resource, it  displays it to  the
    user.

 o  In the  background,  the browser  verifies  the signature  on  the
    information.  To do  this it retrieves the appropriate  public key
    of the publisher through a secure, ubiquitous public  key service.
    The public key is used to decrypt the signature  from the location
    object.  It is compared with the MD-5 hash of the resource.

 o  If the signature does not check out, the browser alerts the user.

 o  If the  user goes  on  to another  resource before  the  signature
    computation is complete, it is discarded.


This assumes  that signatures  are  computed over  the contents  of  a
complete file.   Some resources, such as  search services, can not  be
treated in such a fashion.   One possibility  would be for the URC  to
contain the signature of a  constant header the service provides  with
its results.  The header would  contain a public key used to  verify a

Daniel and Mealling                                           [Page 6]


INTERNET-DRAFT     URC Scenarios and Requirements    November 21, 1994

signature of the search results appended to the search results.

This scenario imposes the requirement that it be possible to establish
an unbroken chain of authentication from a URN through the  URC to the
resource.  Multiple  signatures schemes should  be supported to  allow
different cost/security tradeoffs to be made.



2.4 Ensuring the veracity of the URC


Resources are not the only information that can be tampered with.  The
URC service will provide a  tempting target for attack.   It needs  to
be secured against determined attacks and the information  it provides
needs to be verifiable.  However, security does not come for free, and
we should not impose that cost on  all accesses.  Therefore it  is not
appropriate to make  the URC  server compute a  digital signature  for
every query response it generates.

One approach  would  be  for  the  server  to  keep  two  pre-computed
signatures for each of its  URCs.  The  first is a signature over  the
entire URC, the second is only computed over the  location information
it would return in response to a standard URN resolution query.


 o  User configures the browser to verify URC information.

 o  The user clicks on a link

 o  The browser sends  a URN  resolution request to  the URC  service.
    The request has  a flag set  so that the  URC server will  provide
    digital signature information.

 o  The browser  receives  the  list  of locations  as  in  the  first
    scenario.   In addition it  receives a  digital signature of  that
    information which has been encrypted  with the private key  of the
    URC server.

 o  The browser retrieves the public key of the server, and uses it to
    verify the URC information.

 o  If there  is  no  problem,  the  browser continues  as  before  to
    retrieve the resource.  If  there is a problem the  browser alerts
    the user, who should alert the administrator of the URC server.


If a general query is issued, the URCs for all  matching resources are
returned in their entirety.   The browser then  has to verify each  of
the URCs in  turn.   Validating general queries  will be an  expensive
process, but it is the user's machine paying most of the cost.


Daniel and Mealling                                           [Page 7]


INTERNET-DRAFT     URC Scenarios and Requirements    November 21, 1994

This scenario  requires  that  the  URC  have  a  consistent  external
representation  that  is  suitable  for  the  computation  of  digital
signatures.   That  representation  must be  network friendly  to  the
extent that it will be  transmitted without any changes over  standard
Internet protocols.  Furthermore, it must be possible  to separate the
portion of a URC being signed from the portion carrying the signature.



2.5 Bibliographic Search


In addition  to locations,  the  URC provides  a  convenient place  to
store bibliographic information such  as author, title, subject,  date
of publication,  etc.    Also,  since  publishers  are assumed  to  be
arranged in a hierarchy, it should be possible to find every publisher
affiliated with the URC service.  Combining these two properties opens
up the possibility of bibliographic  searches across the whole of  the
web.   Exactly  how this  should work  is not  so  obvious.   A  naive
approach would be:


 o  User enters author, title, and/or subject information into a form

 o  Browser passes the query to the URC service.

 o  Within the URC service, each node is consulted with the query, the
    results are collected and passed back to the browser.

 o  The browser presents the search results to the user.


Of course, the scenario above is unrealistic.   If every bibliographic
search of every user consults every URC server, the service as a whole
will soon grind to a halt.  The obvious alternative is  for some sites
to come forward  and carry the  burden of  these searches, similar  to
the current situation with  Archie.   Some sites will  do this out  of
the goodness of their heart, while  others may charge a fee  for their
services.  The usage scenario is now:


 o  User connects to a URC search site

 o  Browser puts up the form from that site

 o  User fills it in and hits ``submit''

 o  The URC  search  site handles  the  query  over its  database  and
    returns the result to the browser.

 o  The browser displays the results to the user.


Daniel and Mealling                                           [Page 8]


INTERNET-DRAFT     URC Scenarios and Requirements    November 21, 1994

The  database  for  handling  the  search  is  updated   regularly  by
harvesting the network.



 o  Search  server  starts  a  depth-first  search  of  the   tree  of
    publishers.

 o  Search server queries the current URC server for all URCs that are
    new or have been  modified since the  last time the search  server
    visited.   Those  URCs are  put into  the database  of the  search
    service.

 o  Search server asks the URC  server for all changes  in publication
    hierarchy since last visit.

 o  Search server continues depth-first search using the new topology


The URC  service will  grow beyond  the capabilities  of  all but  the
most dedicated sites  (OCLC, Library  of Congress,  etc.)   to keep  a
comprehensive index.   The  natural course  is for  search servers  to
only keep a portion of the URCs  that exist.  Exactly how  they choose
the subset to retain  will be a decision  that varies from one  search
service to another.

Several requirements  for  the  URC service  spring  from  considering
searching.    First, we  must  be  able to  connect  to a  variety  of
URC servers  instead of  having only  one URC  server  be our  gateway
to the  world.    Second,  if  URN  resolution is  handled  through  a
query forwarding mechanism, servers  will want to distinguish  between
a simple resolution  request (which should  be forwarded) and  general
bibliographic queries which should not be forwarded to most sites.  If
URN resolution does not  require query forwarding  then this is not  a
problem.  Third,  there will need  to be a  means for determining  how
to contact the  server administrator  so that  the administrator  will
add the  central search  services to  the list  of  entities that  can
launch certain queries.    Fourth, a  publisher's server  must keep  a
complete record of all the sub-publishers authorized by that publisher
and be able  to provide  that list  in response to  a query.    Fifth,
we must be  able to  determine the  parent publisher  of a  publisher,
either from the URN or by a special request to the URC server.  Sixth,
the administrator of a URC  server should be able to  make incremental
modifications to  the URCs  on  that server.    Seventh,  URCs  should
carry information on  their creation  and modification  dates so  that
incremental harvesting is possible.







Daniel and Mealling                                           [Page 9]


INTERNET-DRAFT     URC Scenarios and Requirements    November 21, 1994

2.6 Filtering by Seals of Approval


One of  the  interesting  concepts  to  come  out  of  the  Interpedia
effort [2]  is  the concept  of  SOAPs (Seals  Of  APproval).    SOAPs
are capsule reviews of  a resource and  are implemented using  digital
signature technology  so  that they  will  be extremely  difficult  to
forge.   Critics, professional organizations,  etc.   could use  SOAPs
to carry quick  reviews of resources  and to  point to more  elaborate
reviews.  For example, the IEEE might receive a request to ``publish''
a resource in one of their  electronic journals.  The  editorial board
of the journal lines  up the requisite  number of reviewers and  sends
them the URL  of the  resource.   Each  of the  reviewers sends  their
review back to  the editors,  who either  turn the  author down  flat,
recommend changes, or accept the resource as it is.   If the editorial
board accepts it, they form  a digital signature of the resource,  the
quick rating, an optional  URN of a full review,  etc.  all  encrypted
with the private key of the particular journal.

Users could use SOAPs to augment bibliographic searches.  For example,
a new physics grad student might  ask to see all the abstracts  of all
the resources dealing with (string theory AND  quantum chromodynamics)
which had been reviewed by the American Physical Society  and received
a rating of 9 or above.

Such queries do not  necessarily need to  proceed in the same  fashion
as the general bibliographic search described in the  earlier section.
Instead, SOAPs may well  become the valuable intellectual property  of
professional organizations.  It may be that if you wish to do searches
on things with  the SOAP  of the  APS, you  have to  connect to  their
server to do  it, presumably  paying them  for the privilege.    Given
this money-making  potential, it  is doubtful  that many  professional
organizations will allow authors to include a SOAP in the  default URC
for their resource unless the author pays for the privilege.



 o  User connects to the server  of a reviewing organization, or  to a
    server that has licensed the right to use the  SOAPs of particular
    reviewing organizations.

 o  Browser displays the search form of that organization.   This will
    be a  typical bibliographic  search  form augmented  with  special
    features for the SOAPs issued by the organization.

 o  User fills out the form and submits it.

 o  The server does the search and returns the results to the browser.

 o  The browser displays the results of the search to the user.



Daniel and Mealling                                          [Page 10]


INTERNET-DRAFT     URC Scenarios and Requirements    November 21, 1994

This scenario imposes two requirements on  the URC. First, it  must be
possible to extend the URC by adding arbitrary elements.   In the case
above, the SOAP is the  new element.   Second, it must be possible  to
ignore elements that you do not  understand.  For this to  be possible
it must be possible  to determine where  any particular element  ends,
even if you  know nothing  about the structure  of information  inside
the element.  Note  that there is an interaction  between ignorability
and having a  consistent representation  for the  purposes of  digital
signatures.    Digital  signatures  are  computed  over  the  external
representation, which can include experimental elements.  Ignorability
is a  feature of  the conversion  from the  external  to the  internal
representation, where if we do  not understand an element we  are free
to discard it while we are parsing the URC.



3 Provider Scenarios


3.1 Publishing a new resource


This is  one of  the fundamental  operations  for resource  providers.
Consequently it needs to be as simple and as bulletproof as possible.

Consider the processes of preparing and  testing a new resource.   Any
anchors in the resource must be expressed as URNs, not URLs.  However,
the resource will  typically undergo considerable  change while it  is
being developed,  so it  is  not appropriate  for  a community  larger
than the  developers to  be able  to resolve  the URNs  to URLs.    To
meet this  need,  the  authors  request "development  URNs"  from  the
naming authority.    Development  URNs will  have very  minimal  URCs.
Typically they will contain  zero or one  URL and some access  control
information.   These  URNs  are hidden  from  all but  the  developers
and server administrator.   Using the development URNs,  the author(s)
prepare and test the  new resource.   Note that many development  URNs
will never make it to the status of full URNs.

When the author(s)  are ready to  publish the  resource to the  world,
they will modify the access control information in the development URC
to allow wider access.   They  may also augment  the URC with  author,
title, publication date, etc.  The amount of information needed in the
URC of a published  resource will vary  from one publisher to  another
and can be enforced by the publisher's URC software.   If the resource
is to be verifiable,  the signature of the  resource will be put  into
the URC at  this time.   Once all  the material for  the URC has  been
provided, a signature can be computed over it as well.

Once the URC information  has been put onto  the local URC server,  it
will be propagated to any other servers around the globe that can play
the role of default server for that publisher.


Daniel and Mealling                                          [Page 11]


INTERNET-DRAFT     URC Scenarios and Requirements    November 21, 1994

This first  publishing  scenario  imposes  several requirements.     A
publisher must be able to  provide developmental URNs and to  shepherd
the corresponding URC through the  development process.  Minimal  URCs
should be easy to generate by hand, and the URC  must be incrementally
modifiable.  Note that a  logical consequence of this is that  we will
want to  maintain versioning  information for  the URC,  not just  the
resource it describes.   However, that is  not foreseen to be part  of
a minimal URC. While in development, harvester queries should  not get
these URCs.   Finally,  note that  we leave open  the possibility  for
multiple URC servers to provide  default information for the works  of
a particular  publisher.   Any  proposed specifications  will need  to
show how they meet requirements for consistency among such cooperating
servers.  At a minimum, a  URC server for a publisher should  know all
the other URC servers for that  publisher and be able to  update their
records.



3.2 Publishing a new version of a resource


When it is time to revise a resource the authors request a development
version of the  URC info.   This version  will have restricted  access
so that ordinary users  only see the  older version while the  authors
and URC  server administrator  can  see the  new version.    Once  the
new version of  the resource is  ready, the  modifications in the  URC
are made  publicly accessible.    Locations for  the  new version  are
established, and the locations for the old version should gradually go
away.

This scenario requires that  the developers be  able to augment  their
resolution queries with version information so that they will  be able
to access  the new  version  while the  rest  of the  world  continues
to receive the  old version.    It also requires  that access  control
mechanisms have a fine enough granularity  in the URC to allow  such a
discrimination to be made.


3.3 Providing an additional location for a resource


One of the main benefits  we are looking for  from the URC service  it
the ability to have multiple locations for a resource.   How are these
additional locations to be  established?   There will be several  ways
this might  happen, the  appropriate model  will  depend on  financial
considerations more  than technical  ones.    We will  consider  three
cases out of many  possible ones.   The first  is simple mirroring  of
free information.    The second  is a  mirror of  a small  publisher's
information that is  sold.   The  third is  a contractual  arrangement
between sites.



Daniel and Mealling                                          [Page 12]


INTERNET-DRAFT     URC Scenarios and Requirements    November 21, 1994

3.3.1 Mirroring of free information


A researcher in  Australia comes  across a  collection of  interesting
technical reports on a server  in Sweden.   He wishes to mirror  those
reports as  a service  to the  research community  in Australia.    He
contacts the administrator of the archive in Sweden, who  also happens
to be the author of the reports of interest.  She gives her permission
for a mirror to be  established.  He  pulls over the reports and  sets
them up  on his  HTTP server.    Now  that they  have URLs,  he  sends
a register_new_url message  to  the URC  service.    Since the  Swedish
researcher has provided a  digital signature for  the URCs of all  the
reports, a new  location can  not just be  blindly entered.   The  URC
service forwards the request  to the Swedish  researcher.  She  checks
out the new URLs to make  sure that they are faithful versions  of her
reports, then signs the  register_new_url  message with her private  key
before sending  it back  to the  URC service.    The service  verifies
the authentication information,  sees that  it is good,  adds the  new
location to  the URC  of each  report and  recalculates the  signature
information.   Now when  users attempt  to resolve the  URN, they  can
fetch it from either Australia  or Sweden.   As a matter of  courtesy,
the Australian researcher periodically informs the  Swedish researcher
about how many times her reports have been accessed.

This scenario  does not  impose any  requirements on  the URC  service
beyond those already described for modifying the URC information.


3.3.2 Mirroring of information that is for sale


An experimental film  maker in  Germany has  been selling  avant-garde
videos over the WWW. A film distributor in Canada contacts  her to see
if they can serve  these up to the  North American market in  exchange
for a cut of the action.  The film maker says ``sure''.   The Canadian
distributor puts  copies of  the videos  onto their  video server  and
attempts to  register the  new location  with the  URC service.    The
service forwards the request to the  film maker, who authorizes  it by
signing the request with her private key.  Periodically  the Canadians
send the film  maker a  check to  cover the royalties  the film  maker
collects from every download from the Canadian server.  As part of the
contract between the two sites, the film maker can access  the logs on
the distributor's server to make sure  that she is being paid  for all
the copies it provides.

This scenario does not  impose many requirements  on the URC  service.
Note that  the access  logs  are an  obvious point  of  attack for  an
unscrupulous mirror site administrator.  It would be nice if there was
a means for  ensuring their  veracity, however,  that is  an HTTP  (or
equivalent) server issue, not a URC server issue.



Daniel and Mealling                                          [Page 13]


INTERNET-DRAFT     URC Scenarios and Requirements    November 21, 1994

3.3.3 Mirroring on a regular basis


Some large sites  may set up  cooperative mirroring  agreements.   For
example, Los Alamos National  Laboratory might make arrangements  with
CERN to provide mirrors  of each others  work.   When either of  these
sites publishes a new resource, it sends a message to the other.   The
second site fetches the resource and puts it on their server.  It then
issues a register_new_url  message to the URC service.  It  is forwarded
to the publisher of the  resource, where it is  automatically approved
without human intervention.

This scenario  requires  that  the  URC server's  access  controls  be
capable of registering multiple users  - not a big  problem.  It  also
adds the concept of  a list of  sites to notify  when new material  is
published.  However, that requirement could be eliminated  in favor of
a polling model  as already  discussed in  the information  harvesting
scenario.



3.4 Removing a location for a resource


One of  the  other  strong  motivations  for the  URC  service  is  to
allow administrators of collections of information to  rearrange their
collections without breaking pages across the globe.  Moving resources
can be accomplished in two steps - establishing the new  location then
deleting the original location.   Deletion  is also necessary when  we
wish to remove a resource for any reason.


 o  Administrator  of a  resource  location  sends  a  delete_location
    message  to  the  URC  server.     This  will   typically  require
    authentication that is provided through digital signature means.

 o  The URC service authenticates the request.   If the issuer  of the
    request has  permission, the  URC is  searched  for the  specified
    location.  If found, it is removed and a new signature for the URC
    is computed.

 o  If there are other  URC servers providing default information  for
    the particular publisher, they are  notified as well so  that they
    may also modify their databases.


This scenario requires  that we be  able to select  portions of a  URC
and delete them.  Access  control mechanisms should operate on  a fine
enough grain that the administrator of one location could delete their
location from the URC, but could not delete other locations.



Daniel and Mealling                                          [Page 14]


INTERNET-DRAFT     URC Scenarios and Requirements    November 21, 1994

3.5 Establishing a new publishing authority


Publishers are arranged  in a  hierarchy where new  publishers can  be
added as children of existing ones.



 o  Billy Bob Riker, Harley biker, decides to publish his  doggerel to
    the world.   He contacts his  friendly neighborhood web  publisher
    who, in exchange for a modest amount of cash, establishes ``HogDog
    Press'' as a publisher by issuing the following request to the URC
    service, signed with the private key of the publisher:

 o  Register_new_publisher(parent_publisher, name_of_new_publisher, signa-
    ture_of_request)

 o  Since Billy Bob's  nomadic life  style is  a little  hard on  disk
    drives, he contracts with a  third party to provide storage,  HTTP
    service, and URC  service.   These  are private business  dealings
    between the two parties and do not especially concern us.

 o  Billy Bob's prose is published  to the world using  the operations
    described earlier.


3.6 Dealing with the demise of a publisher


Poor Billy Bob.    The market for  Harley doggerel  was not enough  to
cover his yearly  storage fees and  his service  provider is about  to
evict his bits.  While the parent publisher will  never again register
an entity as ``HogDog  Press'' no one  is paying the service  provider
for the machine resources, so it  is time to remove the URLs  from the
URCs for Billy Bob's resources.

Accomplishing this  in the  presence of  digital  signatures could  be
a tricky  question.   Billy  will have  signed the  URC elements  with
HogDog's private key, and he is  not about to go along  willingly with
the eviction proceedings.  Of  course, he is not the  administrator of
the HTTP and  URC servers.   The administrator  of the servers  simply
clobbers the old  URC and replaces  it with one  that contains a  ``no
longer available'' element.  It can't be signed with  Billy Bob's key,
but so what?  Well, it leads to a form of denial of service attack.

Once the new URC is in place, the resources are deleted  from the HTTP
server.

This scenario requires us  to pay considerable  attention to who  will
sign URCs and URC components, how URCs might be nested  in other URCs,
etc.


Daniel and Mealling                                          [Page 15]


INTERNET-DRAFT     URC Scenarios and Requirements    November 21, 1994

4 Requirements


In each of  the scenarios above  we listed  any new requirements  that
would be placed on the URC and the URC service.  This section collects
those requirements into 2  categories:  requirements  on the URC,  and
requirements on the URC service.  Any proposed specifications  for the
URC and URC  service will need  to demonstrate how  they meet all  the
requirements, or demonstrate how  the requirements are unnecessary  or
in error.



4.1 Requirements on the URC


Machine Consumption A URC must be parsable by a computer.

Consistent External Representation In order for digital  signatures of
    the URC  information  to work,  and  to simplify  the  requirement
    for  parsability,  the   URC  must  have  a  consistent   external
    representation.

Transport Friendliness Related  to  the consistency  of  the  external
    representation, it must be possible to transport a  URC unmodified
    in the common Internet protocols, such as TCP, SMTP,  FTP, Telnet,
    etc.

Human Readability A  URC must have  a printed  representation that  is
    suitable for  printing on  paper, as  well as  suitable for  entry
    by means  of  being typed  by  a user  on  a  keyboard.    Digital
    signature information need not apply to such items given  the high
    probability of trivial differences.

    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.

Simplicity It must  be simple for  humans to generate correct  minimal
    URCs that do not carry any signature information.

Rearrangeability It  must be  possible to  reorder elements  in a  URC
    without changing  their semantics.    Note that  elements in  this
    case may  mean compound  entities.   The  compound entities  (such
    as  information  related  to  a  particular  location)  should  be
    rearrangeable, while the information inside the entity may need to
    have its order preserved.

Generality In the most basic sense, a URC must  be able to contain ANY
    conceivable type of meta-information or URI. Therefore it  must be
    possible to add new types of elements to the  URC without breaking
    previous applications.   Any restrictions on the  representational

Daniel and Mealling                                          [Page 16]


INTERNET-DRAFT     URC Scenarios and Requirements    November 21, 1994

    capability of a URC will be the target of intense scrutiny.

Structure In  accommodate  the  encapsulation  of   objects  that  are
    currently unforeseen,   have a  self-describing  structure.     We
    interpret this as meaning  that elements in  a URC must be  tagged
    with a  descriptive label  and it  must be  possible to  determine
    their extent, even in the presence of nesting.

Ignorability Related to  the previous  2 requirements, an  application
    encountering an  unknown tag  must be  able to  ignore it  without
    error.   This  implies  that it  must  be easy  to tell  where  an
    element stops, even if you don't know anything about  its internal
    structure.  Also note that nesting unknown elements  must still be
    handled correctly.

Searchable It must  be possible to select a  URC based on a  search of
    its components.   It must be  possible to select which  components
    will be searched and which will not be searched.

Subsettable It must  be possible to  form a new  URC from some of  the
    components of another URC.

Seperable It must  be possible to separate  a signature in a URC  from
    the information it signs.

Incrementally Modifiable It  must  be  possible  to  add  (or  delete)
    elements to (or from) a URC in an incremental fashion.  It must be
    possible to provide elements in a URC for tracking  the changes in
    a URC.

Versioning It must be  possible for a URC to track version  changes in
    the resource(s) it describes.   This  is related to, but  distinct
    from, the requirement that a URC be able to  track version changes
    in a URC.

Caching Caching should be  possible for any URC regardless  of whether
    or not any of its specific  elements are not cacheable.   Further,
    it must be possible to determine if a query has been answered from
    cached or authoritative URC information.

Grandfathering Current meta-information  schemes should be allowed  to
    work within the URC structure,  where this will not  conflict with
    the other requirements.



4.2 Requirements on the URC Service


The previous  section  discussed  requirements  on  the  encoding  and
functionality of single URCs.  This section presents  the requirements
we have derived for collections of  URCs sitting on a URC server,  and

Daniel and Mealling                                          [Page 17]


INTERNET-DRAFT     URC Scenarios and Requirements    November 21, 1994

that server's communication with applications.



Resolution It must be possible for a URN to be resolved into a URC.

    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.

Query Language It  must  be  possible for  simple  resolution  queries
    to be  augmented with  information on  the version  of a  resource
    desired, and an indication of whether signature information should
    be supplied.

Security Since  the   URC  service   will  be  providing   information
    of  significant  value,   it  will  be   a  tempting  target   for
    attack.    It  must be  possible  to secure  the  service  without
    imposing performance penalties on unauthenticated access  to free,
    unencrypted, information.

Authentication Chain One  aspect   of  the  general  requirement   for
    security is  that it  must be  possible to  establish  a chain  of
    authentication from  the URN,  through the  URC,  to the  resource
    retrieved through a URL.

Access Control Another aspect of security is that  it must be possible
    to control (at least) read and write access to portions of a URC.

Maintenance The URI  architecture is intended to  be long-lived.   The
    service must  not prevent  the maintenance  of  the resources  and
    their meta-information.

Synchronization If multiple  servers are  equally authoritative for  a
    publisher, they must work  with each other  to keep their URCs  in
    sync within a reasonable time delay.  This delay is certainly less
    than a week, but can be more than an hour.

Development URC servers must support the development  of new resources
    by issuing and handling "development" URNs and URCs.

Choice A  user must  be able to  connect to  a range  of URC  servers,
    and not have to  do all interaction through  one server that is  a
    gateway to the world.

Scalability In  order for  the system  to scale  to  large numbers  of
    users, queries  on  one URC  server  should not  automatically  be
    forwarded in such a fashion that  they will hit a large  number of
    other servers around the globe.



Daniel and Mealling                                          [Page 18]


INTERNET-DRAFT     URC Scenarios and Requirements    November 21, 1994

Administrative Contact There must  be a standard means for  contacting
    the administrator(s) of a server.

Hierarchical Operations A publisher  will have the rights to  register
    sub-publishers.

    The publisher  must  keep a  list  of  the sub-publishers  it  has
    created.

    That list  should be  available as  the result  of an  appropriate
    query to a server that speaks for the publisher.

    It must  be  possible  to  determine the  parent  publisher  of  a
    sub-publisher.



5 Characteristics


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 may  contain transient  information such  as
    timestamps, access privileges, etc.   it can not be  guaranteed to
    have a Time To Live greater than 0.   Any subset of a URC  is free
    to specify its own  TTL but this still  does not affect the  whole
    URC. 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 Fulfilling  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.

Member Element Control By  allowing any piece  meta-information to  be
    included within a URC  the number of globally understood  elements
    will be small  if not non-existent.    Therefore some entity  must
    have some  control  over some  set  of very  concretely  specified


Daniel and Mealling                                          [Page 19]


INTERNET-DRAFT     URC Scenarios and Requirements    November 21, 1994

    member elements.  The specification of that entity  should be done
    in an encoding specification and is outside the scope of this list
    of functional requirements.

Multiple Signatures To  accomodate the requirements  of insertion  and
    deletion in the presence of digital signatures, we anticipate that
    URCs will  be signed  using the  private key  of  a server.    The
    server's public key  would be  signed by  the private  key of  the
    publisher.   Entities with  the authority to  modify URC  elements
    will have to have their keys signed by the server.



References


 [1] Sollins,  K.  and  Masinter,   L.,  Functional  Requirements  for
     Uniform  Resource  Names,  <URL:ftp://cnri.reston.va.us/internet-
     drafts/draft-ietf-uri-urn-req-01.txt>

 [2] Rhine,             J.,             Interpedia           Homepage,
     <URL:http://www.hmc.edu/interpedia/index.html>



Glossary


Default URC The URC that is provided by the publisher of a resource.

Default URC server The  URC server(s)  that  can provide  the  default
    URCs for a publisher.

Local URC server The URC  server that a  user's browser is  configured
    to connect to as a first resort.

Development URN A  URN  used   while  developing  a  resource.      It
    starts  with  very  tight   access  controls  so  that  only   the
    resource developers and the  server administrator can see the  URC
    information and resolve the URN to a URL. The  access controls can
    be eased later.

value-added URC server A  server  that  provides more  than  just  the
    default information on  a resource.   Servers run by  professional
    organizations that  provide SOAPs  are one  example, servers  that
    keep full-text  indices  or n-grams  of  text  in order  to  offer
    greater search capabilities are another.

SOAP Seal  Of APproval -  A capsule  review of a  resource which  uses
    cyptographic techniques to provide guarantees on the source of the
    review and its authenticity.


Daniel and Mealling                                          [Page 20]


INTERNET-DRAFT     URC Scenarios and Requirements    November 21, 1994

Contact Information


Ron Daniel Jr.
MS B287
Los Alamos National Laboratory
Los Alamos, NM, USA 87545
voice:  (505) 665-0139
fax:  (505) 665-4939
rdaniel@lanl.gov


Michael Mealling
Office of Information Technology, Network Services
Georgia Institute of Technology
Atlanta, GA, USA 30332-0730
voice:  (404) 894-1712
fax:  (404) 894 9548
michael.mealling@oit.gatech.edu




    This Internet Draft expires May 25, 1995.





























Daniel and Mealling                                          [Page 21]