idnits 2.17.1 draft-beck-rescap-req-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 224 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 15, 1999) is 8898 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'CONNEG-MEDIA' is defined on line 204, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2553 (ref. 'CONNEG') (Obsoleted by RFC 3493) ** Obsolete normative reference: RFC 2168 (ref. 'NAPTR') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) ** Obsolete normative reference: RFC 2052 (ref. 'SRV') (Obsoleted by RFC 2782) Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft John Beck 2 Document: draft-beck-rescap-req-02.txt Sun Microsystems 3 June 15, 1999 4 Expires December 15, 1999 6 ResCap Requirements 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 To view the list Internet-Draft Shadow Directories, see 24 http://www.ietf.org/shadow.html. 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt 29 Abstract 31 A variety of resource identifiers have been widely deployed on the 32 Internet as a means of identifying various resources, services, and 33 destinations. However, a means of attaching a set of attributes or 34 characteristics to a given resource identifier and subsequently 35 assessing those attributes or characteristics has not been specified 36 and deployed. 38 A particularly important resolution service of this general type is 39 one which, when given a mail address identifying a particular mail 40 recipient, will return a series of attributes describing the 41 capabilities of that recipient. This differs from a directory 42 service in that no searching or other advanced query operations are 43 involved. Likewise; this is not a discovery protocol. 45 Two tasks are envisioned. The first task will be to define a general 46 resolution protocol that will translate resource identifiers to a 47 list of attributes. The second task will be to define an 48 administrative model and update protocol that can be used to set 49 up and maintain the information the resolution protocol accesses. 51 This document defines the requirements for these two protocols. 53 0. Discussion 55 This draft is being discussed on the ResCap mailing list at 56 . Subscription requests can be sent to 57 (send an email message with the 58 word "subscribe" in the body). More information on the mailing 59 list along with an archive of back messages is available at 60 . 62 1. Resolution protocol requirements 64 Throughout the rest of this section, "the protocol" refers to the 65 resolution protocol. 67 1.1 Scalability 69 The protocol must be highly scalable both for number of entries 70 in the database and number of entries per second resolved. 72 Example: Mail services with tens of millions of users could 73 easily expect tens of millions of requests per day for client 74 attribute information. 76 1.2 Reply data 78 The protocol should be capable of returning resource capabilities 79 that are arbitrarily long text or binary values. (E.g., Conneg 80 [CONNEG] uses arbitrary length text values; public key 81 certificates are arbitrary length binary values; etc.) Such data 82 might overflow a UDP datagram, so the protocol must allow for 83 this; however, the default should be to use UDP. [UDP] 85 Example: Lists of media features or S/MIME certificates can 86 easily be longer than a single UDP datagram. 88 1.3 Granularity 90 A mechanism needs to exist whereby a subset of capabilities for 91 a resource can be fetched. I.e., the protocol request syntax 92 should be able ask for one or more features instead of all of 93 them at once. However, the client also needs to be able to ask 94 for all capabilities known to the server without naming all of 95 them. 97 Example: A client might only want to know the S/MIME capabilities 98 of a recipient, but not care about its media features. 100 1.4 Expiration 102 Some means to indicate the expected lifetime of a capability 103 is required, so that a client application can judge whether, 104 or when, the information should be considered stale. 106 The protocol should also support a mechanism for indicating the 107 "last changed date" of a given attribute. 109 Example: The server may believe that the recipient is only 110 temporarily unable to receive large mail messages. 112 1.5 Referral 114 Some sort of request referral mechanism is needed. In other 115 words, the protocol must support a mechanism whereby a response 116 can indicate "I don't know, but go ask the ResCap server at 117 address X." or "use the following URL to retrieve the ResCap 118 response you requested." That is, the response might be a simple 119 DNS name, or it might be a full ResCap URL. 121 Example: A server might delegate all requests for S/MIME 122 certificate information to a different server that keeps track 123 of that type of information. 125 1.6 Security 127 The protocol must be able to handle authenticated queries. 128 The protocol must also support transmission of signed and/or 129 encrypted responses. The protocol should allow for a server to 130 "pre-sign" responses, meaning that the server could sign part of 131 a response off-line so it could present this over and over. 132 Controls on which attributes will be announced should exist. 134 Example: A server might give less information to a client that 135 is unauthenticated than to one that is authenticated. Some 136 information from the server may be important enough for the 137 server to want to prevent tampering, or even to prevent snoopers 138 from reading. 140 1.7 Server location 142 SRV and/or NAPTR resource records may be used to determine a 143 protocol server. [SRV, NAPTR] 145 Example: The ResCap server that is running on the host 146 "example.com" might not be the ResCap server for all resources 147 that have the host "example.com", such as if the administrator 148 at "example.com" had outsourced ResCap services for some resource 149 types to another company. 151 1.8 Preference 153 For a set of capabilities, there should be a means to indicate a 154 preferred value or a ranking of preference. 156 Example: A recipient might strongly prefer image/tiff files over 157 image/jpeg because s/he can display image/tiff on his/her system 158 without launching an external application. 160 1.9 Simplicity 162 The protocol should be sufficiently simple that it allows 163 implementation of client and/or server functionality in very 164 small, low cost devices (e.g. telephones, modems, printers, 165 smart-cards, etc.). 167 2. Administrative update protocol requirements 169 Throughout the rest of this section, "the protocol" refers to the 170 administrative update protocol. 172 2.1 Access control 174 Authentication of anyone updating the database is required. 176 Example: Individual mail users should be able to update some or 177 all of the information about them in the database, but such 178 updates must be done with authentication to prevent others from 179 maliciously entering false information. 181 2.2 Inheritance 183 The protocol must support inheritance. Specifically, mechanisms 184 must be provided by which administrators can set default values 185 for members of their administrative domains. 187 Example: The media features for all addresses at a particular 188 mail server might be the same because the mail server processes 189 all messages at all addresses. 191 3. Security Considerations 193 Security issues are discussed in sections 1.6 and 2.1 of this memo. 195 4. Acknowledgements 197 The author would like to thank Paul Hoffman and Graham Klyne for 198 their assistance. 200 5. References 202 [CONNEG] "A Syntax for Describing Media Feature Sets", RFC 2553. 204 [CONNEG-MEDIA] "MIME content types in media feature expressions", 205 draft-ietf-conneg-feature-type. 207 [NAPTR] "Resolution of Uniform Resource Identifiers using the 208 Domain Name System", RFC 2168. 210 [SRV] "A DNS RR for specifying the location of services (DNS SRV)", 211 RFC 2052. 213 [UDP] "User Datagram Protocol", RFC 768. 215 6. Author's Address 217 John Beck 218 Sun Microsystems 219 901 San Antonio Road 220 M/S U-MPk-17-202 221 Palo Alto, CA 94303-4900 222 (650) 786-8078 223 jbeck+rescap@eng.sun.com