doc: Add RFC documents

1 files changed, 3083 insertions, 0 deletions

diff --git a/doc/rfc/rfc3801.txt b/doc/rfc/rfc3801.txt
new file mode 100644
index 0000000..f4bb25a
--- /dev/null
+++ b/doc/rfc/rfc3801.txt
@@ -0,0 +1,3083 @@
+
+
+
+
+
+
+Network Working Group                                       G. Vaudreuil
+Request for Comments: 3801                           Lucent Technologies
+Obsoletes: 2421                                               G. Parsons
+Category: Standards Track                                Nortel Networks
+                                                               June 2004
+
+
+         Voice Profile for Internet Mail - version 2 (VPIMv2)
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This document specifies a restricted profile of the Internet
+   multimedia messaging protocols for use between voice processing
+   server platforms.  The profile is referred to as the Voice Profile
+   for Internet Mail (VPIM) in this document.  These platforms have
+   historically been special-purpose computers and often do not have the
+   same facilities normally associated with a traditional Internet
+   Email-capable computer.  As a result, VPIM also specifies additional
+   functionality, as it is needed.  This profile is intended to specify
+   the minimum common set of features to allow interworking between
+   conforming systems.
+
+   This document obsoletes RFC 2421 and describes version 2 of the
+   profile with greater precision.  No protocol changes were made in
+   this revision. A list of changes from RFC 2421 are noted in Appendix
+   F.  Appendix A summarizes the protocol profiles of this version of
+   VPIM.
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                     [Page 1]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+Table of Contents
+
+   1.   Introduction...................................................3
+        1.1.  Voice Messaging System Limitations.......................3
+        1.2.  Design Goals.............................................4
+        1.3.  Applicability for VPIM...................................5
+   2.   Requirements Language..........................................5
+   3.   Protocol Restrictions..........................................6
+   4.   Voice Message Interchange Format...............................6
+        4.1.  VPIM Message Addressing Formats..........................7
+        4.2.  Message Header Fields....................................9
+        4.3.  MIME Audio Content Descriptions.........................17
+        4.4.  Voice Message Content Types.............................19
+        4.5.  Other MIME Contents.....................................23
+        4.6.  Delivery Status Notification (DSN)......................25
+        4.7.  Message Disposition Notification (MDN)..................26
+        4.8.  Forwarded Messages......................................26
+        4.9.  Reply Messages..........................................27
+   5.   Message Transport Protocol....................................27
+        5.1.  Base SMTP Protocol......................................28
+        5.2.  SMTP Service Extensions.................................28
+        5.3.  ESMTP - SMTP Downgrading................................30
+   6.   Directory Address Resolution..................................30
+   7.   Management Protocols..........................................30
+        7.1.  Network Management......................................31
+   8.   Conformance Requirements......................................31
+   9.   Security Considerations.......................................32
+        9.1.  General Directive.......................................32
+        9.2.  Threats and Problems....................................32
+        9.3.  Security Techniques.....................................33
+   10.  Normative References..........................................33
+   11.  Acknowledgments...............................................36
+   12.  Appendix A - VPIM Requirements Summary........................37
+   13.  Appendix B - Example Voice Messages...........................43
+   14.  Appendix C - Example Error Voice Processing Error Codes.......49
+   15.  Appendix D - Example Voice Processing Disposition Types.......50
+   16.  Appendix E - IANA Registrations...............................50
+        16.1.  Voice Content-Disposition Parameter Definition.........51
+        16.2.  Multipart/Voice-Message MIME Media Type Definition.....51
+   17.  Appendix F - Change History: RFC 2421 (VPIM V2) To This Doc...53
+   18.  Authors' Addresses............................................54
+   19.  Full Copyright Statement......................................55
+
+
+
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                     [Page 2]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+1.  Introduction
+
+   MIME is the Internet multipurpose, multimedia-messaging standard.
+   This document explicitly recognizes its capabilities and provides a
+   mechanism for the exchange of various messaging technologies,
+   primarily voice and facsimile.
+
+   Voice messaging evolved as telephone answering service into a full
+   send, receive, and forward messaging paradigm with unique message
+   features, semantics and usage patterns.  Voice messaging was
+   introduced on special purpose computers that interface to a telephone
+   switch and provide call answering and voice messaging services.
+   Traditionally, messages sent from one voice messaging system to
+   another were transported using analog networking protocols based on
+   DTMF signaling and analog voice playback. As the demand for
+   networking increases, there was a need for a standard high-quality
+   digital protocol to connect these machines.  VPIM has successfully
+   demonstrated its usefulness as this new standard.  VPIM is widely
+   implemented and is seeing deployment in customer networks.  This
+   document clarifies ambiguities found in the earlier specification and
+   is consistent with implementation practice.  The profile is referred
+   to as Voice Profile for Internet Mail (VPIM) in this document.
+
+   This document specifies a restricted profile of the Internet
+   multimedia messaging protocols for use between voice processing
+   server platforms. These platforms have historically been special-
+   purpose computers and often do not have the same facilities normally
+   associated with a traditional Internet Email-capable computer.  As a
+   result, VPIM also specifies additional functionality, as it is
+   needed.  This profile is intended to specify the minimum common set
+   of features to allow interworking between conforming systems.
+
+   This document obsoletes RFC 2421 and describes VPIM version 2 of with
+   greater precision.  No protocol changes were made in this revision.
+   A list of changes from RFC 2421 are noted in Appendix F.  Appendix A
+   summarizes the protocol profiles of this version of VPIM.
+
+1.1.  Voice Messaging System Limitations
+
+   The following are typical limitations of voice messaging platforms
+   that were considered in creating this baseline profile.
+
+      1) Text messages are not normally received and often cannot be
+      easily displayed or viewed.  They can often be processed only via
+      text-to-speech or text-to-fax features not currently present in
+      many of these machines.
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                     [Page 3]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+      2) Voice mail machines usually act as an integrated Message
+      Transfer Agent, Message Store and User Agent.  There is typically
+      no relaying of messages.  RFC822 header fields may have limited
+      use in the context of the limited messaging features currently
+      deployed.
+
+      3) Voice mail message stores are generally not capable of
+      preserving the full semantics of an Internet message.  As such,
+      use of a voice mail machine for gatewaying is not supported.  In
+      particular, storage of recipient lists, "Received:" lines, and
+      "Message-ID:" may be limited.
+
+      4) Internet-style distribution/exploder mailing lists are not
+      typically supported.  Voice mail machines often implement only
+      local alias lists, with error-to-sender and reply-to-sender
+      behavior. Reply-all capabilities using a Cc list are not generally
+      available.
+
+      5) Error reports must be machine-parsable so that helpful
+      responses can be voiced to users whose only access mechanism is a
+      telephone.
+
+      6) The voice mail systems generally limit address entry to 16 or
+      fewer numeric characters, and normally do not support alphanumeric
+      mailbox names.  Alpha characters are not generally used for
+      mailbox identification, as they cannot be easily entered from a
+      telephone terminal.
+
+   It should be noted that newer systems are based natively on SMTP/MIME
+   and do not suffer these limitations.  In particular, some systems may
+   support media other than voice and fax.
+
+1.2.  Design Goals
+
+   It is a goal of this profile to make as few restrictions and
+   additions to the existing Internet mail protocols as possible while
+   satisfying the requirements for interoperability with current
+   generation voice messaging systems.  This goal is motivated by the
+   desire to increase the accessibility to digital messaging by enabling
+   the use of proven existing networking software for rapid development.
+
+   This specification is intended for use on a TCP/IP network; however,
+   it is possible to use the SMTP protocol suite over other transport
+   protocols.  The necessary protocol parameters for such use are
+   outside the scope of this document.
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                     [Page 4]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+   This profile is intended to be robust enough to be used in an
+   environment, such as the global Internet, with installed-base
+   gateways that do not understand MIME.  Full functionality, such as
+   reliable error messages and binary transport, will require careful
+   selection of gateways (e.g., via MX records) to be used as VPIM
+   forwarding agents. Nothing in this document precludes use of
+   general-purpose MIME email packages to read and compose VPIM
+   messages.  While no special configuration is required to receive VPIM
+   conforming messages, some may be required to originate conforming
+   structures.
+
+   It is expected that a system administrator who can perform TCP/IP
+   network configuration will manage a VPIM messaging system.  When
+   using facsimile or multiple voice encodings, it is suggested that the
+   system administrator maintain a list of the capabilities of the
+   networked mail machines to reduce the sending of undeliverable
+   messages due to lack of feature support.  Configuration,
+   implementation and management of these directory-listing capabilities
+   are local matters.
+
+1.3.  Applicability for VPIM
+
+   VPIM is intended for the exchange of voice messages between
+   traditional voice messaging systems and for systems that need to
+   interoperate with such systems.  VPIM is intended connect voice-
+   messaging systems into special-purpose voice messaging networks.
+   VPIM may also be used between message store servers and VPIM-aware
+   clients such as web servers, TUI, and GUI clients.  VPIM is not
+   intended or optimized for downloading to, or sending from commercial
+   email clients.
+
+   Internet Voice Messaging, the subject of a separate standards
+   initiative, is intended to enable general-purpose email clients to
+   send and receive voice content through general-purpose message stores
+   in an interoperable way.  IVM may also be a suitable format for
+   downloading voice messages from a VPIM server to a commercial email
+   client.  It may also be a suitable format for submission of a voice
+   message from a general-purpose client into a VPIM system.
+
+2.  Requirements Language
+
+   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 [REQ].
+
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                     [Page 5]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+3.  Protocol Restrictions
+
+   This protocol does not limit the number of recipients per message.
+   Where possible, server implementations should not restrict the number
+   of recipients in a single message.  It is recognized that no
+   implementation supports unlimited recipients, and that the number of
+   supported recipients may be quite low.
+
+   This protocol does not limit the maximum message length.
+   Implementers should understand that some machines will be unable to
+   accept excessively long messages.  A mechanism is defined in [SIZE]
+   to declare the maximum message size supported.
+
+   The following sections describe the restrictions and additions to
+   Internet mail protocols that are required to be conforming with this
+   VPIM v2 profile.  Though various SMTP, ESMTP and MIME features are
+   described here, the implementer is referred to the relevant RFCs for
+   complete details.  The table in Appendix A summarizes the protocol
+   details of this profile.
+
+4.  Voice Message Interchange Format
+
+   The voice message interchange format is a profile of the Internet
+   Mail Protocol Suite.  Any Internet Mail message containing the format
+   defined in this section is referred to as a VPIM Message in this
+   document.  As a result, this document assumes an understanding of the
+   Internet Mail specifications.  Specifically, VPIM references
+   components from the message format standard for Internet messages
+   [RFC822], the Multipurpose Internet Message Extensions [MIME1-5], the
+   X.400 gateway specification [X.400], and the delivery status and
+   message disposition notifications [REPORT][DSN][DRPT][STATUS][MDN].
+
+   MIME, introduced in [MIME1], is a general-purpose message body format
+   that is extensible to carry a wide range of body parts.  It provides
+   for encoding binary data so that it can be transported over the 7-bit
+   text-oriented SMTP protocol.  This transport encoding (denoted by the
+   "Content-Transfer-Encoding:" MIME field) is in addition to the audio
+   encoding required to generate a binary object.
+
+   MIME defines two transport-encoding mechanisms to transform binary
+   data into a 7-bit representation, one designed for text-like data
+   ("Quoted-Printable"), and one for arbitrary binary data ("Base64").
+   While Base64 is dramatically more efficient for audio data, either
+   will work.  Where binary transport is available, no transport
+   encoding is needed, and the data can be labeled as "Binary".
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                     [Page 6]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+4.1.  VPIM Message Addressing Formats
+
+   VPIM addresses SHALL use the RFC 822 format based on the Domain Name
+   System.  This naming system has two components: the local part, used
+   for username or mailbox identification; and the host part, used for
+   global machine identification.
+
+4.1.1.  VPIM Addresses
+
+   The local part of the address shall be a US-ASCII string uniquely
+   identifying a mailbox on a destination system.  For voice messaging,
+   the local part SHALL be a printable string containing the mailbox ID
+   of the originator or recipient.  While alpha characters and long
+   mailbox identifiers MAY be permitted, short numeric local parts
+   SHOULD be used as most voice mail networks rely on numeric mailbox
+   identifiers to retain compatibility with the limited 10-digit
+   telephone keypad.  As a result, some voice messaging systems may only
+   be able to handle a numeric local part.  The reception of
+   alphanumeric local parts on these systems may result in the address
+   being mapped to some locally unique (but confusing to the recipient)
+   number or, in the worst case the address could be deleted making the
+   message unreplyable.  Additionally, it may be difficult to create
+   messages on these systems with an alphanumeric local part without
+   complex key sequences or some form of directory lookup (see 6).  The
+   use of the Domain Name System should be transparent to the user.  It
+   is the responsibility of the voice mail machine to lookup the fully-
+   qualified domain name (FQDN) based on the address entered by the user
+   (see 6).
+
+   In the absence of a global directory, specification of the local part
+   is expected to conform to international or private telephone
+   numbering plans.  It is likely that private numbering plans will
+   prevail and these are left for local definition.  However, it is
+   RECOMMENDED that public telephone numbers be noted according to the
+   international numbering plan described in [E.164].  The indication
+   that the local part is a public telephone number is given by a
+   preceding "+" (the "+" would not be entered from a telephone keypad,
+   it is added by the system as a flag). Since the primary information
+   in the numeric scheme is contained by the digits, other character
+   separators (e.g., "-") may be ignored (i.e., to allow parsing of the
+   numeric local mailbox) or may be used to recognize distinct portions
+   of the telephone number (e.g., country code).  The specification of
+   the local part of a VPIM address can be split into the four groups
+   described below:
+
+      1) mailbox number
+          - for use as a private numbering plan (any number of digits)
+          - e.g., 2722@lucent.com
+
+
+
+Vaudreuil & Parsons         Standards Track                     [Page 7]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+      2) mailbox number+extension
+          - for use as a private numbering plan with extensions
+            any number of digits, use of "+" as separator
+          - e.g., 2722+111@Lucent.com
+
+      3) +international number
+          - for international telephone numbers conforming to E.164
+            maximum of 15 digits
+          - e.g., +16137637582@vm.nortel.ca
+
+      4) +international number+extension
+          - for international telephone numbers conforming to E.164
+             maximum of 15 digits, with an extension (e.g., behind a
+             PBX) that has a maximum of 15 digits.
+          - e.g., +17035245550+230@ema.org
+
+   Note that this address format is designed to be compatible with
+   current usage within the voice messaging industry.  It is not
+   compatible with the addressing formats of RFCs 2303-2304.  It is
+   expected that as telephony services become more widespread on the
+   Internet, these addressing formats will converge.
+
+4.1.2.  Special Addresses
+
+   Special addresses to represent the sender are provided for
+   compatibility with the conventions of Internet mail.  These addresses
+   do not use numeric local addresses, both to conform to current
+   Internet practice and to avoid conflict with existing numeric
+   addressing plans. Two special addresses are RESERVED for use as
+   follows:
+
+   postmaster@domain
+
+   By convention, a special mailbox named "postmaster" MUST exist on all
+   systems.  This address is used for diagnostics and should be checked
+   regularly by the system manager. This mailbox is particularly likely
+   to receive text messages, which is not normal on a voice-processing
+   platform.  The specific handling of these messages is an individual
+   implementation choice.
+
+   non-mail-user@domain
+
+   If a reply to a message is not possible, such as a telephone-
+   answering message, then the special address "non-mail-user" SHOULD be
+   used as the originator's address.  Any text name such as "Telephone
+   Answering", or the telephone number if it is available, is permitted.
+   This special address is used as a token to indicate an unreachable
+   originator. A conforming implementation MUST NOT permit a reply to an
+
+
+
+Vaudreuil & Parsons         Standards Track                     [Page 8]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+   address from "non-mail-user".  For compatibility with the installed
+   base of mail user agents, implementations MUST reject the message
+   when a message addressed to "non-mail-user" is received.  The status
+   code for such NDN's is 5.1.1 "Mailbox does not exist".
+
+   Example:
+
+          From: Telephone Answering <non-mail-user@mycompany.com>
+
+4.1.3.  Distribution Lists
+
+   There are many ways to handle distribution list (DL) expansions and
+   none are 'standard'.  A VPIM implementation MAY support DLs.  Using a
+   simple alias is a behavior closest to what many voice mail systems do
+   today and what is to be used with VPIM messages.  A couple of
+   important features that need special care when DLs are used are:
+
+      Reply to the originator - (Address in the RFC822 "Reply-To:" or
+                                 "From" field)
+      Errors to the submitter - (Address in the MAIL FROM field of the
+                                 ESMTP exchange or the "Return-Path:"
+                                 RFC822 field)
+
+   Some proprietary voice messaging protocols include only the recipient
+   of the particular copy in the envelope and include no "header fields"
+   except date and per-message features.  Most voice messaging systems
+   do not provide for "Header Information" in their messaging queues and
+   only include delivery information.  As a result, recipient
+   information MAY be in either the "To:" or "Cc:" header fields. If all
+   recipients cannot be presented then the recipient header fields
+   SHOULD be omitted to indicate that an accurate list of recipients
+   (e.g., for use with a reply-all capability) is not known.
+
+4.2.  Message Header Fields
+
+   Internet messages contain a header information block.  This header
+   block contains information required to identify the sender, the list
+   of recipients, the message send time, and other information intended
+   for user presentation.  Except for specialized gateway and mailing
+   list cases, header fields do not indicate delivery options for the
+   transport of messages.
+
+   Distribution list processors are noted for modifying or adding to the
+   header fields of messages that pass through them.  VPIM systems MUST
+   be able to accept and ignore header fields that are not defined here.
+
+   The following header lines are permitted for use with VPIM messages:
+
+
+
+
+Vaudreuil & Parsons         Standards Track                     [Page 9]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+4.2.1.  From
+
+   SEND RULES
+
+   The originator's fully qualified domain address (a mailbox address
+   followed by the fully qualified domain name) MUST be present.
+   Systems conforming with this profile SHOULD provide the text personal
+   name of the voice message originator in a quoted phrase, if the name
+   is available.  Text names of corporate or positional mailboxes MAY be
+   provided as a simple string.  From: [RFC822]
+
+   Example:
+
+               From: "Joe S. User" <12145551212@mycompany.com>
+
+               From: Technical Support <611@serviceprovider.com>
+
+               From: Non-mail-user@myserver.mycompany.com
+
+   Voice mail machines may not be able to support separate attributes
+   for the "From:" header fields and the SMTP MAIL FROM, VPIM-conforming
+   systems SHOULD set these values to the same address.  Use of
+   addresses different than those present in the "From:" header field
+   address may result in unanticipated behavior.
+
+   RECEIVE RULES
+
+   The user listed in the "From:" field MUST be presented in the voice
+   message envelope of the voice messaging system as the originator of
+   the message, though the exact presentation is an implementation
+   decision (e.g., the mailbox ID or the text name MAY be presented).
+   The "From:" address SHOULD be used for replies (see 4.9).
+
+4.2.2.  To
+
+   The "To:" field contains the recipient's fully-qualified domain
+   address.
+
+   Example:
+
+               To: +12145551213@mycompany.com
+
+   SEND RULES
+
+   There MAY be one or more "To:" fields in any message.  Systems SHOULD
+   provide a list of recipients only if all recipients are available.
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 10]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+   Systems, such as gateways from protocols or legacy platforms that do
+   not indicate the complete list of recipients, MAY provide a "To:"
+   line. Because these systems cannot accurately enumerate all
+   recipients in the "To:" headers, recipients SHOULD NOT be enumerated.
+
+   RECEIVE RULES
+
+   Systems conforming to this profile MAY discard the addresses in the
+   "To:" fields if they are unable to store the information.  This
+   would, of course, make a reply-to-all capability impossible.  If
+   present, the addresses in the "To:" field MAY be used for a reply
+   message to all recipients.
+
+4.2.3.  Cc
+
+   The "Cc:" field contains additional recipients' fully qualified
+   domain addresses.  Many voice mail systems maintain only sufficient
+   envelope information for message delivery and are not capable of
+   storing or providing a complete list of additional recipients.
+
+   SEND RULES
+
+   Conforming implementations MAY send "Cc:" lists if all recipients are
+   known at the time of origination.  If not, systems SHOULD omit the
+   "Cc:" fields to indicate that the full list of recipients is unknown
+   or otherwise unavailable.  The list of disclosed recipients MUST NOT
+   include undisclosed recipients (i.e., those sent via a blind copy).
+
+   Example:
+
+               Cc: +12145551213@mycompany.com
+
+   RECEIVE RULES
+
+   Systems conforming to this profile MAY add all the addresses in the
+   "Cc:" field to the "To:" field, others MAY discard the addresses in
+   the "Cc:" fields.  If a list of "Cc:" addresses is present, these
+   addresses MAY be used for a reply message to all recipients.
+
+4.2.4.  Date
+
+   The "Date:" field contains the date and time the message was sent by
+   the originator.
+
+   SEND RULES
+
+   The sending system MUST report the time the message was sent.  The
+   time zone MUST be present and SHOULD be represented in a four-digit
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 11]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+   time zone offset, such as -0500 for North American Eastern Standard
+   Time.  This MAY be supplemented by a time zone name in parentheses,
+   e.g., "-0700 (PDT)".
+
+   Example:
+
+               Date: Wed, 28 Jul 96 10:08:49 -0800 (PST)
+
+   If the VPIM sender is relaying a message from a system that does not
+   provide a time stamp, the time of arrival at the gateway system
+   SHOULD be used as the date.
+
+   RECEIVE RULES
+
+   Conforming implementations SHOULD be able to convert [RFC822] date
+   and time stamps into local time
+
+4.2.5.  Sender
+
+   The "Sender:" field contains the actual address of the originator if
+   an agent on behalf of the author indicated in the "From:" field sends
+   the message.
+
+   SEND RULES
+
+   This header field MAY be sent by VPIM-conforming systems.
+
+   RECEIVE RULES
+
+   If the address in the "Sender:" field cannot be preserved in the
+   recipient's message queues or in the next-hop protocol from a
+   gateway, the field MAY be silently discarded.
+
+4.2.6.  Return-Path
+
+   The "Return-path:" field is added by the final delivering SMTP
+   server. If present, it contains the address from the MAIL FROM
+   parameter of the ESMTP exchange (see [RFC822]).  Any error messages
+   resulting from the delivery failure MUST be sent to this address.
+   Note that if the "Return-path:" is null ("<>") (e.g., a call answer
+   message would have no return path) delivery status notifications MUST
+   NOT be sent.
+
+   SEND RULES
+
+   The originating system MUST NOT add this header.
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 12]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+   RECEIVE RULES
+
+   If the receiving system is incapable of storing the return path (or
+   MAIL FROM) to be used for subsequent delivery errors (i.e., it is a
+   gateway to a legacy system or protocol), the receiving system must
+   otherwise ensure that further delivery errors don't happen.  Systems
+   that do not support the return path MUST ensure that at the time the
+   message is acknowledged (i.e., when a DSN would be sent), the message
+   is delivered to the recipient's ultimate mailbox.  Non-Delivery
+   notifications SHOULD NOT be sent after that final delivery.
+
+4.2.7.  Message-id
+
+   The "Message-Id:" field contains a globally unique per-message
+   identifier.
+
+   SEND RULES
+
+   A globally unique message-id MUST be generated for each message sent
+   from a VPIM-conforming implementation.
+
+   Example:
+
+               Message-Id: <12345678@mycompany.com>
+
+   RECEIVE RULES
+
+   When provided in the original message, it MUST be used when sending a
+   MDN.  This identifier MAY be used for tracking and auditing.  From
+   [RFC822]
+
+4.2.8.  Reply-To
+
+   If present, the "Reply-To:" header provides a preferred address to
+   which reply messages should be sent (see 4.9).  Typically, voice mail
+   systems can only support one originator of a message so it is likely
+   that this field will be ignored by the receiving system.  From:
+   [RFC822]
+
+   SEND RULES
+
+   A conforming system SHOULD NOT send a "Reply-To:" header.
+
+   RECEIVE RULES
+
+   If a "Reply-To:" field is present, a reply-to-sender message MAY be
+   sent to the address specified (that is, in lieu of the address in the
+   "From:" field).  If the receiving system (e.g., multi-protocol
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 13]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+   gateway) only supports one address for the originator, then the
+   address in the "From:" field MUST be used and the "Reply-To:" field
+   MAY be silently discarded.
+
+4.2.9.  Received
+
+   The "Received:" field contains trace information added to the
+   beginning of a RFC822 message by MTAs.  This is the only field that
+   may be added by an MTA.  Information in this header is useful for
+   debugging when using an US-ASCII message reader or a header-parsing
+   tool.  From: [RFC822]
+
+   SEND RULES
+
+   A VPIM-conforming system MUST add a "Received:" field.  When acting
+   as a gateway, information about the system from which the message was
+   received SHOULD be included.
+
+   RECEIVE RULES
+
+   A VPIM-conforming system MUST NOT remove any "Received:" fields when
+   relaying messages to other MTAs or gateways.  These header fields MAY
+   be ignored or deleted when the message is received at the final
+   destination.
+
+4.2.10.  MIME Version
+
+   The "MIME-Version:" field MUST be present to indicate that the
+   message conforms to [MIME1-5].  Systems conforming with this
+   specification SHOULD include a comment with the words "(Voice 2.0)".
+   [VPIM1] defines an earlier version of this profile and uses the token
+   (Voice 1.0). Example:
+
+               MIME-Version: 1.0 (Voice 2.0)
+
+   This identifier is intended for information only and SHOULD NOT be
+   used to semantically identify the message as being a VPIM message.
+   Instead, the presence of the multipart/voice-message content type
+   defined in section 18.2 SHOULD be used if identification is
+   necessary.
+
+4.2.11.  Content-Type
+
+   The "Content-Type:" header MUST be present to declare the type of
+   content enclosed in the message.  The typical top-level content in a
+   VPIM Message SHOULD be Multipart/Voice-Message.  The allowable
+   contents are detailed starting in section 4.4 of this document.
+   From: [MIME2]
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 14]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+4.2.12.  Content-Transfer-Encoding
+
+   Because Internet mail was initially specified to carry only 7-bit
+   US-ASCII text, it may be necessary to encode voice and fax data into
+   a representation suitable for that environment.  The "Content-
+   Transfer-Encoding:" header describes this transformation if it is
+   needed.
+
+   SEND RULES
+
+   An implementation in conformance with this profile SHOULD send audio
+   and/or facsimile data in "Binary" form when binary message transport
+   is available (see section 5).  When binary transport is not
+   available, implementations MUST encode the audio and/or facsimile
+   data as "Base64".
+
+   RECEIVE RULES
+
+   Conforming implementations MUST recognize and decode the standard
+   encodings, "Binary" (when binary support is available), "7bit,
+   "8bit", "Base64" and "Quoted-Printable" per [MIME1].  The detection
+   and decoding of "Quoted-Printable", "7bit", and "8bit" MUST be
+   supported in order to meet MIME requirements and to preserve
+   interoperability with the fullest range of possible devices.
+
+4.2.13.  Sensitivity
+
+   The "Sensitivity:" field, if present, indicates the requested privacy
+   level.  If no privacy is requested, this field is omitted.  The
+   header definition is as follows:
+
+   Sensitivity := "Sensitivity" ":" Sensitivity-value
+
+   Sensitivity-value := "Personal" / "Private" / "Company-Confidential"
+
+   SEND RULES
+
+   A VPIM-conforming implementation MAY include this header to indicate
+   the sensitivity of a message.  If a user marks a message "Private", a
+   conforming implementation MUST send only the "Private" sensitivity
+   level.  There are no VPIM-specific semantics defined for the values
+   "Personal" or "Company-Confidential".  A conforming implementation
+   SHOULD NOT send the values "Personal" or "Company-Confidential".  If
+   the message is of "Normal" sensitivity, this field SHOULD be omitted.
+   From: [X.400]
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 15]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+   RECEIVE RULES
+
+   If a "Sensitivity:" field with a value of "Private" is present in the
+   message, a conforming system MUST prohibit the recipient from
+   forwarding this message to any other user.  A conforming system,
+   however, SHOULD allow the responder to reply to a sensitive message,
+   but SHOULD NOT include the original message content.  The responder
+   MAY set the sensitivity of the reply message.
+
+   A receiving system MAY ignore sensitivity values of "Personal" and
+   "Company Confidential".
+
+   If the receiving system does not support privacy and the sensitivity
+   is "Private", a negative delivery status notification MUST be sent to
+   the originator with the appropriate status code (5.6.0) "Other or
+   undefined protocol status" indicating that privacy could not be
+   assured.  The message contents SHOULD be returned to the sender to
+   allow for a voice context with the notification.  A non-delivery
+   notification to a private message SHOULD NOT be tagged private since
+   it will be sent to the originator.  From: [X.400]
+
+   A message with no privacy explicitly noted (i.e., no header) or with
+   "Normal" sensitivity has no special treatment.
+
+4.2.14.  Importance
+
+   Indicates the requested importance to be given by the receiving
+   system. If no special importance is requested, this header MAY be
+   omitted and the value of the absent header assumed to be "normal".
+   From: [X.400]
+
+   Importance := "Importance" ":" importance-value
+
+   Importance-value := "low" / "normal" / "high"
+
+   SEND RULES
+
+   Conforming implementations MAY include this header to indicate the
+   importance of a message.
+
+   RECEIVE RULES
+
+   If the receiving system does not support "Importance:", the attribute
+   MAY be silently dropped.
+
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 16]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+4.2.15.  Subject
+
+   The "Subject:" field is often provided by email systems but is not
+   widely supported on voice mail platforms.  From: [RFC822]
+
+   SEND RULES
+
+   For compatibility with text-based mailbox interfaces, a text subject
+   field SHOULD be generated by a conforming implementation.  It is
+   RECOMMENDED that voice-messaging systems that do not support any text
+   user interfaces (e.g., access only by a telephone) insert a generic
+   subject header of "VPIM Message" or "Voice Message" for the benefit
+   of GUI-enabled recipients.
+
+   RECEIVE RULES
+
+   It is anticipated that many voice-only systems will be incapable of
+   storing the subject line.  The subject MAY be discarded by a
+   receiving system.
+
+4.3.  MIME Audio Content Descriptions
+
+4.3.1.  Content-Description
+
+   This field MAY be present to facilitate the text identification of
+   these body parts in simple email readers.  Any values may be used.
+
+   Example:
+
+         Content-Description: Big Telco Voice Message
+
+   SEND RULES
+
+   This field MAY be added to a voice body part to offer a freeform
+   description of the voice content.  It is useful to incorporate the
+   values for Content-Disposition with additional descriptions.  For
+   example, this can be used to indicate product name or transcoding
+   records.
+
+   RECEIVE RULES
+
+   This field MAY be displayed to the recipient.  However, since it is
+   only informative it MAY be ignored.
+
+
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 17]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+4.3.2.  Content-Disposition
+
+   This field MUST be present to allow the parsable identification of
+   body parts within a VPIM voice message.  This is especially useful
+   if, as is typical, more than one Audio/* body occurs within a single
+   level (e.g., Multipart/Voice-Message).  Since a VPIM voice message is
+   intended to be automatically played in the order in which the audio
+   contents occur, the audio contents MUST always be of disposition
+   inline.  However, it is still useful to include a filename value, so
+   this SHOULD be present if this information is available.  From:
+   [DISP]
+
+   SEND RULES
+
+   In order to distinguish between the various types of audio contents
+   in a VPIM voice message a new disposition parameter "voice" is
+   defined with IANA (see section 18.1) with the parameter values below
+   to be used as appropriate:
+
+   Audio-Type := "voice" "=" Audio-type-value
+
+   Audio-type-value := "Voice-Message" / "Voice-Message-Notification" /
+   "Originator-Spoken-Name" /"Recipient-Spoken-Name" /"Spoken-Subject"
+
+      Voice-Message - the primary voice message,
+      Voice-Message-Notification - a spoken delivery notification
+        or spoken disposition notification,
+      Originator-Spoken-Name - the spoken name of the originator,
+      Recipient-Spoken-Name - the spoken name of the recipient(s) if
+        available to the originator
+      Spoken-Subject- the spoken subject of the message, typically
+        spoken by the originator
+
+   Note that there SHOULD only be one instance of each of these types of
+   audio contents per message level.  Additional instances of a given
+   type (i.e., parameter value) MAY occur within an attached forwarded
+   or reply voice message.  If there are multiple recipients for a given
+   message, recipient-spoken-name MUST NOT be used.
+
+   RECEIVE RULES
+
+   Implementations SHOULD use this header.  However, those that do not
+   understand the "voice" parameter (or the "Content-Disposition:"
+   header) can safely ignore it, and will present the audio body parts
+   in order (but will not be able to distinguish between them).  If more
+   than one instance of the "voice" parameter type value is encountered
+   at one level (e.g., multiple 'Voice-Message' tagged contents) then
+   they SHOULD be presented together.
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 18]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+4.3.3.  Content-Duration
+
+   The "Content-Duration:" header provides an indication of the audio
+   length in seconds of the segment.
+
+   Example:
+
+         Content-Duration: 33
+
+   SEND RULES
+
+   This field MAY be present to allow the specification of the length of
+   the audio body part in seconds.
+
+   RECEIVE RULES
+
+   The use of this field on reception is a local implementation issue.
+   From: [DUR]
+
+4.3.4.  Content-Language:
+
+   This field MAY be present to allow the specification of the spoken
+   language of the audio body part.  The encoding is defined in [LANG].
+
+   Example for UK English:
+
+         Content-Language: en-UK
+
+   SEND RULES
+
+   A sending system MAY add this field to indicate the language of the
+   voice.  The determination of this (e.g., automated or user-selected)
+   is a local implementation issue.
+
+   RECEIVE RULES
+
+   The use of this field on reception is a local implementation issue.
+   It MAY be used as a hint to the recipient (e.g., end-user or an
+   automated translation process) as to the language of the voice
+   message.
+
+4.4.  Voice Message Content Types
+
+   The content types described in this section are identified for use
+   within the Multipart/Voice-Message content.  This content is referred
+   to as a "VPIM message" in this document and is the fundamental part
+   of a "VPIM message".
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 19]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+   Only the contents profiled can be sent within a VPIM voice message
+   construct (i.e., the Multipart/Voice-Message content type) to form a
+   simple or a more complex structure (several examples are given in
+   Appendix B).  The presence of other contents within a VPIM voice
+   message is not permitted. In the absence of a bilateral agreement,
+   conforming implementations MUST NOT create a message containing
+   prohibited contents.  In the spirit of liberal acceptance, a
+   conforming implementation MAY accept and render prohibited content.
+   Systems unable to accept or render prohibited contents MAY discard
+   the prohibited contents as necessary to deliver the acceptable
+   content.  When multiple contents are present within the
+   Multipart/Voice-Message, they SHOULD be presented to the user in the
+   order that they appear in the message.
+
+   Some deployed implementations based on a common interpretation of the
+   original VPIM v2 specification reject messages with prohibited
+   content rather than discard the unsupported contents.  For
+   interoperability with these systems, it is especially important that
+   prohibited contents not be sent within a Multipart/Voice-Message.
+
+4.4.1.  Multipart/Voice-Message
+
+   This MIME multipart structure provides a mechanism for packaging a
+   voice message into one container that is tagged as VPIM v2
+   conforming.  The sub-type is identical in semantics and syntax to
+   multipart/mixed, as defined in [MIME2].  As such, it may be safely
+   interpreted as a multipart/mixed by systems that do not understand
+   the sub-type (only the identification as a voice message would be
+   lost).
+
+   In addition to the MIME required boundary parameter, a version
+   parameter is also required for this sub-type.  This is to distinguish
+   this refinement of the sub-type from the previous definition in
+   [VPIM1].  The value of the version parameter is "2.0" if the content
+   conforms to the requirements of this specification.  Should there be
+   further revisions of this content type, there MUST be backwards
+   compatibility (i.e., systems implementing version n can read version
+   2, and systems implementing version 2 can read version 2 contents
+   within a version n).
+
+   SEND RULES
+
+   The Multipart/Voice-Message content-type MUST only contain the
+   profiled media and content types specified in this section (i.e.,
+   Audio/*, Image/*, and Message/RFC822).  The most common will be:
+   spoken name, spoken subject, the message itself, and an attached fax.
+   Forwarded messages are created by simply using the Message/RFC822
+   construct.
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 20]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+   Conformant implementations MUST use Multipart/Voice-Message in a VPIM
+   message.  In most cases, this Multipart/Voice-Message Content-Type
+   will be the top level but may be included within a Message/RFC822 if
+   the message is forwarded or within a multipart/mixed when more than
+   one message is being forwarded.
+
+   RECEIVE RULES
+
+   Conformant implementations MUST recognize the Multipart/Voice-Message
+   content (whether it is a top-level content or contained in a
+   Multipart/Mixed) and MUST be able to separate the contents (e.g.,
+   spoken name or spoken subject).
+
+   The semantic of Multipart/Voice-Message (defined in section 18.2) is
+   identical to Multipart/Mixed and may be interpreted as that by
+   systems that do not recognize this content-type.
+
+4.4.2.  Message/RFC822
+
+   SEND RULES
+
+   MIME requires support of the Message/RFC822 message encapsulation
+   body part.  This body part SHOULD be used within a Multipart/Voice-
+   Message to forward complete messages (see 4.8) or to reply with
+   original content (see 4.9).  From: [MIME2]
+
+   RECEIVE RULES
+
+   The receiving system MUST accept this format and SHOULD treat this
+   attachment as a forwarded message.  The receiving system MAY flatten
+   the forwarding structure (i.e., remove this construct to leave
+   multiple voice contents or even concatenate the voice contents to fit
+   in a recipient's mailbox), if necessary.
+
+4.4.3.  Audio/32KADPCM
+
+   SEND RULES
+
+   An implementation conforming to this profile MUST send Audio/32KADPCM
+   by default for voice [ADPCM].  This encoding is a moderately-
+   compressed encoding with a data rate of 32 kbits/second using
+   moderate processing resources. Typically, this body contains several
+   minutes of message content;  however, if used for spoken name or
+   subject the content is expected to be considerably shorter (i.e.,
+   about 5 and 10 seconds respectively).
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 21]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+   RECEIVE RULES
+
+   Receivers MUST be able to accept and decode Audio/32KADPCM.  If an
+   implementation can only handle one voice body, then multiple voice
+   bodies (if present) SHOULD be concatenated, and MUST NOT be
+   discarded. If concatenated, the contents SHOULD be in the same order
+   they appeared in the multipart.
+
+4.4.4.  Image/TIFF
+
+   A common image encoding for facsimile, known as TIFF-F, is a
+   derivative of the Tag Image File Format (TIFF) and is described in
+   several documents.  For the purposes of VPIM, the F Profile of TIFF
+   for Facsimile (TIFF-F) is defined in [TIFF-F], and the Image/TIFF
+   MIME content-type is defined in [TIFFREG].  While there are several
+   formats of TIFF, only TIFF-F is profiled for use within
+   Multipart/Voice-Message. Further, since the TIFF-F file format is
+   used in a store-and-forward mode with VPIM, the image MUST be encoded
+   so that there is only one image strip per facsimile page.
+
+   SEND RULES
+
+   All VPIM implementations that support facsimile MUST generate TIFF-F
+   compatible facsimile contents in the Image/TIFF subtype using the
+   application=faxbw encoding by default.  If the VPIM message is a
+   voice- annotated fax, the implementation SHOULD send this fax content
+   in Multipart/Voice-Message.  If the message is a simple fax, an
+   implementation MAY send it without using the Multipart/Voice-Message
+   to be more compatible with fax-only (RFC 2305) implementations.
+
+   While any valid MIME body header MAY be used (e.g., Content-
+   Disposition to indicate the filename), none are specified to have
+   special semantics for VPIM and MAY be ignored.  Note that the
+   content-type parameter application=faxbw MUST be included in outbound
+   messages.
+
+   RECEIVE RULES
+
+   Not all VPIM systems support fax, but all SHOULD accept it within the
+   multipart/voice-message.  Within a Multipart/Voice-Message, a
+   receiving system that cannot render fax content SHOULD accept the
+   voice content of a VPIM message and discard the fax content.  Outside
+   a Multipart/Voice-Message, a recipient system MAY reject (with
+   appropriate NDN) the entire message if it cannot store or is not
+   capable of rendering a message with fax attachments.  VPIM conforming
+   systems MAY support fax outside of (or without) the Multipart/Voice-
+   Message.
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 22]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+   Some deployed implementations based on a common interpretation of the
+   original VPIM V2 specification reject messages with fax content
+   within the Multipart/Voice-Message rather than discard the
+   unsupported contents. These systems will return the message to the
+   sender with an NDN indicating lack of support for fax.
+
+4.5.  Other MIME Contents
+
+   The following MIME contents (with the exception of multipart/mixed in
+   section 4.5.1) MAY be included within a multipart/voice message.
+   Other contents MUST NOT be included.  Their handling is a local
+   implementation issue.  Multipart/mixed is included to promote
+   interoperability with a wider range of systems and also to allow the
+   creation of more complex multimedia messages (with a VPIM message as
+   one part).
+
+4.5.1.  Multipart/Mixed
+
+   This common MIME content-type allows the enclosing of several body
+   parts in a single message.
+
+   SEND RULES
+
+   A VPIM voice message (i.e., multipart/voice-message) MAY be included
+   within a message with a Multipart/Mixed top-level content type.
+   Typically, this would only be used when mixing non-voice and non-fax
+   contents with a voice message.
+
+   RECEIVE RULES
+
+   Such a message is not itself a VPIM message and the handling of such
+   a construct is outside the scope of the VPIM profile.  However, an
+   the spirit of liberal acceptance, a conforming implementation MUST
+   accept and render a VPIM voice message contained in a
+   Multipart/Mixed.
+
+4.5.2.  Text/Directory
+
+   SEND RULES
+
+   This content was profiled in the original specification of VPIM v2 as
+   a means of transporting contact information from the sender to the
+   recipient.  This usage did not find widespread adoption and is no
+   longer a feature of VPIM V2.  Conforming implementations SHOULD NOT
+   send the Text/Directory content type.
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 23]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+   RECEIVE RULES
+
+   For compatibility with an earlier specification of VPIM v2, the
+   Text/Directory content type MUST be accepted by a conforming
+   implementation, but need not be stored, processed, or rendered to the
+   recipient.
+
+4.5.3.  Proprietary Voice or Fax Formats
+
+   Use of any other encoding except the required codecs reduces
+   interoperability in the absence of explicit knowledge about the
+   capabilities of the recipient.  A conforming implementation SHOULD
+   NOT use any other encoding unless a unique identifier is registered
+   with the IANA prior to use (see [MIME4]).  The voice encodings SHOULD
+   be registered as subtypes of Audio. The fax encodings SHOULD be
+   registered as subtypes of Image.
+
+   SEND RULES
+
+   Proprietary voice encoding formats or other standard formats SHOULD
+   NOT be sent under this profile unless the sender has a reasonable
+   expectation that the recipient will accept the encoding.  In
+   practice, this requires explicit per-destination configuration
+   information maintained either in a directory, personal address book,
+   or gateway configuration tables.
+
+   RECEIVE RULES
+
+   Systems MAY accept other Audio/* or Image/* content types if they can
+   decode them.  Systems which receive Audio/* or Image/* content types
+   which they are unable to deposit or unable to render MUST return the
+   message (and SHOULD include the original content) to the originator
+   with an NDN indicating media not supported.
+
+4.5.4.  Text/Plain
+
+   MIME requires support of the basic Text/Plain content type (with the
+   US-ASCII character set).  This content type has limited applicability
+   within the voice-messaging environment.  However, because VPIM is a
+   MIME profile, MIME requirements SHOULD be met.
+
+   SEND RULES
+
+   Conforming VPIM implementations SHOULD NOT send the Text/Plain
+   content-type.  Implementations MAY send the Text/Plain content-type
+   outside the Multipart/Voice-Message.
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 24]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+   RECEIVE RULES
+
+   Within a Multipart/Voice-Message, the Text/Plain content-type MAY be
+   dropped from the message, if necessary, to deliver the audio/fax
+   components.  The recipient SHOULD NOT reject the entire message if
+   the text component cannot be accepted or rendered.
+
+   Outside a Multipart/Voice-Message, conforming implementations MUST
+   accept Text/Plain; however, specific handling is left as an
+   implementation decision.  From: [MIME2]
+
+   Some deployed implementations based on a common interpretation of the
+   original VPIM V2 specification reject messages with any text content
+   rather than discard the unsupported contents.  These systems will
+   return the message to the sender with an NDN indicating lack of
+   support for text.
+
+4.6.  Delivery Status Notification (DSN)
+
+   A DSN is a notification of delivery (positive DSN), non-delivery
+   (negative DSN), or temporary delivery delay (delayed DSN).  The top-
+   level content-type of a DSN is Multipart/Report, which is defined in
+   [REPORT].  The content-type which distinguishes DSN's from other
+   types of notifications is Message/Delivery-Status, which is defined
+   in [DSN].
+
+   SEND RULES
+
+   A VPIM-compliant implementation MUST be able to send DSN's that
+   conform to [REPORT] and [DSN].  Unless requested otherwise, a non-
+   delivery DSN MUST be sent when any form of non-delivery of a message
+   occurs.
+
+   A VPIM-compliant implementation SHOULD provide a spoken delivery
+   status in the "human-readable" body part of the DSN, but MAY provide
+   a textual status.
+
+   RECEIVE RULES
+
+   A VPIM-compliant implementation MUST be able to receive DSN's that
+   conform to [REPORT] and [DSN].
+
+   A VPIM-compliant implementation MUST be able to receive a DSN whose
+   "human-readable" body part contains a spoken delivery status phrase
+   or a textual description.  Though subsequent use of the phrase or
+   text is a local implementation issue, the intent of the DSN MUST be
+   presented to the end user.
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 25]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+4.7.  Message Disposition Notification (MDN)
+
+   An MDN is a notification indicating what happens to a message after
+   it is deposited in the recipient's mailbox.  An MDN can be positive
+   (message was read/played/rendered/etc.) or negative (message was
+   deleted before recipient could see it, etc.).  The top-level
+   content-type of a MDN is Multipart/Report, which is defined in
+   [REPORT].  The content-type which distinguishes MDN's from other
+   types of notifications is Message/Disposition-Notification, which is
+   defined in [MDN].
+
+   SEND RULES
+
+   A VPIM-compliant implementation SHOULD support the ability to request
+   MDNs.  This is done via the use of the "Disposition-Notification-To:"
+   header field as defined in [MDN].
+
+   A VPIM-compliant implementation SHOULD support the ability to send
+   MDNs, but these MDNs MUST conform to [REPORT] and [MDN].
+
+   When sending an MDN, a VPIM-compliant implementation SHOULD provide a
+   spoken message disposition in the "human-readable" body part of the
+   MDN, but MAY provide a textual status.
+
+   RECEIVE RULES
+
+   A VPIM-compliant implementation SHOULD respond to an MDN request with
+   an MDN response.
+
+   A VPIM-compliant implementation MUST be able to receive MDNs that
+   conform to [REPORT] and [MDN], if it is capable of requesting MDNs.
+   If a VPIM-compliant implementation is capable of receiving MDNs, it
+   MUST be able to receive a MDN whose "human-readable" body part
+   contains a spoken message disposition phrase or a textual disposition
+   description.  Though subsequent use of the phrase or text is a local
+   implementation issue, the intent of the MDN MUST be presented to the
+   end user.
+
+4.8.  Forwarded Messages
+
+   VPIM v2 explicitly supports the forwarding of voice and fax content
+   with voice or fax annotation.  However, only the two constructs
+   described below are acceptable in a VPIM message.  Since only the
+   first (i.e., Message/RFC822) can be recognized as a forwarded message
+   (or even multiple forwarded messages), it is RECOMMENDED that this
+   construct be used whenever possible.
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 26]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+   Forwarded VPIM messages SHOULD be sent as a Multipart/Voice-Message
+   with the entire original message enclosed in a Message/RFC822
+   content-type and the annotation as a separate Audio/* or Image/* body
+   part.  If the RFC822 header fields are not available for the
+   forwarded content, simulated header fields with available information
+   SHOULD be constructed to indicate the original sending timestamp, and
+   the original sender as indicated in the "From:" field.  Note that at
+   least one of "From:", "Subject:", or "Date:" MUST be present.  As
+   well, the Message/RFC822 content MUST include at least the "MIME-
+   Version:", and "Content-Type:" header fields.  From: [MIME2]
+
+   In the event that forwarding information is lost, the entire audio
+   content MAY be sent as a single Audio/* segment without including any
+   forwarding semantics.  An example of this loss is an AMIS message
+   being forwarded through an AMIS-to-VPIM gateway.
+
+4.9.  Reply Messages
+
+   VPIM v2 explicitly supports replying to received messages.
+
+   Support of multiple originator header fields in a reply message is
+   often not possible on voice messaging systems, so it may be necessary
+   to choose only one when gatewaying a VPIM message to another voice
+   message system.  However, implementers should note that this may make
+   it impossible to send DSN's, MDN's, and replies to their proper
+   destinations.
+
+   In some cases, replying to a message is not possible, such as with a
+   message created by telephone answering (i.e., classic voice mail).
+   In this case, the From field SHOULD contain the special address non-
+   mail-user@domain (see 4.1.2).  The recipient's VPIM system SHOULD NOT
+   offer the option to reply to this kind of message (unless an
+   outcalling feature is offered - which is out of scope for VPIM).
+
+5.  Message Transport Protocol
+
+   Messages are transported between voice mail machines using the
+   Internet Extended Simple Mail Transfer Protocol (ESMTP).  All
+   information required for proper delivery of the message is included
+   in the ESMTP dialog.  This information, including the sender and
+   recipient addresses, is commonly referred to as the message
+   "envelope".  This information is equivalent to the message control
+   block in many analog voice messaging protocols.
+
+   ESMTP is a general-purpose messaging protocol, designed both to send
+   mail and to allow terminal console messaging.  Simple Mail Transport
+   Protocol (SMTP) was originally created for the exchange of US-ASCII
+   7-bit text messages.  Binary and 8-bit text messages have
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 27]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+   traditionally been transported by encoding the messages into a 7-bit
+   text-like form.  [ESMTP] formalized an extension mechanism for SMTP,
+   and subsequent RFCs have defined 8-bit text networking, command
+   streaming, binary networking, and extensions to permit the
+   declaration of message size for the efficient transmission of large
+   messages such as multi-minute voice mail.
+
+   The following sections list ESMTP commands, keywords, and parameters
+   that are required and those that are optional for conformance to this
+   profile.
+
+5.1.  Base SMTP Protocol
+
+   A conforming system MUST implement all mandatory SMTP and ESMTP
+   commands.  Any defined optional command or parameter MAY be
+   supported.
+
+5.2.  SMTP Service Extensions
+
+   VPIM utilizes a number of SMTP Service Extensions to provide full-
+   featured voice messaging service.  The following extensions are
+   profiled for use with VPIM:
+
+5.2.1.  DSN Extension
+
+   The DSN extension defines a mechanism which allows an SMTP client to
+   specify (a) DSN's should be generated under certain conditions, (b)
+   whether such DSN's should return the contents of the message, and (c)
+   additional information, to be returned with a DSN, that allows the
+   sender to identify both the recipient(s) for which the DSN was
+   issued, and the transaction in which the original message was sent.
+
+   The DSN extension MUST be supported by VPIM conforming
+   implementations.
+
+   In addition, beyond the requirements of [DRPT], conforming
+   implementations MUST support NOTIFY parameter on the RCPT command to
+   allow indication of when the originator requests a notification.  The
+   RET parameter SHOULD be supported to return the original message with
+   the notification.  Parameters ORCPT and ENVID MAY also be supported.
+   From: [DRPT]
+
+5.2.2.  SIZE Extension
+
+   The SIZE extension defines a mechanism whereby an SMTP client and
+   server may interact to give the server an opportunity to decline to
+   accept a message (perhaps temporarily) based on the client's estimate
+   of the message size.  From: [SIZE]
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 28]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+   The SIZE extension MUST be supported by VPIM-compliant
+   implementations.
+
+5.2.3.  ENHANCEDSTATUSCODES Extension
+
+   The ENHANCEDSTATUSCODES extension defines a mechanism whereby an SMTP
+   server augments its responses with the enhanced mail system status
+   codes defined in [CODES].  These codes can then be used to provide
+   more informative explanations of error conditions.  From: [STATUS]
+
+   The ENHANCEDSTATUSCODES extension SHOULD be supported by VPIM-
+   compliant implementations.
+
+5.2.4.  PIPELINING Extension
+
+   The PIPELINING extension defines a mechanism whereby an SMTP server
+   can indicate the extent of its ability to accept multiple commands in
+   a single TCP send operation.  Using a single TCP send operation for
+   multiple commands can improve SMTP performance significantly.  From
+   [PIPE]
+
+   The PIPELINING extension SHOULD be supported by VPIM-compliant
+   implementations.
+
+5.2.5.  CHUNKING Extension
+
+   The CHUNKING extension defines a mechanism that enables an SMTP
+   client and server to negotiate the use of the message data transfer
+   command "BDAT" (in alternative to the DATA command) for efficiently
+   sending large MIME messages.  From: [BINARY]
+
+   The CHUNKING extension MAY be supported by VPIM-compliant
+   implementations.
+
+5.2.6.  BINARYMIME Extension
+
+   The BINARYMIME extension defines a mechanism that enables an SMTP
+   client and server to negotiate the transfer of unencoded binary
+   message data utilizing the BDAT command.  From: [BINARY]
+
+   The BINARYMIME extension MAY be supported by VPIM-compliant
+   implementations.  Note that [BINARY] specifies that if BINARYMIME is
+   to be supported, then CHUNKING has to be supported by definition.
+
+
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 29]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+5.3.  ESMTP - SMTP Downgrading
+
+   The SMTP extensions suggested or required for conformance to VPIM
+   fall into two categories.  The first category includes features that
+   increase the efficiency of the transport system such as SIZE,
+   BINARYMIME, and PIPELINING.  In the event of a downgrade to a less-
+   functional transport system, these features can be dropped with no
+   functional change to the sender or recipient.
+
+   The second category of features is transport extensions in support of
+   new functions.  DSN and ENHANCEDSTATUSCODES provide essential
+   improvements in the handling of delivery status notifications to
+   bring email to the level of reliability expected of Voice Mail.  To
+   ensure a consistent level of service across an intranet or the global
+   Internet, it is essential that VPIM-conforming ESMTP support the DSN
+   extension at all hops between a VPIM originating system and the
+   recipient system.  In the situation where a "downgrade" is
+   unavoidable a relay hop may be forced (by the next hop) to forward a
+   VPIM message without the ESMTP request for delivery status
+   notification.  It is RECOMMENDED that the downgrading system should
+   continue to attempt to deliver the message, but MUST send an
+   appropriate delivery status notification to the originator, e.g., the
+   message left an ESMTP host and was sent relayed to a non-DSN-aware
+   destination, and this may be the last DSN received.
+
+6.  Directory Address Resolution
+
+   It is the responsibility of a VPIM system to provide the fully-
+   qualified domain name (FQDN) of the recipient based on the address
+   entered by the user (if the entered address is not already a FQDN).
+   This would typically be an issue on systems that offer only a
+   telephone user interface.  The mapping of the dialed target number to
+   a routable FQDN address, allowing delivery to the destination system,
+   can be accomplished through implementation-specific means.
+
+   To facilitate a local cache, an implementation may wish to populate
+   local directories with the first and last names, as well as the
+   senders' spoken name information extracted from received messages.
+   Addresses or names parsed from the header fields of VPIM messages MAY
+   be used to populate directories.
+
+7.  Management Protocols
+
+   The Internet protocols provide a mechanism for the management of
+   messaging systems, from the management of the physical network
+   through the management of the message queues.  SNMP SHOULD be
+   supported on a VPIM-conforming machine.
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 30]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+7.1.  Network Management
+
+   The digital interface to the VM and the TCP/IP protocols MAY be
+   managed. MIB II MAY be implemented to provide basic statistics and
+   reporting of TCP and IP protocol performance [MIB II].
+
+8.  Conformance Requirements
+
+   VPIM is a messaging application that will be supported in several
+   environments and be supported on differing devices.  These
+   environments include traditional voice processing systems, desktop
+   voice messaging systems, store-and-forward relays, and protocol
+   translation gateways.
+
+   In order to accommodate all environments, this document defines two
+   areas of conformance: transport and content.
+
+   Transport-conformant systems will pass VPIM messages in a store-and-
+   forward manner with assured delivery notifications and without the
+   loss of information.  It is expected that most store-and-forward
+   Internet mail-based messaging systems will be VPIM transport-
+   conformant.
+
+   Content-conformant systems will generate and interpret VPIM messages.
+   Conformance in the generation of VPIM messages indicates that the
+   restrictions of this profile are honored.  Only contents specified in
+   this profile or extensions agreed to by bilateral agreement may be
+   sent. Conformance in the interpretation of VPIM messages indicates
+   that all VPIM content types and constructs can be received;  that all
+   mandatory VPIM content types can be decoded and presented to the
+   recipient in an appropriate manner; and that any unrenderable
+   contents result in the appropriate notification.
+
+   A summary of the conformance requirements is contained in Appendix A.
+
+   VPIM end systems are expected to be both transport- and content-
+   conformant.  Voice messaging systems and protocol conversion gateways
+   are considered end systems.
+
+   Relay systems are expected to be transport-conformant in order to
+   receive and send conforming messages.  However, they must also create
+   VPIM-conforming delivery status notifications in the event of
+   delivery problems.
+
+   Desktop Email clients that support VPIM are expected to be content-
+   conformant.  Desktop email clients use various protocols and API's
+   for exchanging messages with the local message store and message
+   transport system.  While these clients may benefit from VPIM
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 31]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+   transport capabilities, specific client-server requirements are out-
+   of-scope for this document.
+
+9.  Security Considerations
+
+9.1.  General Directive
+
+   This document is a profile of existing Internet mail protocols.  To
+   maintain interoperability with Internet mail, any security to be
+   provided should be part of the Internet security infrastructure,
+   rather than a new mechanism or some other mechanism outside of the
+   Internet infrastructure.
+
+9.2.  Threats and Problems
+
+   Both Internet mail and voice messaging have their own set of threats
+   and countermeasures.  As such, this specification does not create any
+   security issues not already existing in the profiled Internet mail
+   and voice mail protocols themselves.  This section attends only to
+   the set of additional threats that ensue from integrating the two
+   services.
+
+9.2.1.  Spoofed sender
+
+   The actual sender of the voice message might not be the same as that
+   specified in the "Sender:" or "From:" message header fields or the
+   MAIL FROM address from the SMTP envelope.  In a tightly constrained
+   environment, sufficient physical and software controls may be able to
+   ensure prevention of this problem.  In addition, the recognition of
+   the sender's voice may provide confidence of the sender's identity
+   irrespective of that specified in "Sender:" or "From:".  It should be
+   recognized that SMTP implementations do not provide inherent
+   authentication of the senders of messages, nor are sites under
+   obligation to provide such authentication.
+
+9.2.2.  Unsolicited voice mail
+
+   Assigning an Internet mail address to a voice mailbox opens the
+   possibility of receiving unsolicited messages (either text or voice
+   mail).  Traditionally, voice mail systems operated in closed
+   environments and were not susceptible to unknown senders.  Voice mail
+   users have a higher expectation of mailbox privacy and may consider
+   such messages as a security breach.  Many Internet mail systems are
+   choosing to block all messages from unknown sources in an attempt to
+   curb this problem.
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 32]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+9.2.3.  Message disclosure
+
+   Users of voice messaging systems have an expectation of a level of
+   message privacy that is higher than the level provided by Internet
+   mail without security enhancements.  This expectation of privacy by
+   users SHOULD be preserved as much as possible.
+
+9.3.  Security Techniques
+
+   Sufficient physical and software control may be acceptable in
+   constrained environments.  Further, the profile specified in this
+   document does not in any way preclude the use of any Internet object
+   or channel security protocol to encrypt, authenticate, or non-
+   repudiate the messages.
+
+10.  Normative References
+
+   [8BIT]    Klensin, J., Freed, N., Rose, M., Stefferud, E. and D.
+             Crocker, "SMTP Service Extension for 8bit-MIMEtransport",
+             RFC 1652, July 1994.
+
+   [ADPCM]   Vaudreuil, G. and G. Parsons, "Toll Quality Voice - 32
+             kbit/s Adaptive Differential Pulse Code Modulation (ADPCM)
+             MIME Sub-type Registration", RFC 3802, June 2004.
+
+   [AMIS-A]  Audio Messaging Interchange Specifications (AMIS) - Analog
+             Protocol Version 1, Issue 2, February 1992.
+
+   [AMIS-D]  Audio Messaging Interchange Specifications (AMIS) - Digital
+             Protocol Version 1, Issue 3, August 1993.
+
+   [BINARY]  Vaudreuil, G., "SMTP Service Extensions for Transmission of
+             Large and Binary MIME Messages", RFC 3030, December 2000.
+
+   [CODES]   Vaudreuil, G. "Enhanced Mail System Status Codes", RFC
+             1893, January 1996.
+
+   [MIMEDIR] Dawson, F., Howes, T. and M. Smith, "A MIME Content-Type
+             for Directory Information", RFC 2425, September 1998.
+
+   [DISP]    Troost, R. and S. Dorner, "Communicating Presentation
+             Information in Internet Messages:  The Content-Disposition
+             Header", RFC 2183, August 1997.
+
+   [DNS1]    Mockapetris, P., "Domain names - implementation and
+             specification", RFC 1035, November 1987.
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 33]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+   [DNS2]    Mockapetris, P., "Domain names - concepts and facilities",
+             RFC 1034, November 1987.
+
+   [DRPT]    Moore, K., "Simple Mail Transfer Protocol (SMTP) Service
+             Extension for Delivery Status Notifications (DSNs)", RFC
+             3461, January 2003.
+
+   [DSN]     Moore, K. and G. Vaudreuil, "An Extensible Message Format
+             for Delivery Status Notifications", RFC 3464, January 2003.
+
+   [DUR]     Parsons, G. and G. Vaudreuil, "Content Duration MIME Header
+             Definition", RFC 3803, June 2004.
+
+   [E164]    CCITT Recommendation E.164 (1991), Telephone Network and
+             ISDN Operation, Numbering, Routing and  Mobile Service -
+             Numbering Plan for the ISDN Era.
+
+   [ESMTP]   Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
+             April 2001.
+
+   [G726]    CCITT Recommendation G.726 (1990), General Aspects of
+             Digital Transmission Systems, Terminal Equipment - 40, 32,
+             24,16 kbit/s Adaptive Differential Pulse Code Modulation
+             (ADPCM).
+
+   [HOSTREQ] Braden, R., "Requirements for Internet Hosts -- Application
+             and Support", STD 3, RFC 1123, October 1989.
+
+   [LANG]    Alvestrand, H., "Tags for the Identification of Languages",
+             BCP 47, RFC 3066, January 2001.
+
+   [MDN]     Hansen, T., Ed. and G. Vaudreuil, Ed., "Message Disposition
+             Notification", RFC 3798, May 2004.
+
+   [MIB II]  Rose, M., "Management Information Base for Network
+             Management of TCP/IP-based internets:  MIB-II", RFC 1213,
+             March 1991.
+
+   [MIME1]   Freed, N. and N. Borenstein,  "Multipurpose Internet Mail
+             Extensions (MIME) Part One: Format of Internet Message
+             Bodies", RFC 2045, November 1996.
+
+   [MIME2]   Freed, N.  and N. Borenstein,  "Multipurpose Internet Mail
+             Extensions (MIME) Part Two: Media Types ", RFC 2046,
+             November 1996.
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 34]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+   [MIME3]   Moore, K., "Multipurpose Internet Mail Extensions (MIME)
+             Part Three: Message Header Extensions for Non-ASCII Text ",
+             RFC 2047, November 1996.
+
+   [MIME4]   Freed, N., Klensin, J. and J. Postel,  "Multipurpose
+             Internet Mail Extensions (MIME) Part Four: Registration
+             Procedures", RFC 2048, November 1996.
+
+   [MIME5]   Freed, N. and N. Borenstein,  "Multipurpose Internet Mail
+             Extensions (MIME) Part Five: Conformance Criteria and
+             Examples ", RFC 2049, November 1996.
+
+   [PIPE]    Freed, N.and A. Cargille, "SMTP Service Extension for
+             Command Pipelining" STD 60, RFC 2920, September 2000.
+
+   [REPORT]  Vaudreuil, G., "The Multipart/Report Content Type for the
+             Reporting of Mail System Administrative Messages", RFC
+             3462, January 2003.
+
+   [REQ]     Bradner, S., "Key words for use in RFCs to Indicate
+             Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC822]  Crocker, D., "Standard for the Format of ARPA Internet Text
+             Messages", STD 11, RFC 822, August 1982.
+
+   [SIZE]    Klensin, J., Freed, N. and K. Moore, "SMTP Service
+             Extensions for Message Size Declaration" STD 10, RFC 1870,
+             November 1995.
+
+   [STATUS]  Freed, N., "SMTP Service Extension for Returning Enhanced
+             Error Codes", RFC 2034, October 1996.
+
+   [TIFF-F]  Parsons, G. and J. Rafferty, "Tag Image File Format:
+             Application F", RFC 2306, March 1998.
+
+   [TIFFREG] Parsons, G.,  Rafferty, J. and S. Zilles, "Tag Image File
+             Format: image/tiff - MIME sub-type registration", RFC 2302,
+             March 1998.
+
+   [V-MSG]   Vaudreuil, G. and G. Parsons, "VPIM Voice Message MIME
+             Sub-type Registration", RFC 2423, September 1998.
+
+   [VCARD]   Dawson, F. and T. Howes, "vCard MIME Directory Profile" RFC
+             2426, September 1998.
+
+   [VPIM1]   Vaudreuil, G., "Voice Profile for Internet Mail", RFC 1911,
+             February 1996.
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 35]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+   [VPIM2]   Vaudreuil, G. and G. Parsons, "Voice Profile for Internet
+             Mail, Version 2", RFC 2421, September 1998.
+
+   [X.400]   CCITT/ISO, "CCITT Recommendations X.400/ ISO/IEC 10021-1,
+             Message Handling: System and Service Overview", December
+             1988.
+
+11.  Acknowledgments
+
+   The authors would like to offer a special thanks to the Electronic
+   Messaging Association (EMA), especially the members of the Voice
+   Messaging Committee, and the IETF VPIM Work Group, for their support
+   of the VPIM specification and the efforts they have made to ensure
+   its success.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 36]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+12.  Appendix A - VPIM Requirements Summary
+
+   The following table summarizes the profile of VPIM version 2 detailed
+   in this document.  Since in many cases it is not possible to simplify
+   the qualifications for supporting each feature this appendix is
+   informative. The reader is recommended to read the complete
+   explanation of each feature in the referenced section.  The text in
+   the previous sections shall be deemed authoritative if any item in
+   this table is ambiguous.
+
+   The conformance table is separated into various columns:
+
+      Feature - name of protocol feature (note that the indenting
+                indicates a hierarchy of conformance, i.e., the
+                conformance of a lower feature is only relevant if there
+                is conformance to the higher feature)
+
+      Section - reference section in main text of this document
+
+      Area - conformance area to which each feature applies:
+           C - content
+           T - transport
+
+
+   Status - whether the feature is mandatory, optional, or prohibited.
+   The key words used in this table are to be interpreted as described
+   in [REQ], though the following list gives a quick overview of the
+   different degrees of feature conformance:
+
+        Must         - mandatory
+        Should       - required in the absence of a compelling
+                       need to omit.
+        May          - optional
+        Should not   - prohibited in the absence of a compelling
+                       need.
+        Must not     - prohibited
+
+   Footnote - special comment about conformance for a particular feature
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 37]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+                           VPIM version 2 Conformance
+                                                         | | | | |S| |
+                                              |          | | | | |H| |F
+                                              |          | | | | |O|M|o
+                                              |          | | |S| |U|U|o
+                                              |          | | |H| |L|S|t
+                                              |          |A|M|O| |D|T|n
+                                              |          |R|U|U|M| | |o
+                                              |          |E|S|L|A|N|N|t
+                                              |          |A|T|D|Y|O|O|t
+   FEATURE                                    |SECTION   | | | | |T|T|e
+   -------------------------------------------|----------|-|-|-|-|-|-|-
+                                              |          | | | | | | |
+   Message Addressing Formats:                |          | | | | | | |
+     Use DNS host names                       |4.1       |C|x| | | | |
+     Use only numbers in mailbox IDs          |4.1.1     |C| |x| | | |
+     Numbers in mailbox IDs follow E.164      |4.1.1     |C| |x| | | |
+     Use alpha-numeric mailbox IDs            |4.1.1     |C| | |x| | |
+     Support of postmaster@domain             |4.1.2     |C|x| | | | |
+     Support of non-mail-user@domain          |4.1.2     |C| |x| | | |
+     Support of distribution lists            |4.1.3     |C| | |x| | |
+                                              |          | | | | | | |
+   Message Header Fields:                     |          | | | | | | |
+     Sending outbound messages                |          | | | | | | |
+       From                                   |4.2.1     |C|x| | | | |
+         Addition of text name                |4.2.1     |C| |x| | | |
+         Same value as MAIL FROM              |4.2.1     |C| |x| | | |
+       To                                     |4.2.2     |C| |x| | | |1
+       cc                                     |4.2.3     |C| | |x| | |1
+       Date                                   |4.2.4     |C|x| | | | |
+       Sender                                 |4.2.5     |C| | |x| | |
+       Return-Path                            |4.2.6     |C| | | | |x|
+       Message-ID                             |4.2.7     |C|x| | | | |
+       Reply-To                               |4.2.8     |C| | | |x| |
+       Received                               |4.2.9     |C|x| | | | |
+       MIME Version: 1.0 (Voice 2.0)          |4.2.10    |C| |x| | | |
+       Content-Type                           |4.2.11    |C|x| | | | |
+       Content-Transfer-Encoding              |4.2.12    |C|x| | | | |
+       Sensitivity                            |4.2.13    |C| | |x| | |
+       Importance                             |4.2.14    |C| | |x| | |
+       Subject                                |4.2.15    |C| |x| | | |
+       Disposition-notification-to            |4.7       |C| |x| | | |
+       Other Headers                          |4.2       |C| | |x| | |
+                                              |          | | | | | | |
+
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 38]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+                                              |          | | | | |H| |F
+                                              |          | | | | |O|M|o
+                                              |          | | |S| |U|U|o
+                                              |          | | |H| |L|S|t
+                                              |          |A|M|O| |D|T|n
+                                              |          |R|U|U|M| | |o
+                                              |          |E|S|L|A|N|N|t
+                                              |          |A|T|D|Y|O|O|t
+   FEATURE                                    |SECTION   | | | | |T|T|e
+   -------------------------------------------|----------|-|-|-|-|-|-|-
+     Receiving inbound messages               |          | | | | | | |
+       From                                   |4.2.1     |C|x| | | | |
+         Present text personal name           |4.2.1     |C| | |x| | |
+       To                                     |4.2.2     |C|x| | | | |
+       cc                                     |4.2.3     |C| | |x| | |
+       Date                                   |4.2.4     |C|x| | | | |
+         Conversion of Date to local time     |4.2.4     |C| |x| | | |
+       Sender                                 |4.2.5     |C| | |x| | |
+       Return-Path                            |4.2.6     |C| |x| | | |
+       Message-ID                             |4.2.7     |C| | |x| | |
+         MDN requested                        |4.2.7     |C|x| | | | |
+       Reply-To                               |4.2.8     |C| | |x| | |
+       Received                               |4.2.9     |C| | |x| | |
+       MIME Version: 1.0 (Voice 2.0)          |4.2.10    |C| |x| | | |
+       Content Type                           |4.2.11    |C|x| | | | |
+       Content-Transfer-Encoding              |4.2.12    |C|x| | | | |
+       Sensitivity                            |4.2.13    |C|x| | | | |2
+       Importance                             |4.2.14    |C| | |x| | |
+       Subject                                |4.2.15    |C| | |x| | |
+       Disposition-notification-to            |4.7       |C| |x| | | |
+       Other Headers                          |4.2       |C|x| | | | |3
+                                              |          | | | | | | |
+   Message Content Encoding:                  |          | | | | | | |
+     Sending outbound audio/fax contents      |          | | | | | | |
+       7BIT                                   |4.2.12    |C| | | | |x|
+       8BIT                                   |4.2.12    |C| | | | |x|
+       Quoted Printable                       |4.2.12    |C| | | | |x|
+       Base64                                 |4.2.12    |C|x| | | | |4
+       Binary                                 |4.2.12    |C| |x| | | |5
+     Receiving inbound message contents       |          | | | | | | |
+       7BIT                                   |4.2.12    |C|x| | | | |
+       8BIT                                   |4.2.12    |C|x| | | | |
+       Quoted Printable                       |4.2.12    |C|x| | | | |
+       Base64                                 |4.2.12    |C|x| | | | |
+       Binary                                 |4.2.12    |C|x| | | | |5
+                                              |          | | | | | | |
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 39]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+                                                         | | | | |S| |
+                                              |          | | | | |H| |F
+                                              |          | | | | |O|M|o
+                                              |          | | |S| |U|U|o
+                                              |          | | |H| |L|S|t
+                                              |          |A|M|O| |D|T|n
+                                              |          |R|U|U|M| | |o
+                                              |          |E|S|L|A|N|N|t
+                                              |          |A|T|D|Y|O|O|t
+   FEATURE                                    |SECTION   | | | | |T|T|e
+   -------------------------------------------|----------|-|-|-|-|-|-|-
+   Message Content Types:                     |          | | | | | | |
+     Sending outbound messages                |          | | | | | | |
+       Multipart/Voice-Message                |4.4.1     |C|x| | | | |
+         Message/RFC822                       |4.4.2     |C| |x| | | |
+         Audio/32KADPCM                       |4.4.3     |C|x| | | | |
+           Content-Description                |4.3.1     |C| | |x| | |
+           Content-Disposition                |4.3.2     |C|x| | | | |
+           Content-Duration                   |4.3.3     |C| | |x| | |
+           Content-Language                   |4.3.4     |C| | |x| | |
+         Image/TIFF; application=faxbw        |4.4.4     |C|x| | | | |7
+         Text/Directory                       |4.5.2     |C| | | |x| |9
+         Text/plain                           |4.5.4     |C| | | |x| |
+         Audio/* or Image/* (other encodings) |4.5.3     |C| | | |x| |
+         Other contents                       |4.5       |C| | | | |x|
+       Multipart/Mixed                        |4.5.1     |C| | |x| | |
+       Text/plain                             |4.5.4     |C| | |x| | |
+       Multipart/Report                       |4.6, 4.7  |C|x| | | | |
+          human-readable part is voice        |4.6, 4.7  |C| |x| | | |
+          human-readable part is text         |4.6, 4.7  |C| | |x| | |
+          Message/Delivery-Status             |4.6       |C|x| | | | |
+          Message/Disposition-Notification    |4.7       |C| |x| | | |
+       Other contents                         |4.5       |C| | | |x| |6
+
+     Receiving in inbound messages            |          | | | | | | |
+       Multipart/Voice-Message                |4.4.1     |C|x| | | | |
+         Message/RFC822                       |4.4.2     |C|x| | | | |
+         Audio/32KADPCM                       |4.4.3     |C|x| | | | |
+           Content-Description                |4.3.1     |C| | |x| | |
+           Content-Disposition                |4.3.2     |C| |x| | | |
+           Content-Duration                   |4.3.3     |C| | |x| | |
+           Content-Language                   |4.3.4     |C| | |x| | |
+         Image/TIFF; application=faxbw        |4.4.4     |C| |x| | | |8
+         Text/Directory                       |4.5.2     |C|x| | | | |9
+         Text/plain                           |4.5.4     |C| | |x| | |
+         Audio/* or Image/* (other encodings) |4.5.3     |C| | |x| | |
+         Other contents                       |4.5       |C| | |x| | |
+       Multipart/Mixed                        |4.5.1     |C| | |x| | |
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 40]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+                                             |           | | | | |S| |
+                                             |           | | | | |H| |F
+                                             |           | | | | |O|M|o
+                                             |           | | |S| |U|U|o
+                                             |           | | |H| |L|S|t
+                                             |           |A|M|O| |D|T|n
+                                             |           |R|U|U|M| | |o
+                                             |           |E|S|L|A|N|N|t
+                                             |           |A|T|D|Y|O|O|t
+   FEATURE                                   |SECTION    | | | | |T|T|e
+   ------------------------------------------|-----------|-|-|-|-|-|-|-
+                                             |           | | | | | | |
+      Text/plain                             |4.5.4      |C|x| | | | |
+      Multipart/Report                       |4.6, 4.7   |C|x| | | | |
+        human-readable part is voice         |4.6, 4.7   |C|x| | | | |
+        human-readable part is text          |4.6, 4.7   |C|x| | | | |
+        Message/Delivery-Status              |4.6        |C|x| | | | |
+        Message/Disposition-Notification     |4.7        |C| |x| | | |
+      Other contents                         |4.5        |C| | |x| | |6
+                                             |           | | | | | | |
+     Forwarded Messages                      |           | | | | | | |
+       use Message/RFC822 construct          |4.8        |C| |x| | | |
+       simulate headers if none available    |4.8        |C| |x| | | |
+                                             |           | | | | | | |
+     Reply Messages                          |4.9        |C|x| | | | |
+       send to Reply-To, else From address   |4.2.8      |C| | |x| | |
+       send to non-mail-user                 |4.9        |C| | | |x| |
+                                             |           | | | | | | |
+     Notifications                           |           | | | | | | |
+       use Multipart/Report format           |4.6, 4.7   |C|x| | | | |
+       always send error on non-delivery     |4.6        |C|x| | | | |
+       send error messages to return-path    |4.2.6      |C|x| | | | |
+                                             |           | | | | | | |
+   Message Transport Protocol:               |           | | | | | | |
+     Base ESMTP Commands                     |           | | | | | | |
+       HELO                                  |5.1        |T|x| | | | |
+       MAIL FROM                             |5.1        |T|x| | | | |
+       RCPT TO                               |5.1        |T|x| | | | |
+       DATA                                  |5.1        |T|x| | | | |
+       TURN                                  |5.1        |T| | | | |x|
+       QUIT                                  |5.1        |T|x| | | | |
+       RSET                                  |5.1        |T|x| | | | |
+       VRFY                                  |5.1        |T| | |x| | |
+       EHLO                                  |5.1        |T|x| | | | |
+       BDAT                                  |5.1        |T| | |x| | |5
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 41]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+                                                         | | | | |S| |
+                                              |          | | | | |H| |F
+                                              |          | | | | |O|M|o
+                                              |          | | |S| |U|U|o
+                                              |          | | |H| |L|S|t
+                                              |          |A|M|O| |D|T|n
+                                              |          |R|U|U|M| | |o
+                                              |          |E|S|L|A|N|N|t
+                                              |          |A|T|D|Y|O|O|t
+   FEATURE                                    |SECTION   | | | | |T|T|e
+   -------------------------------------------|----------|-|-|-|-|-|-|-
+                                              |          | | | | | | |
+     ESMTP Keywords & Parameters              |          | | | | | | |
+       DSN                                    |5.2.1     |T|x| | | | |
+         NOTIFY                               |5.2.1     |T|x| | | | |
+         RET                                  |5.2.1     |T| |x| | | |
+         ENVID                                |5.2.1     |T| | |x| | |
+         ORCPT                                |5.2.1     |T| | |x| | |
+       SIZE                                   |5.2.2     |T|x| | | | |
+       ENHANCEDSTATUSCODES                    |5.2.3     |T| |x| | | |
+       PIPELINING                             |5.2.4     |T| |x| | | |
+       CHUNKING                               |5.2.5     |T| | |x| | |
+       BINARYMIME                             |5.2.6     |T| | |x| | |
+                                              |          | | | | | | |
+     ESMTP-SMTP Downgrading                   |          | | | | | | |
+       send delivery report upon downgrade    |5.3       |T|x| | | | |
+                                              |          | | | | | | |
+   Directory Address Resolution               |          | | | | | | |
+     provide facility to resolve addresses    |6         |C| |x| | | |
+     use headers to populate local directory  |6         |C| | |x| | |
+                                              |          | | | | | | |
+   Management Protocols:                      |          | | | | | | |
+     Network management                       |7.1       |T| | |x| | |
+   -------------------------------------------|----------|-|-|-|-|-|-|-
+
+   Footnotes:
+
+   1.  SHOULD leave blank if all recipients are not known or resolvable.
+   2.  If a sensitive message is received by a system that does not
+       support  sensitivity, then it MUST be returned to the originator
+       with an  appropriate error notification.  Also, a received
+       sensitive message MUST NOT be forwarded to anyone.
+   3.  If the additional header fields are not understood they MAY
+       be ignored.
+   4.  When binary transport is not available.
+   5.  When binary transport is available.
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 42]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+   6.  Other un-profiled contents MUST only be sent by bilateral
+       agreement.
+   7.  If fax is supported.
+   8.  If the fax content cannot be presented it MAY be dropped.
+   9.  Handling of a vCard in text/directory is no longer defined.
+
+13.  Appendix B - Example Voice Messages
+
+   The following message is a full-featured message addressed to two
+   recipients.  The message includes the sender's spoken name, spoken
+   subject and a short speech segment.  The message is marked as
+   important and private.
+
+To: +19725551212@vm1.mycompany.com
+To: +16135551234@VM1.mycompany.com
+From: "Parsons, Glenn" <12145551234@VM2.mycompany.com>
+Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT)
+MIME-Version: 1.0  (Voice 2.0)
+Content-type: Multipart/Voice-Message; Version=2.0;
+     Boundary="MessageBoundary"
+Content-Transfer-Encoding: 7bit
+Message-ID: 123456789@VM2.mycompany.com
+Sensitivity: Private
+Importance: High
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 43]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+--MessageBoundary
+Content-type: Audio/32KADPCM
+Content-Transfer-Encoding: Base64
+Content-Disposition: inline; voice=Originator-Spoken-Name
+Content-Language: en-US
+Content-ID: part1@VM2-4321
+
+glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
+(This is a sample of the base-64 Spoken Name data)
+fgdhgddlkgpokpeowrit09==
+
+--MessageBoundary
+Content-type: Audio/32KADPCM
+Content-Transfer-Encoding: Base64
+Content-Disposition: inline; voice=Spoken-Subject
+Content-Language: en-US
+Content-ID: part2@VM2-4321
+
+glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
+(This is a sample of the base-64 Spoken Subject data)
+fgdhgddlkgpokpeowrit09==
+
+--MessageBoundary
+Content-type: Audio/32KADPCM
+Content-Transfer-Encoding: Base64
+Content-Description: Brand X Voice Message
+Content-Disposition: inline; voice=Voice-Message; filename=msg1.726
+Content-Duration: 25
+
+iIiIiIjMzN3czdze3s7d7fwfHhcvESJVe/4yEhLz8/FOQjVFRERCESL/zqrq
+(This is a sample of the base64 message data) zb8tFdLTQt1PXj
+u7wjOyRhws+krdns7Rju0t4tLF7cE0K0MxOTOnRW/Pn30c8uHi9==
+
+--MessageBoundary- -                         -                         -
+
+The following message is a forwarded single segment voice.  Both the
+forwarded message and the forwarding message contain the senders spoken
+names.
+
+      To: +12145551212@vm1.mycompany.com
+      From: "Vaudreuil, Greg" <+19725552345@VM2.mycompany.com>
+      Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT)
+      MIME-Version: 1.0  (Voice 2.0)
+      Content-type: Multipart/Voice-Message; Version=2.0;
+        Boundary="MessageBoundary"
+      Content-Transfer-Encoding: 7bit
+      Message-ID: ABCD-123456789@VM2.mycompany.com
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 44]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+      --MessageBoundary
+      Content-type: Audio/32KADPCM
+      Content-Transfer-Encoding: Base64
+      Content-Disposition: inline; voice=Originator-Spoken-Name
+      Content-Language: en-US
+      Content-ID: part3@VM2-4321
+
+      glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
+      (This is a sample of the base-64 Spoken Name data)
+      fgdhgd dlkgpokpeowrit09==
+
+      --MessageBoundary
+      Content-type: Audio/32KADPCM
+      Content-Description: Forwarded Message Annotation
+      Content-Disposition: inline; voice=Voice-Message
+      Content-Transfer-Encoding: Base64
+
+      glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
+      (This is the voiced introductory remarks encoded in base64)
+      jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW
+      dlkgpokpeowrit09==
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 45]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+      --MessageBoundary
+      Content-type: Message/RFC822
+      Content-Transfer-Encoding: 7bit
+
+      To: +19725552345@VM2.mycompany.com
+      From: "Parsons, Glenn, W." <+16135551234@VM1.mycompany.com>
+      Date: Mon, 26 Aug 93 8:23:10 -0500 (EST)
+      Content-type: Multipart/Voice-Message; Version=2.0;
+        Boundary="MessageBoundary2"
+      Content-Transfer-Encoding: 7bit
+      MIME-Version: 1.0  (Voice 2.0)
+
+      --MessageBoundary2
+      Content-type: Audio/32KADPCM
+      Content-Transfer-Encoding: Base64
+      Content-Disposition: inline; voice=Originator-Spoken-Name
+      Content-Language: en-US
+      Content-ID: part6@VM2-4321
+
+      glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
+      (This is a sample of the base-64 Spoken Name data) fgdhgd
+       dlkgpokpeowrit09==
+
+      --MessageBoundary2
+      Content-type: Audio/32KADPCM
+      Content-Disposition: inline; voice=Voice-Message
+      Content-Transfer-Encoding: Base64
+
+      glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
+      (This is the original message audio data) fgwersdfmniwrjj
+      jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW
+      dlkgpokpeowrit09==
+
+      --MessageBoundary2--
+
+      --MessageBoundary--
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 46]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+   The following example is for a DSN sent to the sender of a message by
+   a VPIM gateway at VM1.company.com for a mailbox which does not exist.
+
+      Date: Thu, 7 Jul 1994 17:16:05 -0400
+      From: Mail Delivery Subsystem <MAILER-DAEMON@vm.company.com>
+      Message-ID: <199407072116.RAA14128@vm1.company.com>
+      Subject: Returned voice message
+      To: 2175552345@VM2.mycompany.com
+      MIME-Version: 1.0
+      Content-Type: multipart/report; report-type=delivery-status;
+        boundary="RAA14128.773615765/VM1.COMPANY.COM"
+
+      --RAA14128.773615765/VM1.COMPANY.COM
+      Content-type: Audio/32KADPCM
+      Content-Description: Spoken Delivery Status Notification
+      Content-Disposition: inline; voice= Voice-Message-Notification
+      Content-Transfer-Encoding: Base64
+
+      glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd
+      (This is a voiced description of the error in base64)
+      jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW
+      dlkgpokpeowrit09==
+
+      --RAA14128.773615765/VM1.COMPANY.COM
+      Content-type: Message/Delivery-Status
+
+      Reporting-MTA: dns; vm1.company.com
+
+      Original-Recipient: rfc822; 2145551234@VM1.mycompany.com
+      Final-Recipient: rfc822; 2145551234@VM1.mycompany.com
+      Action: failed
+      Status: 5.1.1 (User does not exist)
+      Diagnostic-Code: smtp; 550 Mailbox not found
+      Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 47]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+      --RAA14128.773615765/VM1.COMPANY.COM
+      content-type: Message/RFC822
+
+      [original VPIM message goes here]
+
+      --RAA14128.773615765/VM1.COMPANY.COM--
+
+   The following example is for an MDN sent to the original sender for a
+   message that has been played.  This delivered VPIM message was
+   received by a corporate gateway and relayed to a unified mailbox.
+
+Date: Thu, 7 Jul 1994 17:16:05 -0400
+From: "Greg Vaudreuil" <22722@vm.company.com>
+Message-ID: <199407072116.RAA14128@exchange.company.com>
+Subject: Voice message played
+To: 2175552345@VM2.mycompany.com
+MIME-Version: 1.0
+Content-Type: multipart/report;
+        Report-type=disposition-notification;
+        Boundary="RAA14128.773615765/EXCHANGE.COMPANY.COM"
+
+--RAA14128.773615765/EXCHANGE.COMPANY.COM
+Content-type: Audio/32KADPCM
+Content-Description: Spoken Disposition Notification
+Content-Disposition: inline; voice= Voice-Message-Notification
+Content-Transfer-Encoding: Base64
+
+glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd
+(Voiced description of the disposition action in base64)
+jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW
+dlkgpokpeowrit09==
+
+--RAA14128.773615765/EXCHANGE.COMPANY.COM
+Content-type: Message/Disposition-Notification
+
+Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0)
+
+Original-Recipient: rfc822;22722@vm.company.com
+Final-Recipient: rfc822;Greg.Vaudreuil@foomail.company.com
+Original-Message-ID: <199509192301.12345@vm2.mycompany.com>
+Disposition: manual-action/MDN-sent-automatically; displayed
+
+--RAA14128.773615765/EXCHANGE.COMPANY.COM
+Content-type: Message/RFC822
+
+[original VPIM message goes here]
+
+--RAA14128.773615765/EXCHANGE.COMPANY.COM--
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 48]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+
+14.  Appendix C - Example Error Voice Processing Error Codes
+
+   The following common voice processing errors and their corresponding
+   status codes are given as examples.  The text after the error codes
+   is intended only for reference to describe the error code.
+   Implementations should provide implementation-specific informative
+   comments after the error code rather than the text below.
+
+      Error condition                 RFC 1893 Error codes
+      -----------------------------   --------------------------------
+
+      Analog delivery failed          4.4.1 Persistent connection error
+      because remote system is busy         - busy
+
+      Analog delivery failed          4.4.1 Persistent protocol error
+      because remote system is              - no answer from host
+      ring-no-answer
+
+      Remote system did not answer    5.5.5 Permanent protocol error
+      AMIS-Analog handshake ("D" in         - wrong version
+      response to "C" at connect
+      time)
+
+      Mailbox does not exist          5.1.1 Permanent mailbox error
+                                            - does not exist
+
+      Mailbox full or over quota      4.2.2 Persistent mailbox error
+                                            - full
+
+      Disk full                       4.3.1 Persistent system error
+                                            - full
+
+      Command out of sequence         5.5.1 Permanent protocol error
+                                            - invalid command
+
+      Frame Error                     5.5.2 Permanent protocol error
+                                                       - syntax error
+
+      Mailbox does not support FAX    5.6.1 Permanent media error
+                                            - not supported
+
+      Mailbox does not support TEXT   5.6.1 Permanent media error
+                                            - not supported
+
+      Sender is not authorized        5.7.1 Permanent security error
+                                            - sender not authorized
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 49]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+      Message marked private, but     5.3.3 Permanent system error
+      system is not private capable         - not feature capable
+
+15.  Appendix D - Example Voice Processing Disposition Types
+
+   The following common voice processing disposition conditions and
+   their corresponding MDN Disposition (which contains the disposition
+   mode, type and modifier, if applicable) are given as examples.
+   Implementers should refer to [MDN] for a full description of the
+   format of message disposition notifications.
+
+Notification event               MDN Disposition mode, type & modifier
+------------------------------   ------------------------------------
+
+Message played by recipient,    manual-action/MDN-sent-automatically;
+receipt automatically returned  displayed
+
+Message deleted from mailbox    manual-action/MDN-sent-automatically;
+by user without listening       deleted
+
+Message cleared when mailbox    manual-action/MDN-sent-automatically;
+deleted by admin                deleted/mailbox-terminated
+
+Message automatically deleted   automatic-action/
+when older than administrator   MDN-sent-automatically; deleted/
+set threshold                   expired
+
+Message processed, however      manual-action/MDN-sent-automatically;
+audio encoding unknown -        processed/error
+unable to play to user          Error: unknown audio encoding
+
+16.  Appendix E - IANA Registrations
+
+   There are no changes to the registration per [DISP] of the voice
+   content disposition parameter defined in the earlier VPIM V2
+   document, RFC 2421.  There are no changes to the registration per
+   [MIME4] of the Multipart/voice-message content type defines in the
+   earlier VPIM v2 document, RFC 2423.
+
+   Both are presented here for information.
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 50]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+16.1.  Voice Content-Disposition Parameter Definition
+
+   To: IANA@IANA.ORG
+
+   Subject: Registration of new Content-Disposition parameter
+
+   Content-Disposition parameter name: voice
+
+   Allowable values for this parameter:
+
+         Voice-Message - the primary voice message,
+         Voice-Message-Notification - a spoken delivery notification
+           or spoken disposition notification,
+         Originator-Spoken-Name - the spoken name of the originator,
+         Recipient-Spoken-Name - the spoken name of the recipient if
+           available to the originator and present if there is ONLY one
+           recipient,
+         Spoken-Subject- the spoken subject of the message, typically
+           spoken by the originator
+
+   Description:
+
+   In order to distinguish between the various types of audio contents
+   in a VPIM voice message a new disposition parameter "voice" is
+   defined with the preceding values to be used as appropriate.  Note
+   that there SHOULD only be one instance of each of these types of
+   audio contents per message level.  Additional instances of a given
+   type (i.e., parameter value) may occur within an attached forwarded
+   voice message.
+
+16.2.  Multipart/Voice-Message MIME Media Type Definition
+
+   To: ietf-types@iana.org
+   Subject: Registration of MIME media type
+            Multipart/voice-message
+
+   MIME media type name: multipart
+
+   MIME subtype name: voice-message
+
+   Required parameters: boundary, version
+
+      The use of boundary is defined in [MIME2]
+
+
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 51]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+      The version parameter that contains the value "2.0" if
+      enclosed content conforms to [VPIM2R2].  The absence of this
+      parameter indicates conformance to the previous version
+      defined in RFC 1911 [VPIM1].
+
+   Optional parameters: none
+
+   Encoding considerations: 7bit, 8bit or Binary
+
+   Security considerations:
+
+      This definition identifies the content as being a voice
+      message.  In some environments (though likely not the
+      majority), the loss of the anonymity of the content may be a
+      security issue.
+
+   Interoperability considerations:
+
+      Systems developed to conform with [VPIM1] may not conform to
+      this registration.  Specifically, the required version will
+      likely be absent, in this case the recipient system should
+      still be able to accept the message and will be able to
+      handle the content.  The VPIM v1 positional identification,
+      however, would likely be lost.
+
+   Published specification:
+      This document
+
+      Applications that use this media type:
+
+      Primarily voice messaging
+
+      Additional information:
+
+      Magic number(s): none
+      File extension(s): .VPM
+      Macintosh File Type Code(s): VPIM
+
+   Person & email address to contact for further information:
+
+      Glenn W. Parsons
+      gparsons@nortelnetworks.com
+
+      Gregory M. Vaudreuil
+      gregv@ieee.org
+
+   Intended usage: COMMON
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 52]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+   Author/Change controller:
+
+      Glenn W. Parsons & Gregory M. Vaudreuil
+
+17.  Appendix F - Change History: RFC 2421 (VPIM V2) to this Document
+
+   The updated profile in this document is based on the implementation
+   and operational deployment experience of several vendors.  The
+   changes are categorized as general, content, transport and
+   conformance.  They are summarized below:
+
+   1. General
+
+      - Various and substantial editorial updates to improve
+        readability.
+
+      - Separated send rules from receive rules to aid clarity.
+
+      - Clarified the behavior upon reception of unrecognized content
+        types expected with the interworking between voice and unified
+        messaging systems.  (E.g., Unsupported non-audio contents should
+        be discarded to deliver the audio message.)
+
+      - Reworked the sensitivity requirements to align them with X.400.
+        Eliminated dependencies upon the MIXER documents.
+
+      - Reorganized the content-type descriptions for clarity
+
+   2. Content
+
+      - Changed handling of received lines by a gateway to SHOULD NOT
+        delete in a gateway.  In gateways to systems such as AMIS, it is
+        not possible to preserve this information.  It is intended that
+        such systems be able to claim conformance.
+
+      - Eliminated the vCard as a supported VPIM V2 content type.
+
+      - Merged in text from RFC 2423 (Multipart/voice-message)
+
+   3. Transport
+
+      - None
+
+   4. Conformance
+
+      - Aligned the table of Appendix A to the requirements in the text.
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 53]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+18.  Authors' Addresses
+
+   Gregory M. Vaudreuil
+   Lucent Technologies
+   7291 Williamson Rd
+   Dallas, TX  75214
+   United States
+
+   EMail: gregv@ieee.org
+
+
+   Glenn W. Parsons
+   Nortel Networks
+   P.O. Box 3511, Station C
+   Ottawa, ON  K1Y 4H7
+   Canada
+
+   Phone: +1-613-763-7582
+   Fax: +1-613-763-2697
+   EMail: GParsons@NortelNetworks.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 54]
+
+RFC 3801                         VPIMv2                        June 2004
+
+
+19.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM 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.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights 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; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat 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 on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   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 implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Vaudreuil & Parsons         Standards Track                    [Page 55]
+