idnits 2.17.1 draft-hoffman-rescap-mua-00.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 current Internet-Drafts. ** 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 360 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract 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. ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. 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 (March 23, 1999) is 9163 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) ** Obsolete normative reference: RFC 2278 (ref. 'CHARSET') (Obsoleted by RFC 2978) ** Obsolete normative reference: RFC 2553 (ref. 'CONNEG') (Obsoleted by RFC 3493) -- Possible downref: Normative reference to a draft: ref. 'CONTENT-DISP' ** Obsolete normative reference: RFC 2305 (ref. 'IFAX-SIMPLE') (Obsoleted by RFC 3965) ** Obsolete normative reference: RFC 2447 (ref. 'IMIP') (Obsoleted by RFC 6047) ** Obsolete normative reference: RFC 1766 (ref. 'LANG') (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 2298 (ref. 'MDN') (Obsoleted by RFC 3798) ** Obsolete normative reference: RFC 2110 (ref. 'MHTML') (Obsoleted by RFC 2557) -- Possible downref: Normative reference to a draft: ref. 'MULTIPART-ONEPASS' ** Obsolete normative reference: RFC 2440 (ref. 'OPEN-PGP') (Obsoleted by RFC 4880) -- Possible downref: Normative reference to a draft: ref. 'SMIME-CERTDIST' Summary: 16 errors (**), 0 flaws (~~), 2 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Paul Hoffman 2 draft-hoffman-rescap-mua-00.txt Internet Mail Consortium 3 March 23, 1999 4 Expires in six months 6 Rescap Profile for Mail User Agents 8 Status of this memo 10 Internet-Drafts are working documents of the Internet Engineering 11 Task Force (IETF), its areas, and its working groups. Note that 12 other groups may also distribute working documents as 13 Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six 16 months and may be updated, replaced, or obsoleted by other 17 documents at any time. It is inappropriate to use Internet- 18 Drafts as reference material or to cite them other than as 19 "work in progress." 21 To view the list Internet-Draft Shadow Directories, see 22 http://www.ietf.org/shadow.html. 24 This document is an Internet-Draft and is in full conformance 25 with all provisions of Section 10 of RFC2026. 27 1. Introduction 29 This document defines a profile of the rescap protocol for mail user 30 agents (MUAs) and mail recipients. It describes the attributes that a 31 mail sender might want or need to know about a particular mail recipient 32 before sending a message. 34 The attributes are divided into four general categories: 35 - MIME handling 36 - S/MIME 37 - OpenPGP 38 - General 40 Note: this list is very preliminary. The process of defining the 41 requirements for rescap has just begun. Because the rescap protocol has 42 not even had a first draft, it is likely that there will be many 43 significant changes to this draft in the future as rescap gets worked 44 on. 46 In this document, "recipient" is used to indicate the user who can 47 accept mail at the URL provided in the rescap request and "sender" is 48 the person or process who requested the rescap information. Note that 49 some of the attributes in this document apply to the MUA a recipient is 50 using, while others apply directly to the mail recipient (which might 51 be a human or a mail-processing program). 53 The attributes described in this document are those that a mail sender 54 would want to know about a recipient or the recipient's MUA. Attributes 55 about the mail recipient that have no relevance to a mail sender (such 56 if the MUA uses IMAP to access its message store) are not included. 58 2. MIME Handling 60 The attributes in this section describe general MIME handling. They include 61 some specific MIME profiles as well as more general MIME characteristics. 63 Identifier: HandlesMIME 64 Value type: Boolean 65 Description: Conforms to [MIME-CONFORM], the general checklist for MIME 66 conformance. 68 Identifier: MIMEHeaderExtensions 69 Value type: Boolean 70 Description: Conforms to [MIME-HEADER-EXTENSIONS], which describes many 71 extensions for MIME headers, such as for non-ASCII characters. 73 Identifier: MIMEParamExtensions 74 Value type: Boolean 75 Description: Conforms to [MIME-PARAM], which describes many extensions 76 for MIME parameter values and encoded words. 78 Identifier: DisplayableMedia 79 Value type: Conneg string 80 Description: A list of MIME types and subtypes that are natively 81 displayed by the receiving MUA without falling back to a default media 82 type. The string is in the format of [CONNEG], as extended by 83 [CONNEG-MEDIA]. This string should contain only MIME types and subtypes, 84 not additional media features. 86 Identifier: MediaFeatures 87 Value type: Conneg string 88 Description: A list of media features of the MUA. The string is in the 89 format of [CONNEG]. 91 Identifier: CharsetsDisplayed 92 Value type: List of strings 93 Description: The list of charset labels that describe the charsets 94 [CHARSET] that can be displayed. The list is in order of preferred 95 charsets, highest preference first. 97 Identifier: PreferredLanguages 98 Value type: List of strings 99 Description: The lists of languages understandable to the recipient, as 100 described in [LANG]. The list is in order of preferred languages, 101 highest preference first. 103 Identifier: HandlesMHTML 104 Value type: Boolean 105 Description: Handles MHTML content natively, as described in [MHTML]. 107 Identifier: HandlesContentDisposition 108 Value type: List of strings 109 Description: Handles Conetent-Disposition headers, as described in 110 [CONTENT-DISP]. The strings must be "inline", "attachment", and 111 "metadata". If the MUA doesn't handle any Content-Disposition 112 headers, then the list should be empty. 114 Identifier: HandlesContentMD5 115 Value type: Boolean 116 Description: Handles Conetent-MD5 headers, as described in 117 [CONTENT-MD5]. 119 Identifier: HandlesMailingListURLs 120 Value type: Boolean 121 Description: Handles mailing list URL headers, as described in 122 [LIST-URLS]. 124 Identifier: HandlesPlainFormat 125 Value type: Boolean 126 Description: Handles the "format" parameter for the text/plain MIME 127 type, as described in [PLAIN-FORMAT]. 129 Identifier: HandlesOnePassMultipart 130 Value type: Boolean 131 Description: Handles the "types" parameter for the 132 multipart/alternative MIME type, as described in [MULTIPART-ONEPASS]. 134 Identifier: RepliesToMDNs 135 Value type: Boolean 136 Description: Is able to reply to message disposition notification 137 requests, as described in [MDN]. Note that this does not mean that the 138 client will necessarily send an MDN back to a particular request, just 139 that it is able to reply to such requests. 141 Identifier: CalendarClient 142 Value type: Boolean 143 Description: Can act as an iCalendar iMIP agent [IMIP]. 145 Identifier: FaxSimpleClient 146 Value type: Boolean 147 Description: Acts as a simple mode Internet FAX receiving agent 148 [IFAX-SIMPLE]. 150 Identifier: FaxExtendedClient 151 Value type: Boolean 152 Description: Acts as a extended mode Internet FAX receiving agent 153 [IFAX-EIFAX]. 155 3. S/MIME 157 The attributes in this section indicate the S/MIME capabilities of the 158 recipient as described in [SMIME-MSG], [SMIME-CERT], and associated 159 documents. 161 Note that some S/MIME public keys are used for both encrypting and 162 signing. This means that there may be duplicated certificates in the 163 SMIMESigningCertsBasic and SMIMEEncryptingCerts lists. 165 Identifier: SMIMEVerifiesSigned 166 Value type: List of strings 167 Description: Indicates that the recipient can verify the signatures on 168 S/MIME signed messages. The strings in the list indicate the type of 169 signatures accepted. The values currently are limited to "id-dsa" and 170 "rsaEncryption". The list is in decreasing order of preference. 172 Identifier: SMIMESigningCertsBasic 173 Value type: List of binary 174 Description: Provides the S/MIME certificates for public signing keys 175 of the recipient. The list is in decreasing order of preference. 177 Identifier: SMIMESigningCertsExtended 178 Value type: List of binary 179 Description: Provides the S/MIME certificates for public signing keys 180 of the recipient, including additional signed attributes, as described 181 in [SMIME-CERTDIST]. The list is in decreasing order of preference. 183 Identifier: SMIMEEncryptingCerts 184 Value type: List of binary 185 Description: Provides the S/MIME certificates for public encrypting 186 keys of the recipient. The list is in decreasing order of preference. 188 Identifier: SMIMEHigherCerts 189 Value type: List of binary 190 Description: Provides the S/MIME certificates for certificate 191 authorities that have signed the recipient's signing and encrypting 192 certificates. These higher-level certificates can be used by the sender 193 to validate the recipient's certificates. The list is in no particular 194 order. 196 Identifier: SMIMESignedReceipts 197 Value type: Boolean 198 Description: Responds to requests for S/MIME signed receipts described 199 in [SMIME-ESS]. 201 Identifier: SMIMESecurityLabels 202 Value type: Boolean 203 Description: Acts on S/MIME security labels, or is behind a gateway 204 that does security label handling, as described in [SMIME-ESS]. 206 Identifier: SMIMESecureMailingList 207 Value type: Boolean 208 Description: Is a a mailing list that uses secure mailing list 209 handling described in [SMIME-ESS]. 211 Identifier: SMIMEHandlesSigningCert 212 Value type: Boolean 213 Description: Handles the signed SigningCertificate attribute 214 described in [SMIME-ESS]. 216 4. OpenPGP 218 The attributes in this section indicate the OpenPGP capabilities of the 219 recipient as described in [OPEN-PGP] and associated documents. 221 Identifier: OpenPGPVerifiesSigned 222 Value type: List of strings 223 Description: Indicates that the recipient can verify the signatures on 224 OpenPGP signed messages. The strings in the list indicate the type of 225 signatures accepted. The values currently are limited to "DSA" and 226 "RSA". The list is in decreasing order of preference. 228 Identifier: OpenPGPSigningCertsBasic 229 Value type: List of binary 230 Description: Provides the OpenPGP certificates for public signing keys 231 of the recipient. The list is in decreasing order of preference. 233 Identifier: OpenPGPEncryptingCerts 234 Value type: List of binary 235 Description: Provides the OpenPGP certificates for public encrypting 236 keys of the recipient. The list is in decreasing order of preference. 238 Identifier: OpenPGPHigherCerts 239 Value type: List of binary 240 Description: Provides the OpenPGP certificates for users and 241 certificate authorities that have signed the recipient's signing and 242 encrypting certificates. These higher-level certificates can be used by 243 the sender to validate the recipient's certificates. The list is in no 244 particular order. 246 5. General 248 User agent and recipient attributes that don't fit into the other 249 categories appear in this section. 251 Identifier: UBEPrefernces 252 Value type: List of pairs of strings 253 Description: Specifies the preferences of the recipient for receiving 254 unsolicited bulk email (UBE). Each entry in the list is a pair of 255 strings. The first entry in the pair is a tag indicating the law or 256 policy being referred to, and the second entry is the value specified 257 for that law or policy. The identities of the laws and policies must be 258 registered with IANA. 260 6. Security Considerations 262 The rescap protocol will control the security of the passing the values 263 for the attributes described here. If digital signatures are not used, 264 an attacker can alter the values that the client receives from the 265 server, thereby causing false values or no values to be received. For 266 example, an attacker can change the legal notices sent, which can cause 267 damage to the named recipient. If encryption is not used, an attacker 268 can watch the values of the attributes as they are transmitted over the 269 Internet. 271 7. References 273 [CHARSET] "IANA Charset Registration Procedures", RFC 2278 275 [CONNEG] "A Syntax for Describing Media Feature Sets", RFC 2553. 277 [CONNEG-MEDIA] "MIME content types in media feature expressions", 278 draft-ietf-conneg-feature-type. 280 [CONTENT-DISP] "Communicating Presentation Information in Internet 281 Messages: The Content-Disposition Header", RFC 2183; and "Metadata 282 Content-Disposition Type", draft-newman-mime-cdisp-metadata. 284 [CONTENT-MD5] "The Content-MD5 Header Field", RFC 1864. 286 [IFAX-EIFAX] "Extended Facsimile Using Internet Mail", RFC 2532. 288 [IFAX-SIMPLE] "A Simple Mode of Facsimile Using Internet Mail", RFC 289 2305. 291 [IMIP] "iCalendar Message-Based Interoperability Protocol (iMIP)", RFC 292 2447. 294 [LANG] "Tags for the Identification of Languages", RFC 1766. 296 [LIST-URLS] "The Use of URLs as Meta-Syntax for Core Mail List Commands 297 and their Transport through Message Header Fields", RFC 2369. 299 [MDN] "An Extensible Message Format for Message Disposition 300 Notifications", RFC 2298. 302 [MHTML] "MIME E-mail Encapsulation of Aggregate Documents, such as HTML 303 (MHTML)", RFC 2110. 305 [MIME-CONFORM] "Multipurpose Internet Mail Extensions (MIME) Part Five: 306 Conformance Criteria and Examples", RFC 2049. 308 [MIME-HEADER-EXTENSIONS] "MIME (Multipurpose Internet Mail Extensions) 309 Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047. 311 [MIME-PARAM] "MIME Parameter Value and Encoded Word Extensions: 312 Character Sets, Languages, and Continuations", RFC 2231. 314 [MULTIPART-ONEPASS] "One Pass Multipart/Alternative Processing", 315 draft-lundblade-1pass-mult-alt. 317 [OPEN-PGP] "OpenPGP Message Format", RFC 2440. 319 [PLAIN-FORMAT] "The Text/Plain Format Parameter", draft-gellens-format. 321 [SMIME-CERT] "S/MIME Version 3 Certificate Handling", 322 draft-ietf-smime-cert. 324 [SMIME-CERTDIST] "Certificate Distribution Specification", 325 draft-ietf-smime-certdist. 327 [SMIME-ESS] "Enhanced Security Services for S/MIME", 328 draft-ietf-smime-ess. 330 [SMIME-MSG] "S/MIME Version 3 Message Specification", 331 draft-ietf-smime-msg. 333 A. IANA Registrations 335 A.1 Attribute Identifier Registrations 337 [[It is likely that all the attribute identifiers in this document will 338 need to be registered.]] 340 A.2 Additional Registrations 342 [[Registration of UCE law and policy identifiers]] 344 B. Author's Address 346 Paul Hoffman 347 Internet Mail Consortium 348 127 Segre Place 349 Santa Cruz, CA 95060 350 (831) 426-9827 351 phoffman@imc.org