diff options
Diffstat (limited to 'doc/rfc/rfc1911.txt')
| -rw-r--r-- | doc/rfc/rfc1911.txt | 1235 |
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] + |