view Side-By-Side changes
Network Working Group Greg Vaudreuil
Internet Draft Octel Network Services
Expires: May September 1, 1995 January 26, March 21, 1995
MIME/ESMTP Profile for
Voice Messaging
<draft-umig-mime-voice-01.txt>
<draft-umig-mime-voice-02.txt>
Changes From the previous version
1) A large number of textual clarifications were made, including
discussion Discussion about interoperation between this profile and AMIS-
Digital was deleted. Such a gateway is outside the scope of X.440. this
document.
2) The reference section Text/Signature body part was updated. dropped in favor of a simpler
mechanism for Spoken-Name support. Spoken name will be contained as
an additional audio/* segment in a multipart.
Work toward Text/Signature will continue in conjunction with Internet
Directory services but is not expected to be completed in the near
term.
3) Examples were fixed The document was edited to reflect a clearer notion of what the current text.
role of this profile is.
4) IANA Registration of Audio/32KADPCM and Multipart/VM is now
included as an appendix.
5) The general level of requirement was reduced. Support of the
binary SMTP extensions is now listed as recommended.
6) Discussion of forwarded messages was added.
7) The status of the SMTP TURN command was changed to discouraged. It
is not clear how the TURN command should function within the ESMTP
framework.
Status of this Memo
This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas,
and its Working Groups. Note that other groups may also distribute
working documents as Internet Drafts.
Internet Drafts are valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet Drafts as reference material or to cite
them other than as a "work in progress".
1.Abstract
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
Internet Draft MIME Voice Profile March 21, 1995
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.
Internet Draft MIME Voice Profile January 26, 1995
2.Scope
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.
It is not
This document specifies a goal to make interoperability possible between the
earlier X.400-based AMIS-Digital and this profile using a
standard X.400-to-MIME gateway. While the message encodings and
messages semantics are similar, of the addressing TCP/IP multimedia messaging
protocols for use by special-purpose voice processing platforms.
These platforms have historically been special-purpose computers and routing are
not. The X.400-based AMIS-Digital addressing format
often do not have facilities normally associated with a traditional
Internet Email-capable computer. This profile is
sufficiently customized so that it cannot be mapped intended to specify
the RFC
822 mail format in the standard manner. minimum common set of features and functionaly for conformant
systems.
The voice profile is
necessarily incompatible because it is intended to use the
standard TCP/IP mail addressing formats.
Because the 1988 X.400 based X.440 does not restrict place limits on the range use of
addressing possible in X.400, translation additional media
types or protocol options. However, systems which are conformant to
this protocol profile should
be possible using the standard X.400 to MIME gateway.
It is a goal of not send messages with features beyond this effort to make as few changes to the
existing Internet mail protocols as possible while satisfying the
user requirements for Voice Networking. This goal is motivated
by the desire to increase the accessibility to digital messaging
by enabling the use
profile unless explicit per-destination configuration of proven existing networking software for
rapid development.
This specification is intended for use on a TCP/IP network.
While it is possible to use these protocols for simple point-to-
point networking, the specification
enhanced features is robust enough to provided. Such configuration information could
be used stored in an environment such as a directory, though the global Internet with installed base
gateways which do not understand MIME. It implementation of this is expected that a local
matter.
The following are typical restrictions of voice messaging system will platform
which were considered in creating this baseline profile.
1)Text messages are not normally received and often cannot be managed by a system administrator who
displayed or viewed. They can perform TCP/IP network configuration. When using facsimile often be processed only via advanced
text-to-speech or multiple voice encodings, it is expected that the system
administrator will maintain text-to-fax features not currently present in these
machines.
2)Voice mail (VM) machines usually act as an integrated Message
Transfer Agent and a list User Agent. The VM is responsible for final
delivery, and there is no relaying of messages. RFC 822 header fields
may have limited use in the capabilities context of the
networked mail machines to reduce simple messaging features
currently deployed.
3)VM message stores are generally not capable of preserving the sending full
semantics of undeliverable
messages due to lack an Internet message. As such, use of feature support.
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, the Simple Mail Transport Protocol; RFC 822, the Standard VM for the format of ARPA Internet Messages; RFC 1521 and RFC 1522,
the Multipurpose Internet Mail Extensions; RFC 1425 and RFC 1427,
Extensions to the SMTP protocol (ESMTP); and RFC 882 and RFC 883,
the Domain Name System. Where additional functionality is
needed, it will be defined in this document or in an appendix. general
Vaudreuil Expires 5/1/95 ] 9/1/95 [Page 2]
Internet Draft MIME Voice Profile January 26, March 21, 1995
3.Protocol Restrictions
This protocol does not limit the number of recipients per
message. Where possible, implementations should
message forwarding and gatewaying is not restrict the
number supported. Storage of recipients in a single message.
Recognising that no implementation supports unlimited
recipients,
"Received" lines and that the number of supported recipients "Message-ID" may be quite low, ESMTP should be extended to provide limited.
Nothing in this document precludes use of a
mechanism for indicating general purpose email
gateway from providing these services. However, severe performance
degradation may result if the number of supported recipients.
This protocol email gateway does not limit support the maximum message length.
Implementors should understand ESMTP
options recommended by this document.
Internet-style mailin
Distribution lists are implemented as local alias lists.
There is generally no human operator. Error reports must be
machine-parsable so that some machines will helpful responses can be unable given 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 indicatd in the ESMTP SIZE command users whose
only access mechanism is in
bytes, not minutes. a telephone.
The number of bytes varies by voice
encoding format and must include the MIME wrapper overhead.
Translation into minutes, can be performed by simple
multiplication if the voice encoding is know from the system
configuration file.
Framework for the voice profile
This document specifies a profile of the TCP/IP multimedia
messaging protocols for use by special-purpose voice processing
platforms. These platforms user names are not general-purpose computers and often do not have facilities normally associated with an Internet
Email-capable computer.
The following are typical restrictions imposed by a voice
messaging platform:
1) Text messages limited to 16 or fewer numeric
characters. Alpha characters are not normally received and often generally used for mailbox
identification as they cannot be
displayed or viewed in easily entered from a telephone
terminal.
It is a goal of this effort to make as few restrictions and additions
to the normal fashion. They can be
processed only via advanced text-to-speech or text-to-fax
features not currently present in these machines.
Voice existing Internet mail (VM) machines act protocols as an integr
Transfer Agent and a User Agent. The VM is responsible possible while satisfying
the user requirements for
final delivery, and there interworking with current voice messaging
systems. This goal is no forwarding of messages. RFC
822 header fields have limited use in motivated by the context of desire to increase the
simple
accessibility to digital messaging features currently deployed.
3) VM message stores are generally not capable of preserving by enabling the
full semantics of an Internet message. As such, use of a VM proven
existing networking software for general message forwarding and gatewaying rapid development.
This specification is not
supported. Storage of "Received" lines and "Message-ID" may
be limited.
Nothing in this document precludes intended for use of on a general purpose
email gateway from providing these services. However, severe
Vaudreuil Expires 5/1/95 3]
Internet Draft MIME Voice Profile January 26, 1995
performance degradation may result if TCP/IP network, however,
it is possible to use the email gateway does
not support SMTP protocol suite over other transport
protocols. The necessary protocol parameters for such use is outside
the advanced ESMTP options required by scope of this document.
Internet-style mailing lists are not generally supported.
Distribution lists are implemented as local alias lists.
5) There
This profile is generally no human operator. Error reports must be
machine-parsable so that helpful responses can intended to be given robust enough to
users whose only access mechanism be used in an
environment such as the global Internet with installed base gateways
which do not understand MIME. It is expected that a telephone.
The messaging system user names are limited to 16 or fewer numeric
characters.
Vaudreuil Expires 5/1/95 ]
Internet Draft MIME Voice Profile January 26, 1995
5.Message Format Profile
The voice profile was written to be based on and
will be consistent
with the managed by a system administrator who can perform TCP/IP Email Protocol Suite with newly standardized
options for enhanced functionality and performance. This section
network configuration. When using facsimile or multiple voice
encodings, it is an overview of expected that the necessary protocols and system administrator will maintain
a profile list of the
applicable protocols as applied to capabilities of the voice messaging
environment.
5.1. Message Addressing Formats
RFC 822 and SMTP addressing uses networked mail machines to reduce
the domain name system. This
naming system has two components: the local part, used for
username or mailbox identification; sending of undeliverable messages due to lack of feature support.
Configuration, implementation and the host part, used for
machine or node identification. These two components are
separated by the commercial "@" symbol.
The local part management of the address this directory listing
capabilities is an ASCII string uniquely
identifying a mailbox on a destination system. The local part matter.
This specification is a printable string containing the mailbox number profile of the
originator or a recipient. Administration of this number space
is expected to be conform to national or corporate private
telephone numbering plans.
The domain part of relevant TCP/IP Internet
protocols. These technologies, as well as the address is a hierarchical global name specifications for
all machines. For participation in the international
Internet
network or for integration within a corporate internet, each VM
machine is required to have a unique domain name. In mail protocols, are defined in the domain
name system, a name is registered with Request for Comment (RFC)
document series. That series documents the Internet Assigned
Number Authority (IANA). The IANA may delegate standards as well as the management of
a branch
lore of the naming space to a company or service provider.
For example, a compliant message may contain the address
2145551212@mycompany.com. It TCP/IP protocol suite. This document should be noted that while read with
the
example mailbox address is based on following RFC documents: RFC 821, Simple Mail Transfer Protocol;
RFC 822, Standard for the North American Numbering
Plan, any other corporate numbering plan can be used. The use format of
the domain naming system should be transparent to the user. It
is the responsibility of the VM to translate the dialed address
to the fully-qualified domain name (FQDN). The mapping of dialed
address to VM destination is generally accomplished through
implementation-specific means, usually a local table.
Mapping of the FQDN to a specific network destination is
generally performed by the Domain Name System. For networks with
a small number of machines, a locally-maintained host table
database can be used as a simpler alternative.
Special addresses are provided for compatibility with the
conventions of the ARPA Internet mail system Messages; RFC 1521
and to facilitate
testing. These addresses do not use numeric local addresses,
both to conform to current RFC 1522, Multipurpose Internet practice Mail Extensions; RFC 1651, RFC
1652, and to avoid
conflict with existing numeric addressing plans. Some special
addresses are as follows: 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.
Vaudreuil Expires 5/1/95 ] 9/1/95 [Page 3]
Internet Draft MIME Voice Profile January 26, March 21, 1995
Postmaster@domain
By convention, a special mailbox named "postmaster"
should exist on all systems. This address is used
for diagnostics and should be checked regularly by
the system manager.
Protocol Restrictions
This mailbox is particularly
likely to receive text messages, which is protocol does not normal
on a voice processing platform; limit the specific
handling number of these messages is a individual
implementation choice.
Loopback@domain
A special mailbox name named "loopback" recipients per message.
Where possible, implementations should be
designated for loopback testing. All messages sent
to this mailbox must be returned back to not restrict the sender
as number of
recipients in a new single message. The originating address should be
"postmaster".
Because VMs do not use alpha-numeric addresses, this
address will not conflict with any internal
numbering plan. Internal to VM, a specific numeric
address for DTMF entry can be mapped to "loopback".
Note that without network level authentication, the
loopback address can be abused by routing messages
through a third-party VM to spoof another device or
to avoid toll charges. It is recommended recognized that no
implementation supports unlimited recipients, and that the
loopback feature number of
supported recipients may be disabled except when testing the
networking between machines.
5.2. Message Header Fields
Internet messages contain quite low, However, ESMTP currently does
not provide a header information block. This
header block contains information required to identify the
sender, mechanism for indicating the list number of recipients, the message send time, and other
information intended for user presentation. Except for
specialized gateway and mailing list cases, headers do supported
recipients.
This protocol does not
indicate delivery options for limit the transport of maximum message length. Implementors
should understand that some machines will be unable to accept
excessively long messages. A mechanism is defined in the RFC 822 defines a set of standard 1425
ESMTP extensions to declare the maximum message header fields. This
set is extended size supported.
The message size indicated in several RFCs.
Note that the specific order of header lines ESMTP SIZE command is in bytes, not specified.
The order cannot be expected to be preserved when sent through
intermediate gateways.
minutes. The following header fields number of bytes varies by voice encoding format and must
include the MIME wrapper overhead. If the length must be
supported.
Network Working Group Greg Vaudreuil
Internet Draft Octel Network Services
Expires: May 1, 1995 January 26, known before
sending, an approximate translation into minutes can be performed if
the voice encoding is known.
Vaudreuil Expires 9/1/95 [Page 4]
Internet Draft MIME Voice Profile March 21, 1995
MIME/ESMTP
Message Format Profile for
Voice Messaging
<draft-umig-mime-voice-01.txt>
Changes From the previous version
1) A large number of textual clarifications were made, including discussion
of X.440.
2)
The reference section was updated.
3) Examples were fixed to reflect voice profile is based on and is consistent with the current text.
Status of this Memo TCP/IP Email
Protocol Suite with newly standardized options for enhanced
functionality and performance. This document section is an Internet Draft. Internet Drafts are working documents overview and profile
of the Internet Engineering Task Force (IETF), its Areas, and its Working
Groups. Note that other groups may also distribute working documents necessary protocols as
Internet Drafts.
Internet Drafts are valid applied to the voice messaging
environment.
Message Addressing Formats
RFC 822 and SMTP addressing uses the domain name system. This naming
system has two components: the local part, used for a maximum of six months username or
mailbox identification; and may be updated,
replaced, the host part, used for machine or obsoleted node
identification. These two components are separated by other documents at any time. It the commercial
"@" symbol.
The local part of the address is inappropriate
to use Internet Drafts as reference material or to cite them other than as an ASCII string uniquely identifying
a "work in progress".
1.Abstract
A class mailbox on a destination system. The local part is a printable
string containing the mailbox ID of special-purpose computers has evolved the originator or recipient.
Administration of this space is expected to provide voice messaging
services. These machines generally interface conform to a national or
corporate private telephone switch and
provide call answering numbering plans. While alpha characters
and voice messaging services. Traditionally,
messages sent to a non-local machine long mailbox identifiers are transported using analog
networking protocols based on DTMF signaling and analog permitted, most voice playback. As mail networks
rely on numeric mailbox identifers to retain compatability with the demand for networking increases, there
limited 10 digit telephone keypad.
The domain part of the address is a need hierarchical global name for a standard high-
quality digital protocol to connect these all
machines. The following document
is a profile of For participation in the international Internet standard MIME and ESMTP protocols network or
for use as integration within a
digital voice networking protocol.
This profile corporate internet, each VM machine is based on an earlier effort in the Audio Message Interchange
Specification (AMIS) group
required to define have 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 unique domain name. In the voice profile in this document.
2.Scope and Design Goals
MIME domain name system, a
name is registered with the Internet multipurpose, multimedia messaging standard. This
document explicitly recognizes its capabilities and provides a mechanism
Internet Draft MIME Voice Profile January 26, 1995
for Assigned Number Authority (IANA).
The IANA may delegate the exchange management of various messaging technologies including voice and
facsimile.
It is not a goal to make interoperability possible between branch of the earlier
X.400-based AMIS-Digital and this profile using naming space
to a standard X.400-to-MIME
gateway. While the company or service provider.
For example, a compliant message encodings and messages semantics are similar, may contain the addressing and routing are not. The X.400-based AMIS-Digital
addressing format is sufficiently customized so that it cannot address
2145551212@mycompany.com. It should be mapped to
the RFC 822 mail format in noted that while the standard manner. The voice profile is
necessarily incompatible because it example
mailbox address is intended to use the standard TCP/IP
mail addressing formats.
Because the 1988 X.400 based X.440 does not restrict on the range North American Numbering Plan, any
other corporate numbering plan can be used. The use of
addressing possible in X.400, translation to this protocol the domain
naming system should be
possible using the standard X.400 transparent to MIME gateway. the user. It is a goal the
responsibility of this effort to make as few changes the VM to lookup the existing
Internet mail protocols as possible while satisfying fully-qualified domain name
(FQDN) based on the user requirements
for Voice Networking. This goal is motivated address entered by the desire user. The mapping of
dialed address to increase VM destination is generally accomplished through
implementation-specific means.
Mapping of the
accessibility FQDN to digital messaging a specific network destination is generally
performed by enabling the use Domain Name System. For networks with a small number
of proven existing
networking software for rapid development.
This specification is intended for use on machines, a TCP/IP network. While it is
possible to use these protocols for simple point-to-point networking, the
specification is robust enough to locally-maintained host table database can be used in an environment such as a
simpler alternative.
Special addresses are provided for compatibility with the conventions
of the
global Internet with installed base gateways which mail system and to facilitate testing. These
addresses 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 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:
Vaudreuil Expires 9/1/95 [Page 5]
Internet Draft MIME Voice Profile March 21, 1995
Postmaster@domain
By convention, a special mailbox named "postmaster" should exist on
all systems. This address is expected that used for diagnostics and should be
checked regularly by the system
administrator will maintain a list of the capabilities of the networked
mail machines manager. This mailbox is particularly
likely to reduce receive text messages, which is not normal on a voice
processing platform; the sending specific handling of undeliverable these messages due to lack
of feature support.
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
individual implementation choice.
Loopback@domain
A special mailbox name named "loopback" should be designated for Comment (RFC) document series.
That series documents
loopback testing. All messages sent to this mailbox must be returned
back to the standards as well sender as the lore of the TCP/IP
protocol suite. This document a new message. The originating address should
be read "postmaster".
Because VMs may use alpha-numeric addresses, these two addresses are
RESERVED so they do not conflict with the following RFC
documents: RFC 821, the Simple Mail Transport Protocol; RFC 822, the
Standard any internal addressing plan.
Internal to VM, a specific numeric address for the format of ARPA Internet Messages; RFC 1521 and RFC 1522,
the Multipurpose Internet Mail Extensions; RFC 1425 and RFC 1427,
Extensions DTMF entry can be
mapped to the SMTP protocol (ESMTP); and RFC 882 "loopback".
Note that without network level authentication, the loopback address
can be used to routing messages through a third-party VM to spoof
another device or to avoid toll charges. It is recommended that the
loopback feature be disabled except when testing the networking
between machines.
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.
RFC 883, 822 defines a set of standard message header fields. This set is
extended in several RFCs.
Note that the
Domain Name System. Where additional functionality specific order of header lines is needed, it will not specified. The
order cannot be
defined expected to be preserved when sent through
intermediate gateways. The following header fields must be supported.
From
The originator's fully-qualified domain address (a mailbox number
followed by the fully-qualified domain name). The user listed in this document or
field should be presented in an appendix.
3.Protocol Restrictions
This protocol does not limit the number of recipients per message. Where
possible, implementations should not restrict voice message envelope as the number
originator of recipients in a
single the message.
Recognising that no implementation supports unlimited recipients, and
It is recommended that all messages contain the number text personal name of supported recipients may
the sender in a quoted phrase if available. The name must be quite low, ESMTP should in the
form "last, first, mi." From [822]
Vaudreuil es 5/1/95 Expires 9/1/95 [Page 6]
Internet Draft MIME Voice Profile January 26, March 21, 1995
be extended to provide a mechanism for indicating
Example:
From: "User, Joe S." <2145551212@mycompany.com>
To
The recipient's fully-qualified domain address. There may be one or
more To: fields in any message.
It is recommended that all addressees contain the number text personal name
of
supported recipients.
This protocol does not limit the maximum message length. Implementors
should understand that some machines will recipient, if known, in a quoted phrase. The name must be unable to accept excessively
long messages. A mechanism is defined in
the RFC 1425 ESMTP extensions form "last, first, mi." From [822]
Example:
To: "User, Sam S." <2145551213@mycompany.com>
Cc
Additional recipients' fully-qualified domain address. Many VM systems
are not capable of storing or reporting the full list of recipients to
declare
the maximum message size supported.
The message size indicatd in receiver. Systems conformant to this profile may discard the ESMTP SIZE command CC
list of incoming messages as necessary. Systems conformant to this
profile should provide a complete list of recipients when possible.
It is recommended that all addressees contain the text personal name
of the recipient, if known, in bytes, not
minutes. a quoted phrase. The number of bytes varies by voice encoding format and name must
include the MIME wrapper overhead. Translation into minutes, can be
performed in
the form "last, first, mi." From [822]
Example:
To: "User, Sam S." <2145551213@mycompany.com>
Date
The date, time, and time zone in which the message was sent by simple multiplication the
originator, or the time specified by the originator if the voice encoding message is know from
the system configuration file.
Framework
scheduled for deferred delivery. Conforming implementations should be
able to convert RFC 822 date and time stamps into local time. If the voice profile
This document specifies a profile of
VM reports message-sent time, the TCP/IP multimedia messaging
protocols for use by special-purpose voice processing platforms. These
platforms are value in the Date field should be
used, not general-purpose computers the time the message was received at the destination system.
From [822]
Example:
Date: Wed, 28 Jul 93 10:08:49 PST
Presentation of seconds and often do not have
facilities normally associated with an Internet Email-capable computer. the day of the week is optional.
Sender
The following are typical restrictions imposed 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 messaging
platform:
Text messages are not normally received system and often cannot
Vaudreuil Expires 9/1/95 [Page 7]
Internet Draft MIME Voice Profile March 21, 1995
should only be displayed
or viewed in generated by a conforming implementation with per-
destination configuration.
The Sender field often contains the normal fashion. They can be processed only via
advanced text-to-speech or text-to-fax features not currently present
in these machines.
2) Voice mail (VM) machines act as name of an integrated Message Transfer Agent Internet-style mailing
list administrator and a User Agent. The VM is responsible the destination address for final delivery, and there reporting errors
if the ESMTP MAIL FROM address is no forwarding of messages. RFC 822 header fields have limited use not available. While it may not be
possible to save this information in the context of the simple messaging features currently deployed.
3) some VM message stores are generally not capable of preserving machines, discarding this
information or the full
semantics of ESMTP MAIL FROM address will make it difficult to
send an Internet message. As such, use of a VM for general error message forwarding and gatewaying to the proper destination. From [822]
Message-id
A unique per-message identifier. This value is not supported. Storage of
"Received" lines and "Message-ID" may be limited.
Nothing in this document precludes use of a general purpose email
gateway from providing these services. However, severe performance
degradation may result if the email gateway does not support the
advanced ESMTP options required by this document.
4) Internet-style mailing lists are not generally supported. Distribution
lists are implemented as local alias lists.
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.
The system user names are limited to 16 or fewer numeric characters.
Vaudreuil Expires 5/1/95 3]
Internet Draft MIME Voice Profile January 26, 1995
5.Message Format Profile
The voice profile was written to be based
stored on and be consistent with the
TCP/IP Email Protocol Suite with newly standardized options for enhanced
functionality and performance. receiving system. This section is an overview of the necessary
protocols identifier may be used for
tracking, auditing, and a profile of the applicable protocols as applied returning read-receipt reports. From [822]
Example:
Message-id: <12345678@mycompany.com>
Received
Special-purpose trace information added to the voice
messaging environment.
5.1. Message Addressing Formats beginning of a RFC 822 and SMTP addressing uses the domain name system.
message by message transport agents (MTA). This naming
system has two components: the local part, used for username or mailbox
identification; and is the host part, used for machine or node identification.
These two components are separated only header
permitted to be added by the commercial "@" symbol.
The local part of the address an MTA. Information in this header is useful
for debugging when using an ASCII string uniquely identifying a
mailbox on message reader or a destination system. The local part is a printable string
containing the mailbox number of the originator or header parsing
tool. A conforming system must add Received headers when acting as a recipient.
Administration of this number space is expected to
gateway and must not remove them. These headers may be conform to national ignored or corporate private telephone numbering plans.
The domain part of
deleted when the address message is a hierarchical global name for all
machines. For participation in received at the international Internet network or for
integration within a corporate internet, each VM machine final destination. From
[822]
MIME Version
The MIME-Version header indicates that the message is required conformant to
have a unique domain name. In
the domain name system, MIME message format specification. This header must be present in
any conforming message. Systems conformant to this profile will
include a name is registered comment with the Internet Assigned Number Authority (IANA). words "(Voice 1.0)". From [MIME]
Example:
MIME-Version: 1.0 (Voice 1.0)
Content-Type
The IANA may delegate content-type header declares the management type of a branch content enclosed in the
message. One of the naming space to a company or service
provider.
For example, allowable contents is multipart, a compliant mechanism for
bundling several 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. components into a single message. The use of the domain naming system should be
transparent to the user. It is
allowable contents are specified in the responsibility next section of the VM to translate
the dialed address to the fully-qualified domain name (FQDN). The mapping
of dialed address to VM destination is generally accomplished through
implementation-specific means, usually a local table.
Mapping of the FQDN to a specific network destination is generally
performed by the Domain Name System. For networks with a small number of
machines, a locally-maintained host table database can be used as a simpler
alternative.
Special addresses are provided for compatibility with the conventions of
the this document.
From [MIME]
Content-Transfer-Encoding
Because Internet mail system and to facilitate testing. These addresses do not
use numeric local addresses, both was initially specified to conform carry only 7-bit US-
ASCII text, it may be necessary to current Internet practice encode voice and to avoid conflict with existing numeric addressing plans. Some special
addresses are as follows:
Postmaster@domain
By convention, fax data into a special mailbox named "postmaster" should
exist on all systems. This address is used for diagnostics
and should be checked regularly by the system manager. This
Vaudreuil es 5/1/95 Expires 9/1/95 [Page 8]
Internet Draft MIME Voice Profile January 26, March 21, 1995
mailbox
representation suitable for that environment. The content-transfer-
encoding header describes this transformation if it is particularly likely to receive text messages, which needed. From
[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 not normal on requested, this field is omitted.
If a voice processing platform; the specific
handling of these messages Sensitivity header is present in the message, a individual implementation
choice.
Loopback@domain
A special mailbox name named "loopback" should be designated
for loopback testing. All messages sent to conformant system
is prohibited from forwarding this mailbox must
be returned back message to any other user. If the sender as a new message. The
originating address should be "postmaster".
Because VMs do not use alpha-numeric addresses, this address
will
receiving system does not conflict with any internal numbering plan. Internal
to VM, a specific numeric address for DTMF entry can be mapped
to "loopback".
Note that without network level authentication, support privacy and the loopback
address can be abused by routing messages through a third-
party VM to spoof another device or to avoid toll charges. It sensitivity is recommended that one
of "Personal" or "Private", the loopback feature message must be disabled except
when testing the networking between machines.
5.2. Message Header Fields
Internet messages contain a header information block. This header block
contains information required returned to identify the sender, the list of
recipients, the sender
with an appropriate error message send time, and other information intended for user
presentation. Except for specialized gateway and mailing list cases,
headers do indicating that privacy could not indicate delivery options for the transport of messages.
RFC 822 defines a set of standard message header fields. This set is
extended in several RFCs.
Note be
assured and that the specific order of header lines is message was not specified. The order
cannot be expected delivered.
Importance
Indicates the requested priority to be preserved when sent through intermediate gateways.
The following header fields must be supported.
From
The originator's fully-qualified domain address (a mailbox
number followed given by the fully-qualified domain name). receiving system.
The user
listed in 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". This field should can be presented used to order
messages in the voice message
envelope as the originator of the message.
It a recipient's mailbox and is recommended that all messages contain the text personal
name of equivalent to the sender in a quoted phrase if available. AMIS-
Digital Priority indication. From
[822]
Example:
From: "Joe S. User" <2145551212@mycompany.com>
To
Vaudreuil es 5/1/95
Internet Draft MIME Voice Profile January 26, 1995 [X400]
Subject
The recipient's fully-qualified domain address. There subject field is often provided by email systems but is not widely
supported on Voice Mail platforms. This field may be
one or more To: fields in any message. All recipients of generated by a
message must
conforming implementation and may be listed in To lines except when a recipient discarded if present.
3 Message Content Types
MIME is
specifically intended to receive a blind carbon copy. Note general-purpose message body format that many VM systems have no facilities for storing or
reporting is extensible to the recipient the list
carry a wide range of recipients. These
systems will generally discard these headers when received.
It body parts. The basic protocol is recommended described in
[MIME]. MIME also provides for encoding binary data so that all messages contain it can be
transported over the text personal
name 7-bit text-oriented SMTP protocol. This
transport encoding is independent of the recipient in a quoted phrase if available. From
[822]
Cc
Additional recipients' fully-qualified domain address. This
field has no meaning beyond "To:" in audio encoding designed to
generate a VM and is not binary object.
MIME defines two transport encoding mechanisms to be
generated by transform binary
data into a conforming implementation. It is included 7 bit representation, one designed for
processing by the receiver text-like data
("Quoted-Printable"), and one for compatibility with general
Internet mail agents that may not restrict the use of this
field.
If the VM supports 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 reporting of multiple recipients, all
names data can be labled as "Binary".
An implementation in the To: and Cc: fields conformance with this profile should be reported. From [822]
Date
The date, time, and time zone the message was composed by the
originator, or the time specified by the originator if the send audio
data in binary form when binary message transport is scheduled for delayed delivery. Conforming 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 also be able supported in order to convert RFC 822 date meet MIME
Vaudreuil Expires 9/1/95 [Page 9]
Internet Draft MIME Voice Profile March 21, 1995
requirements and time
stamps into local time. If the VM reports message-sent time,
the value in to preserve interoperability with the Date field should fullest range
of possible devices.
The following content types are identified for use with this profile.
Note that each of these contents can be used, not the time the sent individually in a message was received at the destination system. From [822]
Example: Wed, 28 Jul 93 10:08:49 PDT
Sender
The actual address
or wrapped in a multipart message to send multi-segment messages.
Message/RFC822 (REQUIRED)
MIME requires support of the originator if the Message/RFC822 message encapsulation body
part. This body part is sent by
an agent on behalf of the author indicated used in the From: field.
This field is not Internet to be generated by forward complete
messages within a conforming
implementation. It is included for multipart/mixed message. Processing of this body
part entails trivial processing by to unencapsulate/encapsulate the receiver
for compatibility with general Internet mail software that may
generate
message. Systems conformant to this header.
The Sender field often contains profile but should not send this
body part but must accepted if in conformance with basic MIME.
Specific handling depends on the name of an Internet-style
mailing list administrator platform, and interpretation of this
content-type is left as an implementation decision. From [MIME]
Text/Plain (REQUIRED)
MIME requires support of the destination address for
reporting errors if basic text/plain content type. This
content type has no applicability within the ESMTP MAIL FROM address is not
available. While it may voice messaging
environment and should not be possible to save this
information in some VM machines, discarding this information
or sent. Specific handling depends on the SMTP MAIL FROM address will make it difficult to send
platform, and interpretation of this content-type is left as an error message to the proper destination.
implementation decision. From [822]
Message-id
Vaudreuil es 5/1/95
Internet Draft [MIME]
Multipart/Mixed (REQUIRED)
MIME Voice Profile January 26, 1995
A unique per-message identifier. Conforming systems must use
an identifier constructed by concatenating a unique 8-digit
serial message number and the sending VM's FQDN with provides the
commercial @ symbol. This identifier will facilities for enclosing several body parts in a
single message. Multipart/Mixed may be used for
tracking, auditing, and returning delivery reports. From
[822]
Example:
Message-id: <12345678@mycompany.com>
Received
Special-purpose trace information added sending multi-segment
voice messages, that is, to preserve across the beginning of a
RFC 822 message by message transport agents (MTA). This is network the only header permitted to be added by
distinction between an MTA. Information
in this header is useful for debugging when using an ASCII
message reader or annotation and a header parsing tool. A conforming system forwarded message. Conformant
systems must add Received headers when acting as accept multipart/mixed body parts. Systems are permitted
to collapse such a gateway and must multi-segment message into a single segment if
multi-segment messages are not remove them. These headers may be ignored or deleted when supported on the receiving machine.
From [MIME]
Message/Notification (REQUIRED)
This MIME body part is used for sending machine-parsable delivery
status notifications. From [NOTIFY]
Multipart/Report (REQUIRED)
The Multipart/Report is used for enclosing a Message/Notification body
part and any returned message content. This body type is received at the final destination. a companion
to Message/Notification. From [822]
MIME Version
Indicates that [NOTIFY2]
Audio/32KADPCM (REQUIRED)
CCITT Recommendation G.721 [G721] describes the message 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 conformant applied to the PCM stream using an
Adaptive Differential Pulse Code Modulation (ADPCM) transcoding
Vaudreuil Expires 9/1/95 [Page 10]
Internet Draft MIME message
format specification. Voice Profile March 21, 1995
technique. This header must be present in any
conforming message. Systems conformant to this profile algorithm will
include a comment be registered with the words "(VOICE 1.0)". From [MIME]
Example:
MIME-Version: 1.0 (VOICE 1.0)
Content-Type
The content-type header declares the type of content enclosed
in IANA for MIME
use under the message. One name Audio/32KADPCM.
Support of the allowable contents Audio/32KADPCM is multipart, a
mechanism required for bundling several message components into a
single message. The allowable contents are specified in the
next section of conformance with this document. From [MIME]
Content-Transfer-Encoding
Because Internet mail was initially specified to carry only 7-
bit US-ASCII text, it
profile.
Proprietary Voice Formats (OPTIONAL)
Proprietary voice encoding formats or other standard formats may be necessary to encode voice and fax
data into a representation suitable for that environment. The
content-transfer-encoding header describes
supported under this transformation
if it profile provided a unique identifier is needed. From [MIME]
Sensitivity
registered with the IANA prior to use. These encodings should be
registered as sub-types of Audio. The requested privacy level. If this field exists, regardless use of the selected case-insensitive value "Personal" or
"Private". If no privacy unregistered content-
type values is requested, strongly discouraged.
Use of any other encoding except Audio/32KADPCM reduces
interoperability in the absence of explicit manual system
configuration. A system conformant to this field is omitted.
Vaudreuil Expires 5/1/95 7
Internet Draft profile will not send
proprietary voice formats without explict configuration.
Multipart/VM (OPTIONAL)
This new MIME Voice Profile January 26, 1995
If multipart structure provides a Sensitivity header is present in mechanism for packaging
the message, senders spoken name, a
conformant system is prohibited from forwarding this spoken subject and, the message.
If The
multipart provides for the receiving system does not support privacy and packaging of three segments, the
sensitivity first is one of "Personal" or "Private",
the message
must be returned to spoken name, the sender with an appropriate error
message indicating that privacy could not be assured second is a spoken subject, and that the third is the
message was not delivered.
The specific privacy values do not need to be offered
individually to users but itself. Forwarded messages can be set on a system-wide basis.
From [X400]
Importance
Indicates the requested priority to be given created by the receiving
system. The case-insensitive values "low", "normal" and
"high" are specified. If no special importance simply nesting
multiparts (this is requested,
this header may be omitted and the value assumed to be
"normal". This field can be used also possible with Multipart/Mixed if spoken name
or spoken subject is not present). This type is defined in an
appendix to order messages this document.
An implementation conformant to this profile will use Audio/32KADPCM
by default. Use of any other encoding except Audio/32KADPCM reduces
interoperability in a
recipient's mailbox the absence of explicit manual system
configuration. A system conformant to this profile will not send
other voice formats without explict configuration.
Vaudreuil Expires 9/1/95 [Page 11]
Internet Draft MIME Voice Profile March 21, 1995
Message Transport Protocol
Messages are transported between VM 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 AMIS-Digital
Priority indication. From [X400]
5.3. Message Content Types
MIME message control block in many analog
voice networking protocols.
ESMTP is a general-purpose message body format that is extensible messaging protocol, designed both to carry a
wide range of body parts. The basic protocol is described in [MIME]. MIME
also provides send
mail and to allow terminal console messaging. Simple Mail Transport
Protocol (SMTP) was originally created for encoding binary data so that it can be transported over the 7-bit text-oriented SMTP protocol. This transport encoding is
independent exchange of the audio encoding designed to generate a binary object.
MIME defines two transport US-ASCII 7-
bit text messages. Binary and 8-bit text messages have traditionally
been transported by encoding mechanisms to transform binary data the messages into a 7 bit representation, one designed for 7-bit text-like data ("Quoted-
Printable"), form.
[ESMTP] was recently published and one for arbitrary binary data ("Base-64"). While Base-64
is dramatically more efficient formalized an extension mechanism
for audio data, both will work. Where SMTP, and subsequent RFCs have defined 8-bit text networking,
binary transport is available, not transport encoding is needed, networking, and the
data can be labled as "Binary".
An implementation in conformance with this profile is required extensions to send
audio data in binary form when binary message transport is available. When
binary transport is not available, implementations must encode permit the declaration of message
as Base-64. The detection and decoding
size for the efficient transmission of "Quoted-Printable", "7bit", and
"8bit" must also be supported in order to meet MIME requirements and to
preserve interoperability with 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 fullest range
number of round-trip packet exchanges and makes it possible devices.
Bullet this list.... to
validate all recipient addresses in one operation. This extension is
optional but recommended.
The following content types sections list ESMTP commands, keywords, and parameters
that are identified for use with this profile. Note required and those 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 are optional.
5.1 ESMTP Commands
HELO (REQUIRED)
MIME requires support
Base SMTP greeting and identification of the Message/RFC822 message
encapsulation body part. sender. This body part is used in the
Internet to forward complete messages within a multipart/mixed
Vaudreuil Expires 5/1/95 ]
Internet Draft MIME Voice Profile January 26, 1995
message. Processing of this body part entails trivial
processing to unencapsulate/encapsulate the message. It command is not
to be sent by a system conformant to this profile but must
be accepted conforming systems unless the more-capable EHLO command
is not accepted. It is included for conformance compatibility with basic MIME. general SMTP
implementations. From [MIME]
Text/Plain [SMTP]
MAIL FROM (REQUIRED)
MIME requires support of the basic text/plain content type.
Originating mailbox. This content type has no applicability within address contains the voice
messaging environment and mailbox to which
errors should not be sent. Specific
handling depends on This address may not be the platform, and interpretation of this
content-type is left same as an implementation decision. Options
include dropping the body part and sending a delivery report
indicating
message sender listed in the lack of support, text-to-speech, and text-to-
fax support. message header fields if the message was
gatewayed or sent to an Internet-style mailing list. From [MIME]
Multipart/Mixed [SMTP]
RCPT TO (REQUIRED)
MIME provides
Recipient's mailbox. This field contains only the facilities for enclosing several body parts
in a single message. Multipart/Mixed may be used for sending
multi-segment voice messages, that is, addresses to preserve across which
the
network message should be delivered for this transaction. In the distinction between an annotation and a forwarded
message. Systems are permitted event
that multiple transport connections to collapse such a multi-
segment message into a single segment if multi-segment
messages multiple destination machines
are not supported on the receiving machine. From
[MIME]
Text/Signature (RECOMMENDED)
Text/Signature provides a mechanism required for the sending same message, this list may not match the list of per-
user directory information including
recipients in the spoken name and message header. From [SMTP]
Vaudreuil Expires 9/1/95 [Page 12]
Internet Draft MIME Voice Profile March 21, 1995
DATA (REQUIRED)
Initiates the transfer of message data. This command is required to
be supported mailbox capabilities. When used with but should only be used in the event the binary mode
command BDAT is not supported. From [SMTP]
TURN (DISCOURAGED)
Requests a caching
mechanism, basic directory services with entries change-of-roles, that is, the client that opened the
connection offers to assume the role of server for commonly
used entries can be maintained. any mail the remote
machine may wish to send. This body part command is intended to
be used useful to support spoken name confirmation. The
Text/Signature can be included with a message poll for
messages.
(Note the security implications of using the
multipart/mixed constructor type. From [SIG]
Message/Notification (REQUIRED) turn command to fetch
mail queued for another destination. This new MIME body part fetching is used for possible
because of the lack of authentication of the sending VM by the
protocol). From [SMTP]
QUIT (REQUIRED)
Requests that the connection be closed. If accepted, the remote
machine parsable
delivery status notifications. will reset and close the connection. From [NOTIFY]
Multipart/Report [SMTP]
RSET (REQUIRED)
The Multipart/Report
Resets the connection to its initial state. From [SMTP]
VRFY (OPTIONAL)
Requests verification that this node can reach the listed recipient.
While this functionality is used for enclosing also included in the RCPT TO command, VRFY
allows the query without beginning a
Message/Notification body part and any returned message
content. mail transfer transaction. This body type
command is a companion to
Message/Notification. useful for debugging and tracing problems. From [NOTIFY2]
Audio/ADPCM (REQUIRED)
CCITT Recommendation G.721 describes [SMTP]
(Note that the algorithm recommended
for conversion implementation of VRFY may simplify the guessing of a 64 KB/s A-law
recipient's mailbox or u-law PCM channel to and
Vaudreuil es 5/1/95
Internet Draft MIME Voice Profile January 26, 1995
from automated sweeps for valid mailbox addresses,
resulting in 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 possible reduction in privacy. Various implementation
techniques may be
registered with used to reduce the IANA for MIME use under threat, such as limiting the name
Audio/ADPCM.
Support
number of Audio/ADPCM is required queries per session.) From [SMTP]
EHLO (REQUIRED)
The enhanced mail greeting that enables a server to announce support
for conformance with this
profile.
Proprietary Voice Formats (OPTIONAL)
Proprietary voice encoding formats extended messaging options. The extended messaging modes are supported under this
profile provided
discussed in a unique identifier later section of this document. From [ESMTP]
BDAT (REQUIRED)
The BDAT command is registered with the
IANA prior an alternative to use.
Note that use of proprietary encodings reduces
interoperability in the absence of explicit manual system
configuration. earlier DATA command. The
BDAT command provides for binary transport and does not require
encoding voice data into 7-bit line-limited formats.
All other commands must be recognized and an appropriate error code
returned if not supported. From [BIN]
Vaudreuil es 5/1/95 Expires 9/1/95 [Page 13]
Internet Draft MIME Voice Profile January 26, March 21, 1995
6. Message Transport Protocol
Messages are transported between VM machines using the Internet Extended
Simple Mail Transport Protocol (ESMTP). All information required for
proper delivery of the message is included in the
ESMTP dialog. This
information, including Keywords
STREAMING (OPTIONAL)
The "STREAMING" keyword indicates ability of the sender and recipient addresses, is commonly
referred receiving SMTP to as
accept pipelined SMTP commands. From [PIPE]
SIZE (REQUIRED)
The "SIZE" keyword provides a mechanism by which the message "envelope". This information is equivalent to receiving SMTP
can indicate the maximum size message control block in many analog voice networking protocols.
ESMTP is a general-purpose messaging protocol, designed both to send mail supported. From [SIZE]
CHUNKING (REQUIRED)
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 to allow terminal console messaging. Simple Mail Transport Protocol
(SMTP) was originally created does not imply support for binary
encoded messages. From [BIN]
BINARYMIME (REQUIRED)
The "BINARYMIME" keyword indicates that the exchange of US-ASCII 7-bit text receiver SMTP can accept
binary encoded MIME messages. Binary and 8-bit text Note that CHUNKING mode must be
supported for this option, but CHUNKING does not mean that binary
messages have traditionally been
transported by encoding can be supported. From [BIN]
NOTIFY (REQUIRED)
The "NOTIFY" keyword indicates that the messages into receiver SMTP will accept
explicit delivery status notification requests. From [DSN]
3 ESMTP Parameters - MAIL FROM
BINARYMIME
The current message is 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 encoded MIME messages. From [BIN]
4 ESMTP Parameters - RCPT TO
NOTIFY
The conditions under which a delivery report should be sent. From
[DSN]
RET
Whether the declaration content of the message size should be returned. From [DSN]
Management Protocols
The Internet protocols provide a mechanism for the efficient
transmission management 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 VM
machines, from the number management 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.
6.1. ESMTP Commands
HELO (REQUIRED)
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. From [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 gatewayed or sent to an Internet-style mailing
list. From [SMTP]
RCPT TO (REQUIRED)
Recipient's mailbox. This field contains only physical network through the addresses
to which
management of the message queues. SNMP 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 supported on a
compliant message
header. From [SMTP]
DATA (REQUIRED) machine.
Vaudreuil Expires 5/1/95 9/1/95 [Page 11] 14]
Internet Draft MIME Voice Profile January 26, March 21, 1995
Initiates the transfer of message data. This command is
required
The digital interface to be supported but should only be used in the event
the binary mode command BDAT is not supported. From [SMTP]
TURN (RECOMMENDED)
Requests a change-of-roles, that is, the client that opened VM and the connection offers to assume TCP/IP protocols should be
managed by the role standard network Management Information Bases (MIBs).
MIB II provides basic statistics and reporting of server for any
mail the remote machine may wish to send. This command is
useful to poll for messages.
(Note the security implications of using the turn command to
fetch mail queued TCP/IP protocol
performance and statistics. Media-specific MIBs are available for another destination.
X.25, Ethernet, FDDI, Token Ring, Frame Relay, and other network
technologies. This fetching is
possible because of the lack of authentication MIB provides necessary information to diagnose
faulty hardware, overloaded network conditions, and excessive traffic
conditions from a remote management station.
Management of the sending
VM by the protocol). From [SMTP]
QUIT (REQUIRED)
Requests that the connection be closed. If accepted, the
remote machine will reset resources and close the connection. From
[SMTP]
RSET (REQUIRED)
Resets the connection to its initial state. From [SMTP]
VRFY (OPTIONAL)
Requests verification that this node can reach the listed
recipient. While this functionality is also included in the
RCPT TO command, VRFY allows message queue monitoring based
on the query without beginning a
mail transfer transaction. This command is useful for
debugging host MIB and tracing problems. From [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.) From [SMTP]
EHLO (REQUIRED)
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. From [ESMTP]
BDAT (REQUIRED)
Initiates binary data transmission. Message and Directory MIB is recommended.
Vaudreuil es 5/1/95 Expires 9/1/95 [Page 15]
Internet Draft MIME Voice Profile January 26, March 21, 1995
The BDAT command is an alternative to the earlier DATA
command. The BDAT command does not require encoding voice
data into 7-bit line-limited formats.
All other commands must be recognized
References
[MIME] Borenstein, N., and an appropriate
error code returned if not supported. From [BIN]
6.2. ESMTP Keywords
STREAMING (Optional)
The "STREAMING" keyword indicates ability of N. Freed, "Multipurpose Internet Mail
Extensions", RFC 1521, Bellcore, Innosoft, Sept 1993.
[MSG822] Crocker, D., "Standard for the receiving
SMTP to accept pipelined SMTP commands. From Format of ARPA Internet
Text Messages", STD 11, RFC 822, UDEL, August 1982.
[X400] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021
and RFC 822", RFC 1327, May 1992.
[PIPE]
SIZE (Required) Freed, N., Klensin, J., "SMTP Service Extension for Command
Pipelining" Internet Draft <draft-freed-streaming-0?.txt>
[ESMTP]Klensin, J., Freed, N., Rose, M., Stefferud, E., and D.
Crocker, "SMTP Service Extensions" RFC 1651, United Nations
University, Innosoft International, Inc., Dover Beach Consulting,
Inc., Network Management Associates, Inc., The "SIZE" keyword provides a mechanism by which the receiving
SMTP can indicate the maximum size message supported. From Branch Office, February
1993.
[SIZE]
CHUNKING (Required) Klensin, J, Freed, N., Moore, K, "SMTP Service Extensions for
Message Size Declaration" RFC 1653, United Nations University,
Innosoft International, Inc., Inc., February 1993. February 1993.
[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 "CHUNKING" keyword indicates that the receiver will
support the high-performance transport mode. Note that
CHUNKING can be used with any message format Branch
Office, February 1993.
[DNS1] Mockapetris, P.,"Domain names - implementation and does not
imply support for binary encoded messages. From
specification", RFC1035, Nov 1987.
[DNS2] Mockapetris, P.,"Domain names - concepts and facilities", RFC
1034, Nov 1987.
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
USC/Information Sciences Institute, August 1982.
[BIN]
BINARYMIME (Required)
The "BINARYMIME" keyword indicates that the receiver SMTP can
accept binary encoded Vaudreuil, G., "SMTP Service Extensions for Transmission of
Large and Binary MIME messages. Note that CHUNKING mode
must be supported Messages", Internet Draft <draft-vaudreuil-
binary-06.txt>
[NOTIFY] Vaudreuil, G., Moore, K., "An Extensible Message Format
for this option, but CHUNKING does not mean
that binary messages can be supported. From [BIN]
NOTIFY (Required)
The "NOTIFY" keywork indicates that the receiver SMTP will
accept explicit delivery status notification requests. From Delivery Status Notifications", Internet Draft <draft-ietf-notary-
mime-delivery-02-txt>
[NOTIFY2] Vaudreuil, G., "Multipart/Report", Internet-Draft,
<draft-ietf-notary-mime-report-04.txt>
[DSN]
6.3. ESMTP Parameters - MAIL FROM
BINARYMIME The current message is a binary encoded Moore, K. "SMTP Service Extensions for Delivery Status
Notifications", Internet Draft <draft-ietf-notary-smtp-drpt-03.txt>.
Vaudreuil Expires 9/1/95 [Page 16]
Internet Draft MIME messages. From
[BIN]
6.4. ESMTP Parameters - RCPT TO
NOTIFY The conditions under which Voice Profile March 21, 1995
[G721] CCITT Recommendation G.700-G.795 (1988), General Aspects of
Digital Transmission Systems, Terminal Equipments. Blue Book.
8. Security Consideration
This document is a delivery report should be sent.
From [DSN]
RET Whether the content profile of existing Internet mail protcols. As
such, it does not create any security issues not already existing in
the profiled Internet mail protocols themselves.
9. Acknowledgements
The author would like to offer special thanks to Glen Parsons/BNR for
his extensive review, helpful suggestions, and extensive editing
including the message should be returned. From
[DSN] requirements matrix.
Author's Address
Gregory M. Vaudreuil
Octel Network Services
17080 Dallas Parkway
Dallas, TX 75248-1905
214-733-2722
Greg.Vaudreuil@ONS.Octel.Com
Vaudreuil Expires 5/1/95 9/1/95 [Page 17]
Internet Draft MIME Voice Profile January 26, March 21, 1995
7.Management Protocols
The Internet protocols provide a mechanism for the management
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 VM
machines, from the management postmaster@domain |4.1 | |x| | | |
Support of the physical network through the
management loopback@domain |4.1 | |x| | | |
| | | | | | |
Message Header Fields: | | | | | | |
Encoding outbound messages | | | | | | |
From |4.2 |x| | | | |
Addition of the message queues. SNMP should be supported on a compliant
message machine.
The digital interface to the VM and the TCP/IP protocols should be managed
by the standard network Managed Information Bases (MIBs). MIB II provides
basic statistics and reporting text personal name |4.2 | |x| | | |
To |4.2 |x| | | | |
Addition of the TCP/IP protocol performance and
statistics. Media-specific MIBs are available for X.25, Ethernet, FDDI,
Token Ring, Frame Relay, and other network technologies. This MIB provides
necessary information to diagnose faulty hardware, overloaded network
conditions, and excessive traffic conditions from a remote management
station.
Management 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 the machine resources and message queue monitoring based on
the host MIB and the Date to local time |4.2 | |x| | | |
Presentation of seconds & weekday |4.2 | | |x| | |
Sender |4.2 | | | |x| |
Message and Directory MIB is recommended but not
required for conformance with this profile. 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| | | | |
Vaudreuil Expires 9/1/95 [Page 18]
Internet Draft MIME Voice Profile March 21, 1995
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| | | | |
Content-Description |4.3, 12 | | |x| | |
Content-Duration |4.3, 12 | | |x| | |
Content-Language |4.3, 12 | | |x| | |
Audio/* (proprietary encodings) |4.3 | | |x| | |
Multipart/VM |4.3, 13 | | |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/VM |4.3, 13 | | |x| | |
| | | | | | |
Message Transport Protocol: | | | | | | |
ESMTP Commands | | | | | | |
EHELO |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 | | | | | | |
Vaudreuil Expires 5/1/95 9/1/95 [Page 14] 19]
Internet Draft MIME Voice Profile January 26, March 21, 1995
8.References
[MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail
Extensions", RFC 1521, Bellcore, Innosoft, Sept 1993.
[MSG822] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, UDEL, August 1982.
[X400] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021
and RFC 822", RFC 1327, May 1992.
[PIPE] Freed, N., Klensin, J., "SMTP Service Extension for Command
Pipelining" Internet Draft <draft-freed-streaming-0?.txt>
[ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker,
"SMTP Service Extensions" RFC 1425, United Nations University,
Innosoft International, Inc., Dover Beach Consulting, Inc.,
Network
STREAMING |5.2 | | |x| | |
SIZE |5.2 |x| | | | |
CHUNKING |5.2 |x| | | | |
BINARYMIME |5.2 |x| | | | |
NOTIFY |5.2 |x| | | | |
| | | | | | |
Management Associates, Inc., The Branch Office, February
1993.
[SIZE] Klensin, J, Freed, N., Moore, K, "SMTP Service Extensions Protocols: | | | | | | |
SNMP for
Message Size Declaration" RFC 1427, United Nations University,
Innosoft International, Inc., Inc., February 1993. February 1993.
[8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E., D. Crocker,
"SMTP Service Extension message & network mgmt |6.0 | |x| | | |
MIBs 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", RFC1035, Nov 1987.
[DNS2] Mockapetris, P.,"Domain names - concepts and facilities", RFC
1034, Nov 1987.
[SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
USC/Information Sciences Institute, August 1982.
[SIG] Vaudreuil, G., "Text/Signature", monitoring queues & resources |6.0 | |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
Vaudreuil Expires 9/1/95 [Page 20]
Internet Draft <draft-vaudreuil-
signature-??.txt>
[BIN] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large
and Binary MIME Messages", Internet Draft <draft-vaudreuil-
binary-??.txt>
[NOTIFY] Vaudreuil, G., Moore, K., "An Extensible Voice Profile March 21, 1995
Appendix - Example Voice Message Format for
Delivery Status Notifications", Internet Draft <draft-ietf-
notary-mime-delivery-0?-txt>
[NOTIFY2] Vaudreuil, G., "Multipart/Report", Internet-Draft, <draft-ietf-
notary-mime-report-0?.txt>
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, Glen, W." 2145551234@mv1.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/VM; Boundary = "MessageBoundary"
Content-Transfer-Encoding: 7bit
Message-ID: VM1.mycompany.co-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
Vaudreuil Expires 5/1/95 9/1/95 [Page 15] 21]
Internet Draft MIME Voice Profile January 26, March 21, 1995
[DSN] Moore, K. "SMTP Service Extensions
Encoding Considerations: Any encoding necessary for Delivery Status
Notifications", Internet Draft <draft-ietf-notary-smtp-drpt-
??.txt>.
9.Security Consideration
This document is a profile transport may be
used.
CCITT Recommendation G.721 [G721] describes the algorithm recommended
for conversion of existing Internet mail protcools. As such,
it does create any security issues not already existing in 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 profiled
Internet mail protocols themselves.
10. Author's Address
Gregory M. Vaudreuil
Octel Communications Corporation
Network Services Divison
17080 Dallas Parkway
Dallas, TX 75248-1905
214-733-2722
Greg.Vaudreuil@ONS.Octel.Com 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 Expires 5/1/95 9/1/95 [Page 16] 22]
Internet Draft MIME Voice Profile January 26, March 21, 1995
11.
13. Appendix - Example Voice Message Multipart/VM
Mime type name: Multipart
Mime Sub-Type name: Spoken-NameVM
Required Parameters: Boundary
Optional Parameters: None
Encoding Considerations: Quoted-Printable and Base-64 are prohibited.
The following message is syntax of a full-featured, all-options-enabled message
addressed Multipart/VM is identical to two recipients. the Multipart/Mixed
content type. The message includes VM content-type contains three body parts. The
first is an audio segment conatining the sender's spoken name
and of the
originator, the second is an audio segment containing a short speech segment. spoken
subject, and the third is the voice message itself. Forwarded voice
messages can be created by simply nesting multiparts .
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 marked as important and
private. Read receipts and positive delivery acknowledgment are requested.
To: 2145551212@vm1.mycompany.com
To: 2145551234@mv1.mycompany.com
From: 2175552345@VM2.mycompany.com
Date: Mon, 26 Aug 93 10:20:20 CST
MIME-Version: 1.0 (Voice Profile Version 1)
Content-type: Multipart/Mixed; Boundary = "MessageBoundary"
Content-Transfer-Encoding: 7bit
Message-ID: VM1.mycompany.co-123456789
Sensitivity: PrivateImportance: High
--MessageBoundary
Content-type: Text/Signature
Name: User, Joe, R. (Joe Random User)
SpokenName: lslfdslsertiflkTfpgkTportrpkTpfgTpoiTpssdasddasdasd
(This is available, the base-64 encoded
segment must still be present but may be empty.
The spoken name)
o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90geQ5tkjpokfgW
dlkgpokpeowrit09IpokporkgwI==
Capabilities: Audio/Basic, Audio/ADPCM, Application/Signature,
Image/G3Fax
--MessageBoundary
Content-type: Audio/ADPCM
Content-Transfer-Encoding: Base-64
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd
(This 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 sample multipart/mixed collections of body parts, though will
typically be an audio segment.
The default handling of the base-64 message data) fgdhgdfgd
jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW
dlkgpokpeowrit09==
--MessageBoundary-- multipart/VM shall be to voice the
spoken-name segment and then the spoken-subject prior to displaying or
voicing the remainder of the message.
Vaudreuil Expires 9/1/95 [Page 23]
----