Internet Draft                                                 John Beck
Document: draft-beck-rescap-req-00.txt                  Sun Microsystems
April 15, 1999
Expires October 15, 1999


                      ResCap Requirements


Status of this memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026.

   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 view the list Internet-Draft Shadow Directories, see
   http://www.ietf.org/shadow.html.

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt


Abstract

   A variety of resource identifiers have been widely deployed on the
   Internet as a means of identifying various resources, services, and
   destinations.  However, a means of attaching a set of attributes or
   characteristics to a given resource identifier and subsequently
   assessing those attributes or characteristics has not been specified
   and deployed.

   A particularly important resolution service of this general type is
   one which, when given a mail address identifying a particular mail
   recipient, will return a series of attributes describing the
   capabilities of that recipient.  This differs from a directory
   service in that no searching or other advanced query operations are
   involved.

   Two tasks are envisioned.  The first task will be to define a general
   resolution protocol that will translate resource identifiers to a
   list of attributes.  The second task will be to define an
   administrative model and update protocol that can be used to set
   up and maintain the information the resolution protocol accesses.

   This document defines the requirements for these two protocols.


0. Discussion

   This draft is being discussed on the ResCap mailing list at
   <rescap@cs.utk.edu>.  Subscription requests can be sent to
   <rescap-request@cs.utk.edu> (send an email message with the
   word "subscribe" in the body).  More information on the mailing
   list along with an archive of back messages is available at
   <ftp://cs.utk.edu/pub/rescap>.


1. Resolution protocol requirements

   [Work in progress: an example is needed for each requirement.]

   Throughout the rest of this section, "the protocol" refers to the
   resolution protocol.

   1.1 Scalability

       The protocol must be highly scalable both for number of entries
       in the database and number of entries per second resolved.

   1.2 Long replies

       Conneg [CONNEG] needs the ability to return arbitrarily long
       text.  This may present a problem with using UDP. [UDP]

   1.3 Granularity

       A mechanism needs to exist whereby a subset of capabilities for
       a resource can be fetched.  I.e., the protocol request syntax
       should be able ask for one or more features instead of all of
       them at once.  However, the client also needs to be able to ask
       for all capabilities known to the server without naming all of
       them.

   1.4 Expiration

       Some sort of time to live (TTL) mechanism is needed.  This
       might also be expressed as a fixed time in the future that
       the information should be considered stale.

   1.5 Referral

       Some sort of request referral mechanism is needed.  In other
       words, the protocol must support a mechanism whereby a response
       can indicate "I don't know, but go ask the ResCap server at
       address X."

   1.6 Privacy

       The protocol must be able to handle authenticated queries.
       The protocol must also support transmission of signed and/or
       encrypted responses.

   1.7 Server location

       SRV and/or NAPTR resource records should be used to determine a
       protocol server.  [SRV, NAPTR]

   1.8 Preference

       For a set of capabilities, there should be a means to indicate a
       preferred value.


2. Administrative update protocol requirements

   [Work in progress: an example is needed for each requirement.]

   Throughout the rest of this section, "the protocol" refers to the
   administrative update protocol.

   2.1 Access control

       Administrators need to be able to control access to updating the
       database.  Specifically, controls on which attributes will be
       announced should exist.

   2.2 Privacy

       The protocol must support storing pre-signed data, which means
       that the protocol must support local signing after updates.

   2.3 Inheritance

       The protocol must support inheritance.


3. Security Considerations

   Security issues are discussed in sections 1.6, 2.1 and 2.2 of this
   memo.


4. References

   [CONNEG] "A Syntax for Describing Media Feature Sets", RFC 2553.

   [CONNEG-MEDIA] "MIME content types in media feature expressions",
   draft-ietf-conneg-feature-type.

   [NAPTR] "Resolution of Uniform Resource Identifiers using the
   Domain Name System", RFC 2168.

   [SRV] "A DNS RR for specifying the location of services (DNS SRV)",
   RFC 2052.

   [UDP] "User Datagram Protocol", RFC 768.


5. Author's Address

   John Beck
   Sun Microsystems
   901 San Antonio Road
   M/S U-MPk-17-202
   Palo Alto, CA  94303-4900
   (650) 786-8078
   jbeck+rescap@eng.sun.com