Internet Draft R. Gellens
Document: draft-ietf-acap-pers-06.txt QUALCOMM
Expires: August 2003 February 2003
ACAP Email Personality Dataset Class
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>.
Copyright Notice
Copyright (C) The Internet Society 2003. All Rights Reserved.
Abstract
It has become common for Internet mail users to receive and compose
mail in the capacity of different roles or identities (for example,
personal and work), to receive and compose mail at different
machines, and to use multiple programs which require mail
composition configuration information. These different roles or
identities have become known as email personalities.
The Application Configuration Access Protocol [ACAP] provides an
ideal mechanism for storage of email personality data.
Gellens Expires August 2003 [Page 1]
Internet Draft ACAP Email Personality Dataset Class February 2003
This specification defines a standard ACAP dataset class for email
personalities, and a common option for indicating a default.
An SMTP URL scheme is also defined.
Gellens Expires August 2003 [Page 2]
Internet Draft ACAP Email Personality Dataset Class February 2003
Table of Contents
1. Conventions Used in this Document . . . . . . . . . . . . . . 3
2. Changes Since Previous Version . . . . . . . . . . . . . . . 3
3. Comments . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. ACAP Standard Options . . . . . . . . . . . . . . . . . . . 4
5. ACAP Email Personality Dataset Class . . . . . . . . . . . . 4
5.1. ACAP Email Personality Dataset Class Prefix . . . . . . 4
5.2. ACAP Email Personality Dataset Hierarchy . . . . . . . . 4
6. ACAP Email Personality Dataset Attributes . . . . . . . . . 4
6.1. Basic Attributes . . . . . . . . . . . . . . . . . . . . 5
6.2. Specific Attributes . . . . . . . . . . . . . . . . . . 5
7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9
8. The SMTP URL Scheme . . . . . . . . . . . . . . . . . . . . 10
8.1. SMTP User Name and Authentication Mechanism . . . . . . . 10
8.2. Relative SMTP URLs . . . . . . . . . . . . . . . . . . . 12
8.3. Multinational Considerations . . . . . . . . . . . . . . 12
8.4. Example . . . . . . . . . . . . . . . . . . . . . . . . 12
8.5. ABNF for SMTP URL scheme . . . . . . . . . . . . . . . . 12
8.6. Security Considerations . . . . . . . . . . . . . . . . 13
9. Normative References . . . . . . . . . . . . . . . . . . . . 13
10. Informative References . . . . . . . . . . . . . . . . . . 15
11. Security Considerations . . . . . . . . . . . . . . . . . . 15
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 15
13. Author's Address . . . . . . . . . . . . . . . . . . . . . 16
Intellectual Property Statement . . . . . . . . . . . . . . . 16
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16
1. Conventions Used in this Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [KEYWORDS].
2. Changes Since Previous Version
- Cleaned up examples.
- Minor text clarifications.
- Added specification of SMTP URL.
3. Comments
Gellens Expires August 2003 [Page 3]
Internet Draft ACAP Email Personality Dataset Class February 2003
Public comments can be sent to the IETF ACAP mailing list,
<ietf-acap+@andrew.cmu.edu>. To subscribe, send a message to
<ietf-acap-request+@andrew.cmu.edu> with the word SUBSCRIBE as the
body. Private comments should be sent to the author.
4. ACAP Standard Options
This specification defines the MUA Default Personality standard
option. This is a scaler option in the ACAP Standard Option
("/option") dataset. The entry name is "mua.default.personality".
The "option.value" attribute contains the value, which is a URL.
Generally, this will be an ACAP URL pointing to an entry in an Email
Personality dataset.
The standard option dataset class is specified in [ACAP-OPTIONS].
ACAP URLs are defined in [ACAP].
5. ACAP Email Personality Dataset Class
The ACAP Email Personality dataset class defines a set of attributes
which specify an email personality; that is, configuration
information used for composing and sending email.
Configuration information related to accessing and retrieving
received email is stored in the ACAP Email Account Dataset Class
[ACAP-ACCOUNT].
5.1. ACAP Email Personality Dataset Class Prefix
Datasets whose names begin with "/personality" are assumed to
contain email personality entries as defined in this specification.
5.2. ACAP Email Personality Dataset Hierarchy
Each user may have a set of named email personalities. The default
is pointed at by the "mua.default.personality" standard option.
(See section 4 for more information.)
Inheritance is likely to be useful both for inheriting site or group
defaults (for example, [SMTP] servers, and initial client
configuration in general) as well as for inheriting user-specific
configuration when using different machines.
Gellens Expires August 2003 [Page 4]
Internet Draft ACAP Email Personality Dataset Class February 2003
6. ACAP Email Personality Dataset Attributes
An email personality entry MUST have an "entry" attribute. All
other attributes are OPTIONAL.
Attributes are specified using Augmented Backus-Naur Form [ABNF].
All attributes are single-valued and textual unless otherwise
stated.
The ABNF defines the content of the attribute values prior to their
encoding as an ACAP string. Clients MUST conform to the syntax when
generating these attributes, but MUST NOT assume that the attribute
values will conform to this syntax on access. Servers MUST NOT
enforce the syntax.
6.1. Basic Attributes
These attributes are defined in ACAP [ACAP] and have meaning in all
dataset classes. This section describes how they are used in an
email personality dataset.
entry
The "entry" attribute is used to hold a unique name for the
personality. This name is used for inheritance, so when
customizing a personality which has an entry in an inherited
dataset, the entry name needs to remain the same. The name
should also be descriptive.
subdataset
The "subdataset" attribute indicates that there is a subdataset
of this entry. The value of this attribute specifies the actual
location of the subdataset, per [ACAP] section 3.1.1.
6.2. Specific Attributes
These attributes are specific to the Email Personality dataset
class.
personality.Auto.Encrypt
This flag indicates if the client should automatically encrypt
messages composed with this personality.
pers-auto-enc = "0" / "1"
Gellens Expires August 2003 [Page 5]
Internet Draft ACAP Email Personality Dataset Class February 2003
personality.Auto.Sign
This flag indicates if the client should automatically apply a
digital signature to messages composed with this personality.
pers-auto-sign = "0" / "1"
personality.Cert-DN
This contains the certificate name to be used when encrypting
and/or signing messages using certificate-based mechanisms.
pers-cert-dn = 1*UTF8-CHAR
personality.Charset
This specifies the default coded character set to be used when
composing messages. The name must be in the IANA charset
registry (located at
<ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets>).
pers-charset = 1*CHAR
personality.File-Into.IMAP
This specifies an IMAP folder into which new messages should be
copied by default. Generally, this is specified as an IMAP URL,
as defined in [URL-IMAP].
pers-file-imap = url ;defined in [URL-BASIC]
personality.File-Into.Local
This specifies the name of a local folder into which new
messages should be placed by default.
pers-file-local = 1*UTF8-CHAR
personality.Header.BCC
This specifies the default BCC header field contents.
pers-hdr-bcc = *address
;address specified in [RFC-822]
personality.Header.CC
This specifies the default CC header field contents.
pers-hdr-cc = 1*address
;address specified in [RFC-822]
Gellens Expires August 2003 [Page 6]
Internet Draft ACAP Email Personality Dataset Class February 2003
personality.Header.Extra
This multivalued attribute contains additional header fields.
Each value contains the complete canonical form of a header name
and contents. Values must conform to [RFC-822] and [MIME].
pers-hdr-extra = 1*CHAR
;must conform to [RFC-822] and [MIME]
personality.Header.Reply-To
This specifies the default Reply-To header field contents.
Values must conform to [RFC-822] and [MIME].
pers-hdr-reply = 1*CHAR
;must conform to [RFC-822] and [MIME]
personality.Language
This contains the default language to be specified in language
tags. The name must be in the IANA language registry (located
at <ftp://ftp.isi.edu/in-notes/iana/assignments/languages>).
pers-lang = 1*CHAR
personality.MIME.Composition-Type
This specifies the default MIME type to use when composing
messages which contain any text elements or parts. The value is
a MIME type and subtype, with optional parameters. The value
should be canonicalized by removing unnecessary quoting. The
type, subtype, and any parameters must conform to [MIME],
including IANA registration requirements. Free insertion of
linear-white-space is not permitted.
pers-mtype = type "/" subtype *(";" SP parameter)
;defined in RFC 2045 [MIME]
personality.PGP.Key-ID.bin
This contains the Key ID when PGP is used to encrypt and/or sign
messages.
pers-pgp-key = *OCTET
personality.Real-Name
This contains the display name associated with the personality.
The phrase component of the From header field should be
constructed from this value.
pers-name = 1*UTF8-CHAR
Gellens Expires August 2003 [Page 7]
Internet Draft ACAP Email Personality Dataset Class February 2003
personality.Return-Address
This contains the [RFC-822] addr-spec associated with the
personality. The addr-spec of the From header field should by
default contain this value. It is separated from the phrase
From field component (stored in "personality.Real-Name") to make
comparisons easier.
pers-addr = addr-spec
;addr-spec defined in [RFC-822]
personality.Server.SMTP
This specifies the [SMTP] server to be used when sending
messages for this personality. Generally, the form is an [SMTP]
URL, as defined in Section 8.
pers-smtp = url ;defined in [URL-BASIC]
personality.Signature.Text
This contains the signature text to be appended by default to
new messages. It is stored in canonical form, with
CRLF-separated lines. When a signature separator line is used,
it SHOULD NOT be contained in this attribute, but instead added
automatically by the client.
pers-sig-text = 1*CHAR
personality.Signature.URL
When the signature to be appended by default to new messages is
stored in a file or other resource, this attribute is used
instead of "personality.Signature.Text". This attribute
contains a URL (for example, a file URL) to the signature text.
It is assumed that the signature text is in canonical form, with
CRLF-separated lines. When a signature separator line is used,
it SHOULD NOT be contained in this file, but instead added
automatically by the client.
pers-sig-url = url ;defined in [URL-BASIC]
personality.Stationery
This attribute contains a URL (for example, a file URL) to the
stationery, or template, to be used when creating new messages
with this personality. In general the stationery contains a
canonicalized message, with header fields and/or body.
pers-statn = url ;defined in [URL-BASIC]
Gellens Expires August 2003 [Page 8]
Internet Draft ACAP Email Personality Dataset Class February 2003
personality.SMTP-Auth.permitted.clear
This attribute specifies if clear-text [SMTP-AUTH] mechanisms
are permitted. A value of "never" indicates such mechanisms can
never be used for this personality. A value of "encrypted"
gives permission to use such mechanisms if an encrypted channel
is in effect, such as [TLS] or [IPSEC]. A value of "always"
permits such mechanisms to be used under all conditions.
Note that use of clear-text mechanisms poses at least two
different risks: one is that the password may be captured
in-transit (which can be mitigated by using an encryption
layer); the second is that the password may be disclosed to an
inappropriate server.
pers-auth-clear = "never" / "encrypted" / "always"
personality.SMTP-Auth.permitted.nonclear
This attribute specifies if non-clear-text [SMTP-AUTH]
mechanisms (such as CRAM-MD5, Kerberos, or One Time Password)
are permitted. A value of "never" indicates such mechanisms can
never be used for this personality. A value of "always" permits
such mechanisms to be used under all conditions.
Note that some non-clear-text mechanisms are vulnerable to
various attacks which could result in an unauthorized server
obtaining the user's password.
pers-auth-nonclear = "never" / "always"
7. Examples
entry personal
personality.File-Into.Local sent mail
personality.Header.Extra X-Pet: Yak
personality.MIME.Composition-Type text/plain; format=flowed
personality.Real-Name L. Eva Message
personality.Return-Address lem@pop.example.net
personality.Server.SMTP smtp:smtp.example.net
personality.Signature.Text L. Eva Message
"sua cuique voluptas"
personality.SMTP-Auth.permitted.clear Never
entry work
personality.File-Into.IMAP IMAP://lem@example.org/sent
personality.Header.Extra Organization: A.T.&Love
personality.MIME.Composition-Type multipart/alternative
personality.Real-Name L. Eva Message
Gellens Expires August 2003 [Page 9]
Internet Draft ACAP Email Personality Dataset Class February 2003
personality.Return-Address lem@mail.example.org
personality.Server.SMTP smtp:smtp.example.org
personality.Signature.URL file://signature.txt
personality.SMTP-Auth.permitted.clear Never
personality.SMTP-Auth.permitted.nonclear
Always
8. The SMTP URL Scheme
The SMTP URL scheme designates an [SMTP] server, and optionally a
port number, authentication mechanism, authentication ID, and/or
authorization ID.
The SMTP URL follows the common Internet scheme syntax as defined in
RFC 1738 [BASIC-URL] except that clear text passwords are not
permitted. If :<port> is omitted, the port defaults to 25.
The SMTP URL is described using [ABNF] in section 8.5.
An SMTP URL is of the general form:
smtp:<user>;auth=<auth>@<host>:<port>
Where <user>, <host>, and <port> are as defined in RFC 1738, and
some or all of the elements, except "smtp:" and <host>, may be
omitted.
8.1. SMTP User Name and Authentication Mechanism
An authorization (which [SMTP] account to access) and authentication
(whose password to check against) identity (referred to as "user
name" for simplicity) and/or authentication mechanism name may be
supplied. These are used in an AUTH [SMTP-AUTH], or extension
command after making the connection to the SMTP server. If the URL
doesn't supply an authentication identifier, the program
interpreting the SMTP URL MAY request one from the user.
An authentication mechanism can be expressed by adding ";AUTH=<enc-
auth-type>" to the end of the user name. If the authentication
mechanism name is not preceded by a "+", it is a SASL SMTP [SASL]
mechanism. If it is preceded by a "+", it is an extension
mechanism.
Gellens Expires August 2003 [Page 10]
Internet Draft ACAP Email Personality Dataset Class February 2003
When an <enc-auth-type> is specified, the client SHOULD request
appropriate credentials from that mechanism and use the "AUTH", (or
extension) command. If no user name is specified and an
<enc-auth-type> is specified, a user name SHOULD be obtained from
the mechanism or requested from the user as appropriate.
The string ";AUTH=*" indicates that the client SHOULD select an
appropriate authentication mechanism. It MAY use any mechanism
supported by the [SMTP] server.
If an <enc-auth-type> other than ";AUTH=*" is specified, the client
SHOULD NOT use a different mechanism without explicit user
permission.
If a user name is included with no authentication mechanism, then
";AUTH=*" is assumed.
Since URLs can easily come from untrusted sources, care must be
taken when resolving a URL which requires or requests any sort of
authentication. If authentication credentials are supplied to the
wrong server, it may compromise the security of the user's account.
The program resolving the URL should make sure it meets at least one
of the following criteria in this case:
(1) The URL comes from a trusted source, such as a referral server
which the client has validated and trusts according to site policy.
Note that user entry of the URL may or may not count as a trusted
source, depending on the experience level of the user and site
policy.
(2) Explicit local site policy permits the client to connect to the
server in the URL. For example, if the client knows the site domain
name, site policy may dictate that any hostname ending in that
domain is trusted.
(3) The user confirms that connecting to that domain name with the
specified credentials and/or mechanism is permitted.
(4) A mechanism is used which validates the server before passing
potentially compromising client credentials.
(5) An authentication mechanism is used which will not reveal
information to the server which could be used to compromise future
connections.
Gellens Expires August 2003 [Page 11]
Internet Draft ACAP Email Personality Dataset Class February 2003
A URL containing ";AUTH=*" should be treated with extra care since
it might fall back on a weaker security mechanism. Finally, clients
are discouraged from using a plain text password as a fallback with
";AUTH=*" unless the connection has strong encryption (e.g., a key
length of greater than 56 bits).
Note that if unsafe or reserved characters such as " " or ";" are
present in the user name or authentication mechanism, they MUST be
encoded as described in RFC 1738 [BASIC-URL].
8.2. Relative SMTP URLs
Relative SMTP URLs are not permitted.
8.3. Multinational Considerations
Since 8-bit characters are not permitted in URLs, [UTF8] characters
are encoded as required by the URL specification [BASIC-URL].
8.4. Example
The following example demonstrate how an SMTP client program might
translate various SMTP URLs into a series of SMTP commands.
Commands sent from the client to the server are prefixed with "C:",
and responses sent from the server to the client are prefixed with
"S:".
The URL:
<smtp:rg;AUTH=CRAM-MD5@smtp.example.com:8025>
Results in the following client commands:
<client requests password from user>
<connect to smtp.example.com, port 8025>
S: 220 smtp.example.com ESMTP server ready
C: EHLO jgm.example.com
S: 250-smtp.example.com
S: 250 AUTH CRAM-MD5 DIGEST-MD5
C: AUTH CRAM-MD5
S: 334
PENCeUxFREJoU0NnbmhNWitOMjNGNndAZWx3b29kLmlubm9zb2Z0LmNvbT4=
C: ZnJlZCA5ZTk1YWVlMDljNDBhZjJiODRhMGMyYjNiYmFlNzg2ZQ==
S: 235 Authentication successful.
Gellens Expires August 2003 [Page 12]
Internet Draft ACAP Email Personality Dataset Class February 2003
8.5. ABNF for SMTP URL scheme
The SMTP URL scheme is described using [ABNF]:
achar = uchar / "&" / "=" / "~"
; see [BASIC-URL] for "uchar" definition
auth = ";AUTH=" ( "*" / enc-auth-type )
enc-auth-type = enc-sasl / enc-ext
enc-ext = "+" 1*achar
;encoded extension mechanism name
enc-sasl = 1*achar
;encoded version of [SASL] "auth_type"
enc-user = 1*achar
;encoded version of SMTP mailbox
smtp-url = "smtp:" server
server = [user-auth "@"] hostport
;See [BASIC-URL] for "hostport" definition
user-auth = enc-user [auth]
8.6. Security Considerations
Security considerations discussed in the [SMTP-AUTH]
specification and the [BASIC-URL] specification are relevant.
Security considerations related to authenticated URLs are discussed
in section 8.1 of this document.
Many email clients store the plain text password for later use
after logging into a server. Such clients MUST NOT use a stored
password in response to an SMTP URL without explicit permission from
the user to supply that password to the specified host name.
9. Normative References
[ABNF] Crocker, Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail Consortium, Demon
Internet Ltd., November 1997.
<ftp://ftp.isi.edu/in-notes/rfc2234.txt>
Gellens Expires August 2003 [Page 13]
Internet Draft ACAP Email Personality Dataset Class February 2003
[ACAP] Newman, Myers, "ACAP -- Application Configuration Access
Protocol", RFC 2244, Innosoft, Netscape, November 1997.
<ftp://ftp.isi.edu/in-notes/rfc2244.txt>
[ACAP-ACCOUNT] Gellens, "ACAP Email Account Dataset Class", work
in Progress.
<ftp://ftp.ietf.org/internet-drafts/draft-ietf-acap-email-xx.txt>
[ACAP-OPTIONS] Hole, "ACAP Application Options Dataset Class",
workin Progress.
<ftp://ftp.ietf.org/internet-drafts/draft-ietf-acap-options-xx.txt>
[KEYWORDS] Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, Harvard University, March 1997.
<ftp://ftp.isi.edu/in-notes/rfc2119.txt>
[RFC-822] Crocker, "Standard for the Format of ARPA Internet
Text Messages", RFC 822, STD 11, University of Delaware, August
1982. <ftp://ftp.isi.edu/in-notes/rfc822.txt>
[MIME] Freed, Borenstein, "Multipurpose Internet Mail Extensions
(MIME) Part One: Format of Internet Message Bodies", RFC 2045,
Innosoft, First Virtual, November 1996; Freed, Borenstein,
"Multipurpose Internet Mail Extensions (MIME) Part Two: Media
Types", RFC 2046, Innosoft, First Virtual, November 1996; Moore,
"MIME (Multipurpose Internet Mail Extensions) Part Three: Message
Header Extensions for Non-ASCII Text", RFC 2047, University of
Tennessee, November 1996. <ftp://ftp.isi.edu/in-notes/rfc2045.txt>
<ftp://ftp.isi.edu/in-notes/rfc2046.txt>
<ftp://ftp.isi.edu/in-notes/rfc2047.txt>
[SMTP-AUTH] J. Myers, "SMTP Service Extension for
Authentication", RFC 2554, Netscape Communications, March 1999.
<ftp://ftp.isi.edu/in-notes/rfc2554.txt>
[URL-BASIC] Berners-Lee, Masinter, McCahill, "Uniform Resource
Locators (URL)", RFC 1738, CERN, Xerox Corporation, University of
Minnesota, December 1994. <ftp://ftp.isi.edu/in-notes/rfc1738.txt>
[URL-IMAP] Newman, "IMAP URL Scheme", RFC 2192, Innosoft,
September 1997. <ftp://ftp.isi.edu/in-notes/rfc2192.txt>
[URL-SMTP] Earhart, "An SMTP URL Interface", work in progress.
<ftp://ftp.ietf.org/internet-drafts/draft-earhart-url-smtp-xx.txt>
Gellens Expires August 2003 [Page 14]
Internet Draft ACAP Email Personality Dataset Class February 2003
[UTF8] Yergeau, F. "UTF-8, a transformation format of ISO
10646", RFC 2279, Alis Technologies, January 1998.
<ftp://ftp.isi.edu/in-notes/rfc2279.txt>
10. Informative References
[IPSEC] R. Atkinson, "Security Architecture for the Internet
Protocol", RFC 1825, August 1995,
<ftp://ftp.isi.edu/in-notes/rfc1825.txt>
[SMTP] J. Klensin, "Simple Mail Transfer Protocol", RFC 2821,
April 2001, <ftp://ftp.isi.edu/in-notes/rfc2821.txt>
[TLS] Dierks, Allen, "The TLS Protocol Version 1.0", RFC 2246,
Certicom, January 1999. <ftp://ftp.isi.edu/in-notes/rfc2246.txt>
11. Security Considerations
As with ACAP datasets in general, it is important that access
controls are set correctly on Email Personality datasets.
Attributes may contain highly personal information which should not
be disclosed except by explicit owner request. In addition, by
changing certain attributes (such as
"personality.SMTP-Auth.permitted.clear",
"personality.SMTP-Auth.permitted.nonclear", and
"personality.server.SMTP"), an attacker could cause a user to
attempt an unsafe and unwise authentication, including potentially
sending the user's password in the clear to a rogue server.
The "personality.SMTP-Auth.permitted.clear" attribute mentions
twoof the risks associated with sending clear-text passwords to an
SMTP server.
The "personality.SMTP-Auth.permitted.nonclear" attribute
mentions one of the risks associated with using non-clear-text
authentication mechanisms.
Security considerations for SMTP URLs are discussed in section
8.6.
12. Acknowledgments
Gellens Expires August 2003 [Page 15]
Internet Draft ACAP Email Personality Dataset Class February 2003
Many thanks to the participants of the IETF ACAP working group
fortheir help, comments, and suggestions.
13. Author's Address
Randall Gellens +1 858 651 5115
QUALCOMM Incorporated randy@qualcomm.com
5775 Morehouse Drive
San Diego, CA 92121-2779
U.S.A.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of
any intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances
of licenses to be made available, or the result of an attempt made
to obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification
can be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society 2003. 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
Gellens Expires August 2003 [Page 16]
Internet Draft ACAP Email Personality Dataset Class February 2003
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.
Gellens Expires August 2003 [Page 17]
