commit anyway on vpim

8 files changed, 6090 insertions, 0 deletions

diff --git a/Documentation/en/I-D/draft-burger-vpim-pc-00.txt b/Documentation/en/I-D/draft-burger-vpim-pc-00.txt
new file mode 100644
index 00000000..348b57c1
--- /dev/null
+++ b/Documentation/en/I-D/draft-burger-vpim-pc-00.txt
@@ -0,0 +1,599 @@
+
+
+Network Working Group                                           E. Burger
+Internet Draft                                   Centigram Communications
+Document: draft-burger-vpim-pc-00.txt                          E. Candell
+Category: Standards Track                        Comverse Network Systems
+Expires in six Months                                        June 6, 2000
+
+
+                    Primary Content of 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.
+
+
+
+1.
+  Abstract
+
+   This document describes a mechanism for identifying the primary
+   content type of a multi-part Internet mail message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+                           Expires 12/6/00                    [Page 1]
+
+                   Primary Content of Internet Mail           May 2000
+
+
+
+Table of Contents
+
+1.  ABSTRACT .........................................................1
+2.  CONVENTIONS USED IN THIS DOCUMENT ................................2
+3.  INTRODUCTION .....................................................2
+
+4.  PRIMARY-CONTENT REFERENCE FIELD ..................................3
+4.1.  Primary-Content Syntax .........................................4
+4.2.  content-type Syntax ............................................4
+5.  SECURITY CONSIDERATIONS ..........................................4
+6.  IANA CONSIDERATIONS ..............................................4
+6.1.  Primary-Content Registration ...................................4
+6.2.  Primary Content Type Registrations .............................5
+6.2.1.  voice-message ................................................5
+6.2.2.  fax-message ..................................................6
+6.2.3.  video-message ................................................7
+6.2.4.  text-message .................................................7
+7.  REFERENCES .......................................................8
+8.  ACKNOWLEDGMENTS ..................................................9
+9.  AUTHOR'S ADDRESSES ...............................................9
+
+
+2.
+  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 [2].
+
+   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.
+
+
+3.
+  Introduction
+
+   This document describes the Primary Content identification for
+   multi-part Internet mail.
+
+
+
+
+Burger and Candell         Expires 12/6/00                    [Page 2]
+
+                   Primary Content of Internet Mail           May 2000
+
+
+
+   There is a need for a method of indicating to a User Agent (UA) that
+   the sender or sending system designates that a particular message is
+   primarily of some type.  For example, some clients put a little fax
+   or telephone icon next to a message header in the client application
+   to indicate of the message is fax mail or voice mail, respectively.
+   In addition, some clients will launch helper applications that are
+   appropriate to a particular type of primary message type.  This is a
+   different approach than the usual method of launching a helper
+   application based on one of the (many) media types in the message.
+
+   One method of indicating the primary media content of a message is
+   to examine the media types in the message.  However, this requires
+   the UA to scan the entire message before making this determination.
+   This is particularly burdensome for the multi-media mail situation,
+   as voice and especially video mail objects are quite large.
+
+   Another method of indicating the primary media content of a message
+   is to register a multipart/* MIME subtype.  For example, the VPIM
+   Work Group has registered multipart/voice-message to indicate that a
+   message is primarily voice mail [3].  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.
+
+   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.
+
+   Since the Primary Content indicator is an attribute of the entire
+   message, it is logical to define a new top-level (RFC 822 [4])
+   message attribute, Primary-Content.
+
+   Primary-Content only serves to identify the primary content type of
+   the message.  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.  See the companion document,
+   Critical Content of Internet Mail [5], for a mechanism to perform
+   these tasks.
+
+   Since Primary-Content is only an indicator, goofy situations, such
+   as a message marked "voice-message" but without a voice body part,
+   MUST NOT generate any error report.
+
+
+4.
+  Primary-Content Reference Field
+
+   The Primary-Content reference field is a top-level header inserted
+   by the sending UA to indicate the primary content type of the
+   message.
+
+
+
+Burger and Candell         Expires 12/6/00                    [Page 3]
+
+                   Primary Content of Internet Mail           May 2000
+
+
+
+  4.1. Primary-Content Syntax
+
+   The syntax of the Primary-Content field, formatted according to the
+   ABNF [6] is as follows.  Note that "Primary-Content" is not case
+   sensitive, per RFC 822.
+
+        "Primary-Content" ":" content-type CRLF
+
+  4.2. content-type Syntax
+
+   The content-type indicates the primary media content type of the
+   message.  This is an IANA registered value.  Current values for
+   Primary-Content are as follows.
+
+        content-type =  1 *( [ "voice-message"]
+                             [ "fax-message" ]
+                             [ "video-message" ]
+                             [ "text-message" ] )
+
+
+
+5.
+  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.
+
+   Don't do that!
+
+
+6.
+  IANA Considerations
+
+   NOTE: We won't send in any registrations until it looks like this
+   will become a RFC!
+
+   Following the policies outlined in [7], IANA assigns values for
+   Primary-Content as Specification Required.
+
+  6.1. Primary-Content Registration
+
+   To: ietf-types@iana.org
+   Subject: Registration of New Top-Level Header Field Primary-Content
+
+   Header name:
+   Primary-Content
+
+   Required parameters:
+   Single 7bit text value
+
+   Parameter value:
+
+
+Burger and Candell         Expires 12/6/00                    [Page 4]
+
+                   Primary Content of Internet Mail           May 2000
+
+
+
+   The parameter value specifies the primary media content type 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-burger-vpim-pc-00.txt
+
+   Applications which use this media type:
+   Mail
+   VPIM
+   FPIM
+
+   Additional information: none
+
+   Person & email address to contact for further information:
+   Eric Burger
+   e.burger@ieee.org
+
+   Intended usage: COMMON
+
+
+  6.2. Primary Content Type Registrations
+
+     6.2.1. voice-message
+
+   To: ietf-types@iana.org
+   Subject: Registration of New Primary-Content type voice-message
+
+   Primary-Content type name:
+   voice-message
+
+   Required parameters:
+   none
+
+   Optional parameters:
+   none
+
+   Encoding considerations:
+   none
+
+   Security considerations:
+   none
+
+   Interoperability considerations:
+   User agents declaring the primary content to be voice-message SHOULD
+   conform to VPIMv2.
+
+
+Burger and Candell         Expires 12/6/00                    [Page 5]
+
+                   Primary Content of Internet Mail           May 2000
+
+
+
+   Published specification:
+   draft-burger-vpim-pc-00.txt
+   RFC 2421, Voice Profile for Internet Mail - version 2
+
+   Applications which use this media type:
+   VPIM
+
+   Additional information:
+   none
+
+   Person & email address to contact for further information:
+   Eric Burger
+   e.burger@ieee.org
+
+   Intended usage: COMMON
+
+
+     6.2.2. fax-message
+
+   To: ietf-types@iana.org
+   Subject: Registration of New Primary-Content type fax-message
+
+   Primary-Content type name:
+   fax-message
+
+   Required parameters:
+   none
+
+   Optional parameters:
+   none
+
+   Encoding considerations:
+   none
+
+   Security considerations:
+   none
+
+   Interoperability considerations:
+   none
+
+   Published specification:
+   draft-burger-vpim-pc-00.txt
+
+   Applications which use this media type:
+   FPIM
+
+   Additional information:
+   none
+
+   Person & email address to contact for further information:
+   Eric Burger
+   e.burger@ieee.org
+
+Burger and Candell         Expires 12/6/00                    [Page 6]
+
+                   Primary Content of Internet Mail           May 2000
+
+
+
+
+   Intended usage: COMMON
+
+
+     6.2.3. video-message
+
+   To: ietf-types@iana.org
+   Subject: Registration of New Primary-Content type video-message
+
+   Primary-Content type name:
+   voice-message
+
+   Required parameters:
+   none
+
+   Optional parameters:
+   none
+
+   Encoding considerations:
+   none
+
+   Security considerations:
+   none
+
+   Interoperability considerations:
+   none
+
+   Published specification:
+   draft-burger-vpim-pc-00.txt
+
+   Applications which use this media type:
+   VPIM, FPIM
+
+   Additional information:
+   none
+
+   Person & email address to contact for further information:
+   Eric Burger
+   e.burger@ieee.org
+
+   Intended usage: COMMON
+
+
+     6.2.4. text-message
+
+   To: ietf-types@iana.org
+   Subject: Registration of New Primary-Content type text-message
+
+   Primary-Content type name:
+   text-message
+
+   Required parameters:
+
+Burger and Candell         Expires 12/6/00                    [Page 7]
+
+                   Primary Content of Internet Mail           May 2000
+
+
+
+   none
+
+   Optional parameters:
+   none
+
+   Encoding considerations:
+   none
+
+   Security considerations:
+   none
+
+   Interoperability considerations:
+   none
+
+   Published specification:
+   draft-burger-vpim-pc-00.txt
+
+   Applications which use this media type:
+   VPIM, FPIM
+
+   Additional information:
+   none
+
+   Person & email address to contact for further information:
+   Eric Burger
+   e.burger@ieee.org
+
+   Intended usage: COMMON
+
+
+7.
+  References
+
+
+   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+      9, RFC 2026, October 1996.
+
+   2  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+      Levels", BCP 14, RFC 2119, March 1997.
+
+   3  Vaudreuil, G. and Parsons, G., "VPIM Voice Message MIME Sub-type
+      Registration", RFC 2423, Lucent Technologies and Northern
+      Telecom, September 1998.
+
+   4  Crocker, D., "Standard for the Format of ARPA Internet Text
+      Messages", STD 11, RFC 822, August 1982.
+
+   5  Burger, E. and Candell, E., "Critical Content of Internet Mail",
+      draft-burger-vpim-cc-00.txt, Work in Progress.
+
+
+
+
+
+Burger and Candell         Expires 12/6/00                    [Page 8]
+
+                   Primary Content of Internet Mail           May 2000
+
+
+
+
+   6  Crocker, D. and Overell, P.(Editors), "Augmented BNF for Syntax
+      Specifications: ABNF", RFC 2234, Internet Mail Consortium and
+      Demon Internet Ltd., November 1997.
+
+   7  Alvestrand, H. and T. Narten, "Guidelines for Writing an IANA
+      Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
+
+
+
+8.
+  Acknowledgments
+
+   Coming soon!
+
+
+9.
+  Author's Addresses
+
+   Eric Burger
+   Centigram Communications Corporation
+   Maryland Technology Center
+   1375 Piccard Dr., MS 150I
+   Rockville, MD  20850-4311
+   USA
+
+   Phone: +1 301/212-3320
+   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
+
+
+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
+
+
+Burger and Candell         Expires 12/6/00                    [Page 9]
+
+                   Primary Content of Internet Mail           May 2000
+
+
+
+   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 which 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 and Candell         Expires 12/6/00                   [Page 10]
+
+
+
diff --git a/Documentation/en/I-D/draft-burger-vpim-pc-01.txt b/Documentation/en/I-D/draft-burger-vpim-pc-01.txt
new file mode 100644
index 00000000..df31a17b
--- /dev/null
+++ b/Documentation/en/I-D/draft-burger-vpim-pc-01.txt
@@ -0,0 +1,10 @@
+

+This document has been replaced by draft-ietf-vpim-hint-00.txt.

+For more information or a copy of the document, contact the author directly.

+

+Draft Author(s):

+

+E. Burger: e.burger@ieee.org                                                       

+E. Candell: emily@comversens.com                                                    

+

+

diff --git a/Documentation/en/I-D/draft-ietf-vpim-hint-00.txt b/Documentation/en/I-D/draft-ietf-vpim-hint-00.txt
new file mode 100644
index 00000000..62e112f8
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-vpim-hint-00.txt
@@ -0,0 +1,913 @@
+
+
+Network Working Group                                           E. Burger
+Internet Draft                                   Centigram Communications
+Document: draft-ietf-vpim-hint-00.txt                          E. Candell
+Obsoletes: draft-burger-vpim-pc-00.txt           Comverse Network Systems
+Category: Standards Track                                        C. Eliot
+Expires in six Months                               Microsoft Corporation
+                                                                 G. Klyne
+                                                     Content Technologies
+                                                            July 14, 2000
+
+
+                     Content Hint 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.
+
+
+1.   Abstract
+
+   This document describes a mechanism to allow senders of a multi-part
+   Internet mail message to convey presentational information on the
+   message as a whole.  The document specifies a RFC 822 header called
+   "Content-Hint".  This mechanism is very 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.  Content-Hint gives clues to the
+   receiving UA for the context of the message display.  This allows
+   the receiving UA to present the message in a meaningful way to the
+   recipient.
+
+   This mechanism is needed because examining the message itself is
+   insufficient to determine the context of the message.  For example,
+   one can envision a UA that distinguishes between a voice mail
+   message with a text annotation and a text message with an audio
+   attachment.  Content-Hint would provide the hint to the receiving UA
+   which context to present the message.
+
+                           Expires 1/14/01                    [Page 1]
+                   Primary Content of Internet Mail          July 2000
+
+
+Table of Contents
+
+1.  ABSTRACT .........................................................1
+2.  CONVENTIONS USED IN THIS DOCUMENT ................................2
+3.  MOTIVATION AND GOALS .............................................3
+
+3.1.  The problem ....................................................3
+3.2.  Some messaging scenarios .......................................4
+3.2.1.    Internet e-mail.............................................4
+3.2.2.    Short text messaging service................................5
+3.2.3.    Facsimile...................................................5
+3.2.4.    Voice mail..................................................6
+3.2.5.    Multimedia message..........................................6
+3.3.  The goal .......................................................7
+
+4.  FUNCTIONAL REQUIREMENTS ..........................................7
+5.  THE CONTENT-HINT .................................................7
+6.  CONTENT-HINT REFERENCE FIELD .....................................8
+6.1.  Content-Hint Syntax ............................................8
+6.2.  content-hint Syntax ............................................8
+6.2.1.    voice-message...............................................9
+6.2.2.    fax-message.................................................9
+
+6.2.3.    video-message...............................................9
+6.2.4.    sms-message.................................................9
+6.2.5.    none........................................................9
+7.  SECURITY CONSIDERATIONS ..........................................9
+8.  IANA CONSIDERATIONS .............................................10
+8.1.  Content-Hint Registration .....................................10
+8.2.  Primary Content Type Registrations ............................11
+8.2.1.    voice-message..............................................11
+
+8.2.2.    fax-message................................................11
+8.2.3.    video-message..............................................12
+8.2.4.    sms-message................................................13
+9.  REFERENCES ......................................................14
+10. ACKNOWLEDGMENTS .................................................14
+11. AUTHOR'S ADDRESSES ..............................................15
+
+
+2.   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].
+
+
+Burger et. al.             Expires 1/14/01                    [Page 2]
+                   Primary Content of Internet Mail          July 2000
+
+
+
+   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.
+
+
+3.   Motivation and goals
+
+  3.1. The problem
+
+   Multimedia messaging systems receive messages that may be presented
+   in variety of ways.  For example, traditional e-mail uses simple
+   text messages that the recipient displays and edits.  An UA may
+   automatically print Fax images.  Another UA may play voice messages
+   through a telephone handset.  Likewise, the receiving desktop
+   computer may process and/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 media 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.  Thus the end-user receiving agent needs 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-forwarding a specific message type into another messaging
+        environment? (e.g., short text to a mobile short message
+        service),
+
+   o    prioritizing and grouping messages in an inbox display list,
+
+   o    suggesting appropriate default handling for presentation,
+
+
+
+Burger et. al.             Expires 1/14/01                    [Page 3]
+                   Primary Content of Internet Mail          July 2000
+
+
+   o    suggesting appropriate default handling for reply, forward,
+        etc., and
+
+   o    filtering the message list for presentation via limited-
+        capability user interfaces (e.g. there is no point in offering
+        images when the user is connected by a voice-only telephone
+        user interface).
+
+   A problem faced by multimedia messaging systems is that it is not
+   always easy to decide the presentation characteristics of a received
+   message.  For example:
+
+   o    a message that contains audio and image data:  is this a fax
+        message that happens to have some voice commentary, or is it a
+        voice message that is accompanied by some supplementary
+        diagrams, or 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 an e-mail
+        with an MP3 music attachment, or 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?
+
+   Thus, the issue of presentation characteristics may be related to
+   message media content, but is not the same thing.  The media type
+   used in a message is not sufficient to indicate presentation
+   characteristics.  One cannot determine a priori which of multiple
+   media types to use in a alternative message.  Also what about
+   distinguishing traditional e-mail text and SMS messages?  They are
+   the same media type, but have different presentation
+   characteristics.
+
+  3.2. Some messaging scenarios
+
+   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 handling hint.
+
+     3.2.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 1/14/01                    [Page 4]
+                   Primary Content of Internet Mail          July 2000
+
+
+
+   Two parties can use E-mail can 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 a larger number 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 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 an e-mail.
+
+     3.2.2. Short text messaging service
+
+   One can use a short text message to convey textual information of
+   limited size, typically, up to 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.
+
+     3.2.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 modest connection-time charges.  Message transfer
+   takes place in real-time.  Thus, people often use facsimile for
+   moderately urgent.
+
+   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 1/14/01                    [Page 5]
+                   Primary Content of Internet Mail          July 2000
+
+
+   Most facsimiles are between just two parties (one-to-one).  However,
+   broadcast facsimile service is 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.
+
+     3.2.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.
+
+     3.2.5. Multimedia message
+
+   We define a multimedia message as a message containing more than one
+   basic media type (text, image, audio, video, model, application).
+   These are the characteristics of a multimedia message.
+
+   In some cases, it 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, it 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.
+
+   The characteristics will vary somewhat with the intent of the
+   sender.  This in turn may affect the user agent or application used
+   to create the message.
+
+
+
+
+
+
+Burger et. al.             Expires 1/14/01                    [Page 6]
+                   Primary Content of Internet Mail          July 2000
+
+
+  3.3. The goal
+
+   The goal, then, of this document is to describe a simple mechanism
+   that provides enough information to allow a receiving user agent to
+   make some reasonable decisions about how to present a message.
+
+   The sort of decisions that a receiving agent needs to make include
+   the following items.
+
+   o    what icon or class name to display for each message in a list
+
+   o    a default device and/or application to use for presentation of
+        the message
+
+   o    whether to try and forward the message into another environment
+
+   It is not a goal for this mechanism to provide detailed handling
+   information.  One may apply other techniques to provide more
+   detailed handling information.  The mechanism designed here should
+   work with, rather than against, these other techniques.
+
+
+4.   Functional requirements
+
+   o    To identify a message as belonging to one of small number of
+        enumerated message classes.
+
+   o    Specify a core set of message classes for all message user
+        agents to recognize.
+
+   o    Specify message classes by the originating user's choice of
+        authoring tool or simple user interaction.
+
+   o    Incorrect or invalid message labelling must not result in
+        failure to transfer or inability to present a message.
+
+   o    Message labeling information has to be interpretable in
+        reasonable fashion by many different user agent systems.
+
+   o    The mechanism should be extensible to allow new kinds of
+        message to be introduced and labelled.
+
+
+5.   The Content-Hint
+
+   One method of indicating the interpretation context of the media
+   content of a message is to examine the media types in the message.
+   However, this requires the UA to scan the entire message before
+   making this determination.  This is particularly burdensome for the
+   multi-media mail situation, as voice and especially video mail
+   objects are quite large.
+
+
+Burger et. al.             Expires 1/14/01                    [Page 7]
+                   Primary Content of Internet Mail          July 2000
+
+
+   Another method of indicating the primary media content of a message
+   is to register a multipart/* MIME subtype.  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.
+
+   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.
+
+   Since the content 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 "Content-Hint".
+
+   Content-Hint only serves to identify the content context of the
+   message.  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.  See the companion document,
+   Critical Content of Internet Mail [6], for a mechanism to perform
+   these tasks.
+
+   Since Content-Hint is only an indicator, goofy situations, such as a
+   message marked "voice-message" but without a voice body part, MUST
+   NOT generate any error report.
+
+
+6.   Content-Hint Reference Field
+
+   The Content-Hint reference field is a top-level header inserted by
+   the sending UA to indicate the primary content type of the message.
+
+  6.1. Content-Hint Syntax
+
+   The syntax of the Content-Hint field, formatted according to the
+   ABNF [7] is as follows.  Note that "Content-Hint" is not case
+   sensitive, per RFC 822.
+
+        "Content-Hint" ":" content-hint CRLF
+
+  6.2. content-hint Syntax
+
+   The content-type indicates the primary media content context of the
+   message.  This is an IANA registered value.  Current values for
+   Content-Hint are as follows.
+
+
+
+
+
+Burger et. al.             Expires 1/14/01                    [Page 8]
+                   Primary Content of Internet Mail          July 2000
+
+
+        content-hint =  1 *( [ "voice-message"]
+                             [ "fax-message" ]
+                             [ "video-message" ]
+                             [ "sms-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>
+
+     6.2.1. voice-message
+
+   The voice-message hint states the message is a voice message, with
+   voice messaging semantics.
+
+     6.2.2. fax-message
+
+   The fax-message hint states the message is a facsimile message, with
+   facsimile messaging semantics.
+
+     6.2.3. video-message
+
+   The video-message hint states the message is a video message, with
+   facsimile messaging sematics.
+
+     6.2.4. sms-message
+
+   The sms-message hint states the message is a short text message
+   service (SMS) message, with SMS messaging semantics.
+
+     6.2.5. none
+
+   The none hint states there is no hint for this message.  Clearly, if
+   a message has no Content-Hint reference field, none MUST be the
+   default value.
+
+7.   Security Considerations
+
+   The intention for this header is to indicate media content context
+   only.  One can imagine one creating an "Application" content hint,
+   and have a poorly designed user agent blindly execute a mailed
+   program.  Don't do that!
+
+   One can envision a denial of service attack by bombing a receiver
+   with a message with a Content-hint that doesn't fit the profile of
+   the actual body parts.  This is why the receiver MUST consider the
+
+
+Burger et. al.             Expires 1/14/01                    [Page 9]
+                   Primary Content of Internet Mail          July 2000
+
+
+   Content-hint to be a hint only.  The receiver SHOULD NOT rely on the
+   Content-hint exclusively for presentation processing.
+
+8.   IANA Considerations
+
+   NOTE: We won't send in any registrations until it looks like this
+   will become a RFC!
+
+   Following the policies outlined in [9], IANA assigns values for
+   Content-Hint as Specification Required.
+
+  8.1. Content-Hint Registration
+
+   To: ietf-types@iana.org
+   Subject: Registration of New Top-Level Header Field Content-Hint
+
+   Header name:
+   Content-Hint
+
+   Required parameters:
+   Single 7bit text value
+
+   Parameter value:
+   The parameter value specifies the primary media content type 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-00.txt
+
+   Applications which use this media type:
+   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 1/14/01                   [Page 10]
+                   Primary Content of Internet Mail          July 2000
+
+
+   8.2.        Primary Content Type Registrations
+
+     8.2.1. voice-message
+
+   To: ietf-types@iana.org
+   Subject: Registration of New Content-Hint type voice-message
+
+   Content-Hint type name:
+   voice-message
+
+   Required parameters:
+   none
+
+   Optional parameters:
+   none
+
+   Encoding considerations:
+   none
+
+   Security considerations:
+   none
+
+   Interoperability considerations:
+   User agents declaring the primary content to be voice-message SHOULD
+   conform to VPIMv2.
+
+   Published specification:
+   draft-ietf-vpim-hint-00.txt
+   RFC 2421, Voice Profile for Internet Mail - version 2
+
+   Applications which use this media type:
+   VPIM
+
+   Additional information:
+   none
+
+   Person & email address to contact for further information:
+   Eric Burger
+   e.burger@ieee.org
+
+   Intended usage: COMMON
+
+
+     8.2.2. fax-message
+
+   To: ietf-types@iana.org
+   Subject: Registration of New Content-Hint type fax-message
+
+   Content-Hint type name:
+   fax-message
+
+
+
+Burger et. al.             Expires 1/14/01                   [Page 11]
+                   Primary Content of Internet Mail          July 2000
+
+
+   Required parameters:
+   none
+
+   Optional parameters:
+   none
+
+   Encoding considerations:
+   none
+
+   Security considerations:
+   none
+
+   Interoperability considerations:
+   none
+
+   Published specification:
+   draft-ietf-vpim-hint-00.txt
+
+   Applications which use this media type:
+   FPIM
+
+   Additional information:
+   none
+
+   Person & email address to contact for further information:
+   Eric Burger
+   e.burger@ieee.org
+
+   Intended usage: COMMON
+
+
+     8.2.3. video-message
+
+   To: ietf-types@iana.org
+   Subject: Registration of New Content-Hint type video-message
+
+   Content-Hint type name:
+   voice-message
+
+   Required parameters:
+   none
+
+   Optional parameters:
+   none
+
+   Encoding considerations:
+   none
+
+   Security considerations:
+   none
+
+
+
+Burger et. al.             Expires 1/14/01                   [Page 12]
+                   Primary Content of Internet Mail          July 2000
+
+
+   Interoperability considerations:
+   none
+
+   Published specification:
+   draft-ietf-vpim-hint-00.txt
+
+   Applications which use this media type:
+   VPIM, FPIM
+
+   Additional information:
+   none
+
+   Person & email address to contact for further information:
+   Eric Burger
+   e.burger@ieee.org
+
+   Intended usage: COMMON
+
+
+     8.2.4. sms-message
+
+   To: ietf-types@iana.org
+   Subject: Registration of New Content-Hint type sms-message
+
+   Content-Hint type name:
+   sms-message
+
+   Required parameters:
+   none
+
+   Optional parameters:
+   none
+
+   Encoding considerations:
+   none
+
+   Security considerations:
+   none
+
+   Interoperability considerations:
+   none
+
+   Published specification:
+   draft-ietf-vpim-hint-00.txt
+
+   Applications which use this media type:
+   VPIM, FPIM
+
+   Additional information:
+   none
+
+
+
+Burger et. al.             Expires 1/14/01                   [Page 13]
+                   Primary Content of Internet Mail          July 2000
+
+
+   Person & email address to contact for further information:
+   Eric Burger
+   e.burger@ieee.org
+
+   Intended usage: COMMON
+
+
+9.   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-00.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.
+
+
+
+10.    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.
+
+
+Burger et. al.             Expires 1/14/01                   [Page 14]
+                   Primary Content of Internet Mail          July 2000
+
+
+
+
+11.    Author's Addresses
+
+   Eric Burger
+   Centigram Communications Corporation
+   Maryland Technology Center
+   1375 Piccard Dr., MS 150I
+   Rockville, MD  20850-4311
+   USA
+
+   Phone/Fax: +1 301/212-3320
+   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
+   <<<I need your address here!!!>>>
+
+   Telephone: <Insert Number Here>
+   E-Mail: charle@Exchange.Microsoft.com
+
+
+
+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
+
+Burger et. al.             Expires 1/14/01                   [Page 15]
+                   Primary Content of Internet Mail          July 2000
+
+
+   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 which 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 1/14/01                   [Page 16]
+
\ No newline at end of file
diff --git a/Documentation/en/I-D/draft-ietf-vpim-hint-01.txt b/Documentation/en/I-D/draft-ietf-vpim-hint-01.txt
new file mode 100644
index 00000000..82139cdd
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-vpim-hint-01.txt
@@ -0,0 +1,1116 @@
+
+Network Working Group                                           E. Burger
+Internet Draft                                         SnowShore Networks
+Document: draft-ietf-vpim-hint-01.txt                          E. Candell
+Category: Standards Track                        Comverse Network Systems
+Expires May 2001                                                 C. Eliot
+                                                    Microsoft Corporation
+                                                                 G. Klyne
+                                                     Content Technologies
+                                                        November 24, 2000
+ 
+ 
+                   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 5/13/01                    [Page 1] 
+                  Message Context for Internet Mail      November 2000   
+ 
+Table of Contents 
+    
+1. ABSTRACT...........................................................1 
+2. INTRODUCTION.......................................................3 
+3. CONVENTIONS USED IN THIS DOCUMENT..................................3 
+4. MOTIVATION.........................................................4 
+5. FUNCTIONAL REQUIREMENTS............................................5 
+6. DETERMINING THE MESSAGE CONTEXT....................................6 
+7. MESSAGE-CONTEXT REFERENCE FIELD....................................6 
+7.1. Message-Context Syntax...........................................7 
+7.2. message-context-class Syntax.....................................7 
+7.2.1. voice-message..................................................7 
+7.2.2. fax-message....................................................7 
+7.2.3. video-message..................................................7 
+7.2.4. short-message..................................................7 
+7.2.5. mail-message...................................................8 
+7.2.6. none...........................................................8 
+8. SECURITY CONSIDERATIONS............................................8 
+9. IANA CONSIDERATIONS................................................8 
+9.1. Message-Context Registration.....................................8 
+9.2. Primary Context Class Registrations..............................9 
+9.2.1. Registration Template..........................................9 
+9.2.2. voice-message.................................................10 
+9.2.3. fax-message...................................................11 
+9.2.4. video-message.................................................11 
+9.2.5. short-message.................................................12 
+9.2.6. video-message.................................................13 
+9.2.7. mail-message..................................................13 
+9.2.8. video-message.................................................14 
+9.2.9. none..........................................................14 
+10. APPENDIX: SOME MESSAGING SCENARIOS...............................15 
+10.1. Internet e-mail................................................15 
+10.2. Short text messaging service...................................16 
+10.3. Facsimile......................................................16 
+10.4. Voice mail.....................................................17 
+10.5. Multimedia message.............................................17 
+11. REFERENCES.......................................................18 
+12. ACKNOWLEDGMENTS..................................................18 
+13. AUTHOR'S ADDRESSES...............................................19 
+14. FULL COPYRIGHT STATEMENT.........................................20 
+    
+    
+
+
+
+
+
+  
+Burger et. al.             Expires 5/24/01                    [Page 2] 
+                  Message Context for Internet Mail      November 2000   
+ 
+   2. Introduction 
+    
+   This document describes a mechanism to allow senders of a multi-part 
+   Internet mail message to convey presentational information of the 
+   message as a whole.  This information specifies the context of the 
+   message.  With this information, the user agent (UA) can optimally 
+   present the message to the user in the context she expects. 
+    
+   In this document, the "message context" is the context 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 gives clues to the receiving UA for the 
+   context of the message display as a whole.  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    Arraigning 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. 
+    
+  
+Burger et. al.             Expires 5/24/01                    [Page 3] 
+                  Message Context for Internet Mail      November 2000   
+ 
+    
+   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 
+   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 
+    
+   o    Filter the message list for presentation via limited-capability 
+        user interfaces (e.g., there is no point in offering images 
+        when the user is connected by a voice-only telephone user 
+        interface). 
+    
+   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. 
+    
+
+  
+Burger et. al.             Expires 5/24/01                    [Page 4] 
+                  Message Context for Internet Mail      November 2000   
+ 
+   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.  
+   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. 
+    
+    
+
+
+
+  
+Burger et. al.             Expires 5/24/01                    [Page 5] 
+                  Message Context for Internet Mail      November 2000   
+ 
+   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. 
+    
+   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". 
+    
+   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. 
+    
+   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.  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 MUST NOT generate an error report or 
+   fail to deliver or process the message.  
+    
+    
+   7. Message-Context Reference Field 
+    
+  
+Burger et. al.             Expires 5/24/01                    [Page 6] 
+                  Message Context for Internet Mail      November 2000   
+ 
+   The Message-Context reference field is a top-level header inserted 
+   by the sending UA to indicate the context of the message. 
+    
+  7.1. Message-Context Syntax 
+    
+   The syntax of the Message-Context field, formatted according to the 
+   ABNF [7] is as follows.  Note that "Message-Context" is case 
+   insensitive, per RFC 822. 
+    
+        "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 =  1 *( [ "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> 
+    
+     7.2.1. voice-message 
+    
+   The voice-message class states the message is a voice message. 
+    
+     7.2.2. fax-message 
+    
+   The fax-message class states the message is a facsimile 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. 
+    
+
+  
+Burger et. al.             Expires 5/24/01                    [Page 7] 
+                  Message Context for Internet Mail      November 2000   
+ 
+     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.  This class is functionally identical to the mail-message 
+   class. 
+    
+   If a message has no Message-Context reference field, "none" MUST be 
+   the default value. 
+    
+    
+   8. Security Considerations 
+ 
+   The intention for this header is to indicate message context only.  
+   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 MUST 
+   consider the Message-Context to be a hint only.  The receiver SHOULD 
+   NOT rely on the Message-Context exclusively for presentation 
+   processing. 
+    
+    
+   9. IANA Considerations 
+    
+   Following the policies outlined in [9] as "Specification Required", 
+   IANA assigns values for Message-Context. 
+    
+  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 
+  
+Burger et. al.             Expires 5/24/01                    [Page 8] 
+                  Message Context for Internet Mail      November 2000   
+ 
+   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 
+    
+    
+  9.2. Primary Context Class Registrations 
+    
+     9.2.1. Registration Template 
+    
+   NOTE: Is ietf-types the appropriate address?  Do we need to set up 
+   another address with IANA? 
+    
+   NOTE: What is the appropriate discussion list to socialize new tags 
+   on?  Is it imc822? 
+    
+   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. 
+    
+
+  
+Burger et. al.             Expires 5/24/01                    [Page 9] 
+                  Message Context for Internet Mail      November 2000   
+ 
+   Interoperability considerations: 
+       | Describe issues with existing RFC's or BCP's, if any. 
+    
+   Published specification: 
+       | List the document(s) that define the context this 
+       | class represents 
+   NOTE: Since classes are pretty straight-forward, can we use the 
+   registration mechanism for including a full description of the class 
+   behavior? 
+    
+   Applications that use this context class: 
+       | List known applications that use this context class 
+   NOTE: Do we need to include the Applications enumeration? 
+    
+   Additional information: 
+       | Any other relevant information that might be useful, such 
+       | as related class definitions, 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 
+    
+   Security considerations: 
+   none 
+    
+   Interoperability considerations: 
+   User agents declaring the primary context to be voice-message SHOULD 
+   conform to VPIMv2. 
+    
+   Published specification: 
+   draft-ietf-vpim-hint-01.txt 
+   RFC 2421, Voice Profile for Internet Mail - version 2 
+    
+   Applications that use this context class: 
+   VPIM                               
+    
+   Additional information: 
+   none 
+    
+
+
+
+  
+Burger et. al.             Expires 5/24/01                   [Page 10] 
+                  Message Context for Internet Mail      November 2000   
+ 
+   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 
+    
+   Security considerations: 
+   none 
+    
+   Interoperability considerations: 
+   none 
+    
+   Published specification: 
+   draft-ietf-vpim-hint-01.txt 
+    
+   Applications that use this context class: 
+   FPIM 
+    
+   Additional information: 
+   none 
+    
+   Person & email address to contact for further information: 
+   Eric Burger 
+   e.burger@ieee.org 
+    
+   Intended usage: COMMON 
+    
+    
+     9.2.4. video-message 
+    
+   To: ietf-types@iana.org 
+   Subject: Registration of New Message-Context class video-message 
+    
+   Message-Context class name: 
+   voice-message 
+    
+   Security considerations: 
+   none 
+    
+   Interoperability considerations: 
+   none 
+    
+
+  
+Burger et. al.             Expires 5/24/01                   [Page 11] 
+                  Message Context for Internet Mail      November 2000   
+ 
+   Published specification: 
+   draft-ietf-vpim-hint-01.txt 
+    
+   Applications that use this context class: 
+   VPIM, FPIM 
+    
+   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 
+    
+   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 
+    
+ 
+
+
+
+
+  
+Burger et. al.             Expires 5/24/01                   [Page 12] 
+                  Message Context for Internet Mail      November 2000   
+ 
+     9.2.6. video-message 
+    
+   To: ietf-types@iana.org 
+   Subject: Registration of New Message-Context class video-message 
+    
+   Message-Context class name: 
+   voice-message 
+    
+   Security considerations: 
+   none 
+    
+   Interoperability considerations: 
+   none 
+    
+   Published specification: 
+   draft-ietf-vpim-hint-01.txt 
+    
+   Applications that use this context class: 
+   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. 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 
+    
+  
+Burger et. al.             Expires 5/24/01                   [Page 13] 
+                  Message Context for Internet Mail      November 2000   
+ 
+   Additional information: 
+   none 
+    
+   Person & email address to contact for further information: 
+   Eric Burger 
+   e.burger@ieee.org 
+    
+   Intended usage: COMMON 
+    
+     9.2.8. video-message 
+    
+   To: ietf-types@iana.org 
+   Subject: Registration of New Message-Context class video-message 
+    
+   Message-Context class name: 
+   voice-message 
+    
+   Security considerations: 
+   none 
+    
+   Interoperability considerations: 
+   none 
+    
+   Published specification: 
+   draft-ietf-vpim-hint-01.txt 
+    
+   Applications that use this context class: 
+   VPIM, FPIM 
+    
+   Additional information: 
+   none 
+    
+   Person & email address to contact for further information: 
+   Eric Burger 
+   e.burger@ieee.org 
+    
+   Intended usage: COMMON 
+    
+ 
+     9.2.9. none 
+    
+   To: ietf-types@iana.org 
+   Subject: Registration of New Message-Context class none 
+    
+   Message-Context class name: 
+   none 
+    
+   Security considerations: 
+   none 
+    
+   Interoperability considerations: 
+   none 
+  
+Burger et. al.             Expires 5/24/01                   [Page 14] 
+                  Message Context for Internet Mail      November 2000   
+ 
+    
+   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. 
+    
+   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 
+  
+Burger et. al.             Expires 5/24/01                   [Page 15] 
+                  Message Context for Internet Mail      November 2000   
+ 
+   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. 
+    
+   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. 
+    
+
+
+  
+Burger et. al.             Expires 5/24/01                   [Page 16] 
+                  Message Context for Internet Mail      November 2000   
+ 
+  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 5/24/01                   [Page 17] 
+                  Message Context for Internet Mail      November 2000   
+ 
+   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. 
+    
+    
+    
+
+
+
+
+
+  
+Burger et. al.             Expires 5/24/01                   [Page 18] 
+                  Message Context for Internet Mail      November 2000   
+ 
+   13. Author's Addresses 
+    
+   Eric Burger 
+   SnowShore Networks, Inc. 
+   c/o CRV 
+   1000 Winter St. 
+   Suite 3300 
+   Waltham, MA  02451-1448 
+   USA 
+    
+   Phone: +1 781 487 5406 
+   Fax:   +1 781 895 9809 
+   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 5/24/01                   [Page 19] 
+                  Message Context for Internet Mail      November 2000   
+ 
+   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 5/24/01                   [Page 20] 
+
diff --git a/Documentation/en/I-D/draft-ietf-vpim-hint-02.txt b/Documentation/en/I-D/draft-ietf-vpim-hint-02.txt
new file mode 100644
index 00000000..c15eb45a
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-vpim-hint-02.txt
@@ -0,0 +1,1061 @@
+
+Network Working Group                                           E. Burger
+Internet Draft                                         SnowShore Networks
+Document: draft-ietf-vpim-hint-02.txt                          E. Candell
+Category: Standards Track                        Comverse Network Systems
+Expires June 2001                                                C. Eliot
+                                                    Microsoft Corporation
+                                                                 G. Klyne
+                                                     Content Technologies
+                                                         January 26, 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 7/25/01                    [Page 1] 
+                  Message Context for Internet Mail       January 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..................................................7 
+7.2.2. fax-message....................................................7 
+7.2.3. video-message..................................................7 
+7.2.4. short-message..................................................8 
+7.2.5. mail-message...................................................8 
+7.2.6. none...........................................................8 
+8. Security Considerations............................................8 
+9. IANA Considerations................................................8 
+9.1. Message-Context Registration.....................................8 
+9.2. Primary Context Class Registrations..............................9 
+9.2.1. Registration Template..........................................9 
+9.2.2. voice-message.................................................10 
+9.2.3. fax-message...................................................11 
+9.2.4. video-message.................................................11 
+9.2.5. short-message.................................................12 
+9.2.6. mail-message..................................................12 
+9.2.7. none..........................................................13 
+10. APPENDIX: Some messaging scenarios...............................14 
+10.1. Internet e-mail................................................14 
+10.2. Short text messaging service...................................14 
+10.3. Facsimile......................................................15 
+10.4. Voice mail.....................................................15 
+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 7/25/01                    [Page 2] 
+                  Message Context for Internet Mail       January 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 7/25/01                    [Page 3] 
+                  Message Context for Internet Mail       January 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 
+    
+   o    Filter the message list for presentation via limited-capability 
+        user interfaces (e.g., there is no point in offering images 
+        when the user is connected by a voice-only telephone user 
+        interface). 
+    
+   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 
+
+  
+Burger et. al.             Expires 7/25/01                    [Page 4] 
+                  Message Context for Internet Mail       January 2001   
+ 
+        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.  
+   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. 
+    
+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. 
+    
+   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 
+  
+Burger et. al.             Expires 7/25/01                    [Page 5] 
+                  Message Context for Internet Mail       January 2001   
+ 
+   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. 
+ 
+
+
+
+
+
+  
+Burger et. al.             Expires 7/25/01                    [Page 6] 
+                  Message Context for Internet Mail       January 2001   
+ 
+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> 
+    
+   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. 
+    
+
+
+
+
+  
+Burger et. al.             Expires 7/25/01                    [Page 7] 
+                  Message Context for Internet Mail       January 2001   
+ 
+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. 
+    
+    
+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. 
+    
+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 
+    
+  
+Burger et. al.             Expires 7/25/01                    [Page 8] 
+                  Message Context for Internet Mail       January 2001   
+ 
+   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 
+    
+    
+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. 
+    
+
+  
+Burger et. al.             Expires 7/25/01                    [Page 9] 
+                  Message Context for Internet Mail       January 2001   
+ 
+   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. 
+    
+   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 
+    
+    
+
+
+
+
+
+  
+Burger et. al.             Expires 7/25/01                   [Page 10] 
+                  Message Context for Internet Mail       January 2001   
+ 
+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 
+    
+    
+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 
+  
+Burger et. al.             Expires 7/25/01                   [Page 11] 
+                  Message Context for Internet Mail       January 2001   
+ 
+    
+   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 
+    
+   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 
+  
+Burger et. al.             Expires 7/25/01                   [Page 12] 
+                  Message Context for Internet Mail       January 2001   
+ 
+    
+   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 
+    
+   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 
+    
+  
+Burger et. al.             Expires 7/25/01                   [Page 13] 
+                  Message Context for Internet Mail       January 2001   
+ 
+   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. 
+    
+   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 
+
+  
+Burger et. al.             Expires 7/25/01                   [Page 14] 
+                  Message Context for Internet Mail       January 2001   
+ 
+   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. 
+    
+   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. 
+    
+  
+Burger et. al.             Expires 7/25/01                   [Page 15] 
+                  Message Context for Internet Mail       January 2001   
+ 
+   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 7/25/01                   [Page 16] 
+                  Message Context for Internet Mail       January 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. 
+    
+    
+    
+
+
+
+
+
+  
+Burger et. al.             Expires 7/25/01                   [Page 17] 
+                  Message Context for Internet Mail       January 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 435 305 2837 
+   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 7/25/01                   [Page 18] 
+                  Message Context for Internet Mail       January 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 7/25/01                   [Page 19] 
+
\ No newline at end of file
diff --git a/Documentation/en/I-D/draft-ietf-vpim-hint-03.txt b/Documentation/en/I-D/draft-ietf-vpim-hint-03.txt
new file mode 100644
index 00000000..a7bdcd42
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-vpim-hint-03.txt
@@ -0,0 +1,1060 @@
+
+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] 
+
\ No newline at end of file
diff --git a/Documentation/en/I-D/draft-ietf-vpim-pndn-00.txt b/Documentation/en/I-D/draft-ietf-vpim-pndn-00.txt
new file mode 100644
index 00000000..e7566af9
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-vpim-pndn-00.txt
@@ -0,0 +1,1312 @@
+
+
+Network Working Group                                            E. Burger
+Internet Draft                                    Centigram Communications
+Document: draft-ietf-vpim-pndn-00.txt                        July 14, 2000
+Obsoletes: draft-ema-vpim-pndn-01.txt
+Category: Standards Track
+Expires in six months
+
+
+                   Partial Non-Delivery Notification
+
+
+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.  Other documents may update, replace, or obsolete this
+   document 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.
+
+
+
+
+1.   Abstract
+   This document describes the interaction between systems sending
+   multi-part Internet mail [2] to systems that cannot render parts of
+   the sent message.  In particular, this document describes an
+   extension to the Delivery Status Notification mechanism described in
+   [3].
+
+   An example of partial message delivery failure is the case when a
+   user sends an audio file and a video file to an Internet Voice Mail
+   [4] system.  The Internet Voice Mail system can render the audio
+   part but not the video part.  In this case, a partial delivery
+   occurs.
+
+   This document reflects work undertaken in support of the Internet
+   Voice Mail and Voice Profile for Internet Mail [5] initiatives.  The
+   VPIM Work Group home page is <http://www.ema.org/vpim>.
+
+
+
+
+
+Burger                    Expires 1/14/2001                   [Page 1]
+                  Partial Non-Delivery Notification         July, 2000
+
+
+Table of Contents
+
+   1.   Abstract .....................................................1
+   2.   Conventions used in this document ............................2
+   3.   Introduction .................................................3
+
+   4.   Operation ....................................................5
+   5.   Contents of the PNDN .........................................6
+     5.1.  The message/partial-delivery-status content-type ..........6
+     5.2.  Per-Message PNDN Fields ...................................7
+        5.2.1.  Fields from RFC 1894 .................................7
+        5.2.2.  Original-Message-ID ..................................7
+     5.3.  Per-Part PNDN Fields ......................................8
+        5.3.1.  Fields from RFC 1894 .................................8
+
+        5.3.2.  Action Field .........................................8
+        5.3.3.  Final Recipient Field ................................9
+        5.3.4.  Original Content ID Field ............................9
+        5.3.5.  Original Content Description Field ...................9
+        5.3.6.  Original Content Disposition Field ..................10
+        5.3.7.  Original Content Type Field .........................10
+        5.3.8.  Status Field ........................................10
+
+   6.   Appendix - Examples .........................................11
+     6.1.  PNDN With One Failed Body Part ...........................13
+     6.2.  PNDN With Two Failed Body Parts ..........................14
+     6.3.  PNDN With One Body Part Failure and Two Recipients .......15
+     6.4.  PNDN With One Body Part Failure for One Recipient and
+           Another Body Part Failure for Two Recipients .............16
+   7.   Formal Syntax ...............................................17
+   8.   Security Considerations .....................................19
+
+     8.1.  Forgery ..................................................19
+     8.2.  Confidentiality ..........................................19
+   9.   References ..................................................21
+   10.  Acknowledgments .............................................21
+   11.  Author's Address ............................................22
+   12.  Notices and Full Copyright Statement ........................23
+
+
+
+
+2.   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.
+
+
+
+
+Burger            Internet Draft - Expires 1/14/2001          [Page 2]
+                  Partial Non-Delivery Notification         July, 2000
+
+
+   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 [6].
+
+   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.
+
+
+
+
+3.   Introduction
+
+   This document describes partial non-delivery notifications (PNDN).
+   Partial non-delivery notifications are an extension of the Delivery
+   Status Notification (DSN) described in RFC 1894 [3].
+
+   The need for a partial non-delivery notification comes about because
+   of the internetworking of Internet mail systems with legacy
+   messaging systems that do not fulfil all of the semantics of
+   Internet mail.  Such legacy systems have a limited ability to render
+   all parts of a given message. This document will use the case of an
+   Internet mail system sending electronic messages a legacy voice
+   messaging system for illustrative purposes.
+
+   Electronic mail has historically been text-centric.  Extensions such
+   as MIME enable the desktop to send and receive multi-part,
+   multimedia messages.  Popular multimedia data types include binary
+   word processing documents, binary business presentation graphics,
+   voice, and video.
+
+   Voice mail has historically been audio-centric.  Many voice
+   messaging systems can only render voice.  Extensions such as fax
+   enable the voice mail system to send and receive fax images as well
+   as create multi-part voice and fax messages.  A few voice mail
+   systems can render text using text-to-speech or text-to-fax
+   technology.  Although theoretically possible, none can today render
+   video.
+
+   An important aspect of the interchange between voice messaging
+   services and desktop e-mail client applications is that the
+   rendering capability of the voice messaging platform is often much
+   less than the rendering capability of a desktop e-mail client.  In
+   the e-mail case, the sender has the expectation that the recipient
+   receives all components of a multimedia message.  This is so even if
+   the recipient cannot render all body parts.  For the most part, the
+
+
+Burger            Internet Draft - Expires 1/14/2001          [Page 3]
+                  Partial Non-Delivery Notification         July, 2000
+
+
+   recipient can either find the appropriate rendering tool or tell the
+   sender that she cannot read the particular attachment.
+
+   This is an important issue.  By definition, a MIME-enabled user
+   agent, conforming to [7] will present or make available all of the
+   body parts to the recipient.  However, a voice mail system may not
+   be capable of storing non-voice objects.  Moreover, the voice mail
+   system may not be capable of notifying the recipient that there were
+   undeliverable message parts.
+
+   The inability of the receiving system to render a body part is
+   usually a permanent failure.  Retransmission of the message will not
+   improve the likelihood of a future successful delivery.  Contrast
+   this to the case with normal data delivery.  Traditional message
+   failures, such as a garbled message or disabled link will benefit
+   from retransmission.
+
+   Note that the PNDN does not attempt to address User Agent failures,
+   such as a corruption of a body part.  PNDN only addresses the
+   capability of a system to handle the data type by observing the
+   part's metadata.  Other mechanisms, such as Message Disposition
+   Notification [8], can address the situation when the recipient
+   system discovers an error in the payload of a body part.
+
+   This document addresses the need to allow Internet e-mail client
+   applications to send arbitrary multi-part multimedia messages to
+   voice messaging systems, retaining the semantics of delivery
+   notification, while taking into account the limitations of the voice
+   messaging system's rendering capabilities.  The method described by
+   this document is applicable to any interface between a full-featured
+   user agent and a recipient mail transfer agent that has less
+   rendering and media type storage capabilities than the sender has.
+
+   Ideally, the voice mail system would notify the recipient of the
+   undeliverable body parts.  Such behavior would satisfy the essential
+   requirements of [8].  In fact, if the voice mail system can notify
+   the recipient there were undeliverable body parts, then there would
+   be no need for this document.  However, many voice mail systems are
+   not capable of making this notification.
+
+   NOTE: Another method of handling partial delivery is to determine
+   what parts of the message the sender considers critical.  If the
+   voice mail system could not deliver the critical parts, then the
+   voice mail system would reject the entire message.  If the voice
+   mail system could deliver the critical parts, but there were other
+   undeliverable parts, it would silently delete the parts from the
+   delivered message.  However, currently there is no method to
+   identify critical parts.  In light of the limitations of voice mail
+   systems, we decided to deliver as much of the message as possible,
+   notifying the sender of any parts that the voice mail system fails
+   to deliver.
+
+
+Burger            Internet Draft - Expires 1/14/2001          [Page 4]
+                  Partial Non-Delivery Notification         July, 2000
+
+
+   NOTE: The concept of a critical part indicator is still a useful
+   construction.  The sender may wish to specify a body part as so
+   important that if the system cannot deliver the specified body part,
+   then the system will not deliver any parts of the message.  However,
+   this is beyond the scope of this document.  We should revisit this
+   issue once there is an acceptable mechanism for identifying critical
+   parts.
+
+
+
+
+4.   Operation
+
+   The sending system sees the Internet Voice Mail system as a peer e-
+   mail client.  The only special consideration on the part of the
+   sending system is that it may encode the MIME message following the
+   format specified by VPIM [5] or the Internet Voice Mail Profile [4].
+   Properly encoding and profiling the message will enhance the
+   receiving system's ability to process and successfully deliver the
+   message.  Such considerations include the formatting and encoding of
+   the sender's audio name clip, return address information, out-dial
+   destinations, and other elements.  Refer to [5] for more
+   information.
+
+   The recipient system, on receipt of e-mail destined for a voice mail
+   user, makes a best-efforts attempt to deliver what parts it can to
+   the user.
+
+   If the recipient system is capable of delivering the entire message,
+   it follows the notification protocols specified in [4].
+
+   If the recipient system cannot deliver any part of the message, it
+   will return the non-delivery notification specified in [4].
+
+   If the recipient system is capable of delivering only part of the
+   message, it will return a partial non-delivery notification (PNDN)
+   as described below.
+
+   Delivery failure can occur for all recipients of a message because
+   the recipient system cannot handle a given body part.  However,
+   body-part delivery failure can also occur for a subset of recipients
+   of a message.  This happens if the recipient system is capable of
+   handling the media type of the body part, but the recipient user
+   does not subscribe to a service that can present the media type.
+   For example, consider an Internet Voice Mail platform that can
+   handle fax.  Now consider a service provider that has a class of
+   service that is voice only.  If the message recipient user has a
+   voice only class of service, she will not be able to render fax,
+   which is an image.
+
+   NOTE:  We chose Delivery Status Notification (DSN) [3] over Message
+   Disposition Notification (MDN) [8] as a model for PNDN.  There was
+
+Burger            Internet Draft - Expires 1/14/2001          [Page 5]
+                  Partial Non-Delivery Notification         July, 2000
+
+
+   some discussion on this point because an Internet Voice Mail system
+   acts as both a UA and a MTA.  The Message Disposition Notification
+   deals with things such as return receipt.  The generation of the
+   return receipt can occur long after the receiving system has
+   received the message.  On the other hand, the receiving system can
+   know on receipt whether it has the capabilities to deliver all parts
+   of the message.  In this case, the recipient acts more like an MTA
+   than a UA.  In addition, we decided it was more important for the
+   sender to know the system would never deliver some parts of the
+   message.  It would not be desirable to wait for the recipient to
+   attempt to read the message and only at that point generate a
+   notification that the system could not deliver parts of the message.
+
+   NOTE:  This is why the language uses "is capable of delivering"
+   rather than "delivers" in the description above.
+
+
+
+
+5.   Contents of the PNDN
+
+   The PNDN informs a human or machine sender that the recipient system
+   could not deliver one or more parts of a message they have sent.
+
+   The PNDN is a special case of Delivery Status Notification.  In the
+   sections that follow, refer to [3] for a full description of the
+   fields.
+
+   The receiving system transmits a PNDN as a MIME message with a top-
+   level content-type of multipart/report, as defined in [3].
+
+   The mail system can use the multipart/report content-type for any of
+   several kinds of reports.  For a PNDN, the report-type parameter
+   uses the DSN multipart/report content-type of "delivery-status".
+
+   As described in [9], the first part of a multipart/report content-
+   type is a human readable explanation of the report.  For a PNDN, the
+   second component of the multipart/report is of content-type
+   message/delivery-status.  The third component of the
+   multipart/report consists of the original message or some portion
+   thereof.
+
+
+
+5.1. The message/delivery-status content-type
+
+   The message/delivery-status content-type definition is as follows:
+
+     MIME type name:            message
+     MIME subtype name:         delivery-status
+     Optional parameters:       none.
+     Encoding considerations:   "7bit" encoding is sufficient and
+
+Burger            Internet Draft - Expires 1/14/2001          [Page 6]
+                  Partial Non-Delivery Notification         July, 2000
+
+
+                                conforming systems MUST use it to
+                                maintain readability when viewed
+                                by non-MIME mail readers.
+     Security considerations:   discussed in section 7 of this memo.
+
+
+   The message/delivery-status report type for use in the
+   multipart/report is "delivery-status".
+
+   The body of a message/delivery-status consists of one or more
+   "fields" formatted according to the ABNF [10] specified below and in
+   [3].  The per-message fields appear first, followed by a blank line.
+   Following the per-message fields are one or more groups of per-
+   recipient/per-body part fields.  A blank line precedes each group of
+   per-recipient fields.
+
+   The syntax of the message/delivery-status content is in section 7.
+
+   Section 5.2 describes the per-message-fields.  Section 5.3 describes
+   the per-part-fields.
+
+   NOTE:  Readers should focus on Section 5.3 as it describes the
+   essential extensions to DSN.
+
+
+
+5.2. Per-Message PNDN Fields
+
+
+5.2.1. Fields from RFC 1894
+
+   Except as noted below, the PNDN contains all fields as appropriate
+   from DSN [3].  In particular, Reporting-MTA MUST be present.
+
+   NOTE:  The sender's MTA could generate a DSN.  In this case, the
+   Reporting-MTA is optional.  However, only receiving systems will
+   generate Partial Non-Delivery Notifications.  Thus, the sender needs
+   to know who reported the failure.
+
+
+5.2.2. Original-Message-ID
+
+   The recipient system MUST generate an Original-Message-ID field if a
+   Message-ID field was present in the original message.
+
+   NOTE:  This is a change from RFC 1894.  Few User Agents insert an
+   Envelope-ID.  The sender needs to know what message failed.  Sending
+   back the original message in a multimedia environment has security
+   implications.  In particular, requiring the receiving system to send
+   back large multimedia files would make them vulnerable to denial of
+   service attacks.  Moreover, MIME-encoded body parts are in base64.
+   Since we cannot rely on the user recognizing the original text of
+
+Burger            Internet Draft - Expires 1/14/2001          [Page 7]
+                  Partial Non-Delivery Notification         July, 2000
+
+
+   their message, we must rely on alternative identifying
+   characteristics.
+
+
+
+5.3. Per-Part PNDN Fields
+
+   A PNDN contains information about attempts to deliver a message's
+   parts to one or more recipients.  A group of contiguous per-message,
+   per-recipient body-part content partial non-delivery notification
+   fields contains delivery information for that recipient.  A blank
+   line precedes each group of per-recipient fields.
+
+   PNDN expands upon DSN by introducing body part indicators to DSN's
+   per-recipient block.  This extension allows multiple body part
+   indicators per per-recipient block.  A conforming implementation
+   MUST choose to separate each body-part failure into its own per-
+   recipient block.
+
+   For example, take a message sent to two users, A and B.  In
+   addition, let's say that Part 1 fails for the same reason for both
+   users, and Part 2 fails only for user B for the same reason Part 1
+   failed.  Here is the way of rendering the per-recipient block.
+
+             Recipient A Failure
+             Part 1 Failure
+
+             Recipient B Failure
+             Part 1 Failure
+             Part 2 Failure
+
+
+
+   NOTE:  This RFC could have allowed splitting the report by body-
+   parts. However, this would break other NDN implementations,
+   especially MIXER.
+
+5.3.1. Fields from RFC 1894
+
+   Except as noted below, the PNDN contains all fields as appropriate
+   from DSN [3].  The Original-Recipient, Final-Recipient, Last-
+   Attempt-Date, and Final-Log-ID fields follow their meaning and
+   requirements set forth in DSN.  The Will-Retry-Until field is not
+   relevant, as the PNDN is not a delayed delivery notification.
+
+
+5.3.2. Action Field
+
+   The action field reflects the disposition of the message.  Since the
+   receiving system can deliver at least part of the message, the
+   action value SHOULD be "delivered".  If the recipient system did not
+
+
+Burger            Internet Draft - Expires 1/14/2001          [Page 8]
+                  Partial Non-Delivery Notification         July, 2000
+
+
+   deliver any parts of the message, then it would perform the normal
+   undeliverable message processing described by DSN [3].
+
+   NOTE: Considering partial delivery a failure or a success is a
+   matter of many debates.  There is work ongoing in the IETF to
+   develop an indicator for identifying critical body parts.  With a
+   critical body part indicator, the recipient system can return to the
+   sender a success or failure indication based on whether or not the
+   system succeeded in delivering the critical parts.
+
+   Without critical part indicators, one may chose to err on the side
+   of failing the entire message.  However, from a practical point of
+   view, the sender probably will have some idea of the capabilities of
+   the recipient.  Moreover, experience shows that users do not take
+   well to being bombarded with failure notices they believe should be
+   warnings.
+
+   Therefore, until such a time as we have a critical body part
+   indicator, the best practice is to return a delivered notice to the
+   sender, with the appropriate warning and explanation message for the
+   body part(s) not delivered.
+
+
+5.3.3. Final Recipient Field
+
+   The Final-Recipient field indicates the recipient for which this set
+   of per-part fields applies.  The definition of the final recipient
+   field is as described by DSN [3].  However, for security reasons,
+   the PNDN relaxes the imperative for including this field.  That is,
+   the per-part data MAY include the final recipient field
+
+   NOTE:  The change in imperative from [3], from MUST to MAY, comes
+   from the Internet Voice Mail environment.  One can envision Internet
+   Voice Mail implementations where the service provider wishes to keep
+   the actual host name of the voice mail system hidden yet in the
+   Internet name space.  Reporting the final recipient field may
+   include the actual host name of a voice mail node.  Making that
+   information public through a PNDN may enable attacks on that node.
+
+
+5.3.4. Original Content ID Field
+
+   The Original-Content-ID field MUST be present in the PNDN if a
+   Content-ID field is present in the original message.  This field
+   aids the sender in understanding exactly which body part the
+   receiving system is not capable of delivering.
+
+
+5.3.5. Original Content Description Field
+
+   The Original-Content-Description field MUST be present in the PNDN
+   if a Content-Description field is present in the original message.
+
+Burger            Internet Draft - Expires 1/14/2001          [Page 9]
+                  Partial Non-Delivery Notification         July, 2000
+
+
+   This field aids the sender in understanding exactly which body part
+   the receiving system is not capable of delivering.  This field will
+   be much more useful than the Original-Content-ID field to a human
+   sender.  However, few User Agents insert the Content-Description
+   field in a message.
+
+
+5.3.6. Original Content Disposition Field
+
+   The Original-Content-Disposition field MAY be present in the PNDN if
+   a Content-Disposition field is present in the original message.
+
+   If the original message does not have a Content-Type field, the
+   Original-Content-Disposition field MUST be present in the PNDN if a
+   Content-Disposition field is present in the original message.
+
+   The Original-Content-Disposition field aids the sender in
+   understanding exactly which body part the receiving system is not
+   capable of delivering.  This field will be more useful than the
+   Original-Content-ID field to a human sender.  It will let the human
+   know the file name of the part the receiving system is not capable
+   of handling.
+
+
+5.3.7. Original Content Type Field
+
+   The Original-Content-Type field MUST be present in the PNDN if a
+   Content-Type field is present in the original message.  This field
+   aids the sender in understanding exactly which body part the
+   receiving system is not capable of delivering.  This field will be
+   much more useful than the Original-Content-ID field to a human
+   sender.  It will let the human know the MIME types that the
+   receiving system is not capable of handling.  In addition, the
+   sender will get a clue as to what body part the receiving system is
+   not capable of handling from the filename sub-field, if present.
+
+
+5.3.8. Status Field
+
+   Message Transfer Agents (MTAs) are free to generate standard status
+   codes from [11].  This section describes status codes that have
+   special meaning for PNDN.
+
+   All of these status codes are of type "permanent failures of media",
+   type 5.
+
+   Receiving systems that generate Partial Non-Delivery Notifications
+   MUST insert descriptive text in the comment field of the status code
+   so a human sender can understand why his message failed.
+
+   Sending systems that automatically process returned status codes
+   MUST use the numeric status code and MUST NOT use the comment.
+
+Burger            Internet Draft - Expires 1/14/2001         [Page 10]
+                  Partial Non-Delivery Notification         July, 2000
+
+
+
+
+5.3.8.1.  Media not Supported
+
+   If the recipient system is not capable of delivering a part of a
+   message because it does not support a given media type, it MUST
+   return the Media not Supported status code.  For example, if an
+   Internet Voice Mail system receives an AutoCAD document and it can
+   only render voice, the Internet Voice Mail system will return a
+   Media not Supported status code.
+
+   The Media not Supported status code is 5.6.1 [11].
+
+
+5.3.8.2.  Conversion With Loss Performed
+
+   If the recipient system can deliver the part, but only with a lossy
+   conversion, the receiving system SHOULD NOT return Conversion With
+   Loss Performed.
+
+   NOTE:  We considered the optional return code of Conversion With
+   Loss Performed, Status 5.6.4.  However, we realized two things.
+   First, few Internet Voice Mail systems would necessarily have the
+   capability of generating this warning.  Second, there is dubious
+   value to the sender of receiving this warning.  If the receiver has
+   trouble understanding the rendering of the body part, she can always
+   send a message to the sender.  On the other hand, we could foresee
+   confusion on the part of the sender if he constantly received
+   warning messages every time he sends a message to the particular
+   recipient.
+
+
+
+
+6.   Appendix - Examples
+
+   NOTE:  These examples are for illustrative purposes only and are not
+   a normative part of the PNDN definition.  If an example conflicts
+   with the normative description of sections 3 through 5, the example
+   is wrong.
+
+   The examples in this appendix use the following MIME-Encoded message
+   for the original sent message.
+
+   The message has three parts.  The first part is a text message.  The
+   second part is a voice message.  The third part is a fax message.
+   Here is the sample message.
+
+
+
+   Message-ID: 005901bf3532$2c0c3e20$29010981@mtc.telecnnct.com
+   From: "Eric Burger" <ericb@mtc.telecnnct.com>
+
+Burger            Internet Draft - Expires 1/14/2001         [Page 11]
+                  Partial Non-Delivery Notification         July, 2000
+
+
+   To: "Eric Burger" <eric.burger@centigram.com>
+   Subject: Three-part Message
+   Date: Mon, 22 Nov 1999 12:02:30 -0500
+   MIME-Version: 1.0
+   Content-Type: multipart/mixed;
+        boundary="----=_NextPart_000_0007_01BF34E1.74123720"
+   X-Priority: 3
+   X-Mailer: The One And Only Test Platform V8.1222.974B
+
+   This is a multi-part message in MIME format.
+
+   ------=_NextPart_000_0007_01BF34E1.74123720
+   Content-Type: text/plain;
+        charset="iso-8859-1"
+   Content-Transfer-Encoding: 7bit
+   Content-ID: TextPart0AFF8B
+
+   Here is a three-part message.  The first part is text (this one).
+   The second part is voice.  The third part is fax.
+
+
+
+   ------=_NextPart_000_0007_01BF34E1.74123720
+   Content-Type: audio/wav;
+        name="Voice Message.wav"
+   Content-Transfer-Encoding: base64
+   Content-Disposition: attachment;
+        filename="Voice Message.wav"
+
+   UklGRjgRAABXQVZFZm10IBQAAAAxAAEAQB8AAFkGAABBAAAAAgBAAWZhY3QEAAAAwFMA
+   EQAASfYQFoWCEkuSTST3JGyiTbIfDybr9hltilsnh+uBo/OEpE1iTFGWuFEcFJFuVAxk
+   ...
+   0TIT1twS7JVeyYHHFDaWIEN1mcYMlvLNgGoakdxbL2ErxZprJS+htNhu4ozNYKmwCGvT
+   wErbIgazEvRAGn5hMxhcqGS59UE1cHEjR08A
+
+   ------=_NextPart_000_0007_01BF34E1.74123720
+   Content-Type: image/tiff;
+        name="My House.tif"
+   Content-Transfer-Encoding: base64
+   Content-Disposition: attachment;
+        filename="My House.tif"
+   Content-Description: Picture of My House
+
+   SUkqABhSAAAAAU2agAFNmoABTZqAAU2agAFNmoABTZqAAU2agAFNmoABTZqAAU2agAFN
+   AU2agAFNmoABTZqAAU2agAFNmoABTZqAAU2agAGRqDuH4JefU8/YSwd8/xdn7CKC4PMW
+   ...
+   UAAAGgEFAAEAAAAIUgAAGwEFAAEAAAAQUgAAJAEEAAEAAAAEAAAAKAEDAAEAAAACAAAA
+   AAAAAAEARgEDAAEAAAAAAAAARwEDAAEAAAAAAAAAAAAAAA==
+
+   ------=_NextPart_000_0007_01BF34E1.74123720--
+
+
+
+Burger            Internet Draft - Expires 1/14/2001         [Page 12]
+                  Partial Non-Delivery Notification         July, 2000
+
+
+
+6.1. PNDN With One Failed Body Part
+
+   This example shows a PNDN for a system that does not handle text,
+   but does handle voice and fax.
+
+
+
+   Date: Thu, 22 Nov 1999 09:05:15 -0800
+   From: Mail Delivery Subsystem <MAILER-DAEMON@CENTIGRAM.COM>
+   Message-Id: <199407072116.RAA14128@TELECNNCT>
+   Subject: WARNING: Could Not Delivery Body Part
+   To: <ericb@mtc.telecnnct.com>
+   MIME-Version: 1.0
+   Content-Type: multipart/report; report-type=delivery-status;
+         boundary="RAA14128.773615765/CENTIGRAM.COM"
+
+   --RAA14128.773615765/CENTIGRAM.COM
+
+   The original message was received at Mon, 22 Nov 1999 09:05:05 -0800
+   from root@localhost
+
+      ----- The following addresses had delivery problems -----
+   <eric.burger@centigram.com>  (warning)
+
+      ----- Transcript of session follows -----
+   Could Not Deliver Text Part to < eric.burger@centigram.com >
+
+   Body part will be deleted from queue
+
+   --RAA14128.773615765/CENTIGRAM.COM
+   content-type: message/delivery-status
+
+   Original-Message-ID:
+        005901bf3532$2c0c3e20$29010981@mtc.telecnnct.com
+   Reporting-MTA: dns; telecnnct.com
+
+   Action: delivered
+   Status: 5.6.1     (Media not Supported)
+   Original-Recipient: rfc822;eric.burger@centigram.com
+   Original-Content-ID: TextPart0AFF8B
+
+
+   --RAA14128.773615765/CENTIGRAM.COM
+   content-type: message/rfc822
+
+   Here is a three-part message.  The first part is text (this one).
+   The second part is voice.  The third part is fax.
+
+   --RAA14128.773615765/CENTIGRAM.COM--
+
+
+
+Burger            Internet Draft - Expires 1/14/2001         [Page 13]
+                  Partial Non-Delivery Notification         July, 2000
+
+
+
+6.2. PNDN With Two Failed Body Parts
+
+   This example shows a PNDN for a system that does not handle text or
+   fax.
+
+
+
+   Date: Thu, 22 Nov 1999 09:05:15 -0800
+   From: Mail Delivery Subsystem <MAILER-DAEMON@CENTIGRAM.COM>
+   Message-Id: <199407072116.RAA14128@TELECNNCT>
+   Subject: WARNING: Could Not Delivery Body Part
+   To: <ericb@mtc.telecnnct.com>
+   MIME-Version: 1.0
+   Content-Type: multipart/report; report-type=delivery-status;
+         boundary="RAA14128.773615765/CENTIGRAM.COM"
+
+   --RAA14128.773615765/CENTIGRAM.COM
+
+   The original message was received at Mon, 22 Nov 1999 09:05:05 -0800
+   from root@localhost
+
+      ----- The following addresses had delivery problems -----
+   <eric.burger@centigram.com>  (warning)
+
+      ----- Transcript of session follows -----
+   Could Not Deliver Text Part to < eric.burger@centigram.com >
+   Could Not Deliver Fax Part to < eric.burger@centigram.com >
+
+   Body parts will be deleted from queue
+
+   --RAA14128.773615765/CENTIGRAM.COM
+   content-type: message/delivery-status
+
+   Original-Message-ID:
+        005901bf3532$2c0c3e20$29010981@mtc.telecnnct.com
+   Reporting-MTA: dns; telecnnct.com
+
+   Original-Recipient: rfc822;eric.burger@centigram.com
+   Status: 5.6.1     (Media not Supported)
+   Action: delivered
+   Original-Content-Description: Picture of My House
+   Original-Content-Type: image/tiff; name="My House.tif"
+   Original-Content-Disposition: attachment; filename="My House.tif"
+   Status: 5.6.1     (Media not Supported)
+   Action: delivered
+   Original-Content-ID: TextPart0AFF8B
+
+   --RAA14128.773615765/CENTIGRAM.COM
+   content-type: message/rfc822
+
+
+
+Burger            Internet Draft - Expires 1/14/2001         [Page 14]
+                  Partial Non-Delivery Notification         July, 2000
+
+
+   Here is a three-part message.  The first part is text (this one).
+   The second part is voice.  The third part is fax.
+
+   --RAA14128.773615765/CENTIGRAM.COM--
+
+
+
+6.3. PNDN With One Body Part Failure and Two
+     Recipients
+
+   This example shows a PNDN for a system that does not handle text,
+   but does handle voice and fax.  Assume the original message was sent
+   to <ericb@mtc.telecnnct.com> and <8005551212@vm.sp.net>.
+
+
+
+   Date: Thu, 22 Nov 1999 09:05:15 -0800
+   From: Mail Delivery Subsystem <MAILER-DAEMON@CENTIGRAM.COM>
+   Message-Id: <199407072116.RAA14128@TELECNNCT>
+   Subject: WARNING: Could Not Delivery Body Part
+   To: <ericb@mtc.telecnnct.com>
+   MIME-Version: 1.0
+   Content-Type: multipart/report; report-type=delivery-status;
+         boundary="RAA14128.773615765/CENTIGRAM.COM"
+
+   --RAA14128.773615765/CENTIGRAM.COM
+
+   The original message was received at Mon, 22 Nov 1999 09:05:05 -0800
+   from root@localhost
+
+      ----- The following addresses had delivery problems -----
+   <eric.burger@centigram.com>  (warning)
+   <8005551212@vm.sp.net>  (warning)
+
+      ----- Transcript of session follows -----
+   Could Not Deliver Text Part to < eric.burger@centigram.com >
+   Could Not Deliver Text Part to < 8005551212@vm.sp.net >
+
+   Body part will be deleted from queue
+
+   --RAA14128.773615765/CENTIGRAM.COM
+   content-type: message/delivery-status
+
+   Original-Message-ID:
+        005901bf3532$2c0c3e20$29010981@mtc.telecnnct.com
+   Reporting-MTA: dns; telecnnct.com
+
+   Action: delivered
+   Status: 5.6.1     (Media not Supported)
+   Original-Recipient: rfc822;eric.burger@centigram.com
+   Final-Recipient: rfc822;eburger@vmail27.sp.net
+   Original-Content-ID: TextPart0AFF8B
+
+Burger            Internet Draft - Expires 1/14/2001         [Page 15]
+                  Partial Non-Delivery Notification         July, 2000
+
+
+
+   Action: delivered
+   Status: 5.6.1     (Media not Supported)
+   Original-Recipient: rfc822;8005551212@vm.sp.net
+   Final-Recipient: rfc822;eburger@vmail27.sp.net
+   Original-Content-ID: TextPart0AFF8B
+
+
+   --RAA14128.773615765/CENTIGRAM.COM
+   content-type: message/rfc822
+
+   Here is a three-part message.  The first part is text (this one).
+   The second part is voice.  The third part is fax.
+
+   --RAA14128.773615765/CENTIGRAM.COM--
+
+
+
+6.4. PNDN With One Body Part Failure for One Recipient
+     and Another Body Part Failure for Two Recipients
+
+   This example shows a PNDN for a system that does not handle text,
+   but does handle voice and fax.  However, the recipient at
+   ericb@mtc.telecnnct.com does not subscribe to a fax service.  Assume
+   the original message was sent to <ericb@mtc.telecnnct.com> and
+   <8005551212@vm.sp.net>.
+
+
+
+   Date: Thu, 22 Nov 1999 09:05:15 -0800
+   From: Mail Delivery Subsystem <MAILER-DAEMON@CENTIGRAM.COM>
+   Message-Id: <199407072116.RAA14128@TELECNNCT>
+   Subject: WARNING: Could Not Delivery Body Part
+   To: <ericb@mtc.telecnnct.com>
+   MIME-Version: 1.0
+   Content-Type: multipart/report; report-type=delivery-status;
+         boundary="RAA14128.773615765/CENTIGRAM.COM"
+
+   --RAA14128.773615765/CENTIGRAM.COM
+
+   The original message was received at Mon, 22 Nov 1999 09:05:05 -0800
+   from root@localhost
+
+      ----- The following addresses had delivery problems -----
+   <eric.burger@centigram.com>  (warning)
+   <8005551212@vm.sp.net>  (warning)
+
+      ----- Transcript of session follows -----
+   Could Not Deliver Text Part to < eric.burger@centigram.com >
+   Could Not Deliver Text Part to < 8005551212@vm.sp.net >
+   Could Not Deliver Fax Part to < eric.burger@centigram.com >
+
+
+Burger            Internet Draft - Expires 1/14/2001         [Page 16]
+                  Partial Non-Delivery Notification         July, 2000
+
+
+   Body part will be deleted from queue
+
+   --RAA14128.773615765/CENTIGRAM.COM
+   content-type: message/delivery-status
+
+   Original-Message-ID:
+        005901bf3532$2c0c3e20$29010981@mtc.telecnnct.com
+   Reporting-MTA: dns; telecnnct.com
+
+   Action: delivered
+   Status: 5.6.1     (Media not Supported)
+   Original-Recipient: rfc822;eric.burger@centigram.com
+   Final-Recipient: rfc822;eburger@vmail27.sp.net
+   Original-Content-ID: TextPart0AFF8B
+   Action: delivered
+   Status: 5.6.1     (Media not Supported)
+   Original-Content-Description: Picture of My House
+   Original-Content-Type: image/tiff; name="My House.tif"
+   Original-Content-Disposition: attachment; filename="My House.tif"
+
+   Action: delivered
+   Status: 5.6.1     (Media not Supported)
+   Original-Recipient: rfc822;8005551212@vm.sp.net
+   Original-Content-ID: TextPart0AFF8B
+
+   --RAA14128.773615765/CENTIGRAM.COM
+   content-type: message/rfc822
+
+   Here is a three-part message.  The first part is text (this one).
+   The second part is voice.  The third part is fax.
+
+   --RAA14128.773615765/CENTIGRAM.COM--
+
+
+
+
+7.   Formal Syntax
+
+   The following syntax specification uses the augmented Backus-Naur
+   Form (BNF) as described in RFC-2234 [10].
+
+
+   delivery-status-content =
+          per-message-fields 1*( CRLF per-part-fields)
+
+
+7.1. Syntax of Per-Message Fields
+
+   per-message-fields =
+          [ original-message-id-field CRLF ]
+          [ original-envelope-id-field CRLF ]
+          reporting-mta-field CRLF
+
+Burger            Internet Draft - Expires 1/14/2001         [Page 17]
+                  Partial Non-Delivery Notification         July, 2000
+
+
+          [ dsn-gateway-field CRLF ]
+          [ received-from-mta-field CRLF ]
+          [ arrival-date-field CRLF ]
+          *( extension-field CRLF )
+
+
+   original-message-id-field =
+          "Original-Message-ID" ":" message-id
+
+   message-id = *text
+
+
+   Original-envelope-id-field, reporting-mta-field, dsn-gateway-field,
+   received-from-mta-field, arrival-date-field, and extension-field are
+   all as defined in DSN [3].
+
+
+7.2. Syntax of Per-Part Fields
+
+   per-part-fields =
+       1*( [ original-content-description-field CRLF ]
+           [ original-content-id-field CRLF ]
+           [ original-content-disposition-field CRLF ]
+           [ original-content-type-field CRLF ] )
+       1*( [ original-recipient-field CRLF ]
+           final-recipient-field CRLF )
+       action-field CRLF
+       status-field CRLF
+       [ remote-mta-field CRLF ]
+       [ diagnostic-code-field CRLF ]
+       [ last-attempt-date-field CRLF ]
+       *( extension-field CRLF )
+
+
+   action-field =
+        "Action: delivered"
+
+   original-content-id-field =
+             "Original-Content-ID" ":" content-id
+
+   content-id = *text
+
+   original-content-description-field =
+             "Original-Content-Description" ":" content-description
+
+   content-description = *text
+
+   original-content-disposition-field =
+             "Original-Content-Disposition" ":" content-disposition
+
+   content-disposition = *text
+
+
+Burger            Internet Draft - Expires 1/14/2001         [Page 18]
+                  Partial Non-Delivery Notification         July, 2000
+
+
+   original-content-type-field =
+             "Original-Content-Type" ":" content-type
+
+   content-type = *text
+
+   status-field =
+          "Status" ":" status-code "(" comment ")"
+
+   status-code =
+          DIGIT "." 1*3DIGIT "." 1*3DIGIT
+
+   comment = *text
+
+
+   Original-recipient-field, final-recipient-field, remote-mta-field,
+   diagnostic-code-field, last-attempt-date-field, and extension-field
+   are as defined in DSN [3].
+
+   Status-code is defined in [11].
+
+
+8.   Security Considerations
+
+   The following security considerations apply when using PNDNs.
+
+
+
+8.1. Forgery
+
+   One can forge a PNDN as easily as ordinary Internet electronic mail.
+   User agents and automatic mail handling facilities (such as
+   automatic voice mail forwarding agents) that wish to make use of
+   PNDNs should take appropriate precautions to minimize the potential
+   damage from denial-of-service attacks.
+
+   Security threats related to forged PNDNs include the sending of:
+
+   (a) A falsified delivery notification when the message is
+       not delivered to the indicated recipient,
+   (b) A falsified Final-Recipient address, or
+   (c) A falsified Remote-MTA identification.
+
+
+
+8.2. Confidentiality
+
+   Another dimension of security is confidentiality.  For example, a
+   message recipient can be autoforwarding messages.  However, she does
+   not wish to divulge her autoforward address.  The desire for such
+   confidentiality will probably be heightened as "wireless mailboxes",
+   such as pagers, become more widely used as autoforward addresses.
+
+
+Burger            Internet Draft - Expires 1/14/2001         [Page 19]
+                  Partial Non-Delivery Notification         July, 2000
+
+
+   Confidentiality also applies to the service provider.  For example,
+   in an Internet Voice Mail scenario, one can envision implementations
+   of protocols such as VPIM [5] where reporting the actual Internet
+   host name can open the system to attack.
+
+   MTA authors are encouraged to provide a mechanism that enables the
+   end user to preserve the confidentiality of a forwarding address.
+   Depending on the degree of confidentiality required, and the nature
+   of the environment to which a message were being forwarded, this
+   might be accomplished by one or more of:
+
+   (a) omitting the "Final-Recipient" field, as it has
+       little use to the sender,
+
+   (b) omitting "Remote-*" or extension fields of a PNDN
+       whenever they would otherwise contain confidential
+       information (such as a confidential forwarding address),
+
+   (c) for messages forwarded to a confidential address,
+       setting the envelope return address (e.g. SMTP MAIL FROM
+       address) to the NULL reverse-path ("<>") (so that no
+       PNDNs would be sent from a downstream MTA to the
+       original sender), or
+
+   (d) when forwarding mail to a confidential address, having
+       the forwarding MTA rewrite the envelope return address
+       for the forwarded message and attempt delivery of that
+       message as if the forwarding MTA were the originator.
+       On its receipt of final delivery status, the forwarding
+       MTA would issue a PNDN to the original sender.
+
+   In general, the Reporting MTA site can omit any optional PNDN field
+   that it determines inclusion of the field would impose too great a
+   compromise of site confidentiality.  The need for such
+   confidentiality must be balanced against the utility of the omitted
+   information in trouble reports.
+
+   Implementers are cautioned that many existing MTAs will send non-
+   delivery notifications to a return address in the message header
+   (rather than to the one in the envelope), in violation of SMTP and
+   other protocols.  If a message is forwarded through such an MTA, no
+   reasonable action on the part of the forwarding MTA will prevent the
+   downstream MTA from compromising the forwarding address.  Likewise,
+   if the recipient's MTA automatically responds to messages based on a
+   request in the message header (such as the nonstandard, but widely
+   used, Return-Receipt-To extension header), it will also compromise
+   the forwarding address.
+
+
+
+
+
+
+Burger            Internet Draft - Expires 1/14/2001         [Page 20]
+                  Partial Non-Delivery Notification         July, 2000
+
+
+9.   References
+
+
+   1  Bradner, S., "The Internet Standards Process -- Revision 3", BCP
+      9, RFC 2026, October 1996.
+
+   2  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.
+
+   3  Moore, K. and Vaudreuil, G., "An Extensible Message Format for
+      Delivery Status Notifications", RFC 1894, U. Tennessee and Octel
+      Network Services, January 1996.
+
+   4  a.k.a. VPIMv3
+
+   5  Vaudreuil, G. and Parsons, G., "Voice Profile for Internet Mail -
+      version 2", Lucent Technologies and Nortel Networks, RFC 2421,
+      September 1998.
+
+   6  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+      Levels", BCP 14, RFC 2119, March 1997.
+
+   7  Freed, N. and Borenstein, N, "Multipurpose Internet Mail
+      Extensions (MIME) Part Two: Media Types", RFC 2046, Innosoft and
+      First Virtual, November 1996.
+
+   8  Fajman, R., "An Extensible Message Format for Message Disposition
+      Notifications", RFC 2298, National Institutes of Health, March
+      1998.
+
+   9  Vaudreuil, G., "The Multipart/Report Content Type for the
+      Reporting of Mail System Administrative Messages", RFC 1892,
+      Octel Network Services, January 1996.
+
+   10 Crocker, D. and Overell, P., "Augmented BNF for Syntax
+      Specifications: ABNF", RFC 2234, Internet Mail Consortium and
+      Demon Internet Ltd., November 1997.
+
+   11 Vaudreuil, G., "Enhanced Mail System Status Codes", RFC 1893,
+      Octel Network Systems, January 1996.
+
+
+
+
+10.    Acknowledgments
+
+   I'd like to thank Graham Klyne and Keith Moore for valuable insights
+   into the mechanics of DSN.  Graham Klyne also helped me put this
+   document into English.  However, any bizarre language is my own
+   fault.
+
+
+Burger            Internet Draft - Expires 1/14/2001         [Page 21]
+                  Partial Non-Delivery Notification         July, 2000
+
+
+   Ned Freed and Herman R. Silbiger both had valuable experience
+   corroborating the assertion that users do not like to receive
+   failure notices unless there is a real failure.  Carl-Uno Mauros was
+   able to put into words much better than I did in a prior draft the
+   differences between a system that cannot render a particular part
+   versus a transmission failure.
+
+
+
+11.    Author's Address
+
+   Eric W. Burger
+   Centigram Communications Corporation
+   Maryland Technology Center
+   1375 Piccard Dr., MS 150 R
+   Rockville, MD  20850-4311
+   USA
+   Phone: +1 301/212-3320
+   Email: e.burger@ieee.org
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Burger            Internet Draft - Expires 1/14/2001         [Page 22]
+                  Partial Non-Delivery Notification         July, 2000
+
+
+12.    Notices and 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 implementors or users of this specification
+   can be obtained from the IETF Secretariat.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights which may cover technology that may be required to practice
+   this standard.  Please address the information to the IETF Executive
+   Director.
+
+   Copyright (C) 1999, 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 implmentation 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            Internet Draft - Expires 1/14/2001         [Page 23]
+
\ No newline at end of file
diff --git a/Documentation/en/I-D/draft-ietf-vpim-pndn-01.txt b/Documentation/en/I-D/draft-ietf-vpim-pndn-01.txt
new file mode 100644
index 00000000..bdcd591f
--- /dev/null
+++ b/Documentation/en/I-D/draft-ietf-vpim-pndn-01.txt
@@ -0,0 +1,19 @@
+

+This Internet-Draft has been deleted. Unrevised documents placed in the

+Internet-Drafts directories have a maximum life of six months. After

+that time, they are deleted. This Internet-Draft was not published as

+an RFC.

+

+Internet-Drafts are not an archival document series, and expired

+drafts, such as this one, are not available; please do not ask for

+copies... they are not available. The Secretariat does not have

+information as to future plans of the authors or working groups WRT the

+deleted Internet-Draft.

+

+For more information or a copy of the document, contact the author directly.

+

+Draft Author(s):

+

+E. Burger: e.burger@ieee.org                                                       

+

+