< draft-ietf-vpim-hint   rfc3458.txt 
Network Working Group E. Burger Network Working Group E. Burger
Internet Draft SnowShore Networks Request for Comments: 3458 SnowShore Networks
Document: draft-ietf-vpim-hint-07.txt E. Candell Category: Standards Track E. Candell
Category: Standards Track Comverse Comverse
Expires December 2001 C. Eliot C. Eliot
Microsoft Corporation Microsoft Corporation
G. Klyne G. Klyne
Baltimore Technologies Nine by Nine
June 5, 2001 January 2003
Message Context for Internet Mail Message Context for Internet Mail
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document specifies an Internet standards track protocol for the
all provisions of Section 10 of RFC2026 [1]. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Internet-Drafts are working documents of the Internet Engineering Official Protocol Standards" (STD 1) for the standardization state
Task Force (IETF), its areas, and its working groups. Note that and status of this protocol. Distribution of this memo is unlimited.
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 Copyright Notice
http://www.ietf.org/shadow.html .
This document is a work product of the IETF Voice Profile for Copyright (C) The Internet Society (2003). All Rights Reserved.
Internet Mail (VPIM) Work Group.
1. Abstract Abstract
This memo describes a new RFC2822 message header, "Message-Context". This memo describes a new RFC 2822 message header, "Message-Context".
This header provides information about the context and presentation This header provides information about the context and presentation
characteristics of a message. characteristics of a message.
A receiving user agent (UA) may use this information as a hint to A receiving user agent (UA) may use this information as a hint to
optimally present the message. optimally present the message.
Table of Contents Table of Contents
1. Abstract...........................................................1 1. Introduction....................................................2
2. Introduction.......................................................3 2. Conventions used in this document...............................3
3. Conventions used in this document..................................3 3. Motivation......................................................3
4. Motivation.........................................................4 4. Functional Requirements.........................................5
5. Functional Requirements............................................5 5. Determining the Message Context.................................6
6. Determining the Message Context....................................6 6. Message-Context Reference Field.................................7
7. Message-Context Reference Field....................................7 6.1. Message-Context Syntax......................................7
7.1. Message-Context Syntax...........................................7 6.2. message-context-class Syntax................................7
7.2. message-context-class Syntax.....................................7 6.2.1. voice-message...........................................8
7.2.1. voice-message..................................................8 6.2.2. fax-message.............................................8
7.2.2. fax-message....................................................8 6.2.3. pager-message...........................................8
7.2.3. pager-message..................................................8 6.2.4. multimedia-message......................................8
7.2.4. multimedia-message.............................................8 6.2.5. text-message............................................8
7.2.5. text-message...................................................8 6.2.6. none....................................................8
7.2.6. none...........................................................9 7. Security Considerations.........................................9
8. Security Considerations............................................9 8. IANA Considerations.............................................9
9. IANA Considerations................................................9 8.1. Message Content Type Registrations..........................9
9.1. Message Content Type Registrations..............................10 8.2. Registration Template......................................10
9.2. Registration Template...........................................10 8.3. Message-Context Registration...............................11
9.3. Message-Context Registration....................................11 9. APPENDIX: Some messaging scenarios.............................12
10. APPENDIX: Some messaging scenarios...............................11 9.1. Internet e-mail............................................12
10.1. Internet e-mail................................................11 9.2. Pager service..............................................12
10.2. Pager service..................................................12 9.3. Facsimile..................................................13
10.3. Facsimile......................................................13 9.4. Voice mail.................................................14
10.4. Voice mail.....................................................13 9.5. Multimedia message.........................................14
10.5. Multimedia message.............................................13 10. References....................................................15
11. References.......................................................14 10.1 Normative References.......................................15
12. Acknowledgments..................................................15 10.2 Informative References.....................................15
13. Author's Addresses...............................................15 11. Acknowledgments...............................................15
14. Full Copyright Statement.........................................17 12. Authors' Addresses............................................16
2. Introduction 13. Full Copyright Statement......................................17
1. Introduction
This document describes a mechanism to allow senders of an Internet This document describes a mechanism to allow senders of an Internet
mail message to convey the message's contextual information. Taking mail message to convey the message's contextual information. Taking
account of this information, the receiving user agent (UA) can make account of this information, the receiving user agent (UA) can make
decisions that improve message presentation for the user in the decisions that improve message presentation for the user in the
context the sender and receiver expects. context the sender and receiver expects.
In this document, the "message context" conveys information about In this document, the "message context" conveys information about the
the way the user expects to interact with the message. For example, way the user expects to interact with the message. For example, a
a message may be e-mail, voice mail, fax mail, etc. A smart UA may message may be e-mail, voice mail, fax mail, etc. A smart UA may
have specialized behavior based on the context of the message. have specialized behavior based on the context of the message.
This document specifies a RFC2822 header called "Message-Context". This document specifies a RFC 2822 header called "Message-Context".
The mechanism is in some ways similar to the use of the Content- The mechanism is in some ways similar to the use of the Content-
Disposition MIME entity described in [2]. Content-Disposition gives Disposition MIME entity described in [6]. Content-Disposition gives
clues to the receiving User Agent (UA) for how to display a given 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 body part. Message-Context can give clues to the receiving UA for
the presentation of the message. This allows the receiving UA to the presentation of the message. This allows the receiving UA to
present the message in a meaningful and helpful way to the present the message to the recipient, in a meaningful and helpful
recipient. way.
Typical uses for this mechanism include: 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 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.
2. Conventions used in this document
This document refers generically to the sender of a message in the This document refers generically to the sender of a message in the
masculine (he/him/his) and the recipient of the 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 feminine (she/her/hers). This convention is purely for convenience
and makes no assumption about the gender of a message sender or and makes no assumption about the gender of a message sender or
recipient. recipient.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
this document are to be interpreted as described in RFC-2119 [3]. document are to be interpreted as described in BCP 14, RFC 2119 [2].
FORMATTING NOTE: Notes, such at this one, provide additional FORMATTING NOTE: Notes, such at this one, provide additional
nonessential information that the reader may skip without missing nonessential information that the reader may skip without missing
anything essential. The primary purpose of these non-essential anything essential. The primary purpose of these non-essential notes
notes is to convey information about the rationale of this document, is to convey information about the rationale of this document, or to
or to place this document in the proper historical or evolutionary place this document in the proper historical or evolutionary context.
context. Readers whose sole purpose is to construct a conformant Readers whose sole purpose is to construct a conformant
implementation may skip such information. However, it may be of use implementation may skip such information. However, it may be of use
to those who wish to understand why we made certain design choices. to those who wish to understand why we made certain design choices.
4. Motivation 3. Motivation
Multimedia messaging systems receive messages that a UA may present Multimedia messaging systems receive messages that a UA may present
in variety of ways. For example, traditional e-mail uses simple in variety of ways. For example, traditional e-mail uses simple text
text messages that the recipient displays and edits. One UA may messages that the recipient displays and edits. One UA may
automatically print Fax images. Another UA may play voice messages automatically print Fax images. Another UA may play voice messages
through a telephone handset. Likewise, a receiving desktop computer through a telephone handset. Likewise, a receiving desktop computer
may process or present documents transferred over e-mail using a may process or present documents transferred over e-mail using a
local application. Emerging and future developments may deliver local application. Emerging and future developments may deliver
other forms of information that have their own characteristics for other forms of information that have their own characteristics for
user presentation, such as video messages and pager messages. user presentation, such as video messages and pager messages.
An often-requested characteristic for multimedia messaging systems An often-requested characteristic for multimedia messaging systems is
is to collect received messages in a "universal inbox", and to offer to collect received messages in a "universal inbox", and to offer
them to the user as a combined list. them to the user as a combined list.
In the context of "unified messaging", different message contexts In the context of "unified messaging", different message contexts may
may have different implied semantics. For example, some users may have different implied semantics. For example, some users may
perceive voicemail to have an implicit assumption of urgency. Thus perceive voicemail to have an implicit assumption of urgency. Thus
they may wish to gather them together and process them before other they may wish to gather them together and process them before other
messages. This results in the end-user receiving agent needing to messages. This results in the end-user receiving agent needing to be
be able to identify voicemail and distinguish it from other able to identify voicemail and distinguish it from other messages.
messages.
The uses of this kind of presentation characteristic for each The uses of this kind of presentation characteristic for each message
message is multi-fold: are multi-fold:
o Display an indication to the user (e.g., by a suitably o Display an indication to the user (e.g., by a suitably evocative
evocative icon along with other summary fields), icon along with other summary fields),
o Auto-forward a given message type into another messaging o Auto-forward a given message type into another messaging
environment (e.g., a page to a mobile short message service), environment (e.g., a page to a mobile short message service),
o Prioritize and group messages in an inbox display list, o Prioritize and group messages in an inbox display list,
o Suggest appropriate default handling for presentation, o Suggest appropriate default handling for presentation,
o Suggest appropriate default handling for reply, forward, etc., o Suggest appropriate default handling for reply, forward, etc.
and
A problem faced by multimedia messaging systems is that it is not A problem faced by multimedia messaging systems is that it is not
always easy to decide the context of a received message. For always easy to decide the context of a received message. For
example, consider the following scenarios. example, consider the following scenarios.
o A message that contains audio and image data: Is this a fax o A message that contains audio and image data: Is this a fax
message that happens to have some voice commentary? Is it a message that happens to have some voice commentary? Is it a voice
voice message that is accompanied by some supplementary message that is accompanied by some supplementary diagrams? Is it
diagrams? Is it a fully multimedia message, in which all parts a fully multimedia message, in which all parts are expected to
are expected to carry equal significance? carry equal significance?
o A message containing text and audio data: Is this e-mail with o A message containing text and audio data: Is this e-mail with an
an MP3 music attachment? Is it a voice message that happens to MP3 music attachment? Is it a voice message that happens to have
have been generated with an initial text header for the benefit been generated with an initial text header for the benefit of
of non-voice-enabled e-mail receivers? non-voice-enabled e-mail receivers?
The message context does relate to the message media content. The message context does relate to the message media content.
However, it is not the same thing. As shown above, the media type 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. used in a message is not sufficient to indicate the message context.
One cannot determine a priori which media types to use in One cannot determine a priori which media types to use in alternative
alternative (gateway) message. Also, what if the user cares about (gateway) messages. Also, what if the user cares about
distinguishing traditional e-mail text from SMS messages? They are distinguishing traditional e-mail text from SMS messages? They are
both the same media type, text, but they have different user both the same media type, text, but they have different user
contexts. contexts.
5. Functional Requirements 4. Functional Requirements
The goals stated above lead to the following functional The goals stated above lead to the following functional requirements.
requirements.
For receivers: For receivers:
o Identify a message as belonging to a message class.
o Incorrect or invalid message classification must not result in o Identify a message as belonging to a message class.
failure to transfer or inability to present a message.
o Incorrect or invalid message classification must not result in
failure to transfer or inability to present a message.
For senders: For senders:
o Specify message classes by the originating user's choice of
authoring tool or simple user interaction. o Specify message classes by the originating user's choice of
authoring tool or simple user interaction.
For both: 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 o Specify a well-defined set of message classes to make
reasonable fashion by many different user agent systems. interoperability between mail user agents (UAs) possible.
o The mechanism should be extensible to allow for the o Message classification information has to be interpretable in
introduction of new kinds of messages. 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 NOTE: We specifically do not specify user agent behavior when the
user agent forwards a message. Clearly, the user agent, being user agent forwards a message. Clearly, the user agent, being
message-context-aware, should provide a meaningful message-context. message-context-aware, should provide a meaningful message-context.
It is obvious what to do for the easy cases. Messages that the user It is obvious what to do for the easy cases. Messages that the user
simply forwards will most likely keep the context unchanged. simply forwards will most likely keep the context unchanged.
However, it is beyond the scope of this document to specify the user However, it is beyond the scope of this document to specify the user
agent behavior for any other scenario. agent behavior for any other scenario.
6. Determining the Message Context 5. Determining the Message Context
One method of indicating the interpretation context of a message is One method of indicating the interpretation context of a message is
to examine the media types in the message. However, this requires to examine the media types in the message. However, this requires
the UA to scan the entire message before it can make this the UA to scan the entire message before it can make this
determination. This approach is particularly burdensome for the determination. This approach is particularly burdensome for the
multi-media mail situation, as voice and especially video mail multi-media mail situation, as voice and especially video mail
objects are quite large. objects are quite large.
We considered indicating the message context by registering a We considered indicating the message context by registering a
multipart/* MIME subtype (Content-Type). For example, the VPIM Work multipart/* MIME subtype (Content-Type). For example, the VPIM Work
Group has registered multipart/voice-message to indicate that a Group has registered multipart/voice-message to indicate that a
message is primarily voice mail [4]. However, multipart/voice- message is primarily voice mail [7]. However, multipart/voice-
message is identical in syntax to multipart/mixed. The only message is identical in syntax to multipart/mixed. The only
difference is that VPIM mail transfer agents and user agents difference is that VPIM mail transfer agents and user agents
recognize that they can perform special handling of the message recognize that they can perform special handling of the message based
based on it being a voice mail message. Moreover, Content-Type on it being a voice mail message. Moreover, Content-Type refers to a
refers to a given MIME body part, not to the message as a whole. given MIME body part, not to the message as a whole.
We wish to avoid scanning the entire message. In addition, we wish We wish to avoid scanning the entire message. In addition, we wish
to avoid having to create multiple aliases for multipart/mixed every to avoid having to create multiple aliases for multipart/mixed every
time someone identifies a new primary content type. Multiple time someone identifies a new primary content type. Multiple aliases
aliases for multipart/mixed are not desirable as they remove the for multipart/mixed are not desirable as they remove the possibility
possibility for specifying a message as multipart/alternate, for specifying a message as multipart/alternate, multipart/parallel,
multipart/parallel, or multipart/encrypted, for example. or multipart/encrypted, for example.
Since the message context is an attribute of the entire message, it Since the message context is an attribute of the entire message, it
is logical to define a new top-level (RFC2822 [5]) message is logical to define a new top-level (RFC 2822 [3]) message
attribute. To this end, this document introduces the message attribute. To this end, this document introduces the message
attribute "Message-Context". attribute "Message-Context".
Message-Context only serves to identify the message context. It Message-Context only serves to identify the message context. It does
does not provide any indication of content that the UA must be not provide any indication of content that the UA must be capable of
capable of delivering. It does not imply any message disposition or delivering. It does not imply any message disposition or delivery
delivery notification. There is a related effort to define Critical notification. There is a related effort to define Critical Content
Content of Internet Mail [6] that one might use to perform these of Internet Mail [8] that one might use to perform these tasks.
tasks.
Message-Context is only an indicator. We do not intend for it to Message-Context is only an indicator. We do not intend for it to
convey information that is critical for presentation of the message. convey information that is critical for presentation of the message.
One can conceive of goofy situations, such as a message marked One can conceive of goofy situations, such as a message marked
"voice-message" but without an audio body part. In this case, the "voice-message" but without an audio body part. In this case, the
fact that the contents of a message dont match its context does not 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 mean the receiving system should generate an error report or fail to
deliver or process the message. deliver or process the message.
7. Message-Context Reference Field 6. Message-Context Reference Field
The Message-Context reference field is a top-level header inserted The Message-Context reference field is a top-level header inserted by
by the sending UA to indicate the context of the message. the sending UA to indicate the context of the message.
A receiving user agent MUST NOT depend on the indicated message- A receiving user agent MUST NOT depend on the indicated message-
context value in a way that prevents proper presentation of the context value in a way that prevents proper presentation of the
message. If the value is incorrect or does not match the message message. If the value is incorrect or does not match the message
content, the receiving user agent MUST still be capable of content, the receiving user agent MUST still be capable of displaying
displaying the message content at least as meaningfully as it would the message content at least as meaningfully as it would if no
if no Message-Context value were present. Message-Context value were present.
One can envision situations where a well-formed message ends up not One can envision situations where a well-formed message ends up not
including a media type one would expect from the message-context. including a media type one would expect from the message-context.
For example, consider a voice messaging system that records a voice For example, consider a voice messaging system that records a voice
message and also performs speech-to-text processing on the message. message and also performs speech-to-text processing on the message.
The message then passes through a content gateway, such as a The message then passes through a content gateway, such as a
firewall, that removes non-critical body parts over a certain firewall, that removes non-critical body parts over a certain length.
length. The receiving user agent will receive a message in the The receiving user agent will receive a message in the voice-message
voice-message context that has only a text part and no audio. Even context that has only a text part and no audio. Even though the
though the message does not have audio, it is still in the voice message does not have audio, it is still in the voice message
message context. context.
Said differently, the receiving UA can use the message-context to Said differently, the receiving UA can use the message-context to
determine whether, when, and possibly where to display a message. determine whether, when, and possibly where to display a message.
However, the message-context should not affect the actual rendering However, the message-context should not affect the actual rendering
or presentation. For example, if the message is in the voice- or presentation. For example, if the message is in the voice-message
message context, then don't try to send it to a fax terminal. context, then don't try to send it to a fax terminal. Conversely,
Conversely, consider the case of a message in the voice-message consider the case of a message in the voice-message context that gets
context that gets delivered to a multimedia voice terminal with a delivered to a multimedia voice terminal with a printer. However,
printer. However, this message only has fax content. In this this message only has fax content. In this situation, the "voice-
situation, the "voice-message" context should not stop the terminal message" context should not stop the terminal from properly rendering
from being properly rendering the message. 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 6.1. Message-Context Syntax
The message-context-class indicates the context of the message. The syntax of the Message-Context field, described using the ABNF [4]
This is an IANA registered value. Current values for message- is as follows. Note that the Message-Context header field name and
context-class are as follows. message-context-class values are not case sensitive.
message-context-class = ( "voice-message" "Message-Context" ":" message-context-class CRLF
| "fax-message"
| "pager-message"
| "multimedia-message"
| "text-message"
| "none"
| extension-type )
extension-type = token ; Defined and registered per Section 8 6.2. message-context-class Syntax
/ vnd.token ; Experimental, private use
token = <syntax as defined by [8], The message-context-class indicates the context of the message. This
but not starting with the characters "vnd."> is an IANA registered value. Current values for message-context-
class are as follows.
vnd.token = <Vendor-specific, private token> message-context-class = ( "voice-message"
/ "fax-message"
/ "pager-message"
/ "multimedia-message"
/ "text-message"
/ "none"
)
Note: The values for Message-Context must be either IANA registered Note: The values for Message-Context MUST be IANA registered values
values or experimental, vendor tokens. This ensures that user following the directions in the IANA Considerations section below.
agents from different vendors will interoperate and perform in a
uniform manner without an undue burden on the vendors.
7.2.1. voice-message 6.2.1. voice-message
The voice-message class states the message is a voice mail message. The voice-message class states the message is a voice mail message.
7.2.2. fax-message 6.2.2. fax-message
The fax-message class states the message is a facsimile mail The fax-message class states the message is a facsimile mail message.
message.
7.2.3. pager-message 6.2.3. pager-message
The pager-message class states the message is a page, such as a text The pager-message class states the message is a page, such as a text
or numeric pager message or a traditional short text message service or numeric pager message or a traditional short text message service
(SMS) message. (SMS) message.
7.2.4. multimedia-message 6.2.4. multimedia-message
The multimedia-message class states the message is an aggregate The multimedia-message class states the message is an aggregate
multimedia message, such as a message specified by [9]. This helps multimedia message, such as a message specified by [9]. This helps
identify a message in a multimedia context. For example, a MIME identify a message in a multimedia context. For example, a MIME
multipart/related [10] data part and resource part looks the same as multipart/related [10] data part and resource part looks the same as
a multimedia MHTML multipart/related. However, the semantics are a multimedia MHTML multipart/related. However, the semantics are
quite different. quite different.
7.2.5. text-message 6.2.5. text-message
The text-message class states the message is a traditional internet The text-message class states the message is a traditional internet
mail message. Such a message consists of text, possibly richly mail message. Such a message consists of text, possibly richly
formatted, with or without attachments. formatted, with or without attachments.
7.2.6. none 6.2.6. none
The none class states there is no context information for this The none class states there is no context information for this
message. message.
If a message has no Message-Context reference field, a receiving If a message has no Message-Context reference field, a receiving user
user agent MUST treat it the same as it would if the message has a agent MUST treat it the same as it would if the message has a "none"
"none" value. value.
8. Security Considerations 7. Security Considerations
The intention for this header is to be an indicator only of message
context. One can imagine someone creating an "Application" Message- The intention for this header is to be an indicator of message
Context. A poorly designed user agent could blindly execute a context only. One can imagine someone creating an "Application"
mailed program based on the Message-Context. Don't do that! 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 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 with a message that has a Message-Context that doesn't fit the
profile of the actual body parts. This is why the receiver profile of the actual body parts. This is why the receiver considers
considers the Message-Context to be a hint only. the Message-Context to be a hint only.
9. IANA Considerations 8. IANA Considerations
Section 9.3 is a registration for a new top-level RFC2822 [5] Section 8.3 is a registration for a new top-level RFC 2822 [3]
message header, "Message-Context". message header, "Message-Context".
This document creates an extensible set of context types. To This document creates an extensible set of context types. To promote
promote interoperability and coherent interpretations of different interoperability and coherent interpretations of different types, a
types, we need a central repository for well-known context types. central repository has been established for well-known context types.
IANA will create a repository for context types called "Internet The IANA has created a repository for context types called "Internet
Message Context Types". Following the policies outlined in [11], Message Context Types". Following the policies outlined in [5], this
this repository is "Specification Required" by RFC. Section 9.1 repository is "Specification Required" by RFC. Section 8.1 describes
describes the initial values for this registry. the initial values for this registry.
To create a new message context type, you MUST publish an RFC to To create a new message context type, you MUST publish an RFC to
document the type. In the RFC, include a copy of the registration document the type. In the RFC, include a copy of the registration
template found in Section 9.2 of this document. Put the template in template found in Section 8.2 of this document. Put the template in
your IANA Considerations section, filling-in the appropriate fields. your IANA Considerations section, filling-in the appropriate fields.
You MUST describe any interoperability and security issues in your You MUST describe any interoperability and security issues in your
draft. document.
9.1. Message Content Type Registrations 8.1. Message Content Type Registrations
Internet Message Content Types Internet Message Content Types
============================== ==============================
Value Description Reference Value Description Reference
----- ----------- --------- ----- ----------- ---------
voice-message Indicates a message whose primary This RFC voice-message Indicates a message whose primary This RFC
content is a voice mail message. The content is a voice mail message. The
primary content is audio data. The primary content is audio data. The
context is usually a message recorded context is usually a message recorded
skipping to change at page 10, line 41 skipping to change at page 10, line 28
content is a multimedia message. The content is a multimedia message. The
primary content is multimedia, most primary content is multimedia, most
likely MHTML. The context is often likely MHTML. The context is often
spam or newsletters. spam or newsletters.
text-message Indicates a classic, text-based, This RFC text-message Indicates a classic, text-based, This RFC
Internet message. Internet message.
None Indicates an unknown message context. This RFC None Indicates an unknown message context. This RFC
9.2. Registration Template 8.2. Registration Template
In the following template, a pipe symbol, "|", precedes instructions In the following template, a pipe symbol, "|", precedes instructions
or other helpful material. Be sure to replace "<classname>" with or other helpful material. Be sure to replace "<classname>" with the
the class name you are defining. class name you are defining.
Message-Context class name: Message-Context class name:
<classname> <classname>
Summary of the message class: Summary of the message class:
| Include a short (no longer than 4 lines) description or summary | Include a short (no longer than 4 lines) description or summary
| Examples: | Examples:
| "Palmtop devices have a 320x160 pixel display, so we can..." | "Palmtop devices have a 320x160 pixel display, so we can..."
| "Color fax is so different than black & white that..." | "Color fax is so different than black & white that..."
Person & email address to contact for further information: Person & email address to contact for further information:
| Name & e-mail | Name & e-mail
9.3. Message-Context Registration 8.3. Message-Context Registration
To: [email protected] To: [email protected]
Subject: Registration of New RFC 2822 Header Subject: Registration of New RFC 2822 Header
RFC 2822 Header Name: RFC 2822 Header Name:
Message-Context Message-Context
Allowable values for this parameter: Allowable values for this parameter:
Please create a new registry for Primary Context Class Please create a new registry for Primary Context Class
registrations. See section 9.1 of this document for the initial registrations. See section 8.1 of this document for the initial
values. values.
RFC 2822 Section 3.6 Repeat Value: RFC 2822 Section 3.6 Repeat Value:
Field Min Number Max Number Notes Field Min Number Max Number Notes
Message-Context 0 1 Message-Context 0 1
Person & email address to contact for further information: Person & email address to contact for further information:
Eric Burger Eric Burger
[email protected] [email protected]
10. APPENDIX: Some messaging scenarios 9. APPENDIX: Some messaging scenarios
This section is not a normative part of this document. We include This section is not a normative part of this document. We include it
it here as a historical perspective on the issue of multimedia here as a historical perspective on the issue of multimedia message
message types. types.
These scenarios are neither comprehensive nor fixed. For example, These scenarios are neither comprehensive nor fixed. For example,
e-mails being typically text-based do not mean that they cannot e-mails being typically text-based do not mean that they cannot
convey a voice-message. This very mutability serves to underline convey a voice-message. This very mutability serves to underline the
the desirability of providing some explicit message context hint. desirability of providing some explicit message context hint.
10.1. Internet e-mail 9.1. Internet e-mail
Internet e-mail carries textual information. Sometimes it conveys Internet e-mail carries textual information. Sometimes it conveys
computer application data of arbitrary size. computer application data of arbitrary size.
Typically, one uses e-mail for non-urgent messages, which the Typically, one uses e-mail for non-urgent messages, which the
recipient will retrieve and process at a time convenient to her. recipient will retrieve and process at a time convenient to her.
The normal device for receiving and processing e-mail messages is The normal device for receiving and processing e-mail messages is
some kind of personal computer. Modern personal computers usually some kind of personal computer. Modern personal computers usually
come with a reasonably large display and an alphanumeric keyboard. come with a reasonably large display and an alphanumeric keyboard.
Audio, video, and printing capabilities are not necessarily Audio, video, and printing capabilities are not necessarily
available. available.
One can use E-mail for communication between two parties (one-to- 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 one), a small number of known parties (one-to-few) or, via an e-mail
distribution list, between larger numbers of unknown parties (one- distribution list, between larger numbers of unknown parties (one-
to-many). to-many).
One of the endearing characteristics of e-mail is the way that it 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 allows the recipient to forward all or part of the message to another
another party, with or without additional comments. It is quite party, with or without additional comments. It is quite common for
common for an e-mail to contain snippets of content from several an e-mail to contain snippets of content from several previous
previous messages. Similar features apply when replying to e-mail. messages. Similar features apply when replying to e-mail.
10.2. Pager service 9.2. Pager service
One uses a pager message to convey notifications and alerts. For One uses a pager message to convey notifications and alerts. For the
the most part, these notifications are textual information of most part, these notifications are textual information of limited
limited size. The typical limit is 160 characters. People use size. The typical limit is 160 characters. People use pages for
pages for relatively urgent messages, which the sender wishes the relatively urgent messages, which the sender wishes the receiver to
receiver to see and possibly respond to within a short time period. see and possibly respond to within a short time period. Pager
Pager messages are often used as a way of alerting users to messages are often used as a way of alerting users to something
something needing their attention. For example, a system can use a needing their attention. For example, a system can use a page to
page to notify a subscriber there is a voicemail message requiring notify a subscriber there is a voicemail message requiring her
her attention. attention.
Example devices for sending and receiving a pager message are a Example devices for sending and receiving a pager message are a
mobile telephone with a small character display or a text pager. mobile telephone with a small character display or a text pager.
Personal computers and personal digital assistants (PDAs) can also Personal computers and personal digital assistants (PDAs) can also
participate in pager messaging. participate in pager messaging.
Currently, the most common use of pager messages are between just Currently, the most common use of pager messages are between just two
two parties (one-to-one). parties (one-to-one).
One delivery method for pager messages is the short text messaging One delivery method for pager messages is the short text messaging
service (SMS). SMS is a facility that has evolved for use with service (SMS). SMS is a facility that has evolved for use with
mobile telephones, and has an associated per-message transmission mobile telephones, and has an associated per-message transmission
charge. Note that the focus here is on the notification aspect of charge. Note that the focus here is on the notification aspect of
SMS. From the beginning, SMS was envisioned to be more than a SMS. From the beginning, SMS was envisioned to be more than a simple
simple pager service. Operators can use SMS to provision the phone, pager service. Operators can use SMS to provision the phone, for
for example. From the subscriber point of view, SMS has evolved example. From the subscriber point of view, SMS has evolved
considerably from its origins as a pure pager replacement service. considerably from its origins as a pure pager replacement service.
For example, with mobile originate service, people can have two-way For example, with mobile originate service, people can have two-way
text chat sessions using SMS and a mobile phone. In addition, there text chat sessions using SMS and a mobile phone. In addition, there
are SMS-enabled handsets that can display pictures. However, for are SMS-enabled handsets that can display pictures. However, for the
the purposes of this document, there is still a need to capture the purposes of this document, there is still a need to capture the
essence of a "highly urgent, short-text, notification or alert" essence of a "highly urgent, short-text, notification or alert"
service. service.
Users often send pager messages in isolation, rather than as part of Users often send pager messages in isolation, rather than as part of
a longer exchange. One use for them is as a prompt or invitation to 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 communicate by some more convenient and content-rich method, such as
a telephone call. a telephone call.
10.3. Facsimile 9.3. Facsimile
People use facsimile to convey image information of moderate size, People use facsimile to convey image information of moderate size,
typically a small number of pages. Sometimes people use facsimile typically a small number of pages. Sometimes people use facsimile
for larger documents. for larger documents.
Facsimile is a facility that usually uses circuit-switched telephone Facsimile is a facility that usually uses circuit-switched telephone
circuits, with connection-time charges. Message transfer takes circuits, with connection-time charges. Message transfer takes place
place in real-time. Thus, people often use facsimile for urgent in real-time. Thus, people often use facsimile for urgent
communication. communication.
The normal device for sending and receiving a facsimile is a self- The normal device for sending and receiving a facsimile is a self-
contained scanning and printing device connected to a telephone line contained scanning and printing device connected to a telephone line
or a desktop computer. or a desktop computer.
Most facsimiles are between just two parties (one-to-one). However, Most facsimiles are between just two parties (one-to-one). However,
a significant portion of facsimile service is broadcast between a significant portion of facsimile service is broadcast between
multiple parties (one-to-many). multiple parties (one-to-many).
Most facsimile exchanges are in isolation, rather than as part of a Most facsimile exchanges are in isolation, rather than as part of a
longer exchange. Facsimile data is typically not suitable for longer exchange. Facsimile data is typically not suitable for
further processing by computer. further processing by computer.
10.4. Voice mail 9.4. Voice mail
People use voice mail to convey audio information, almost People use voice mail to convey audio information, almost exclusively
exclusively human speech. human speech.
Voice mail is a facility that usually uses circuit-switched Voice mail is a facility that usually uses circuit-switched telephone
telephone circuits, with modest connection-time charges, often used circuits, with modest connection-time charges, often used for
for moderately urgent messages. A common use for them is as a moderately urgent messages. A common use for them is as a prompt or
prompt or invitation to communicate by some more convenient method, invitation to communicate by some more convenient method, such as a
such as a telephone call. In most, but not all cases, the sender of telephone call. In most, but not all cases, the sender of a voice
a voice message does not want to send a message at all. Rather, message does not want to send a message at all. Rather, they wished
they wished to engage in a real-time conversation. to engage in a real-time conversation.
The normal device for sending and receiving a voice mail is a The normal device for sending and receiving a voice mail is a
telephone handset. telephone handset.
Voice messages are usually sent between just two parties (one-to- Voice messages are usually sent between just two parties (one-to-
one). one).
Voice mail data is not generally suitable for further processing by Voice mail data is not generally suitable for further processing by
computer. computer.
10.5. Multimedia message 9.5. Multimedia message
We define a multimedia message as a message containing more than one We define a multimedia message as a message containing more than one
basic media type (text, image, audio, video, model, application). basic media type (text, image, audio, video, model, application).
The following are some characteristics of a multimedia message. The following are some characteristics of a multimedia message.
In some cases, a multimedia message is just e-mail with an In some cases, a multimedia message is just e-mail with an attachment
attachment that a multimedia display application presents. For that a multimedia display application presents. For example, I can
example, I can send you an MP3 of something I recorded in my garage send you an MP3 of something I recorded in my garage today.
today.
In other cases, a multimedia message represents a convergence In other cases, a multimedia message represents a convergence between
between two or more of the scenarios described above. For example, two or more of the scenarios described above. For example, a voice
a voice message with an accompanying diagram or a talking head video message with an accompanying diagram or a talking head video message
message is a multimedia message. is a multimedia message.
The characteristics will vary somewhat with the intent of the The characteristics will vary somewhat with the intent of the sender.
sender. This in turn may affect the user agent or application used This in turn may affect the user agent or application used to render
to render the message. the message.
11. References 10. References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 10.1 Normative References
9, RFC 2026, October 1996.
2 Troost, R., Dorner, S., and Moore, K., "Communicating [1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
Presentation Information in Internet Messages: The Content- 9, RFC 2026, October 1996.
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 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
4 Vaudreuil, G. and Parsons, G., "VPIM Voice Message MIME Sub-type [3] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
Registration", RFC 2423, Lucent Technologies and Northern
Telecom, September 1998.
5 Resnick, P., "Internet Message Format", RFC 2822, Qualcomm, April [4] Crocker, D. and P. Overell, Eds., "Augmented BNF for Syntax
2001. Specifications: ABNF", RFC 2234, November 1997.
6 Burger, E., "Critical Content of Internet Mail", draft-ietf-vpim- [5] Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
cc-04.txt, Work in Progress. Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
7 Crocker, D. and Overell, P. (Editors), "Augmented BNF for Syntax 10.2 Informative References
Specifications: ABNF", RFC 2234, Internet Mail Consortium and
Demon Internet Ltd., November 1997.
8 Freed, N. and Borenstein, N., "Multipurpose Internet Mail [6] Troost, R., Dorner, S. and K. Moore, "Communicating Presentation
Extensions (MIME) Part One: Format of Internet Message Bodies", Information in Internet Messages: The Content-Disposition Header
RFC 2045, Innosoft and First Virtual, November 1996. Field", RFC 2183, August 1997.
9 Palme, J., Hopmann, A., Shelness, N., "MIME Encapsulation of [7] Vaudreuil, G. and G. Parsons, "VPIM Voice Message MIME Sub-type
Aggregate Documents, such as HTML (MHTML)", RFC 2557, Stockholm Registration", RFC 2423, September 1998.
University/KTH, Microsoft, and Lotus Development Corporation,
March 1999.
10 Levinson, E., "The MIME Multipart/Related Content-type", RFC [8] Burger, E., "Critical Content of Internet Mail", RFC 3459,
2387, August 1998. January 2003.
11 Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA [9] Palme, J., Hopmann, A. and N. Shelness, "MIME Encapsulation of
Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Aggregate Documents, such as HTML (MHTML)", RFC 2557, March
1999.
12. Acknowledgments [10] Levinson, E., "The MIME Multipart/Related Content-type", RFC
2387, August 1998.
11. Acknowledgments
Many of the ideas here arose originally from a discussion with Jutta Many of the ideas here arose originally from a discussion with Jutta
Degener. Degener.
We'd also like to thank Keith Moore for helping us tighten-up our We'd also like to thank Keith Moore for helping us tighten-up our
explanations. explanations.
In the last round, we got some rather good advise from Caleb Clausen In the last round, we got some rather good advise from Caleb Clausen
and Dave Aronson. and Dave Aronson.
Antti Vaha-Sipila pointed out advances in SMS, while Stuart McRae Antti Vaha-Sipila pointed out advances in SMS, while Stuart McRae
helped distil the essence of the pager service vis a vis SMS. helped distil the essence of the pager service vis a vis SMS.
We offer an extra special thanks to Greg Vaudreuil for pulling RFC We offer an extra special thanks to Greg Vaudreuil for pulling RFC
2557 out of his hat. 2557 out of his hat.
13. Author's Addresses 12. Authors' Addresses
Eric Burger Eric Burger
SnowShore Networks, Inc. SnowShore Networks, Inc.
285 Billerica Rd. 285 Billerica Rd.
Chelmsford, MA 01824-4120 Chelmsford, MA 01824-4120
USA USA
Phone: +1 978 367 8403 Phone: +1 978 367 8403
Fax: +1 603 457 5944 EMail: [email protected]
Email: [email protected]
Emily Candell Emily Candell
Comverse Network Systems Comverse Network Systems
200 Quannapowitt Pkwy. 200 Quannapowitt Pkwy.
Wakefield, MA 01880 Wakefield, MA 01880
USA USA
Phone: +1 781 213 2324 Phone: +1 781 213 2324
Email: [email protected] EMail: [email protected]
Graham Klyne Graham Klyne
Baltimore Technologies Ltd. Nine by Nine
1310 Waterside
Arlington Business Park
Theale
Reading, RG7 4SA
United Kingdom United Kingdom
Telephone: +44 118 930 8000 EMail: [email protected]
Facsimile: +44 118 930 9000
E-mail: [email protected]
Charles Eliot Charles Eliot
Microsoft Corporation Microsoft Corporation
One Microsoft Way One Microsoft Way
Redmond WA 98052 Redmond WA 98052
USA USA
Telephone: +1 425 936 9760 Phone: +1 425 706 9760
E-Mail: [email protected] EMail: [email protected]
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 13. Full Copyright Statement
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) 2001 The Internet Society. All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph kind, provided that the above copyright notice and this paragraph are
are included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than followed, or as required to translate it into languages other than
English. English.
The limited permissions granted above are perpetual and will not be The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns. revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 120 change blocks. 
347 lines changed or deleted 298 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/