RESCAP P. Hoffman Internet-Draft Internet Mail Consortium Expires: December 23, 2002 June 24, 2002 RESCAP Profile for Mail User Agents draft-ietf-rescap-mua-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 23, 2002. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document defines RESCAP Attributes for Mail User Agents (MUAs) and mail recipients. Values for these attributes will contain information that a mail sender might want or need to know about a particular mail recipient before sending a message. Hoffman Expires December 23, 2002 [Page 1] Internet-Draft RESCAP MUA Profile June 2002 1. Introduction This document defines Attributes for the RESCAP protocol for mail user agents (MUAs) and mail recipients. It describes the attributes that a mail sender might want or need to know about a particular mail recipient before sending a message. The attributes are divided into four general categories: o MIME handling o S/MIME o OpenPGP o General Note: this list is very preliminary. The process of defining the requirements for rescap has just begun. Because the rescap protocol has not even had a first draft, it is likely that there will be many significant changes to this draft in the future as rescap gets worked on. In this document, "recipient" is used to indicate the user who can accept mail at the URL provided in the rescap request and "sender" is the person or process who requested the rescap information. Note that some of the attributes in this document apply to the MUA a recipient is using, while others apply directly to the mail recipient (which might be a human or a mail-processing program). The attributes described in this document are those that a mail sender would want to know about a recipient or the recipient's MUA. Attributes about the mail recipient that have no relevance to a mail sender (such if the MUA uses IMAP to access its message store) are not included. Hoffman Expires December 23, 2002 [Page 2] Internet-Draft RESCAP MUA Profile June 2002 2. MIME Handling The attributes in this section describe general MIME handling. They include some specific MIME profiles as well as more general MIME characteristics. Identifier: urn:ietf:params:rescap:mua:PlainTextOnly Value type: Boolean ("0" or "1") Description: Can only read single-part text/plain messages. Put another way, cannot parse a MIME message. Identifier: urn:ietf:params:rescap:mua:MIMEIntlHeaders Value type: Boolean ("0" or "1") Description: Conforms to [3], which describes many extensions for MIME headers, such as for non-ASCII characters. Identifier: urn:ietf:params:rescap:mua:MIMEParamExtensions Value type: Boolean ("0" or "1") Description: Conforms to [5], which describes many extensions for MIME parameter values and encoded words. Identifier: urn:ietf:params:rescap:mua:DisplayableMedia Value type: String Description: A list of MIME types and subtypes that are natively displayed by the receiving MUA without falling back to a default media type. The string is in the format of [12], as extended by [16]. This string should contain only MIME types and subtypes, not additional media features. Identifier: urn:ietf:params:rescap:mua:MediaFeatures Value type: String Description: A list of media features of the MUA. The string is in the format of [12]. Identifier: urn:ietf:params:rescap:mua:CharsetsDisplayed Value type: Conneg string Description: The list of charset labels that describe the charsets [6] that can be displayed. Note that US-ASCII, and support for at least the US-ASCII subset of ISO-8859-*, is assumed regardless of the value of this attribute. The string is in the format of [12], using the tags defined in [17]. Identifier: urn:ietf:params:rescap:mua:PreferredLanguages Value type: List of strings Description: The lists of languages understandable to the recipient, as described in [1]. The string is in the format of [12], using the tags defined in [CONNEG-CHARLANG]. Hoffman Expires December 23, 2002 [Page 3] Internet-Draft RESCAP MUA Profile June 2002 Identifier: urn:ietf:params:rescap:mua:LineLength Value type: Integer Description: The width, in characters, of a line in the display of the MUA. For variable-width displays, this should be an estimate of the number of characters per line from a typical mail message. For systems that have no line limitations, this value should be set to 0. Identifier: urn:ietf:params:rescap:mua:HandlesMHTML Value type: Boolean ("0" or "1) Description: Handles MHTML content natively, as described in [4]. Identifier: urn:ietf:params:rescap:mua:HandlesContentMD5 Value type: Boolean ("0" or "1") Description: Handles Content-MD5 headers, as described in [2]. If the recipient does not handle Content-MD5 headers, as many don't, this the sender can save time by not constructing one. Identifier: urn:ietf:params:rescap:mua:HandlesMailingListURLs Value type: Boolean ("0" or "1") Description: Handles mailing list URL headers, as described in [LIST-URLS]. Identifier: urn:ietf:params:rescap:mua:RepliesToMDNs Value type: Boolean ("0" or "1") Description: Is able to reply to message disposition notification requests, as described in [7]. Note that this does not mean that the client will necessarily send an MDN back to a particular request, just that it is able to reply to such requests. This field helps a sending MUA decide whether or not to keep track of the MDNs sent to the recipient; if the recipient is known not to reply to MDNs, then the sender doesn't need to track them. This can also reduce the size of messages sent over bandwidth- restricted lines. Identifier: urn:ietf:params:rescap:mua:CalendarClient Value type: Boolean ("0" or "1") Description: Can act as an iCalendar iMIP agent [11]. Hoffman Expires December 23, 2002 [Page 4] Internet-Draft RESCAP MUA Profile June 2002 3. S/MIME The attributes in this section indicate the S/MIME capabilities of the recipient as described in [14], [13], and associated documents. Note that some S/MIME public keys are used for both encrypting and signing. This means that there may be duplicated certificates in the SMIMESigningCertsBasic and SMIMEEncryptingCerts lists. Identifier: urn:ietf:params:rescap:mua:SMIMEVerifiesSigned Value type: List of strings Description: Indicates that the recipient can verify the signatures on S/MIME signed messages. The strings in the list indicate the type of signatures accepted. The values currently are limited to "id-dsa" and "rsaEncryption". The list is in decreasing order of preference. Identifier: urn:ietf:params:rescap:mua:SMIMESigningCertsBasic Value type: List of strings Description: Provides the S/MIME certificates for public signing keys of the recipient. The list is in decreasing order of preference. Identifier: urn:ietf:params:rescap:mua:SMIMESigningCertsExtended Value type: List of strings Description: Provides the S/MIME certificates for public signing keys of the recipient. The list is in decreasing order of preference. Identifier: urn:ietf:params:rescap:mua:SMIMEEncryptingCerts Value type: List of strings Description: Provides the S/MIME certificates for public encrypting keys of the recipient. The list is in decreasing order of preference. Identifier: urn:ietf:params:rescap:mua:SMIMEHigherCerts Value type: List of strings Description: Provides the S/MIME certificates for certificate authorities that have signed the recipient's signing and encrypting certificates. These higher-level certificates can be used by the sender to validate the recipient's certificates. The list is in no particular order. Identifier: urn:ietf:params:rescap:mua:SMIMESignedReceipts Value type: Boolean ("0" or "1") Description: Responds to requests for S/MIME signed receipts described in [15]. Hoffman Expires December 23, 2002 [Page 5] Internet-Draft RESCAP MUA Profile June 2002 Identifier: urn:ietf:params:rescap:mua:SMIMESecurityLabels Value type: Boolean ("0" or "1") Description: Acts on S/MIME security labels, or is behind a gateway that does security label handling, as described in [15]. Identifier: urn:ietf:params:rescap:mua:SMIMESecureMailingList Value type: Boolean ("0" or "1") Description: Is a mailing list that uses secure mailing list handling described in [15]. Identifier: urn:ietf:params:rescap:mua:SMIMEHandlesSigningCert Value type: Boolean ("0" or "1") Description: Handles the signed SigningCertificate attribute described in [15]. Hoffman Expires December 23, 2002 [Page 6] Internet-Draft RESCAP MUA Profile June 2002 4. OpenPGP The attributes in this section indicate the OpenPGP capabilities of the recipient as described in [10] and associated documents. Identifier: urn:ietf:params:rescap:mua:OpenPGPVerifiesSigned Value type: List of strings Description: Indicates that the recipient can verify the signatures on OpenPGP signed messages. The strings in the list indicate the type of signatures accepted. The values currently are limited to "DSA" and "RSA". The list is in decreasing order of preference. Identifier: urn:ietf:params:rescap:mua:OpenPGPSigningCertsBasic Value type: List of strings Description: Provides the OpenPGP certificates for public signing keys of the recipient. The list is in decreasing order of preference. Identifier: urn:ietf:params:rescap:mua:OpenPGPEncryptingCerts Value type: List of strings Description: Provides the OpenPGP certificates for public encrypting keys of the recipient. The list is in decreasing order of preference. Identifier: urn:ietf:params:rescap:mua:OpenPGPHigherCerts Value type: List of strings Description: Provides the OpenPGP certificates for users and certificate authorities that have signed the recipient's signing and encrypting certificates. These higher-level certificates can be used by the sender to validate the recipient's certificates. The list is in no particular order. Hoffman Expires December 23, 2002 [Page 7] Internet-Draft RESCAP MUA Profile June 2002 5. General User agent and recipient attributes that don't fit into the other categories appear in this section. Identifier: urn:ietf:params:rescap:mua:UBEPrefernces Value type: List of strings Description: Specifies the preferences of the recipient for receiving unsolicited bulk email (UBE). Each entry in the list is a pair of strings. The first entry in the pair is a tag indicating the law or policy being referred to, and the second entry is the value specified for that law or policy. The identities of the laws and policies must be registered with IANA. Identifier: urn:ietf:params:rescap:mua:MailingListInfo Value type: String Description: Gives information about a mailing list. The format of the information is single string consisting of RFC 822 headers, as described in [8]. If the recipient is not a mailing list and this attribute is included in the rescap response, the string should be empty. Identifier: urn:ietf:params:rescap:mua:GeneralInfo Value type: vCard string Description: Gives information about the person or system that is associated with the recipient. The information is returned in the vCard format described in [9]. Note that any information in this attribute that can also be represented in other attributes in this profile should also be delivered in the other attributes. No client should have to retrieve the value for this attribute in order to get information that is also available in other attributes. Identifier: urn:ietf:params:rescap:mua:AssociatedEmailAddresses Value type: List of lists Description: Lists the email addresses used by this recipient. The list contains items that contain a pair of string items. The pairs consist of an email address and a description. The description should be the strings "home", "work", "all", "unused". The "unused" term indicates an email address that is no longer valid for the recipient. Hoffman Expires December 23, 2002 [Page 8] Internet-Draft RESCAP MUA Profile June 2002 6. Security Considerations The rescap protocol will control the security of the passing the values for the attributes described here. If digital signatures are not used, an attacker can alter the values that the client receives from the server, thereby causing false values or no values to be received. For example, an attacker can change the legal notices sent, which can cause damage to the named recipient. If encryption is not used, an attacker can watch the values of the attributes as they are transmitted over the Internet. Hoffman Expires December 23, 2002 [Page 9] Internet-Draft RESCAP MUA Profile June 2002 Normative References [1] Alvestrand, H., "Tags for the Identification of Languages", RFC 1766, March 1995. [2] Myers, J. and M. Rose, "The Content-MD5 Header Field", RFC 1864, October 1995. [3] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996. [4] Palme, J. and A. Hopmann, "MIME E-mail Encapsulation of Aggregate Documents, such as HTML (MHTML)", RFC 2110, March 1997. [5] Freed, N. and K. Moore, "MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations", RFC 2231, November 1997. [6] Freed, N. and J. Postel, "IANA Charset Registration Procedures", BCP 19, RFC 2278, January 1998. [7] Fajman, R., "An Extensible Message Format for Message Disposition Notifications", RFC 2298, March 1998. [8] Baer, J. and G. Neufeld, "The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields", RFC 2369, July 1998. [9] MISSING ORGANIZATION and MISSING ORGANIZATION, "vCard MIME Directory Profile", RFC 2426, September 1998. [10] Callas, J., Donnerhacke, L., Finney, H. and R. Thayer, "OpenPGP Message Format", RFC 2440, November 1998. [11] Dawson, F., Mansour, S. and S. Silverberg, "iCalendar Message- Based Interoperability Protocol (iMIP)", RFC 2447, November 1998. [12] Klyne, G., "A Syntax for Describing Media Feature Sets", RFC 2533, March 1999. [13] Ramsdell, B., "S/MIME Version 3 Certificate Handling", RFC 2632, June 1999. [14] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 2633, June 1999. Hoffman Expires December 23, 2002 [Page 10] Internet-Draft RESCAP MUA Profile June 2002 [15] Hoffman, P., "Enhanced Security Services for S/MIME", RFC 2634, June 1999. [16] Klyne, G., "MIME Content Types in Media Feature Expressions", RFC 2913, September 2000. [17] Hoffman, P., "Registration of Charset and Languages Media Features Tags", RFC 2987, November 2000. Author's Address Paul Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz, CA 95060 USA EMail: paul.hoffman@imc.org and paul.hoffman@vpnc.org Hoffman Expires December 23, 2002 [Page 11] Internet-Draft RESCAP MUA Profile June 2002 Appendix A. IANA Registrations A.1 Attribute Identifier Registrations [[It is likely that all the attribute identifiers in this document will need to be registered.]] A.2 Additional Registrations [[Registration of UCE law and policy identifiers]] Hoffman Expires December 23, 2002 [Page 12] Internet-Draft RESCAP MUA Profile June 2002 Appendix B. Acknowledgments The following people have contributed changes and additions to this document: Chris Newman Graham Klyne Larry Masinter Tony Hansen Hoffman Expires December 23, 2002 [Page 13] Internet-Draft RESCAP MUA Profile June 2002 Appendix C. Changes between versions of the draft Updated to reflect changes in the base RESCAP protocol. Specifically, Attribute Names are now URIs Hoffman Expires December 23, 2002 [Page 14] Internet-Draft RESCAP MUA Profile June 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Hoffman Expires December 23, 2002 [Page 15]