分享
 
 
 

RFC1911 - Voice Profile for Internet Mail

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

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

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. RFC822 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.

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 RFCdocuments: RFC821, Simple Mail Transfer Protocol;

RFC822, Standard for the format of ARPA Internet Messages; RFC1521

and RFC1522, Multipurpose Internet Mail Extensions; RFC1651, RFC

1652, and RFC1653, SMTP Service Extensions (ESMTP); and RFC1034 and

RFC1035, 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.

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 RFC822 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

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].

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 RFC822 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].

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 RFC822 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].

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].

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].

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.

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

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].

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

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].

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", RFC1521, Bellcore, Innosoft, September 1993.

[MSG822] Crocker, D., "Standard for the Format of ARPA Internet Text

Messages", STD 11, RFC822, UDEL, August 1982.

[X400] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO

10021 and RFC822", RFC1327, UCL, May 1992.

[PIPE] Freed, N., and A. Cargille, "SMTP Service Extension for

Command Pipelining", RFC1854, October 1995.

[ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.

Crocker, "SMTP Service Extensions", RFC1869, 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", RFC1870, 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", RFC1426,

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, RFC1035, USC/Information Sciences

Institute, November 1987.

[DNS2] Mockapetris, P., "Domain Names - Concepts and Facilities",

STD 13, RFC1034, USC/Information Sciences Institute,

November 1987.

[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC821,

USC/Information Sciences Institute, August 1982.

[BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of

Large and Binary MIME Messages", RFC1830, Octel Network

Services, October 1995.

[NOTIFY] Moore, K., and G. Vaudreuil, "An Extensible Message

Format for Delivery Status Notifications", RFC1894,

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.

[DSN] Moore, K., "SMTP Service Extensions for Delivery Status

Notifications", RFC1891, 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", RFC1566,

January 1994.

[MIB II] Rose, M., "Management Information Base for Network

Management of TCP/IP-based internets: MIB-II", RFC1158,

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

11. Appendix - MIME/ESMTP Voice Profile Requirements Summary

S

H F

OMo

S UUo

H LSt

MO DTn

UUM o

SLANNt

TDYOOt

FEATURE SECTION TTe

-----------------------------------------------------------

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

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

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

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.

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.

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有