idnits 2.17.1 draft-hoffman-rescap-mua-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 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == 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 393 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. 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 (November 20, 1999) is 8924 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 2447 (ref. 'IMIP') (Obsoleted by RFC 6047) ** Obsolete normative reference: RFC 1766 (ref. 'LANG') (Obsoleted by RFC 3066, RFC 3282) -- Duplicate reference: RFC2369, mentioned in 'MAILLIST', was also mentioned in 'LIST-URLS'. ** Obsolete normative reference: RFC 2298 (ref. 'MDN') (Obsoleted by RFC 3798) ** Obsolete normative reference: RFC 2110 (ref. 'MHTML') (Obsoleted by RFC 2557) ** Obsolete normative reference: RFC 2440 (ref. 'OPEN-PGP') (Obsoleted by RFC 4880) ** Obsolete normative reference: RFC 2632 (ref. 'SMIME-CERT') (Obsoleted by RFC 3850) -- Possible downref: Normative reference to a draft: ref. 'SMIME-CERTDIST' ** Obsolete normative reference: RFC 2633 (ref. 'SMIME-MSG') (Obsoleted by RFC 3851) ** Obsolete normative reference: RFC 2426 (ref. 'VCARD') (Obsoleted by RFC 6350) Summary: 15 errors (**), 0 flaws (~~), 2 warnings (==), 4 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-02.txt Internet Mail Consortium 3 November 20, 1999 4 Expires in six months 6 Rescap Profile for Mail User Agents 8 Status of this memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other 15 groups may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet- Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 1. Introduction 30 This document defines a profile of the rescap protocol for mail user 31 agents (MUAs) and mail recipients. It describes the attributes that a 32 mail sender might want or need to know about a particular mail 33 recipient before sending a message. 35 The attributes are divided into four general categories: 36 - MIME handling 37 - S/MIME 38 - OpenPGP 39 - General 41 Note: this list is very preliminary. The process of defining the 42 requirements for rescap has just begun. Because the rescap protocol has 43 not even had a first draft, it is likely that there will be many 44 significant changes to this draft in the future as rescap gets worked 45 on. 47 In this document, "recipient" is used to indicate the user who can 48 accept mail at the URL provided in the rescap request and "sender" is 49 the person or process who requested the rescap information. Note that 50 some of the attributes in this document apply to the MUA a recipient is 51 using, while others apply directly to the mail recipient (which might 52 be a human or a mail-processing program). 54 The attributes described in this document are those that a mail sender 55 would want to know about a recipient or the recipient's MUA. Attributes 56 about the mail recipient that have no relevance to a mail sender (such 57 if the MUA uses IMAP to access its message store) are not included. 59 2. MIME Handling 61 The attributes in this section describe general MIME handling. They 62 include some specific MIME profiles as well as more general MIME 63 characteristics. 65 Identifier: PlainTextOnly 66 Value type: Boolean 67 Description: Can only read single-part text/plain messages. Put 68 another way, cannot parse a MIME message. 70 Identifier: MIMEIntlHeaders 71 Value type: Boolean 72 Description: Conforms to [MIME-HEADER-EXTENSIONS], which describes 73 many extensions for MIME headers, such as for non-ASCII characters. 75 Identifier: MIMEParamExtensions 76 Value type: Boolean 77 Description: Conforms to [MIME-PARAM], which describes many extensions 78 for MIME parameter values and encoded words. 80 Identifier: DisplayableMedia 81 Value type: Conneg string 82 Description: A list of MIME types and subtypes that are natively 83 displayed by the receiving MUA without falling back to a default media 84 type. The string is in the format of [CONNEG], as extended by 85 [CONNEG-MEDIA]. This string should contain only MIME types and 86 subtypes, not additional media features. 88 Identifier: MediaFeatures 89 Value type: Conneg string 90 Description: A list of media features of the MUA. The string is in the 91 format of [CONNEG]. 93 Identifier: CharsetsDisplayed 94 Value type: Conneg string 95 Description: The list of charset labels that describe the charsets 96 [CHARSET] that can be displayed. Note that US-ASCII, and support for at 97 least the US-ASCII subset of ISO-8859-*, is assumed regardless of the 98 value of this attribute. The string is in the format of [CONNEG], using 99 the tags defined in [CONNEG-CHARLANG]. 101 Identifier: PreferredLanguages 102 Value type: List of strings 103 Description: The lists of languages understandable to the recipient, 104 as described in [LANG]. The string is in the format of [CONNEG], using 105 the tags defined in [CONNEG-CHARLANG]. 107 Identifier: LineLength 108 Value type: Integer 109 Description: The width, in characters, of a line in the display of the 110 MUA. For variable-width displays, this should be an estimate of the 111 number of characters per line from a typical mail message. For systems 112 that have no line limitations, this value should be set to 0. 114 Identifier: HandlesMHTML 115 Value type: Boolean 116 Description: Handles MHTML content natively, as described in [MHTML]. 118 Identifier: HandlesContentMD5 119 Value type: Boolean 120 Description: Handles Content-MD5 headers, as described in 121 [CONTENT-MD5]. If the recipient does not handle Content-MD5 headers, as 122 many don't, this the sender can save time by not constructing one. 124 Identifier: HandlesMailingListURLs 125 Value type: Boolean 126 Description: Handles mailing list URL headers, as described in 127 [LIST-URLS]. 129 Identifier: RepliesToMDNs 130 Value type: Boolean 131 Description: Is able to reply to message disposition notification 132 requests, as described in [MDN]. Note that this does not mean that the 133 client will necessarily send an MDN back to a particular request, just 134 that it is able to reply to such requests. This field helps a sending 135 MUA decide whether or not to keep track of the MDNs sent to the 136 recipient; if the recipient is known not to reply to MDNs, then the 137 sender doesn't need to track them. This can also reduce the size of 138 messages sent over bandwidth-restricted lines. 140 Identifier: CalendarClient 141 Value type: Boolean 142 Description: Can act as an iCalendar iMIP agent [IMIP]. 144 3. S/MIME 146 The attributes in this section indicate the S/MIME capabilities of the 147 recipient as described in [SMIME-MSG], [SMIME-CERT], and associated 148 documents. 150 Note that some S/MIME public keys are used for both encrypting and 151 signing. This means that there may be duplicated certificates in the 152 SMIMESigningCertsBasic and SMIMEEncryptingCerts lists. 154 Identifier: SMIMEVerifiesSigned 155 Value type: List of strings 156 Description: Indicates that the recipient can verify the signatures on 157 S/MIME signed messages. The strings in the list indicate the type of 158 signatures accepted. The values currently are limited to "id-dsa" and 159 "rsaEncryption". The list is in decreasing order of preference. 161 Identifier: SMIMESigningCertsBasic 162 Value type: List of binary 163 Description: Provides the S/MIME certificates for public signing keys 164 of the recipient. The list is in decreasing order of preference. 166 Identifier: SMIMESigningCertsExtended 167 Value type: List of binary 168 Description: Provides the S/MIME certificates for public signing keys 169 of the recipient, including additional signed attributes, as described 170 in [SMIME-CERTDIST]. The list is in decreasing order of preference. 172 Identifier: SMIMEEncryptingCerts 173 Value type: List of binary 174 Description: Provides the S/MIME certificates for public encrypting 175 keys of the recipient. The list is in decreasing order of preference. 177 Identifier: SMIMEHigherCerts 178 Value type: List of binary 179 Description: Provides the S/MIME certificates for certificate 180 authorities that have signed the recipient's signing and encrypting 181 certificates. These higher-level certificates can be used by the sender 182 to validate the recipient's certificates. The list is in no particular 183 order. 185 Identifier: SMIMESignedReceipts 186 Value type: Boolean 187 Description: Responds to requests for S/MIME signed receipts described 188 in [SMIME-ESS]. 190 Identifier: SMIMESecurityLabels 191 Value type: Boolean 192 Description: Acts on S/MIME security labels, or is behind a gateway 193 that does security label handling, as described in [SMIME-ESS]. 195 Identifier: SMIMESecureMailingList 196 Value type: Boolean 197 Description: Is a mailing list that uses secure mailing list 198 handling described in [SMIME-ESS]. 200 Identifier: SMIMEHandlesSigningCert 201 Value type: Boolean 202 Description: Handles the signed SigningCertificate attribute 203 described in [SMIME-ESS]. 205 4. OpenPGP 207 The attributes in this section indicate the OpenPGP capabilities of the 208 recipient as described in [OPEN-PGP] and associated documents. 210 Identifier: OpenPGPVerifiesSigned 211 Value type: List of strings 212 Description: Indicates that the recipient can verify the signatures on 213 OpenPGP signed messages. The strings in the list indicate the type of 214 signatures accepted. The values currently are limited to "DSA" and 215 "RSA". The list is in decreasing order of preference. 217 Identifier: OpenPGPSigningCertsBasic 218 Value type: List of binary 219 Description: Provides the OpenPGP certificates for public signing keys 220 of the recipient. The list is in decreasing order of preference. 222 Identifier: OpenPGPEncryptingCerts 223 Value type: List of binary 224 Description: Provides the OpenPGP certificates for public encrypting 225 keys of the recipient. The list is in decreasing order of preference. 227 Identifier: OpenPGPHigherCerts 228 Value type: List of binary 229 Description: Provides the OpenPGP certificates for users and 230 certificate authorities that have signed the recipient's signing and 231 encrypting certificates. These higher-level certificates can be used by 232 the sender to validate the recipient's certificates. The list is in no 233 particular order. 235 5. General 237 User agent and recipient attributes that don't fit into the other 238 categories appear in this section. 240 Identifier: UBEPrefernces 241 Value type: List of pairs of strings 242 Description: Specifies the preferences of the recipient for receiving 243 unsolicited bulk email (UBE). Each entry in the list is a pair of 244 strings. The first entry in the pair is a tag indicating the law or 245 policy being referred to, and the second entry is the value specified 246 for that law or policy. The identities of the laws and policies must be 247 registered with IANA. 249 Identifier: MailingListInfo 250 Value type: String 251 Description: Gives information about a mailing list. The format of the 252 information is single string consisting of RFC 822 headers, as 253 described in [MAILLIST]. If the recipient is not a mailing list and 254 this attribute is included in the rescap response, the string should be 255 empty. 257 Identifier: GeneralInfo 258 Value type: vCard string 259 Description: Gives information about the person or system that is 260 associated with the recipient. The information is returned in the vCard 261 format described in [VCARD]. Note that any information in this 262 attribute that can also be represented in other attributes in this 263 profile should also be delivered in the other attributes. No client 264 should have to retrieve the value for this attribute in order to get 265 information that is also available in other attributes. 267 Identifier: AssociatedEmailAddresses 268 Value type: List of lists 269 Description: Lists the email addresses used by this recipient. The 270 list contains items that contain a pair of string items. The pairs 271 consist of an email address and a description. The description should 272 be the strings "home", "work", "all", "unused". The "unused" term 273 indicates an email address that is no longer valid for the recipient. 275 6. Security Considerations 277 The rescap protocol will control the security of the passing the values 278 for the attributes described here. If digital signatures are not used, 279 an attacker can alter the values that the client receives from the 280 server, thereby causing false values or no values to be received. For 281 example, an attacker can change the legal notices sent, which can cause 282 damage to the named recipient. If encryption is not used, an attacker 283 can watch the values of the attributes as they are transmitted over the 284 Internet. 286 7. References 288 [CHARSET] "IANA Charset Registration Procedures", RFC 2278 290 [CONNEG] "A Syntax for Describing Media Feature Sets", RFC 2533. 292 [CONNEG-CHARLANG] "Registration of Charset and Languages Media Features 293 Tags", draft-hoffman-char-lang-media. 295 [CONNEG-MEDIA] "MIME content types in media feature expressions", 296 draft-ietf-conneg-feature-type. 298 [CONTENT-MD5] "The Content-MD5 Header Field", RFC 1864. 300 [IMIP] "iCalendar Message-Based Interoperability Protocol (iMIP)", RFC 301 2447. 303 [LANG] "Tags for the Identification of Languages", RFC 1766. 305 [LIST-URLS] "The Use of URLs as Meta-Syntax for Core Mail List Commands 306 and their Transport through Message Header Fields", RFC 2369. 308 [MAILLIST] "The Use of URLs as Meta-Syntax for Core Mail List Commands 309 and their Transport through Message Header Fields", RFC 2369. 311 [MDN] "An Extensible Message Format for Message Disposition 312 Notifications", RFC 2298. 314 [MHTML] "MIME E-mail Encapsulation of Aggregate Documents, such as HTML 315 (MHTML)", RFC 2110. 317 [MIME-HEADER-EXTENSIONS] "MIME (Multipurpose Internet Mail Extensions) 318 Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047. 320 [MIME-PARAM] "MIME Parameter Value and Encoded Word Extensions: 321 Character Sets, Languages, and Continuations", RFC 2231. 323 [OPEN-PGP] "OpenPGP Message Format", RFC 2440. 325 [SMIME-CERT] "S/MIME Version 3 Certificate Handling", 326 RFC 2632. 328 [SMIME-CERTDIST] "Certificate Distribution Specification", 329 draft-ietf-smime-certdist. 331 [SMIME-ESS] "Enhanced Security Services for S/MIME", 332 RFC 2634. 334 [SMIME-MSG] "S/MIME Version 3 Message Specification", 335 RFC 2633. 337 [VCARD] "vCard MIME Directory Profile", RFC 2426. 339 A. IANA Registrations 341 A.1 Attribute Identifier Registrations 343 [[It is likely that all the attribute identifiers in this document will 344 need to be registered.]] 346 A.2 Additional Registrations 348 [[Registration of UCE law and policy identifiers]] 350 B. Acknowledgments 352 The following people have contributed changes and additions to this 353 document: 355 Chris Newman 356 Graham Klyne 357 Larry Masinter 358 Tony Hansen 360 C. Changes between versions of the draft 362 C.1 Changes between -01 and -02 364 Corrected RFC number for [CONNEG]. 366 Changed CharsetsDisplayed and PreferredLanguages to conneg strings. 368 Added LineLegth. 370 Removed multipart-onepass because the feature is dead. 372 Added reference to [CONNEG-CHARLANG]. 374 Updated the S/MIME references to the RFCs. 376 D. Author's Address 378 Paul Hoffman 379 Internet Mail Consortium 380 127 Segre Place 381 Santa Cruz, CA 95060 382 phoffman@imc.org