doc: Add RFC documents

1 files changed, 1235 insertions, 0 deletions

diff --git a/doc/rfc/rfc1911.txt b/doc/rfc/rfc1911.txt
new file mode 100644
index 0000000..588af2f
--- /dev/null
+++ b/doc/rfc/rfc1911.txt
@@ -0,0 +1,1235 @@
+
+
+
+
+
+
+Network Working Group                                       G. Vaudreuil
+Request for Comments: 1911                        Octel Network Services
+Category: Experimental                                     February 1996
+
+
+                    Voice Profile for Internet Mail
+
+Status of this Memo
+
+   This memo defines an Experimental Protocol for the Internet
+   community.  This memo does not specify an Internet standard of any
+   kind.  Discussion and suggestions for improvement are requested.
+   Distribution of this memo is unlimited.
+
+1. Abstract
+
+   A class of special-purpose computers has evolved to provide voice
+   messaging services.  These machines generally interface to a
+   telephone switch and provide call answering and voice messaging
+   services.  Traditionally, messages sent to a non-local machine are
+   transported using analog networking protocols based on DTMF signaling
+   and analog voice playback.  As the demand for networking increases,
+   there is a need for a standard high-quality digital protocol to
+   connect these machines.  The following document is a profile of the
+   Internet standard MIME and ESMTP protocols for use as a digital voice
+   networking protocol.
+
+   This profile is based on an earlier effort in the Audio Message
+   Interchange Specification (AMIS) group to define a voice messaging
+   protocol based on X.400 technology.  This protocol is intended to
+   satisfy the user requirements statement from that earlier work with
+   the industry standard ESMTP/MIME mail protocol infrastructures
+   already used within corporate internets.  This profile will be called
+   the voice profile in this document.
+
+2. Scope and Design Goals
+
+   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
+   including voice and facsimile.
+
+   This document specifies a profile of the TCP/IP multimedia messaging
+   protocols for use by special-purpose voice processing platforms.
+   These platforms have historically been special-purpose computers and
+   often do not have facilities normally associated with a traditional
+   Internet Email-capable computer.  This profile is intended to specify
+   the minimum common set of features and functionally for conformant
+
+
+
+Vaudreuil                     Experimental                      [Page 1]
+
+RFC 1911                   MIME Voice Profile              February 1996
+
+
+   systems.
+
+   The voice profile does not place limits on the use of additional
+   media types or protocol options.  However, systems which are
+   conformant to this profile should not send messages with features
+   beyond this profile unless explicit per-destination configuration of
+   these enhanced features is provided.  Such configuration information
+   could be stored in a directory, though the implementation of this is
+   a local matter.
+
+   The following are typical limitations of voice messaging platform
+   which were considered in creating this baseline profile.
+
+      1) Text messages are not normally received and often cannot be
+      displayed or viewed.  They can often be processed only via
+      advanced text-to-speech or text-to-fax features not currently
+      present in these machines.
+
+      2) Voice mail machines usually act as an integrated Message
+      Transfer Agent and a User Agent.  The voice mail machine is
+      responsible for final delivery, and there is no relaying of
+      messages.  RFC 822 header fields may have limited use in the
+      context of the simple messaging features currently deployed.
+
+      3) VM message stores are generally not capable of preserving the
+      full semantics of an Internet message.  As such, use of a voice
+      mail machine for general message forwarding and gatewaying is not
+      supported.  Storage of "Received" lines and "Message-ID" may be
+      limited.
+
+      4) Nothing in this document precludes use of a general purpose
+      email gateway from providing these services.  However, significant
+      performance degradation may result if the email gateway does not
+      support the ESMTP options recommended by this document.
+
+      5) Internet-style mailing lists are not generally supported.
+      Distribution lists are implemented as local alias lists.
+
+      6) There is generally no human operator.  Error reports must be
+      machine-parsable so that helpful responses can be given to users
+      whose only access mechanism is a telephone.
+
+      7) The system user names are often limited to 16 or fewer numeric
+      characters.  Alpha characters are not generally used for mailbox
+      identification as they cannot be easily entered from a telephone
+      terminal.
+
+
+
+
+
+Vaudreuil                     Experimental                      [Page 2]
+
+RFC 1911                   MIME Voice Profile              February 1996
+
+
+   It is a goal of this effort to make as few restrictions and additions
+   to the existing Internet mail protocols as possible while satisfying
+   the user requirements for interoperability with current 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 is outside
+   the scope of this document.
+
+   This profile is intended to be robust enough to be used in an
+   environment such as the global Internet with installed base gateways
+   which do not understand MIME.  It is expected that a messaging system
+   will be managed by a system administrator who can perform TCP/IP
+   network configuration.  When using facsimile or multiple voice
+   encodings, it is expected that the system administrator will 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 this directory
+   listing capabilities is a local matter.
+
+   This specification is a profile of the relevant TCP/IP Internet
+   protocols.  These technologies, as well as the specifications for the
+   Internet mail protocols, are defined in the Request for Comment (RFC)
+   document series.  That series documents the standards as well as the
+   lore of the TCP/IP protocol suite.  This document should be read with
+   the following RFC documents: RFC 821, Simple Mail Transfer Protocol;
+   RFC 822, Standard for the format of ARPA Internet Messages; RFC 1521
+   and RFC 1522, Multipurpose Internet Mail Extensions; RFC 1651, RFC
+   1652, and RFC 1653, SMTP Service Extensions (ESMTP); and RFC 1034 and
+   RFC 1035, Domain Name System. Where additional functionality is
+   needed, it will be defined in this document or in an appendix.
+
+3. Protocol Restrictions
+
+   This protocol does not limit the number of recipients per message.
+   Where possible, 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.  However, ESMTP currently does
+   not provide a mechanism for indicating the number of supported
+   recipients.
+
+
+
+
+
+
+
+Vaudreuil                     Experimental                      [Page 3]
+
+RFC 1911                   MIME Voice Profile              February 1996
+
+
+   This protocol does not limit the maximum message length.
+   Implementors should understand that some machines will be unable to
+   accept excessively long messages.  A mechanism is defined in the RFC
+   1425 ESMTP extensions to declare the maximum message size supported.
+
+   The message size indicated in the ESMTP SIZE command is in bytes, not
+   minutes.  The number of bytes varies by voice encoding format and
+   must include the MIME wrapper overhead.  If the length must be known
+   before sending, an approximate translation into minutes can be
+   performed if the voice encoding is known.
+
+4. Voice Message Interexchange Format
+
+   The voice message interchange format is a profile of the Internet
+   Email Protocol Suite.  It requires components from the message format
+   standard for Internet messages [RFC822], the Multipurpose Internet
+   Message Extensions [MIME], the X.400 gateway specification [X.400],
+   and the delivery report specifications [DRPT][STATUS].
+
+4.1 Message Addressing Formats
+
+   The RFC 822 uses 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.
+
+   The local part of the address shall be an ASCII string uniquely
+   identifying a mailbox on a destination system.  For voice messaging,
+   the local part is a printable string containing the mailbox ID of the
+   originator or recipient.  Administration of this space is expected to
+   conform to national or corporate private telephone numbering plans.
+   While alpha characters and long mailbox identifiers are permitted,
+   most voice mail networks rely on numeric mailbox identifiers to
+   retain compatibility with the limited 10 digit telephone keypad.
+
+   For example, a compliant message may contain the address
+   2145551212@mycompany.com. It should be noted that while the example
+   mailbox address is based on the North American Numbering Plan, any
+   other corporate numbering plan can be used.  The use of the domain
+   naming 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.  The mapping of dialed address to final destination system is
+   generally accomplished through implementation-specific means.
+
+   Special addresses are provided for compatibility with the conventions
+   of the Internet mail system and to facilitate testing.  These
+   addresses do not use numeric local addresses, both to conform to
+
+
+
+Vaudreuil                     Experimental                      [Page 4]
+
+RFC 1911                   MIME Voice Profile              February 1996
+
+
+   current Internet practice and to avoid conflict with existing numeric
+   addressing plans.  Some special addresses are 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 a individual
+   implementation choice.
+
+   Loopback@domain
+
+   A special mailbox name named "loopback" SHOULD be designated for
+   loopback testing.  If supported, all messages sent to this mailbox
+   MUST be returned back to the address listed in the From: address as a
+   new message.  The originating address of the returned address MUST be
+   "postmaster" to prevent mail loops.
+
+   These two addresses are RESERVED so they do not conflict with any
+   internal addressing plan.
+
+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, headers do not indicate delivery options for the
+   transport of messages.
+
+   The following header lines are permitted for use with voice messages.
+
+   From
+
+   The originator's fully-qualified domain address (a mailbox address
+   followed by the fully-qualified domain name).  The user listed in
+   this field should be presented in the voice message envelope as the
+   originator of the message.
+
+   Systems conformant to this profile SHOULD provide the text personal
+   name of the sender in a quoted phrase if available.  To facilitate
+   storage of the text name in a local dial-by-name cache directory, the
+   first and last name MUST be separable.  Text names in voice messages
+   MUST be represented in the form "last, first, mi." [822].
+
+
+
+
+
+Vaudreuil                     Experimental                      [Page 5]
+
+RFC 1911                   MIME Voice Profile              February 1996
+
+
+     Example:
+
+       From: "User, Joe S." <2145551212@mycompany.com>
+
+     To
+
+   The TO header contains the recipient's fully-qualified domain
+   address.  There may be one or more To: fields in any message.
+
+   Systems conformant to this profile SHOULD provide the text personal
+   name of the recipient, if known, in a quoted phrase.  The name MUST
+   be in the form "last, first, mi." [822].
+
+     Example:
+
+       To: "User, Sam S." <2145551213@mycompany.com>
+
+   Cc
+
+   The CC header contains additional recipients' fully-qualified domain
+   addresses. Many voice mail systems are not capable of storing or
+   reporting the full list of recipients to the receiver.
+
+   Systems conformant to this profile SHOULD provide the text personal
+   name of the recipient, if known, in a quoted phrase.  The name MUST
+   be in the form "last, first, mi." [822].
+
+     Example:
+
+       To: "User, Sam S." <2145551213@mycompany.com>
+
+   Systems conformant to this profile may discard the CC list of
+   incoming messages as necessary.  Systems conformant to this profile
+   should provide a complete list of recipients when possible.
+
+   Date
+
+   The Date header contains the date, time, and time zone in which the
+   message was sent by the originator.  Conforming implementations
+   SHOULD be able to convert RFC 822 date and time stamps into local
+   time.
+
+     Example:
+
+       Date: Wed, 28 Jul 93 10:08:49 PST
+
+   The sending system MUST report the time the message was sent [822].
+
+
+
+
+Vaudreuil                     Experimental                      [Page 6]
+
+RFC 1911                   MIME Voice Profile              February 1996
+
+
+   Sender
+
+   The Sender header contains the actual address of the originator if
+   the message is sent by an agent on behalf of the author indicated in
+   the From: field.  Support for this field cannot be assumed when
+   talking to a voice system and SHOULD NOT be generated by a conforming
+   implementation.
+
+   While it may not be possible to save this information in some voice
+   mail machines, discarding this information or the ESMTP MAIL FROM
+   address will make it difficult to send an error message to the proper
+   destination [822].
+
+   Message-id
+
+   The Message-id header contains a unique per-message identifier.  A
+   unique message-id MUST be generated for each message sent from a
+   conforming implementation.
+
+   The message-id is not required to be stored on the receiving system.
+   This identifier MAY be used for tracking, auditing, and returning
+   read-receipt reports [822].
+
+     Example:
+
+       Message-id: <12345678@mycompany.com>
+
+   Received
+
+   The Received header contains trace information added to the beginning
+   of a RFC 822 message by message transport agents (MTA).  This is the
+   only header permitted to be added by an MTA.  Information in this
+   header is useful for debugging when using an ASCII message reader or
+   a header parsing tool.
+
+   A conforming system MUST add Received headers when acting as a
+   gateway and must not remove them.  These headers MAY be ignored or
+   deleted when the message is received at the final destination [822].
+
+   MIME Version
+
+   The MIME-Version header indicates that the message is conformant to
+   the MIME message format specification. Systems conformant to the
+   voice messaging profile MUST include a comment with the words "(Voice
+   1.0)" [MIME].
+
+
+
+
+
+
+Vaudreuil                     Experimental                      [Page 7]
+
+RFC 1911                   MIME Voice Profile              February 1996
+
+
+     Example:
+
+       MIME-Version: 1.0 (Voice 1.0)
+
+   Content-Type
+
+   The content-type header declares the type of content enclosed in the
+   message.  One of the allowable contents is multipart, a mechanism for
+   bundling several message components into a single message.  The
+   allowable contents are specified in the next section of this document
+   [MIME].
+
+   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.  Conformant implementations MUST recognize and decode the
+   standard encodings, "Binary", "7bit, "8bit", "Base-64" and "Quoted-
+   Printable".  The allowable content-transfer-encodings are specified
+   in the next section of this document [MIME].
+
+   Sensitivity
+
+   The sensitivity header, if present, indicates the requested privacy
+   level.  The case-insensitive values "Personal" and "Private" are
+   specified. If no privacy is requested, this field is omitted.
+
+   If a sensitivity header is present in the message, a conformant
+   system MUST prohibit the recipient from forwarding this message to
+   any other user.  If the receiving system does not support privacy and
+   the sensitivity is one of "Personal" or "Private", the message MUST
+   be returned to the sender with an appropriate error code indicating
+   that privacy could not be assured and that the message was not
+   delivered [X400].
+
+   Importance
+
+   Indicates the requested priority to be given by the receiving system.
+   The case-insensitive values "low", "normal" and "high" are specified.
+   If no special importance is requested, this header may be omitted and
+   the value assumed to be "normal".
+
+   Conformant implementations MAY use this header to indicate the
+   importance of a message and may order messages in a recipient's
+   mailbox [X400].
+
+
+
+
+Vaudreuil                     Experimental                      [Page 8]
+
+RFC 1911                   MIME Voice Profile              February 1996
+
+
+   Subject
+
+   The subject field is often provided by email systems but is not
+   widely supported on Voice Mail platforms. This field MAY be generated
+   by a conforming implementation and may be discarded if present by a
+   receiving system [822].
+
+4.3 Message Content Types
+
+   MIME is a general-purpose message body format that is extensible to
+   carry a wide range of body parts.  The basic protocol is described in
+   [MIME].  MIME also provides for encoding binary data so that it can
+   be transported over the 7-bit text-oriented SMTP protocol.  This
+   transport encoding is independent of the audio encoding designed 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 ("Base-64").
+   While Base-64 is dramatically more efficient for audio data, both
+   will work.  Where binary transport is available, no transport
+   encoding is needed, and the data can be labeled as "Binary".
+
+   An implementation in conformance with this profile SHOULD send audio
+   data in binary form when binary message transport is available.  When
+   binary transport is not available, implementations MUST encode the
+   message as Base-64.  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.
+
+   The following content types are identified for use with this profile.
+   Note that each of these contents can be sent individually in a
+   message or wrapped in a multipart message to send multi-segment
+   messages.
+
+   Message/RFC822
+
+   MIME requires support of the Message/RFC822 message encapsulation
+   body part.  This body part is used in the Internet to forward
+   complete messages within a multipart/mixed message.  Processing of
+   this body part entails trivial processing to decapsulate/encapsulate
+   the message.  Systems conformant to this profile SHOULD NOT send this
+   body part but MUST accept if in conformance with basic MIME.
+   Specific handling depends on the platform, and interpretation of this
+   content-type is left as an implementation decision [MIME].
+
+
+
+
+
+Vaudreuil                     Experimental                      [Page 9]
+
+RFC 1911                   MIME Voice Profile              February 1996
+
+
+   Text/Plain
+
+   MIME requires support of the basic Text/Plain content type.  This
+   content type has no applicability within the voice messaging
+   environment.  Conformant implementations MUST NOT send the Text/Plain
+   content-type.  Conformant implementations MUST accept Text/Plain
+   messages, however, specific handling is left as an implementation
+   decision.  One option is to return the message to the sender with a
+   media-unsupported error code [MIME].
+
+   Multipart/Mixed
+
+   MIME provides the facilities for enclosing several body parts in a
+   single message. Multipart/Mixed MAY be used for sending multi-segment
+   voice messages, that is, to preserve across the network the
+   distinction between an annotation and a forwarded message.
+   Conformant systems MUST accept multipart/mixed body parts.  Systems
+   MAY to collapse such a multi-segment message into a single segment if
+   multi-segment messages are not supported on the receiving machine
+   [MIME].
+
+   Message/Notification
+
+   This MIME body part is used for sending machine-parsable delivery
+   status notifications.  Conformant implementations must use the
+   Message/Notification construct when returning messages or sending
+   warnings.  Conformant implementations must recognize and decode the
+   Message/Notification content type and present the reason for failure
+   to the user [NOTIFY].
+
+   Multipart/Report
+
+   The Multipart/Report is used for enclosing a Message/Notification
+   body part and any returned message content.  This body type is a
+   companion to Message/Notification.  Conformant implementations must
+   use the Multipart/Report construct when returning messages or sending
+   warnings.  Conformant implementations must recognize and decode the
+   Multipart/Report content type [REPORT].
+
+   Audio/32KADPCM
+
+   CCITT Recommendation G.721 [G721] describes the algorithm recommended
+   for conversion of a 64 KB/s A-law or u-law PCM channel to and from a
+   32 KB/s channel.  The conversion is applied to the PCM stream using
+   an Adaptive Differential Pulse Code Modulation (ADPCM) transcoding
+   technique. This algorithm will be registered with the IANA for MIME
+   use under the name Audio/32KADPCM.
+
+
+
+
+Vaudreuil                     Experimental                     [Page 10]
+
+RFC 1911                   MIME Voice Profile              February 1996
+
+
+   An implementation conformant to this profile MUST use Audio/32KADPCM
+   by default.
+
+   Proprietary Voice Formats
+
+   Proprietary voice encoding formats or other standard formats may be
+   supported under this profile provided a unique identifier is
+   registered with the IANA prior to use.  These encodings should be
+   registered as sub-types of Audio.
+
+   Use of any other encoding except Audio/32KADPCM reduces
+   interoperability in the absence of explicit manual system
+   configuration.  A conformant implementation MAY use any other
+   encoding with explicit per-destination configuration.
+
+   Multipart/Voice-Message
+
+   This new MIME multipart structure provides a mechanism for packaging
+   the senders spoken name, a spoken subject and, the message.  The
+   multipart provides for the packaging of three segments, the first is
+   the spoken name, the second is a spoken subject, and the third is the
+   message itself.  Forwarded messages can be created by simply nesting
+   multipart content-types (this is also possible with Multipart/Mixed
+   if spoken name or spoken subject is not present).  This type is
+   defined in an appendix to this document.
+
+   Conforming implementations MUST send the Multipart/Voice-Message if a
+   spoken name or spoken subject is available.  Conforming
+   implementations SHOULD recognize the Multipart/Voice-Message and
+   separate the spoken name or spoken subject.
+
+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 networking 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
+   traditionally been transported by encoding the messages into a 7-bit
+   text-like form.  [ESMTP] was recently published and formalized an
+   extension mechanism for SMTP, and subsequent RFCs have defined 8-bit
+
+
+
+Vaudreuil                     Experimental                     [Page 11]
+
+RFC 1911                   MIME Voice Profile              February 1996
+
+
+   text networking, binary networking, and extensions to permit the
+   declaration of message size for the efficient transmission of large
+   messages such as multi-minute voice mail.
+
+   A command streaming extension for high performance message
+   transmission has been defined [PIPE].  This extension reduces the
+   number of round-trip packet exchanges and makes it possible to
+   validate all recipient addresses in one operation.  This extension is
+   optional but recommended.
+
+   The following sections list ESMTP commands, keywords, and parameters
+   that are required and those that are optional.
+
+5.1 ESMTP Commands
+
+   HELO
+
+   Base SMTP greeting and identification of sender.  This command is not
+   to be sent by conforming systems unless the more-capable EHLO command
+   is not accepted.  It is included for compatibility with general SMTP
+   implementations. Conforming implementations MUST implement the HELO
+   command for backward compatibility but SHOULD NOT send it unless EHLO
+   is not supported [SMTP].
+
+   MAIL FROM (REQUIRED)
+
+   Originating mailbox.  This address contains the mailbox to which
+   errors should be sent.  This address may not be the same as the
+   message sender listed in the message header fields if the message was
+   received from a gateway or sent to an Internet-style mailing list.
+   Conforming implementations MUST implement the extended MAIL FROM
+   command [SMTP, ESMTP].
+
+   RCPT TO
+
+   Recipient's mailbox.  This field contains only the addresses to which
+   the message should be delivered for this transaction.  In the event
+   that multiple transport connections to multiple destination machines
+   are required for the same message, this list may not match the list
+   of recipients in the message header. Conforming implementations MUST
+   implement the extended RCPT TO command [SMTP, ESMTP].
+
+   DATA
+
+   Initiates the transfer of message data.  Support for this command is
+   required in the event the binary mode command BDAT is not supported
+   by the remote system.  Conforming implementations MUST implement the
+   SMTP DATA command for backwards compatibility [SMTP].
+
+
+
+Vaudreuil                     Experimental                     [Page 12]
+
+RFC 1911                   MIME Voice Profile              February 1996
+
+
+   TURN
+
+   Requests a change-of-roles, that is, the client that opened the
+   connection offers to assume the role of server for any mail the
+   remote machine may wish to send.  Because SMTP is not an
+   authenticated protocol, the TURN command presents an opportunity to
+   improperly fetch mail queued for another destination.  Conforming
+   implementations SHOULD NOT implement the TURN command [SMTP].
+
+   QUIT
+
+   Requests that the connection be closed.  If accepted, the remote
+   machine will reset and close the connection.  Conforming
+   implementations MUST implement the QUIT command [SMTP].
+
+   RSET
+
+   Resets the connection to its initial state.  Conforming
+   implementations MUST implement the RSET command [SMTP].
+
+   VRFY
+
+   Requests verification that this node can reach the listed recipient.
+   While this functionality is also included in the RCPT TO command,
+   VRFY allows the query without beginning a mail transfer transaction.
+   This command is useful for debugging and tracing problems.
+   Conforming implementations MAY implement the VRFY command [SMTP].
+
+   (Note that the implementation of VRFY may simplify the guessing of a
+   recipient's mailbox or automated sweeps for valid mailbox addresses,
+   resulting in a possible reduction in privacy.  Various implementation
+   techniques may be used to reduce the threat, such as limiting the
+   number of queries per session [SMTP].)
+
+   EHLO
+
+   The enhanced mail greeting that enables a server to announce support
+   for extended messaging options.  The extended messaging modes are
+   discussed in a later section of this document.  Conformant
+   implementations MUST implement the ESMTP command and return the
+   capabilities indicated later in this memo [ESMTP].
+
+   BDAT
+
+   The BDAT command provides a higher efficiency alternative to the
+   earlier DATA command, especially for voice. The BDAT command provides
+   for native binary transport.  Because voice messages are large binary
+   objects otherwise subject to BASE-64 encoding, BDAT will result in a
+
+
+
+Vaudreuil                     Experimental                     [Page 13]
+
+RFC 1911                   MIME Voice Profile              February 1996
+
+
+   substantial improvement in transmission efficiency over DATA.
+   Conformant implementations SHOULD support binary transport using the
+   BDAT command [BINARY].
+
+5.2 ESMTP Capabilities
+
+   The following ESMTP keywords indicate extended features useful for
+   voice messaging.
+
+   PIPELINING
+
+   The "PIPELINING" keyword indicates ability of the receiving SMTP to
+   accept pipelined commands.  Pipelining commands dramatically improves
+   the protocol performance over wide area networks.  Conformant
+   implementations SHOULD support the command pipelining indicated by
+   this parameter [PIPE].
+
+   SIZE
+
+   The "SIZE" keyword provides a mechanism by which the receiving SMTP
+   can indicate the maximum size message supported.  Conformant
+   implementations MUST provide the size capability and SHOULD honor any
+   size limitations when sending [SIZE].
+
+   CHUNKING
+
+   The "CHUNKING" keyword indicates that the receiver will support the
+   high-performance binary transport mode.  Note that CHUNKING can be
+   used with any message format and does not imply support for binary
+   encoded messages. Conformant implementations SHOULD support binary
+   transport indicated by this capability [BINARY].
+
+   BINARYMIME
+
+   The "BINARYMIME" keyword indicates that the receiver SMTP can accept
+   binary encoded MIME messages. Conformant implementations should
+   support binary transport indicated by this capability [BINARY].
+
+   NOTIFY
+
+   The "NOTIFY" keyword indicates that the receiver SMTP will accept
+   explicit delivery status notification requests.  Conformant
+   implementations MUST support the delivery notification extensions in
+   [DSN].
+
+
+
+
+
+
+
+Vaudreuil                     Experimental                     [Page 14]
+
+RFC 1911                   MIME Voice Profile              February 1996
+
+
+5.3 ESMTP Parameters - MAIL FROM
+
+   BINARYMIME
+
+   The current message is a binary encoded MIME messages.  Conformant
+   implementations SHOULD support binary transport indicated by this
+   parameter [BINARY].
+
+5.4 ESMTP Parameters - RCPT TO
+
+   NOTIFY
+
+   The NOTIFY parameter indicates the conditions under which a delivery
+   report SHOULD be sent. Conformant implementations must honor this
+   request [DSN].
+
+   RET
+
+   The RET parameter indicates whether the content of the message should
+   be returned.  Conformant systems SHOULD honor a request for returned
+   content [DSN].
+
+6. 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 compliant message machine.
+
+6.1 Network Management
+
+   The digital interface to the VM and the TCP/IP protocols SHOULD be
+   managed.  MIB II SHOULD be implemented to provide basic statistics
+   and reporting of TCP and IP protocol performance [MIB II].
+
+6.2 Directory and Message Management
+
+   Conformant systems SHOULD provide for the management of message
+   traffic and queue monitoring based on the Message and Directory MIB
+   [MADMAN].
+
+7. References
+
+  [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
+         Extensions", RFC 1521, Bellcore, Innosoft, September 1993.
+
+  [MSG822] Crocker, D., "Standard for the Format of ARPA Internet Text
+           Messages", STD 11, RFC 822, UDEL, August 1982.
+
+
+
+Vaudreuil                     Experimental                     [Page 15]
+
+RFC 1911                   MIME Voice Profile              February 1996
+
+
+  [X400] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO
+         10021 and RFC 822", RFC 1327, UCL, May 1992.
+
+  [PIPE] Freed, N., and A. Cargille, "SMTP Service Extension for
+         Command Pipelining", RFC 1854, October 1995.
+
+  [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
+          Crocker, "SMTP Service Extensions", RFC 1869, United Nations
+          University, Innosoft International, Inc., Dover Beach
+          Consulting, Inc., Network Management Associates, Inc., The
+          Branch Office, November 1995.
+
+  [SIZE] Klensin, J, Freed, N., Moore, K, "SMTP Service Extensions for
+         Message Size Declaration", RFC 1870, United Nations
+         University, Innosoft International, Inc., November 1995.
+
+  [8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E., D. Crocker,
+         "SMTP Service Extension for 8bit-MIMEtransport", RFC 1426,
+         United Nations University, Innosoft International, Inc.,
+         Dover Beach Consulting, Inc., Network Management Associates,
+         Inc., The Branch Office, February 1993.
+
+  [DNS1] Mockapetris, P., "Domain Names - Implementation and
+         Specification", STD 13, RFC 1035, USC/Information Sciences
+         Institute, November 1987.
+
+  [DNS2] Mockapetris, P., "Domain Names - Concepts and Facilities",
+         STD 13, RFC 1034, USC/Information Sciences Institute,
+         November 1987.
+
+  [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
+         USC/Information Sciences Institute, August 1982.
+
+  [BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of
+           Large and Binary MIME Messages", RFC 1830, Octel Network
+           Services, October 1995.
+
+  [NOTIFY] Moore, K., and G. Vaudreuil, "An Extensible Message
+           Format for Delivery Status Notifications", RFC 1894,
+           University of Tennessee, Octel Network Services, January
+           1996.
+
+  [REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the
+           Reporting of Mail System Administrative Messages", RFC
+           1892, Octel Network Services, January 1996.
+
+
+
+
+
+
+Vaudreuil                     Experimental                     [Page 16]
+
+RFC 1911                   MIME Voice Profile              February 1996
+
+
+  [DSN] Moore, K., "SMTP Service Extensions for Delivery Status
+        Notifications", RFC 1891, University of Tennessee, January
+        1996.
+
+  [G721] CCITT Recommendation G.700-G.795 (1988), General Aspects of
+         Digital Transmission Systems, Terminal Equipment.  Blue Book.
+
+  [MADMAN] Freed, N., and S. Kille, "Mail Monitoring MIB", RFC 1566,
+           January 1994.
+
+  [MIB II] Rose, M., "Management Information Base for Network
+           Management of TCP/IP-based internets: MIB-II", RFC 1158,
+           May 1990.
+
+8. Security Consideration
+
+   This document is a profile of existing Internet mail protocols.  As
+   such, it does not create any security issues not already existing in
+   the profiled Internet mail protocols themselves.
+
+9. Acknowledgments
+
+   The author would like to offer special thanks to Glenn Parsons/BNR
+   for his extensive review, helpful suggestions, and extensive editing
+   including the requirements matrix.
+
+10. Author's Address
+
+   Gregory M. Vaudreuil
+   Octel Network Services
+   17080 Dallas Parkway
+   Dallas, TX 75248-1905
+
+   Phone/Fax: +1-214-733-2722
+   EMail: Greg.Vaudreuil@Octel.Com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil                     Experimental                     [Page 17]
+
+RFC 1911                   MIME Voice Profile              February 1996
+
+
+11. Appendix - MIME/ESMTP Voice Profile Requirements Summary
+
+                                               |          | | | |S| |
+                                               |          | | | |H| |F
+                                               |          | | | |O|M|o
+                                               |          | |S| |U|U|o
+                                               |          | |H| |L|S|t
+                                               |          |M|O| |D|T|n
+                                               |          |U|U|M| | |o
+                                               |          |S|L|A|N|N|t
+                                               |          |T|D|Y|O|O|t
+    FEATURE                                    |SECTION   | | | |T|T|e
+    -------------------------------------------|----------|-|-|-|-|-|-
+                                               |          | | | | | |
+    Message Addressing Formats:                |          | | | | | |
+      Use DNS host names                       |4.1       |x| | | | |
+      Use only numbers in mailbox IDs          |4.1       | |x| | | |
+      Use alpha-numeric mailbox IDs            |4.1       | | |x| | |
+      Support of postmaster@domain             |4.1       | |x| | | |
+      Support of loopback@domain               |4.1       | |x| | | |
+                                               |          | | | | | |
+    Message Header Fields:                     |          | | | | | |
+      Encoding outbound messages               |          | | | | | |
+        From                                   |4.2       |x| | | | |
+          Addition of text personal name       |4.2       | |x| | | |
+        To                                     |4.2       |x| | | | |
+          Addition of text personal name       |4.2       | |x| | | |
+        CC                                     |4.2       | | |x| | |
+        Date                                   |4.2       |x| | | | |
+        Sender                                 |4.2       | | | |x| |
+        Message-id                             |4.2       | |x| | | |
+        Received                               |4.2       |x| | | | |
+        MIME Version: 1.0 (Voice 1.0)          |4.2       |x| | | | |
+        Content-Type                           |4.2       |x| | | | |
+        Content-Transfer-Encoding              |4.2       |x| | | | |
+        Sensitivity                            |4.2       | | |x| | |
+        Importance                             |4.2       | | |x| | |
+        Subject                                |4.2       | | |x| | |
+      Detection & Decoding inbound messages    |          | | | | | |
+        From                                   |4.2       |x| | | | |
+          Utilize text personal name           |4.2       | |x| | | |
+        To                                     |4.2       |x| | | | |
+          Utilize text personal name           |4.2       | | |x| | |
+        CC                                     |4.2       | | |x| | |
+          Utilize text personal name           |4.2       | | |x| | |
+        Date                                   |4.2       |x| | | | |
+          Conversion of Date to local time     |4.2       | |x| | | |
+        Sender                                 |4.2       | | | |x| |
+
+
+
+Vaudreuil                     Experimental                     [Page 18]
+
+RFC 1911                   MIME Voice Profile              February 1996
+
+
+        Message ID                             |4.2       |x| | | | |
+        Received                               |4.2       | |x| | | |
+        MIME Version: 1.0 (Voice 1.0)          |4.2       |x| | | | |
+        Content Type                           |4.2       |x| | | | |
+        Content-Transfer-Encoding              |4.2       |x| | | | |
+        Sensitivity                            |4.2       |x| | | | |1
+        Importance                             |4.2       | | |x| | |
+        Subject                                |4.2       | | |x| | |
+                                               |          | | | | | |
+    Binary Content Encoding:                   |          | | | | | |
+      Encoding outbound messages               |          | | | | | |
+        7BITMIME                               |4.3       | | | | |x|
+        8BITMIME                               |4.3       | | | | |x|
+        Quoted Printable                       |4.3       | | | | |x|
+        Base-64                                |4.3       |x| | | | |2
+        Binary                                 |4.3       |x| | | | |3
+      Detection & decoding inbound messages    |          | | | | | |
+        7BITMIME                               |4.3       |x| | | | |
+        8BITMIME                               |4.3       |x| | | | |
+        Quoted Printable                       |4.3       |x| | | | |
+        Base-64                                |4.3       |x| | | | |
+        Binary                                 |4.3       |x| | | | |
+                                               |          | | | | | |
+    Message Content Types:                     |          | | | | | |
+      Inclusion in outbound messages           |          | | | | | |
+        Message/RFC822                         |4.3       | | | |x| |
+        Text/plain                             |4.3       | | | | |x|
+        Multipart/Mixed                        |4.3       | | |x| | |
+        Message/Notification                   |4.3       |x| | | | |
+        Multipart/Report                       |4.3       |x| | | | |
+        Audio/32KADPCM                         |4.3       |x| | | | |
+        Audio/* (proprietary encodings)        |4.3       | | |x| | |
+        Multipart/Voice-Message                |4.3       |X| | | | |
+      Detection & decoding in inbound messages |          | | | | | |
+        Message/RFC822                         |4.3       |x| | | | |
+        Text/plain                             |4.3       |x| | | | |
+        Multipart/Mixed                        |4.3       |x| | | | |
+        Message/Notification                   |4.3       |x| | | | |
+        Multipart/Report                       |4.3       |x| | | | |
+        Audio/32KADPCM                         |4.3       |x| | | | |
+        Audio/* (proprietary encodings)        |4.3       | | |x| | |
+        Multipart/Voice-Message                |4.3       |X| | | | |
+                                               |          | | | | | |
+    Message Transport Protocol:                |          | | | | | |
+      ESMTP Commands                           |          | | | | | |
+        HELO                                   |5.1       |x| | | | |
+        MAIL FROM                              |5.1       |x| | | | |
+        RCPT TO                                |5.1       |x| | | | |
+
+
+
+Vaudreuil                     Experimental                     [Page 19]
+
+RFC 1911                   MIME Voice Profile              February 1996
+
+
+        DATA                                   |5.1       |x| | | | |
+        TURN                                   |5.1       | | | | |x|
+        QUIT                                   |5.1       |x| | | | |
+        RSET                                   |5.1       |x| | | | |
+        VRFY                                   |5.1       | | |x| | |
+        EHLO                                   |5.1       |x| | | | |
+        BDAT                                   |5.1       | |x| | | |3
+      ESMTP Keywords                           |          | | | | | |
+        PIPELINING                             |5.2       | |x| | | |
+        SIZE                                   |5.2       |x| | | | |
+        CHUNKING                               |5.2       | |x| | | |
+        BINARYMIME                             |5.2       | |x| | | |
+        NOTIFY                                 |5.2       |x| | | | |
+                                               |          | | | | | |
+    Management Protocols:                      |          | | | | | |
+      Network management                       |6.1       | |x| | | |
+      Monitoring queues                        |6.2       | |x| | | |
+    -------------------------------------------|----------|-|-|-|-|-|-
+
+     1.  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.
+     2.  When binary transport is not available
+     3.  When binary transport is available
+
+
+12. Appendix - Example Voice Message
+
+   The following message is a full-featured, all-options-enabled message
+   addressed to two recipients. The message includes the sender's spoken
+   name and a short speech segment.  The message is marked as important
+   and private.
+
+     To: 2145551212@vm1.mycompany.com
+     To: "Parsons, Glenn, W." 2145551234@VM1.mycompany.com
+     From: "Vaudreuil, Greg" 2175552345@VM2.mycompany.com
+     Date: Mon, 26 Aug 93 10:20:20 CST
+     MIME-Version: 1.0  (Voice 1.0)
+     Content-type: Multipart/Voice-Message; Boundary = "MessageBoundary"
+     Content-Transfer-Encoding: 7bit
+     Message-ID: VM2.mycompany.com-123456789
+     Sensitivity: Private
+     Importance: High
+
+     --MessageBoundary
+     Content-type: Audio/32KADPCM
+     Content-Transfer-Encoding: Base-64
+
+
+
+
+Vaudreuil                     Experimental                     [Page 20]
+
+RFC 1911                   MIME Voice Profile              February 1996
+
+
+     glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
+     (This is a sample of the base-64 Spoken Name data) fgdhgd
+     jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW
+     dlkgpokpeowrit09==
+
+     --MessageBoundary
+     Content-type: Audio/32KADPCM
+     Content-Transfer-Encoding: Base-64
+
+     glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
+     (This is a sample of the base-64 Spoken Subject data) fgdhgd
+     jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW
+     dlkgpokpeowrit09==
+
+     --MessageBoundary
+     Content-type: Audio/32KADPCM
+     Content-Transfer-Encoding: Base-64
+
+     glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
+     (This is a sample of the base-64 message data) fgdhgdfwgd
+     jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW
+     dlkgpokpeowrit09==
+
+     --MessageBoundary--
+
+
+13. Appendix - Audio/32KADPCM Content Type
+
+     Mime type name: Audio
+     Mime Sub-Type name: 32KADPCM
+     Required Parameters: None
+     Optional Parameters: None
+     Encoding Considerations: Any encoding necessary for transport may be
+     used.
+
+   CCITT Recommendation G.721 [G721] describes the algorithm recommended
+   for conversion of a 64 KB/s A-law or u-law PCM channel to and from a
+   32 KB/s channel.  The conversion is applied to the PCM stream using
+   an Adaptive Differential Pulse Code Modulation (ADPCM) transcoding
+   technique.
+
+   No header information shall be included before the audio data. When
+   this subtype is present, a sample rate of 8000 Hz and a single
+   channel is assumed.
+
+
+
+
+
+
+
+Vaudreuil                     Experimental                     [Page 21]
+
+RFC 1911                   MIME Voice Profile              February 1996
+
+
+14.  Appendix - Multipart/Voice-Message
+
+     Mime type name: Multipart
+     Mime Sub-Type name: Voice-Message
+     Required Parameters: Boundary
+     Optional Parameters: None
+     Encoding Considerations: Binary of 7 bit are sufficient.  Base-64
+     and Quoted-Printable are prohibited on multipart content-types.
+
+   The syntax of a Multipart/Voice-Message is identical to the
+   Multipart/Mixed content type.  The Voice-Message content-type
+   contains three body parts.  The first is an audio segment containing
+   the spoken name of the originator, the second is an audio segment
+   containing a spoken subject, and the third is the voice message
+   itself.  Forwarded voice messages can be created by simply nesting
+   multipart content types.
+
+   The spoken name segment shall contain the name of the message sender
+   in the voice of the sender.  The length of the spoken name segment
+   must not exceed 12 seconds.  If no spoken name is available, the
+   segment must still be present but may be empty.
+
+   The spoken subject segment shall contain the subject of the message
+   sender in the voice of the sender.  The length of the spoken subject
+   segment must not exceed 20 seconds.  If no spoken subject segment is
+   available, the segment must still be present but may be empty.
+
+   The voice message body part may contain any arbitrary content
+   including a multipart/mixed collections of body parts, though will
+   typically be an audio segment.
+
+   The default handling of the Multipart/Voice-Message shall be to voice
+   the spoken-name segment and then the spoken-subject prior to
+   displaying or voicing the remainder of the message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Vaudreuil                     Experimental                     [Page 22]
+