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