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]
