idnits 2.17.1 draft-hoffman-rescap-mua-03.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 415 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** The abstract seems to contain references ([RESCAP-MAIN]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 (August 8, 2000) is 8655 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) -- Possible downref: Normative reference to a draft: ref. 'RESCAP-MAIN' ** 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 (==), 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-03.txt Internet Mail Consortium 3 August 8, 2000 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 Abstract 30 This document defines a profile of the rescap protocol [RESCAP-MAIN] for 31 mail user agents (MUAs) and mail recipients. It describes the attributes 32 that a mail sender might want or need to know about a particular mail 33 recipient before sending a message. 35 1. Introduction 37 The attributes described in this document are divided into four general 38 categories: 40 - MIME handling 41 - S/MIME 42 - OpenPGP 43 - General 45 In this document, "recipient" is used to indicate the user who can 46 accept mail at the URL provided in the rescap request and "sender" is 47 the person or process who requested the rescap information. Note that 48 some of the attributes in this document apply to the MUA a recipient is 49 using, while others apply directly to the mail recipient (which might 50 be a human or a mail-processing program). 52 The attributes described in this document are those that a mail sender 53 would want to know about a recipient or the recipient's MUA. Attributes 54 about the mail recipient that have no relevance to a mail sender (such 55 if the MUA uses IMAP to access its message store) are not included. 57 1.1 Value types 59 This document specifies a list of request-type items for rescap. 60 Each item specifies an indentifier and associated tag, a value 61 type which describes the format of the response-type associated 62 with the request, and a description. 64 The value types described in this document are: 66 Boolean: a one-octet value. x00 indicates false, and x01 indicates true. 68 Integer: a two-octect value that indicates an integer between 0 69 and 65535. 71 List of strings: a structure for strings. Each element of the structure 72 consists of a two-octet length, followed by a string of octets. 74 String: a string of octets. 76 2. MIME Handling 78 The attributes in this section describe general MIME handling. They 79 include some specific MIME profiles as well as more general MIME 80 characteristics. 82 Identifier: PlainTextOnly 83 Value type: Boolean 84 Description: Can only read single-part text/plain messages. Put 85 another way, cannot parse a MIME message. 87 Identifier: MIMEIntlHeaders 88 Value type: Boolean 89 Description: Conforms to [MIME-HEADER-EXTENSIONS], which describes 90 many extensions for MIME headers, such as for non-ASCII characters. 92 Identifier: MIMEParamExtensions 93 Value type: Boolean 94 Description: Conforms to [MIME-PARAM], which describes many extensions 95 for MIME parameter values and encoded words. 97 Identifier: DisplayableMedia 98 Value type: String 99 Description: A list of MIME types and subtypes that are natively 100 displayed by the receiving MUA without falling back to a default media 101 type. The string is in the format of [CONNEG], as extended by 102 [CONNEG-MEDIA]. This string should contain only MIME types and 103 subtypes, not additional media features. 105 Identifier: MediaFeatures 106 Value type: String 107 Description: A list of media features of the MUA. The string is in the 108 format of [CONNEG]. 110 Identifier: CharsetsDisplayed 111 Value type: String 112 Description: The list of charset labels that describe the charsets 113 [CHARSET] that can be displayed. Note that US-ASCII, and support for at 114 least the US-ASCII subset of ISO-8859-*, is assumed regardless of the 115 value of this attribute. The string is in the format of [CONNEG], using 116 the tags defined in [CONNEG-CHARLANG]. 118 Identifier: PreferredLanguages 119 Value type: List of strings 120 Description: The lists of languages understandable to the recipient, 121 as described in [LANG]. The string is in the format of [CONNEG], using 122 the tags defined in [CONNEG-CHARLANG]. 124 Identifier: LineLength 125 Value type: Integer 126 Description: The width, in characters, of a line in the display of the 127 MUA. For variable-width displays, this should be an estimate of the 128 number of characters per line (probably in "em widths") for a typical 129 mail message. For systems that have no line limitations, this value 130 should be set to 0. 132 Identifier: HandlesMHTML 133 Value type: Boolean 134 Description: Handles MHTML content natively, as described in [MHTML]. 136 Identifier: HandlesContentMD5 137 Value type: Boolean 138 Description: Handles Content-MD5 headers, as described in 139 [CONTENT-MD5]. If the recipient does not handle Content-MD5 headers, as 140 many don't, this the sender can save time by not constructing one. 142 Identifier: HandlesMailingListURLs 143 Value type: Boolean 144 Description: Handles mailing list URL headers, as described in 145 [LIST-URLS]. 147 Identifier: RepliesToMDNs 148 Value type: Boolean 149 Description: Is able to reply to message disposition notification 150 requests, as described in [MDN]. Note that this does not mean that the 151 client will necessarily send an MDN back to a particular request, just 152 that it is able to reply to such requests. This field helps a sending 153 MUA decide whether or not to keep track of the MDNs sent to the 154 recipient; if the recipient is known not to reply to MDNs, then the 155 sender doesn't need to track them. This can also reduce the size of 156 messages sent over bandwidth-restricted lines. 158 Identifier: CalendarClient 159 Value type: Boolean 160 Description: Can act as an iCalendar iMIP agent [IMIP]. 162 3. S/MIME 164 The attributes in this section indicate the S/MIME capabilities of the 165 recipient as described in [SMIME-MSG], [SMIME-CERT], and associated 166 documents. 168 Note that some S/MIME public keys are used for both encrypting and 169 signing. This means that there may be duplicated certificates in the 170 SMIMESigningCertsBasic and SMIMEEncryptingCerts lists. 172 Identifier: SMIMEVerifiesSigned 173 Value type: List of strings 174 Description: Indicates that the recipient can verify the signatures on 175 S/MIME signed messages. The strings in the list indicate the type of 176 signatures accepted. The values currently are limited to "id-dsa" and 177 "rsaEncryption". The list is in decreasing order of preference. 179 Identifier: SMIMESigningCertsBasic 180 Value type: List of strings 181 Description: Provides the S/MIME certificates for public signing keys 182 of the recipient. The list is in decreasing order of preference. 184 Identifier: SMIMESigningCertsExtended 185 Value type: List of strings 186 Description: Provides the S/MIME certificates for public signing keys 187 of the recipient, including additional signed attributes, as described 188 in [SMIME-CERTDIST]. The list is in decreasing order of preference. 190 Identifier: SMIMEEncryptingCerts 191 Value type: List of strings 192 Description: Provides the S/MIME certificates for public encrypting 193 keys of the recipient. The list is in decreasing order of preference. 195 Identifier: SMIMEHigherCerts 196 Value type: List of strings 197 Description: Provides the S/MIME certificates for certificate 198 authorities that have signed the recipient's signing and encrypting 199 certificates. These higher-level certificates can be used by the sender 200 to validate the recipient's certificates. The list is in no particular 201 order. 203 Identifier: SMIMESignedReceipts 204 Value type: Boolean 205 Description: Responds to requests for S/MIME signed receipts described 206 in [SMIME-ESS]. 208 Identifier: SMIMESecurityLabels 209 Value type: Boolean 210 Description: Acts on S/MIME security labels, or is behind a gateway 211 that does security label handling, as described in [SMIME-ESS]. 213 Identifier: SMIMESecureMailingList 214 Value type: Boolean 215 Description: Is a mailing list that uses secure mailing list 216 handling described in [SMIME-ESS]. 218 Identifier: SMIMEHandlesSigningCert 219 Value type: Boolean 220 Description: Handles the signed SigningCertificate attribute 221 described in [SMIME-ESS]. 223 4. OpenPGP 225 The attributes in this section indicate the OpenPGP capabilities of the 226 recipient as described in [OPEN-PGP] and associated documents. 228 Identifier: OpenPGPVerifiesSigned 229 Value type: List of strings 230 Description: Indicates that the recipient can verify the signatures on 231 OpenPGP signed messages. The strings in the list indicate the type of 232 signatures accepted. The values currently are limited to "DSA" and 233 "RSA". The list is in decreasing order of preference. 235 Identifier: OpenPGPSigningCertsBasic 236 Value type: List of strings 237 Description: Provides the OpenPGP certificates for public signing keys 238 of the recipient. The list is in decreasing order of preference. 240 Identifier: OpenPGPEncryptingCerts 241 Value type: List of strings 242 Description: Provides the OpenPGP certificates for public encrypting 243 keys of the recipient. The list is in decreasing order of preference. 245 Identifier: OpenPGPHigherCerts 246 Value type: List of strings 247 Description: Provides the OpenPGP certificates for users and 248 certificate authorities that have signed the recipient's signing and 249 encrypting certificates. These higher-level certificates can be used by 250 the sender to validate the recipient's certificates. The list is in no 251 particular order. 253 5. General 255 User agent and recipient attributes that don't fit into the other 256 categories appear in this section. 258 Identifier: UBEPrefernces 259 Value type: List of strings 260 Description: Specifies the preferences of the recipient for receiving 261 unsolicited bulk email (UBE). Each entry in the list consists of two 262 sub-strings that are separated by a vertical bar character ("|", ASCII 263 0x7C). The first substring is a tag indicating the law or policy being 264 referred to, and the second substring is the value specified for that 265 law or policy. The identities of the laws and policies must be 266 registered with IANA. 268 Identifier: MailingListInfo 269 Value type: String 270 Description: Gives information about a mailing list. The format of the 271 information is single string consisting of RFC 822 headers, as 272 described in [MAILLIST]. If the recipient is not a mailing list and 273 this attribute is included in the rescap response, the string should be 274 empty. 276 Identifier: GeneralInfo 277 Value type: String 278 Description: Gives information about the person or system that is 279 associated with the recipient. The information is returned in the vCard 280 format described in [VCARD]. Note that any information in this 281 attribute that can also be represented in other attributes in this 282 profile should also be delivered in the other attributes. No client 283 should have to retrieve the value for this attribute in order to get 284 information that is also available in other attributes. 286 Identifier: AssociatedEmailAddresses 287 Value type: List of strings 288 Description: Lists the email addresses used by this recipient. Each 289 entry in the list consists of two sub-strings that are separated by a 290 vertical bar character ("|", ASCII 0x7C). The first sub-string is an 291 email address, and the second sub-string a description. The description 292 should be the strings "home", "work", "all", "unused". The "unused" term 293 indicates an email address that is no longer valid for the recipient. 294 Note that this attribute could be used by an unscrupulous marketer to 295 obtain additional addresses to which they can send UBE. 297 6. Security Considerations 299 The rescap protocol will control the security of the passing the values 300 for the attributes described here. If authentication is not used, an 301 attacker can alter the values that the client receives from the server, 302 thereby causing false values or no values to be received. For example, 303 an attacker can change the legal notices sent, which can cause damage 304 to the named recipient. If encryption is not used, an attacker can 305 watch the values of the attributes as they are transmitted over the 306 Internet. 308 7. References 310 [CHARSET] "IANA Charset Registration Procedures", RFC 2278 312 [CONNEG] "A Syntax for Describing Media Feature Sets", RFC 2533. 314 [CONNEG-CHARLANG] "Registration of Charset and Languages Media Features 315 Tags", draft-hoffman-char-lang-media. 317 [CONNEG-MEDIA] "MIME content types in media feature expressions", 318 draft-ietf-conneg-feature-type. 320 [CONTENT-MD5] "The Content-MD5 Header Field", RFC 1864. 322 [IMIP] "iCalendar Message-Based Interoperability Protocol (iMIP)", RFC 323 2447. 325 [LANG] "Tags for the Identification of Languages", RFC 1766. 327 [LIST-URLS] "The Use of URLs as Meta-Syntax for Core Mail List Commands 328 and their Transport through Message Header Fields", RFC 2369. 330 [MAILLIST] "The Use of URLs as Meta-Syntax for Core Mail List Commands 331 and their Transport through Message Header Fields", RFC 2369. 333 [MDN] "An Extensible Message Format for Message Disposition 334 Notifications", RFC 2298. 336 [MHTML] "MIME E-mail Encapsulation of Aggregate Documents, such as HTML 337 (MHTML)", RFC 2110. 339 [MIME-HEADER-EXTENSIONS] "MIME (Multipurpose Internet Mail Extensions) 340 Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047. 342 [MIME-PARAM] "MIME Parameter Value and Encoded Word Extensions: 343 Character Sets, Languages, and Continuations", RFC 2231. 345 [OPEN-PGP] "OpenPGP Message Format", RFC 2440. 347 [RESCAP-MAIN] "The rescap Resolution Protocol", 348 draft-ietf-rescap-proto-main. 350 [SMIME-CERT] "S/MIME Version 3 Certificate Handling", 351 RFC 2632. 353 [SMIME-CERTDIST] "Certificate Distribution Specification", 354 draft-ietf-smime-certdist. 356 [SMIME-ESS] "Enhanced Security Services for S/MIME", 357 RFC 2634. 359 [SMIME-MSG] "S/MIME Version 3 Message Specification", 360 RFC 2633. 362 [VCARD] "vCard MIME Directory Profile", RFC 2426. 364 A. IANA Registrations 366 A.1 Attribute Identifier Registrations 368 [[All the attribute identifiers in this document will 369 need to be registered.]] 371 A.2 Additional Registrations 373 [[Registration of UCE law and policy identifiers]] 375 B. Acknowledgments 377 The following people have contributed changes and additions to this 378 document: 380 Chris Newman 381 Graham Klyne 382 Larry Masinter 383 Tony Hansen 385 C. Changes between versions of the draft 387 C.1 Changes between -02 and -03 389 Added section 1.1. 391 Added sentence about UBE to AssociatedEmailAddresses. 393 Added the note about em widths in LineLength. 395 Got rid of list of pairs of strings for simplicity. 397 D. Author's Address 399 Paul Hoffman 400 Internet Mail Consortium 401 127 Segre Place 402 Santa Cruz, CA 95060 403 phoffman@imc.org