idnits 2.17.1 draft-ietf-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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (June 24, 2002) is 7975 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) -- Looks like a reference, but probably isn't: 'CONNEG-CHARLANG' on line 125 -- Looks like a reference, but probably isn't: 'LIST-URLS' on line 148 ** Obsolete normative reference: RFC 1766 (ref. '1') (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 2110 (ref. '4') (Obsoleted by RFC 2557) ** Obsolete normative reference: RFC 2278 (ref. '6') (Obsoleted by RFC 2978) ** Obsolete normative reference: RFC 2298 (ref. '7') (Obsoleted by RFC 3798) ** Obsolete normative reference: RFC 2426 (ref. '9') (Obsoleted by RFC 6350) ** Obsolete normative reference: RFC 2440 (ref. '10') (Obsoleted by RFC 4880) ** Obsolete normative reference: RFC 2447 (ref. '11') (Obsoleted by RFC 6047) ** Obsolete normative reference: RFC 2632 (ref. '13') (Obsoleted by RFC 3850) ** Obsolete normative reference: RFC 2633 (ref. '14') (Obsoleted by RFC 3851) Summary: 11 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 RESCAP P. Hoffman 3 Internet-Draft Internet Mail Consortium 4 Expires: December 23, 2002 June 24, 2002 6 RESCAP Profile for Mail User Agents 7 draft-ietf-rescap-mua-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on December 23, 2002. 32 Copyright Notice 34 Copyright (C) The Internet Society (2002). All Rights Reserved. 36 Abstract 38 This document defines RESCAP Attributes for Mail User Agents (MUAs) 39 and mail recipients. Values for these attributes will contain 40 information that a mail sender might want or need to know about a 41 particular mail recipient before sending a message. 43 1. Introduction 45 This document defines Attributes for the RESCAP protocol for mail 46 user agents (MUAs) and mail recipients. It describes the attributes 47 that a mail sender might want or need to know about a particular mail 48 recipient before sending a message. 50 The attributes are divided into four general categories: 52 o MIME handling 54 o S/MIME 56 o OpenPGP 58 o General 60 Note: this list is very preliminary. The process of defining the 61 requirements for rescap has just begun. Because the rescap protocol 62 has not even had a first draft, it is likely that there will be many 63 significant changes to this draft in the future as rescap gets worked 64 on. 66 In this document, "recipient" is used to indicate the user who can 67 accept mail at the URL provided in the rescap request and "sender" is 68 the person or process who requested the rescap information. Note 69 that some of the attributes in this document apply to the MUA a 70 recipient is using, while others apply directly to the mail recipient 71 (which might be a human or a mail-processing program). 73 The attributes described in this document are those that a mail 74 sender would want to know about a recipient or the recipient's MUA. 75 Attributes about the mail recipient that have no relevance to a mail 76 sender (such if the MUA uses IMAP to access its message store) are 77 not included. 79 2. MIME Handling 81 The attributes in this section describe general MIME handling. They 82 include some specific MIME profiles as well as more general MIME 83 characteristics. 85 Identifier: urn:ietf:params:rescap:mua:PlainTextOnly 86 Value type: Boolean ("0" or "1") 87 Description: Can only read single-part text/plain messages. Put 88 another way, cannot parse a MIME message. 90 Identifier: urn:ietf:params:rescap:mua:MIMEIntlHeaders 91 Value type: Boolean ("0" or "1") 92 Description: Conforms to [3], which describes many extensions for 93 MIME headers, such as for non-ASCII characters. 95 Identifier: urn:ietf:params:rescap:mua:MIMEParamExtensions 96 Value type: Boolean ("0" or "1") 97 Description: Conforms to [5], which describes many extensions for 98 MIME parameter values and encoded words. 100 Identifier: urn:ietf:params:rescap:mua:DisplayableMedia 101 Value type: String 102 Description: A list of MIME types and subtypes that are natively 103 displayed by the receiving MUA without falling back to a default 104 media type. The string is in the format of [12], as extended by 105 [16]. This string should contain only MIME types and subtypes, 106 not additional media features. 108 Identifier: urn:ietf:params:rescap:mua:MediaFeatures 109 Value type: String 110 Description: A list of media features of the MUA. The string is 111 in the format of [12]. 113 Identifier: urn:ietf:params:rescap:mua:CharsetsDisplayed 114 Value type: Conneg string 115 Description: The list of charset labels that describe the 116 charsets [6] that can be displayed. Note that US-ASCII, and 117 support for at least the US-ASCII subset of ISO-8859-*, is assumed 118 regardless of the value of this attribute. The string is in the 119 format of [12], using the tags defined in [17]. 121 Identifier: urn:ietf:params:rescap:mua:PreferredLanguages 122 Value type: List of strings 123 Description: The lists of languages understandable to the 124 recipient, as described in [1]. The string is in the format of 125 [12], using the tags defined in [CONNEG-CHARLANG]. 127 Identifier: urn:ietf:params:rescap:mua:LineLength 128 Value type: Integer 129 Description: The width, in characters, of a line in the display 130 of the MUA. For variable-width displays, this should be an 131 estimate of the number of characters per line from a typical mail 132 message. For systems that have no line limitations, this value 133 should be set to 0. 135 Identifier: urn:ietf:params:rescap:mua:HandlesMHTML 136 Value type: Boolean ("0" or "1) 137 Description: Handles MHTML content natively, as described in [4]. 139 Identifier: urn:ietf:params:rescap:mua:HandlesContentMD5 140 Value type: Boolean ("0" or "1") 141 Description: Handles Content-MD5 headers, as described in [2]. 142 If the recipient does not handle Content-MD5 headers, as many 143 don't, this the sender can save time by not constructing one. 145 Identifier: urn:ietf:params:rescap:mua:HandlesMailingListURLs 146 Value type: Boolean ("0" or "1") 147 Description: Handles mailing list URL headers, as described in 148 [LIST-URLS]. 150 Identifier: urn:ietf:params:rescap:mua:RepliesToMDNs 151 Value type: Boolean ("0" or "1") 152 Description: Is able to reply to message disposition notification 153 requests, as described in [7]. Note that this does not mean that 154 the client will necessarily send an MDN back to a particular 155 request, just that it is able to reply to such requests. This 156 field helps a sending MUA decide whether or not to keep track of 157 the MDNs sent to the recipient; if the recipient is known not to 158 reply to MDNs, then the sender doesn't need to track them. This 159 can also reduce the size of messages sent over bandwidth- 160 restricted lines. 162 Identifier: urn:ietf:params:rescap:mua:CalendarClient 163 Value type: Boolean ("0" or "1") 164 Description: Can act as an iCalendar iMIP agent [11]. 166 3. S/MIME 168 The attributes in this section indicate the S/MIME capabilities of 169 the recipient as described in [14], [13], and associated documents. 171 Note that some S/MIME public keys are used for both encrypting and 172 signing. This means that there may be duplicated certificates in the 173 SMIMESigningCertsBasic and SMIMEEncryptingCerts lists. 175 Identifier: urn:ietf:params:rescap:mua:SMIMEVerifiesSigned 176 Value type: List of strings 177 Description: Indicates that the recipient can verify the 178 signatures on S/MIME signed messages. The strings in the list 179 indicate the type of signatures accepted. The values currently 180 are limited to "id-dsa" and "rsaEncryption". The list is in 181 decreasing order of preference. 183 Identifier: urn:ietf:params:rescap:mua:SMIMESigningCertsBasic 184 Value type: List of strings 185 Description: Provides the S/MIME certificates for public signing 186 keys of the recipient. The list is in decreasing order of 187 preference. 189 Identifier: urn:ietf:params:rescap:mua:SMIMESigningCertsExtended 190 Value type: List of strings 191 Description: Provides the S/MIME certificates for public signing 192 keys of the recipient. The list is in decreasing order of 193 preference. 195 Identifier: urn:ietf:params:rescap:mua:SMIMEEncryptingCerts 196 Value type: List of strings 197 Description: Provides the S/MIME certificates for public 198 encrypting keys of the recipient. The list is in decreasing order 199 of preference. 201 Identifier: urn:ietf:params:rescap:mua:SMIMEHigherCerts 202 Value type: List of strings 203 Description: Provides the S/MIME certificates for certificate 204 authorities that have signed the recipient's signing and 205 encrypting certificates. These higher-level certificates can be 206 used by the sender to validate the recipient's certificates. The 207 list is in no particular order. 209 Identifier: urn:ietf:params:rescap:mua:SMIMESignedReceipts 210 Value type: Boolean ("0" or "1") 211 Description: Responds to requests for S/MIME signed receipts 212 described in [15]. 214 Identifier: urn:ietf:params:rescap:mua:SMIMESecurityLabels 215 Value type: Boolean ("0" or "1") 216 Description: Acts on S/MIME security labels, or is behind a 217 gateway that does security label handling, as described in [15]. 219 Identifier: urn:ietf:params:rescap:mua:SMIMESecureMailingList 220 Value type: Boolean ("0" or "1") 221 Description: Is a mailing list that uses secure mailing list 222 handling described in [15]. 224 Identifier: urn:ietf:params:rescap:mua:SMIMEHandlesSigningCert 225 Value type: Boolean ("0" or "1") 226 Description: Handles the signed SigningCertificate attribute 227 described in [15]. 229 4. OpenPGP 231 The attributes in this section indicate the OpenPGP capabilities of 232 the recipient as described in [10] and associated documents. 234 Identifier: urn:ietf:params:rescap:mua:OpenPGPVerifiesSigned 235 Value type: List of strings 236 Description: Indicates that the recipient can verify the 237 signatures on OpenPGP signed messages. The strings in the list 238 indicate the type of signatures accepted. The values currently 239 are limited to "DSA" and "RSA". The list is in decreasing order 240 of preference. 242 Identifier: urn:ietf:params:rescap:mua:OpenPGPSigningCertsBasic 243 Value type: List of strings 244 Description: Provides the OpenPGP certificates for public signing 245 keys of the recipient. The list is in decreasing order of 246 preference. 248 Identifier: urn:ietf:params:rescap:mua:OpenPGPEncryptingCerts 249 Value type: List of strings 250 Description: Provides the OpenPGP certificates for public 251 encrypting keys of the recipient. The list is in decreasing order 252 of preference. 254 Identifier: urn:ietf:params:rescap:mua:OpenPGPHigherCerts 255 Value type: List of strings 256 Description: Provides the OpenPGP certificates for users and 257 certificate authorities that have signed the recipient's signing 258 and encrypting certificates. These higher-level certificates can 259 be used by the sender to validate the recipient's certificates. 260 The list is in no particular order. 262 5. General 264 User agent and recipient attributes that don't fit into the other 265 categories appear in this section. 267 Identifier: urn:ietf:params:rescap:mua:UBEPrefernces 268 Value type: List of strings 269 Description: Specifies the preferences of the recipient for 270 receiving unsolicited bulk email (UBE). Each entry in the list is 271 a pair of strings. The first entry in the pair is a tag 272 indicating the law or policy being referred to, and the second 273 entry is the value specified for that law or policy. The 274 identities of the laws and policies must be registered with IANA. 276 Identifier: urn:ietf:params:rescap:mua:MailingListInfo 277 Value type: String 278 Description: Gives information about a mailing list. The format 279 of the information is single string consisting of RFC 822 headers, 280 as described in [8]. If the recipient is not a mailing list and 281 this attribute is included in the rescap response, the string 282 should be empty. 284 Identifier: urn:ietf:params:rescap:mua:GeneralInfo 285 Value type: vCard string 286 Description: Gives information about the person or system that is 287 associated with the recipient. The information is returned in the 288 vCard format described in [9]. Note that any information in this 289 attribute that can also be represented in other attributes in this 290 profile should also be delivered in the other attributes. No 291 client should have to retrieve the value for this attribute in 292 order to get information that is also available in other 293 attributes. 295 Identifier: urn:ietf:params:rescap:mua:AssociatedEmailAddresses 296 Value type: List of lists 297 Description: Lists the email addresses used by this recipient. 298 The list contains items that contain a pair of string items. The 299 pairs consist of an email address and a description. The 300 description should be the strings "home", "work", "all", "unused". 301 The "unused" term indicates an email address that is no longer 302 valid for the recipient. 304 6. Security Considerations 306 The rescap protocol will control the security of the passing the 307 values for the attributes described here. If digital signatures are 308 not used, an attacker can alter the values that the client receives 309 from the server, thereby causing false values or no values to be 310 received. For example, an attacker can change the legal notices 311 sent, which can cause damage to the named recipient. If encryption 312 is not used, an attacker can watch the values of the attributes as 313 they are transmitted over the Internet. 315 Normative References 317 [1] Alvestrand, H., "Tags for the Identification of Languages", RFC 318 1766, March 1995. 320 [2] Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC 321 1864, October 1995. 323 [3] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part 324 Three: Message Header Extensions for Non-ASCII Text", RFC 2047, 325 November 1996. 327 [4] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of 328 Aggregate Documents, such as HTML (MHTML)", RFC 2110, March 329 1997. 331 [5] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word 332 Extensions: Character Sets, Languages, and Continuations", RFC 333 2231, November 1997. 335 [6] Freed, N. and J. Postel, "IANA Charset Registration 336 Procedures", BCP 19, RFC 2278, January 1998. 338 [7] Fajman, R., "An Extensible Message Format for Message 339 Disposition Notifications", RFC 2298, March 1998. 341 [8] Baer, J. and G. Neufeld, "The Use of URLs as Meta-Syntax for 342 Core Mail List Commands and their Transport through Message 343 Header Fields", RFC 2369, July 1998. 345 [9] MISSING ORGANIZATION and MISSING ORGANIZATION, "vCard MIME 346 Directory Profile", RFC 2426, September 1998. 348 [10] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP 349 Message Format", RFC 2440, November 1998. 351 [11] Dawson, F., Mansour, S. and S. Silverberg, "iCalendar Message- 352 Based Interoperability Protocol (iMIP)", RFC 2447, November 353 1998. 355 [12] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 356 2533, March 1999. 358 [13] Ramsdell, B., "S/MIME Version 3 Certificate Handling", RFC 359 2632, June 1999. 361 [14] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 362 2633, June 1999. 364 [15] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, 365 June 1999. 367 [16] Klyne, G., "MIME Content Types in Media Feature Expressions", 368 RFC 2913, September 2000. 370 [17] Hoffman, P., "Registration of Charset and Languages Media 371 Features Tags", RFC 2987, November 2000. 373 Author's Address 375 Paul Hoffman 376 Internet Mail Consortium 377 127 Segre Place 378 Santa Cruz, CA 95060 379 USA 381 EMail: paul.hoffman@imc.org and paul.hoffman@vpnc.org 383 Appendix A. IANA Registrations 385 A.1 Attribute Identifier Registrations 387 [[It is likely that all the attribute identifiers in this document 388 will need to be registered.]] 390 A.2 Additional Registrations 392 [[Registration of UCE law and policy identifiers]] 394 Appendix B. Acknowledgments 396 The following people have contributed changes and additions to this 397 document: 399 Chris Newman 401 Graham Klyne 403 Larry Masinter 405 Tony Hansen 407 Appendix C. Changes between versions of the draft 409 Updated to reflect changes in the base RESCAP protocol. 410 Specifically, Attribute Names are now URIs 412 Full Copyright Statement 414 Copyright (C) The Internet Society (2002). All Rights Reserved. 416 This document and translations of it may be copied and furnished to 417 others, and derivative works that comment on or otherwise explain it 418 or assist in its implementation may be prepared, copied, published 419 and distributed, in whole or in part, without restriction of any 420 kind, provided that the above copyright notice and this paragraph are 421 included on all such copies and derivative works. However, this 422 document itself may not be modified in any way, such as by removing 423 the copyright notice or references to the Internet Society or other 424 Internet organizations, except as needed for the purpose of 425 developing Internet standards in which case the procedures for 426 copyrights defined in the Internet Standards process must be 427 followed, or as required to translate it into languages other than 428 English. 430 The limited permissions granted above are perpetual and will not be 431 revoked by the Internet Society or its successors or assigns. 433 This document and the information contained herein is provided on an 434 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 435 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 436 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 437 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 438 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 440 Acknowledgement 442 Funding for the RFC Editor function is currently provided by the 443 Internet Society.