Network Working Group E. Burger
Internet Draft SnowShore Networks
Document: draft-ietf-vpim-hint-03.txt E. Candell
Category: Standards Track Comverse Network Systems
Expires August 2001 C. Eliot
Microsoft Corporation
G. Klyne
Content Technologies
February 16, 2001
Message Context for Internet Mail
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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 document is a work product of the IETF Voice Profile for
Internet Mail (VPIM) Work Group. The URL for the VPIM website is
<http://www.vpim.org>.
1. Abstract
This memo describes a new RFC822 message header, "Message-Context".
This header provides information about the context and presentation
characteristics of a message.
A receiving user agent (UA) may use this information as a hint to
optimally present the message.
Expires 8/16/01 [Page 1]
Message Context for Internet Mail February 2001
Table of Contents
1. Abstract...........................................................1
2. Introduction.......................................................2
3. Conventions used in this document..................................3
4. Motivation.........................................................3
5. Functional Requirements............................................5
6. Determining the Message Context....................................5
7. Message-Context Reference Field....................................6
7.1. Message-Context Syntax...........................................7
7.2. message-context-class Syntax.....................................7
7.2.1. voice-message..................................................8
7.2.2. fax-message....................................................8
7.2.3. video-message..................................................8
7.2.4. short-message..................................................8
7.2.5. mail-message...................................................8
7.2.6. none...........................................................8
8. Security Considerations............................................8
9. IANA Considerations................................................9
9.1. Message-Context Registration.....................................9
9.2. Primary Context Class Registrations.............................10
9.2.1. Registration Template.........................................10
9.2.2. voice-message.................................................10
9.2.3. fax-message...................................................11
9.2.4. video-message.................................................12
9.2.5. short-message.................................................12
9.2.6. mail-message..................................................13
9.2.7. none..........................................................13
10. APPENDIX: Some messaging scenarios...............................14
10.1. Internet e-mail................................................14
10.2. Short text messaging service...................................15
10.3. Facsimile......................................................15
10.4. Voice mail.....................................................16
10.5. Multimedia message.............................................16
11. References.......................................................17
12. Acknowledgments..................................................17
13. Author's Addresses...............................................18
14. Full Copyright Statement.........................................19
2. Introduction
This document describes a mechanism to allow senders of an Internet
mail message to convey the message's contextual information. Taking
account of this information, the receiving user agent (UA) can make
decisions that improve message presentation for the user in the
context the sender and receiver expects.
Burger et. al. Expires 8/16/01 [Page 2]
Message Context for Internet Mail February 2001
In this document, the "message context" conveys information about
the way the user expects to interact with the message. For example,
a message may be e-mail, voice mail, fax mail, etc. A smart UA may
have specialized behavior based on the context of the message.
This document specifies a RFC 822 header called "Message-Context".
The mechanism is in some ways similar to the use of the Content-
Disposition MIME entity described in [2]. Content-Disposition gives
clues to the receiving User Agent (UA) for how to display a given
body part. Message-Context can give clues to the receiving UA for
the presentation of the message. This allows the receiving UA to
present the message in a meaningful and helpful way to the
recipient.
Typical uses for this mechanism include:
o Selecting a special viewer for a given message.
o Selecting an icon indicating the kind of message in a displayed
list of messages.
o Arranging messages in an inbox display.
o Filtering messages the UA presents when the user has limited
access.
3. Conventions used in this document
This document refers generically to the sender of a message in the
masculine (he/him/his) and the recipient of the message in the
feminine (she/her/hers). This convention is purely for convenience
and makes no assumption about the gender of a message sender or
recipient.
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 [3].
FORMATTING NOTE: Notes, such at this one, provide additional
nonessential information that the reader may skip without missing
anything essential. The primary purpose of these non-essential
notes is to convey information about the rationale of this document,
or to place this document in the proper historical or evolutionary
context. Readers whose sole purpose is to construct a conformant
implementation may skip such information. However, it may be of use
to those who wish to understand why we made certain design choices.
4. Motivation
Multimedia messaging systems receive messages that a UA may present
in variety of ways. For example, traditional e-mail uses simple
text messages that the recipient displays and edits. One UA may
automatically print Fax images. Another UA may play voice messages
through a telephone handset. Likewise, a receiving desktop computer
Burger et. al. Expires 8/16/01 [Page 3]
Message Context for Internet Mail February 2001
may process or present documents transferred over e-mail using a
local application. Emerging and future developments may deliver
other forms of information that have their own characteristics for
user presentation, such as video messages and short text messages.
An often-requested characteristic for multimedia messaging systems
is to collect received messages in a "universal inbox", and to offer
them to the user as a combined list.
In the context of "unified messaging", different message contexts
may have different implied semantics. For example, some users may
perceive voicemail to have an implicit assumption of urgency. Thus
they may wish to gather them together and process them before other
messages. This results in the end-user receiving agent needing to
be able to identify voicemail and distinguish it from other
messages.
The uses of this kind of presentation characteristic for each
message is multi-fold:
o Display an indication to the user (e.g., by a suitably
evocative icon along with other summary fields),
o Auto-forward a given message type into another messaging
environment (e.g., short text to a mobile short message
service),
o Prioritize and group messages in an inbox display list,
o Suggest appropriate default handling for presentation,
o Suggest appropriate default handling for reply, forward, etc.,
and
A problem faced by multimedia messaging systems is that it is not
always easy to decide the context of a received message. For
example, consider the following scenarios.
o A message that contains audio and image data: Is this a fax
message that happens to have some voice commentary? Is it a
voice message that is accompanied by some supplementary
diagrams? Is it a fully multimedia message, in which all parts
are expected to carry equal significance?
o A message containing text and audio data: Is this e-mail with
an MP3 music attachment? Is it a voice message that happens to
have been generated with an initial text header for the benefit
of non-voice-enabled e-mail receivers?
The message context does relate to the message media content.
However, it is not the same thing. As shown above, the media type
used in a message is not sufficient to indicate the message context.
Burger et. al. Expires 8/16/01 [Page 4]
Message Context for Internet Mail February 2001
One cannot determine a priori which media types to use in
alternative (gateway) message. Also, what if the user cares about
distinguishing traditional e-mail text from SMS messages? They are
both the same media type, text, but they have different user
contexts.
5. Functional Requirements
The goals stated above lead to the following functional
requirements.
For receivers:
o Identify a message as belonging to a message class.
o Incorrect or invalid message classification must not result in
failure to transfer or inability to present a message.
For senders:
o Specify message classes by the originating user's choice of
authoring tool or simple user interaction.
For both:
o Specify a well-defined set of message classes to make
interoperability between mail user agents (UAs) possible.
o Message classification information has to be interpretable in
reasonable fashion by many different user agent systems.
o The mechanism should be extensible to allow for the
introduction of new kinds of messages.
NOTE: We specifically do not specify user agent behavior when the
user agent forwards a message. Clearly, the user agent, being
message-context-aware, should provide a meaningful message-context.
It is obvious what to do for the easy cases. Messages that the user
simply forwards will most likely keep the context unchanged.
However, it is beyond the scope of this document to specify the user
agent behavior for any other scenario.
6. Determining the Message Context
One method of indicating the interpretation context of a message is
to examine the media types in the message. However, this requires
the UA to scan the entire message before it can make this
determination. This approach is particularly burdensome for the
multi-media mail situation, as voice and especially video mail
objects are quite large.
Burger et. al. Expires 8/16/01 [Page 5]
Message Context for Internet Mail February 2001
We considered indicating the message context by registering a
multipart/* MIME subtype (Content-Type). For example, the VPIM Work
Group has registered multipart/voice-message to indicate that a
message is primarily voice mail [4]. However, multipart/voice-
message is identical in syntax to multipart/mixed. The only
difference is that VPIM mail transfer agents and user agents
recognize that they can perform special handling of the message
based on it being a voice mail message. Moreover, Content-Type
refers to a given MIME body part, not to the message as a whole.
We wish to avoid scanning the entire message. In addition, we wish
to avoid having to create multiple aliases for multipart/mixed every
time someone identifies a new primary content type. Multiple
aliases for multipart/mixed are not desirable as they remove the
possibility for specifying a message as multipart/alternate,
multipart/parallel, or multipart/encrypted, for example.
Since the message context is an attribute of the entire message, it
is logical to define a new top-level (RFC 822 [5]) message
attribute. To this end, this document introduces the message
attribute "Message-Context".
Message-Context only serves to identify the message context. It
does not provide any indication of content that the UA must be
capable of delivering. It does not imply any message disposition or
delivery notification. There is a related effort to define Critical
Content of Internet Mail [6] that one might use to perform these
tasks.
Message-Context is only an indicator. We do not intend for it to
convey information that is critical for presentation of the message.
One can conceive of goofy situations, such as a message marked
"voice-message" but without an audio body part. In this case, the
fact that the contents of a message don't match its context does not
mean the receiving system should generate an error report or fail to
deliver or process the message.
7. Message-Context Reference Field
The Message-Context reference field is a top-level header inserted
by the sending UA to indicate the context of the message.
A receiving user agent MUST NOT depend on the indicated message-
context value in a way that prevents proper presentation of the
message. If the value is incorrect or does not match the message
content, the receiving user agent MUST still be capable of
displaying the message content at least as meaningfully as it would
if no Message-Context value were present.
One can envision situations where a well-formed message ends up not
including a media type one would expect from the message-context.
Burger et. al. Expires 8/16/01 [Page 6]
Message Context for Internet Mail February 2001
For example, consider a voice messaging system that records a voice
message and also performs speech-to-text processing on the message.
The message then passes through a content gateway, such as a
firewall, that removes non-critical body parts over a certain
length. The receiving user agent will receive a message in the
voice-message context that has only a text part and no audio. Even
though the message does not have audio, it is still in the voice
message context.
Said differently, the receiving UA can use the message-context to
determine whether, when, and possibly where to display a message.
However, the message-context should not affect the actual rendering
or presentation. For example, if the message is in the voice-
message context, then don't try to send it to a fax terminal.
Conversely, consider the case of a message in the voice-message
context that gets delivered to a multimedia voice terminal with a
printer. However, this message only has fax content. In this
situation, the "voice-message" context should not stop the terminal
from being properly rendering the message.
7.1. Message-Context Syntax
The syntax of the Message-Context field, described using the ABNF
[7] is as follows. Note that the Message-Context header field name
and message-context-class values are not case sensitive.
"Message-Context" ":" message-context-class CRLF
7.2. message-context-class Syntax
The message-context-class indicates the context of the message.
This is an IANA registered value. Current values for message-
context-class are as follows.
message-context-class = ( "voice-message"
| "fax-message"
| "video-message"
| "short-message"
| "mail-message"
| "none"
| extension-type )
extension-type = token ; Defined and registered per Section 8
/ x-token ; Experimental, private use
token = <syntax as defined by [8],
but not starting with the characters "X-" or "x-">
x-token = <syntax as defined by [8] for private use>
Burger et. al. Expires 8/16/01 [Page 7]
Message Context for Internet Mail February 2001
Note: The values for Message-Context must be either IANA registered
values or experimental, X- tokens. This ensures that user agents
from different vendors will interoperate and perform in a uniform
manner without an undue burden on the vendors.
7.2.1. voice-message
The voice-message class states the message is a voice mail message.
7.2.2. fax-message
The fax-message class states the message is a facsimile mail
message.
7.2.3. video-message
The video-message class states the message is a video message.
7.2.4. short-message
The short-message class states the message is a short text message,
such as a short text message service (SMS) message or text pager
message.
7.2.5. mail-message
The mail-message class states the message is a normal internet mail
message, with or without attachments.
7.2.6. none
The none class states there is no context information for this
message.
If a message has no Message-Context reference field, a receiving
user agent MUST treat it the same as it would if the message has a
"none" value.
8. Security Considerations
The intention for this header is to be an indicator only of message
context. One can imagine someone creating an "Application" Message-
Context. A poorly designed user agent could blindly execute a
mailed program based on the Message-Context. Don't do that!
One can envision a denial of service attack by bombing a receiver
with a message that has a Message-Context that doesn't fit the
profile of the actual body parts. This is why the receiver
considers the Message-Context to be a hint only.
Burger et. al. Expires 8/16/01 [Page 8]
Message Context for Internet Mail February 2001
9. IANA Considerations
Following the policies outlined in [9] as "Specification Required",
IANA assigns values for Message-Context.
NOTE: ietf-types@iana.org is a placeholder for the appropriate IANA
address for registrations.
We would expect new registrations to reflect sensible message
contexts that will arise in the future. For example, we include
video-message as an expected message type.
9.1. Message-Context Registration
To: ietf-types@iana.org
Subject: Registration of New Top-Level Header Field Message-Context
Header name:
Message-Context
Required parameters:
Single 7bit text value
Parameter value:
The parameter value specifies the message context for the message.
Security considerations:
The intention for this header is to indicate media content type
only. One can imagine one creating an "Application" primary content
type, and have a poorly designed user agent blindly execute a mailed
program.
Published specification:
draft-ietf-vpim-hint-01.txt
Applications that use this context class:
Mail
VPIM
FPIM
Additional information: none
Person & email address to contact for further information:
Eric Burger
e.burger@ieee.org
Intended usage: COMMON
Burger et. al. Expires 8/16/01 [Page 9]
Message Context for Internet Mail February 2001
9.2. Primary Context Class Registrations
9.2.1. Registration Template
In the following template, a pipe symbol, "|", precedes instructions
or other helpful material. Be sure to replace "<classname>" with
the class name you are defining.
To: ietf-types@iana.org
Subject: Registration of New Message-Context class <classname>
Message-Context class name:
<classname>
Summary of the message class:
| Include a short (no longer than 4 lines) description or summary
| Examples:
| "Palmtop devices have a 320x160 pixel display, so we can..."
| "Color fax is so different than black & white that..."
Security considerations:
| Describe issues related to security. Examples include privacy
| concerns, denial of service concerns, malicious behavior, etc.
Interoperability considerations:
| Describe issues with existing RFC's or BCP's, if any.
Additional information:
| Any other relevant information that might be useful, such
| as related class definitions, reference to specific
| applications and specifications to which this class
| relates, etc.
Person & email address to contact for further information:
| Name & e-mail!
Intended usage:
| pick one of COMMON, LIMITED USE, or OBSOLETE
9.2.2. voice-message
To: ietf-types@iana.org
Subject: Registration of New Message-Context class voice-message
Message-Context class name:
voice-message
Summary of the message class:
"voice-message" indicates a message whose primary content is a voice
mail message. The primary content is audio data. The context is
usually a message recorded from a voice telephone call.
Burger et. al. Expires 8/16/01 [Page 10]
Message Context for Internet Mail February 2001
Security considerations:
none
Interoperability considerations:
None.
Applications that use this context class:
VPIM
Additional information:
RFC 2421, Voice Profile for Internet Mail - version 2
Person & email address to contact for further information:
Eric Burger
e.burger@ieee.org
Intended usage: COMMON
9.2.3. fax-message
To: ietf-types@iana.org
Subject: Registration of New Message-Context class fax-message
Message-Context class name:
fax-message
Summary of the message class:
"fax-message" indicates a message whose primary content is a fax
mail message. The primary content is image data. The context is
usually a message recorded from a facsimile telephone call.
Security considerations:
none
Interoperability considerations:
none
Applications that use this context class:
FPIM
Additional information:
RFC 2305, A Simple Mode of Facsimile Using Internet Mail
RFC 2421, Voice Profile for Internet Mail - version 2
RFC 2532, Extended Facsimile Using Internet Mail
Person & email address to contact for further information:
Eric Burger
e.burger@ieee.org
Intended usage: COMMON
Burger et. al. Expires 8/16/01 [Page 11]
Message Context for Internet Mail February 2001
9.2.4. video-message
To: ietf-types@iana.org
Subject: Registration of New Message-Context class video-message
Message-Context class name:
video-message
Summary of the message class:
"video-message" indicates a message whose primary content is a video
mail message. The primary content is video data. The context is
usually a message recorded from a video terminal.
Security considerations:
none
Interoperability considerations:
none
Applications that use this context class:
none
Additional information:
none
Person & email address to contact for further information:
Eric Burger
e.burger@ieee.org
Intended usage: COMMON
9.2.5. short-message
To: ietf-types@iana.org
Subject: Registration of New Message-Context class short-message
Message-Context class name:
short-message
Summary of the message class:
"short-message" indicates a message whose primary content is a short
text message. The primary content is text data. The context is
usually an urgent message of a limited length.
Security considerations:
none
Interoperability considerations:
none
Burger et. al. Expires 8/16/01 [Page 12]
Message Context for Internet Mail February 2001
Applications that use this context class:
Mail
VPIM
FPIM
Additional information:
none
Person & email address to contact for further information:
Eric Burger
e.burger@ieee.org
Intended usage: COMMON
9.2.6. mail-message
To: ietf-types@iana.org
Subject: Registration of New Message-Context class mail-message
Message-Context class name:
mail-message
Security considerations:
none
Interoperability considerations:
none
Published specification:
draft-ietf-vpim-hint-01.txt
Applications that use this context class:
Mail
VPIM
FPIM
Additional information:
none
Person & email address to contact for further information:
Eric Burger
e.burger@ieee.org
Intended usage: COMMON
9.2.7. none
To: ietf-types@iana.org
Subject: Registration of New Message-Context class none
Burger et. al. Expires 8/16/01 [Page 13]
Message Context for Internet Mail February 2001
Message-Context class name:
none
Security considerations:
none
Interoperability considerations:
none
Published specification:
draft-ietf-vpim-hint-01.txt
Applications that use this context class:
Mail
VPIM
FPIM
Additional information:
none
Person & email address to contact for further information:
Eric Burger
e.burger@ieee.org
Intended usage: COMMON
10. APPENDIX: Some messaging scenarios
This section is not a normative part of this document. We include
it here as a historical perspective on the issue of multimedia
message types.
These scenarios are neither comprehensive nor fixed. For example,
e-mails being typically text-based do not mean that they cannot
convey a voice-message. This very mutability serves to underline
the desirability of providing some explicit message context hint.
10.1. Internet e-mail
Internet e-mail carries textual information. Sometimes it conveys
computer application data of arbitrary size.
Typically, one uses e-mail for non-urgent messages, which the
recipient will retrieve and process at a time convenient to her.
The normal device for receiving and processing e-mail messages is
some kind of personal computer. Modern personal computers usually
come with a reasonably large display and an alphanumeric keyboard.
Audio, video, and printing capabilities are not necessarily
available.
Burger et. al. Expires 8/16/01 [Page 14]
Message Context for Internet Mail February 2001
One can use E-mail for communication between two parties (one-to-
one), a small number of known parties (one-to-few) or, via an e-mail
distribution list, between larger numbers of unknown parties (one-
to-many).
One of the endearing characteristics of e-mail is the way that it
allows the recipient to forward all or part of the message a to
another party, with or without additional comments. It is quite
common for an e-mail to contain snippets of content from several
previous messages. Similar features apply when replying to e-mail.
10.2. Short text messaging service
One can use a short text message to convey textual information of
limited size. The typical limit is 160 characters.
The short text messaging service (SMS) is a facility that has
evolved for use with mobile telephones, and has an associated per-
message transmission charge. People use SMS for relatively urgent
messages, which the sender wishes the receiver to see and possibly
respond to within a short time period.
The normal device for sending and receiving a short text message is
a mobile telephone with a small character display and a numeric-only
keyboard. Personal computers and personal digital assistants (PDAs)
can also participate in short text messaging.
Currently, the most common use of short text messages are between
just two parties (one-to-one).
Users often send short text messages in isolation, rather than as
part of a longer exchange. One use for them is as a prompt or
invitation to communicate by some more convenient and content-rich
method, such as a telephone call.
10.3. Facsimile
People use facsimile to convey image information of moderate size,
typically a small number of pages. Sometimes people use facsimile
for larger documents.
Facsimile is a facility that usually uses circuit-switched telephone
circuits, with connection-time charges. Message transfer takes
place in real-time. Thus, people often use facsimile for urgent
communication.
The normal device for sending and receiving a facsimile is a self-
contained scanning and printing device connected to a telephone line
or a desktop computer.
Burger et. al. Expires 8/16/01 [Page 15]
Message Context for Internet Mail February 2001
Most facsimiles are between just two parties (one-to-one). However,
a significant portion of facsimile service is broadcast between
multiple parties (one-to-many).
Most facsimile exchanges are in isolation, rather than as part of a
longer exchange. Facsimile data is typically not suitable for
further processing by computer.
10.4. Voice mail
People use voice mail to convey audio information, almost
exclusively human speech.
Voice mail is a facility that usually uses circuit-switched
telephone circuits, with modest connection-time charges, often used
for moderately urgent messages. A common use for them is as a
prompt or invitation to communicate by some more convenient method,
such as a telephone call. In most, but not all cases, the sender of
a voice message does not want to send a message at all. Rather,
they wished to engage in a real-time conversation.
The normal device for sending and receiving a voice mail is a
telephone handset.
Voice messages are usually sent between just two parties (one-to-
one).
Voice mail data is not generally suitable for further processing by
computer.
10.5. Multimedia message
We define a multimedia message as a message containing more than one
basic media type (text, image, audio, video, model, application).
The following are some characteristics of a multimedia message.
In some cases, a multimedia message is just e-mail with an
attachment that a multimedia display application presents. For
example, I can send you an MP3 of something I recorded in my garage
today.
In other cases, a multimedia message represents a convergence
between two or more of the scenarios described above. For example,
a voice message with an accompanying diagram or a talking head video
message is a multimedia message.
The characteristics will vary somewhat with the intent of the
sender. This in turn may affect the user agent or application used
to render the message.
Burger et. al. Expires 8/16/01 [Page 16]
Message Context for Internet Mail February 2001
11. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
2 Troost, R., Dorner, S., and Moore, K., "Communicating
Presentation Information in Internet Messages: The Content-
Disposition Header Field", RFC 2183, New Century Systems,
QUALCOMM Incorporated, and University of Tennessee, August 1997.
3 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
4 Vaudreuil, G. and Parsons, G., "VPIM Voice Message MIME Sub-type
Registration", RFC 2423, Lucent Technologies and Northern
Telecom, September 1998.
5 Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982.
6 Burger, E. and Candell, E., "Critical Content of Internet Mail",
draft-ietf-vpim-cc-01.txt, Work in Progress.
7 Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, Internet Mail Consortium and
Demon Internet Ltd., November 1997.
8 Freed, N. and Borenstein, N., "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, Innosoft and First Virtual, November 1996.
9 Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
12. Acknowledgments
Many of the ideas here arose originally from a discussion with Jutta
Degener.
We'd also like to thank Keith Moore for helping us tighten-up our
explanations.
In the last round, we got some rather good advise from Caleb Clausen
and Dave Aronson.
Burger et. al. Expires 8/16/01 [Page 17]
Message Context for Internet Mail February 2001
13. Author's Addresses
Eric Burger
SnowShore Networks, Inc.
285 Billerica Rd.
Chelmsford, MA 01824-4120
USA
Phone: +1 703 304 3883
Fax: +1 603 457 5944
Email: e.burger@ieee.org
Emily Candell
Comverse Network Systems
200 Quannapowitt Pkwy.
Wakefield, MA 01880
USA
Phone: +1 781 213 2324
Email: emily@comversens.com
Graham Klyne
Content Technologies Ltd.
1220 Parkview,
Arlington Business Park
Theale
Reading, RG7 4SA
United Kingdom.
Telephone: +44 118 930 1300
Facsimile: +44 118 930 1301
E-mail: GK@ACM.ORG
Charles Eliot
Microsoft Corporation
One Microsoft Way
Redmond WA 98052
USA
Telephone: +1 425 936 9760
E-Mail: charle@Microsoft.com
Burger et. al. Expires 8/16/01 [Page 18]
Message Context for Internet Mail February 2001
14. Full Copyright 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 implementers 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 that may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Copyright (C) 2000 The Internet Society. 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.
Burger et. al. Expires 8/16/01 [Page 19]