remove obsolete ones

6 files changed, 0 insertions, 6061 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
deleted file mode 100644
index 348b57c1..00000000
--- a/Documentation/en/I-D/draft-burger-vpim-pc-00.txt
+++ /dev/null
@@ -1,599 +0,0 @@
-
-
-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-ietf-vpim-hint-00.txt b/Documentation/en/I-D/draft-ietf-vpim-hint-00.txt
deleted file mode 100644
index 62e112f8..00000000
--- a/Documentation/en/I-D/draft-ietf-vpim-hint-00.txt
+++ /dev/null
@@ -1,913 +0,0 @@
-
-
-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
deleted file mode 100644
index 82139cdd..00000000
--- a/Documentation/en/I-D/draft-ietf-vpim-hint-01.txt
+++ /dev/null
@@ -1,1116 +0,0 @@
-
-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
deleted file mode 100644
index c15eb45a..00000000
--- a/Documentation/en/I-D/draft-ietf-vpim-hint-02.txt
+++ /dev/null
@@ -1,1061 +0,0 @@
-
-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
deleted file mode 100644
index a7bdcd42..00000000
--- a/Documentation/en/I-D/draft-ietf-vpim-hint-03.txt
+++ /dev/null
@@ -1,1060 +0,0 @@
-
-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
deleted file mode 100644
index e7566af9..00000000
--- a/Documentation/en/I-D/draft-ietf-vpim-pndn-00.txt
+++ /dev/null
@@ -1,1312 +0,0 @@
-
-
-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