idnits 2.17.1 draft-umig-mime-voice-03.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-28) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 23 longer pages, the longest (page 15) being 61 lines == It seems as if not all pages are separated by form feeds - found 21 form feeds but 23 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 195 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 216: '...x named "postmaster" MUST exist on all...' RFC 2119 keyword, line 225: '...named "loopback" SHOULD be designated ...' RFC 2119 keyword, line 227: '... MUST be returned back to the addr...' RFC 2119 keyword, line 228: '...ddress of the returned address MUST be...' RFC 2119 keyword, line 252: '... to this profile SHOULD provide the te...' (53 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1003 has weird spacing: '...Message is id...' == Line 1025 has weird spacing: '...Message shall...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 5, 1995) is 10555 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'DRPT' is mentioned on line 180, but not defined == Missing Reference: 'STATUS' is mentioned on line 180, but not defined -- Looks like a reference, but probably isn't: '822' on line 347 == Unused Reference: 'MSG822' is defined on line 731, but no explicit reference was found in the text == Unused Reference: '8BIT' is defined on line 750, but no explicit reference was found in the text == Unused Reference: 'DNS1' is defined on line 756, but no explicit reference was found in the text == Unused Reference: 'DNS2' is defined on line 759, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1521 (ref. 'MIME') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1327 (ref. 'X400') (Obsoleted by RFC 2156) -- Possible downref: Non-RFC (?) normative reference: ref. 'PIPE' ** Obsolete normative reference: RFC 1651 (ref. 'ESMTP') (Obsoleted by RFC 1869) ** Obsolete normative reference: RFC 1653 (ref. 'SIZE') (Obsoleted by RFC 1870) ** Obsolete normative reference: RFC 1426 (ref. '8BIT') (Obsoleted by RFC 1652) ** Obsolete normative reference: RFC 821 (ref. 'SMTP') (Obsoleted by RFC 2821) -- Possible downref: Non-RFC (?) normative reference: ref. 'BINARY' -- Possible downref: Non-RFC (?) normative reference: ref. 'NOTIFY' -- Possible downref: Non-RFC (?) normative reference: ref. 'REPORT' -- Possible downref: Non-RFC (?) normative reference: ref. 'DSN' -- Possible downref: Non-RFC (?) normative reference: ref. 'G721' ** Obsolete normative reference: RFC 1566 (ref. 'MADMAN') (Obsoleted by RFC 2249, RFC 2789) ** Obsolete normative reference: RFC 1158 (ref. 'MIB II') (Obsoleted by RFC 1213) Summary: 21 errors (**), 0 flaws (~~), 11 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Greg Vaudreuil 3 Internet Draft Octel Network Services 4 Expires: 11/5/1995 May 5, 1995 6 MIME/ESMTP Profile for 7 Voice Messaging 9 11 Changes From the previous version 13 1) Message format profile and processing rules are more clearly 14 separated. 16 2) Much tutorial text was eliminated. A basic familiarity with the 17 SMTP/MIME protocols is now uniformly assumed. Text describing the 18 voice messaging environment remains to promote understanding between 19 the traditional email community and the voice processing community. 21 3) Text using the words "Recommended", "Required", "Optional" and 22 "Discouraged" has been replaced with the more normal "Must", "Must 23 Not", "Should", and "Should Not". 25 Status of this Memo 27 This document is an Internet Draft. Internet Drafts are working 28 documents of the Internet Engineering Task Force (IETF), its Areas, 29 and its Working Groups. Note that other groups may also distribute 30 working documents as Internet Drafts. 32 Internet Drafts are valid for a maximum of six months and may be 33 updated, replaced, or obsoleted by other documents at any time. It is 34 inappropriate to use Internet Drafts as reference material or to cite 35 them other than as a "work in progress". 37 1. Abstract 39 A class of special-purpose computers has evolved to provide voice 40 messaging services. These machines generally interface to a telephone 41 switch and provide call answering and voice messaging services. 42 Traditionally, messages sent to a non-local machine are transported 43 using analog networking protocols based on DTMF signaling and analog 44 voice playback. As the demand for networking increases, there is a 45 need for a standard high-quality digital protocol to connect these 46 machines. The following document is a profile of the Internet 47 standard MIME and ESMTP protocols for use as a digital voice 48 networking protocol. 50 This profile is based on an earlier effort in the Audio Message 51 Interchange Specification (AMIS) group to define a voice messaging 52 protocol based on X.400 technology. This protocol is intended to 53 satisfy the user requirements statement from that earlier work with 54 the industry standard ESMTP/MIME mail protocol infrastructures already 55 used within corporate internets. This profile will be called the 56 voice profile in this document. 58 2. Scope and Design Goals 60 MIME is the Internet multipurpose, multimedia messaging standard. 61 This document explicitly recognizes its capabilities and provides a 62 mechanism for the exchange of various messaging technologies including 63 voice and facsimile. 65 This document specifies a profile of the TCP/IP multimedia messaging 66 protocols for use by special-purpose voice processing platforms. 67 These platforms have historically been special-purpose computers and 68 often do not have facilities normally associated with a traditional 69 Internet Email-capable computer. This profile is intended to specify 70 the minimum common set of features and functionally for conformant 71 systems. 73 The voice profile does not place limits on the use of additional media 74 types or protocol options. However, systems which are conformant to 75 this profile should not send messages with features beyond this 76 profile unless explicit per-destination configuration of these 77 enhanced features is provided. Such configuration information could 78 be stored in a directory, though the implementation of this is a local 79 matter. 81 The following are typical restrictions of voice messaging platform 82 which were considered in creating this baseline profile. 84 1) Text messages are not normally received and often cannot be 85 displayed or viewed. They can often be processed only via advanced 86 text-to-speech or text-to-fax features not currently present in 87 these machines. 89 2) Voice mail machines usually act as an integrated Message 90 Transfer Agent and a User Agent. The voice mail machine is 91 responsible for final delivery, and there is no relaying of 92 messages. RFC 822 header fields may have limited use in the 93 context of the simple messaging features currently deployed. 95 3) VM message stores are generally not capable of preserving the 96 full semantics of an Internet message. As such, use of a voice 97 mail machine for general message forwarding and gatewaying is not 98 supported. Storage of "Received" lines and "Message-ID" may be 99 limited. 101 4) Nothing in this document precludes use of a general purpose 102 email gateway from providing these services. However, severe 103 performance degradation may result if the email gateway does not 104 support the ESMTP options recommended by this document. 106 5) Internet-style mailing lists are not generally supported. 107 Distribution lists are implemented as local alias lists. 109 6) There is generally no human operator. Error reports must be 110 machine-parsable so that helpful responses can be given to users 111 whose only access mechanism is a telephone. 113 7) The system user names are often limited to 16 or fewer numeric 114 characters. Alpha characters are not generally used for mailbox 115 identification as they cannot be easily entered from a telephone 116 terminal. 118 It is a goal of this effort to make as few restrictions and additions 119 to the existing Internet mail protocols as possible while satisfying 120 the user requirements for interoperability with current voice 121 messaging systems. This goal is motivated by the desire to increase 122 the accessibility to digital messaging by enabling the use of proven 123 existing networking software for rapid development. 125 This specification is intended for use on a TCP/IP network, however, 126 it is possible to use the SMTP protocol suite over other transport 127 protocols. The necessary protocol parameters for such use is outside 128 the scope of this document. 130 This profile is intended to be robust enough to be used in an 131 environment such as the global Internet with installed base gateways 132 which do not understand MIME. It is expected that a messaging system 133 will be managed by a system administrator who can perform TCP/IP 134 network configuration. When using facsimile or multiple voice 135 encodings, it is expected that the system administrator will maintain 136 a list of the capabilities of the networked mail machines to reduce 137 the sending of undeliverable messages due to lack of feature support. 138 Configuration, implementation and management of this directory listing 139 capabilities is a local matter. 141 This specification is a profile of the relevant TCP/IP Internet 142 protocols. These technologies, as well as the specifications for the 143 Internet mail protocols, are defined in the Request for Comment (RFC) 144 document series. That series documents the standards as well as the 145 lore of the TCP/IP protocol suite. This document should be read with 146 the following RFC documents: RFC 821, Simple Mail Transfer Protocol; 147 RFC 822, Standard for the format of ARPA Internet Messages; RFC 1521 148 and RFC 1522, Multipurpose Internet Mail Extensions; RFC 1651, RFC 149 1652, and RFC 1653, SMTP Service Extensions (ESMTP); and RFC 1034 and 150 RFC 1035, Domain Name System. Where additional functionality is 151 needed, it will be defined in this document or in an appendix. 153 3. Protocol Restrictions 155 This protocol does not limit the number of recipients per message. 156 Where possible, implementations should not restrict the number of 157 recipients in a single message. It is recognized that no 158 implementation supports unlimited recipients, and that the number of 159 supported recipients may be quite low. However, ESMTP currently does 160 not provide a mechanism for indicating the number of supported 161 recipients. 163 This protocol does not limit the maximum message length. Implementors 164 should understand that some machines will be unable to accept 165 excessively long messages. A mechanism is defined in the RFC 1425 166 ESMTP extensions to declare the maximum message size supported. 168 The message size indicated in the ESMTP SIZE command is in bytes, not 169 minutes. The number of bytes varies by voice encoding format and must 170 include the MIME wrapper overhead. If the length must be known before 171 sending, an approximate translation into minutes can be performed if 172 the voice encoding is known. 174 4. Voice Message Interexchange Format 176 The voice message interchange format is a profile of the Internet 177 Email Protocol Suite. It requires components from the message format 178 standard for Internet messages {RFC822], the Multipurpose Internet 179 Message Extensions [MIME], the X.400 gateway specification [X.400], 180 and the delivery report specifications [DRPT][STATUS]. 182 4.1 Message Addressing Formats 184 The RFC 822 uses the domain name system. This naming system has two 185 components: the local part, used for username or mailbox 186 identification; and the host part, used for global machine 187 identification. 189 The local part of the address shall be an ASCII string uniquely 190 identifying a mailbox on a destination system. For voice messaging, 191 the local part is a printable string containing the mailbox ID of the 192 originator or recipient. Administration of this space is expected to 193 conform to national or corporate private telephone numbering plans. 194 While alpha characters and long mailbox identifiers are permitted, 195 most voice mail networks rely on numeric mailbox identifiers to retain 196 compatibility with the limited 10 digit telephone keypad. 198 For example, a compliant message may contain the address 199 2145551212@mycompany.com. It should be noted that while the example 200 mailbox address is based on the North American Numbering Plan, any 201 other corporate numbering plan can be used. The use of the domain 202 naming system should be transparent to the user. It is the 203 responsibility of the voice mail machine to lookup the fully-qualified 204 domain name (FQDN) based on the address entered by the user. The 205 mapping of dialed address to final destination system is generally 206 accomplished through implementation-specific means. 208 Special addresses are provided for compatibility with the conventions 209 of the Internet mail system and to facilitate testing. These 210 addresses do not use numeric local addresses, both to conform to 211 current Internet practice and to avoid conflict with existing numeric 212 addressing plans. Some special addresses are as follows: 214 Postmaster@domain 216 By convention, a special mailbox named "postmaster" MUST exist on all 217 systems. This address is used for diagnostics and should be checked 218 regularly by the system manager. This mailbox is particularly likely 219 to receive text messages, which is not normal on a voice processing 220 platform; the specific handling of these messages is a individual 221 implementation choice. 223 Loopback@domain 225 A special mailbox name named "loopback" SHOULD be designated for 226 loopback testing. If supported, all messages sent to this mailbox 227 MUST be returned back to the address listed in the From: address as a 228 new message. The originating address of the returned address MUST be 229 "postmaster" to prevent mail loops. 231 These two addresses are RESERVED so they do not conflict with any 232 internal addressing plan. 234 4.2 Message Header Fields 236 Internet messages contain a header information block. This header 237 block contains information required to identify the sender, the list 238 of recipients, the message send time, and other information intended 239 for user presentation. Except for specialized gateway and mailing 240 list cases, headers do not indicate delivery options for the transport 241 of messages. 243 The following header lines are permitted for use with voice messages. 245 From 247 The originator's fully-qualified domain address (a mailbox address 248 followed by the fully-qualified domain name). The user listed in this 249 field should be presented in the voice message envelope as the 250 originator of the message. 252 Systems conformant to this profile SHOULD provide the text personal 253 name of the sender in a quoted phrase if available. To facilitate 254 storage of the text name in a local dial-by-name cache directory, the 255 first and last name MUST be separable. Text names in voice messages 256 MUST be represented in the form "last, first, mi." From [822] 258 Example: 260 From: "User, Joe S." <2145551212@mycompany.com> 262 To 264 The TO header contains the recipient's fully-qualified domain address. 265 There may be one or more To: fields in any message. 267 Systems conformant to this profile SHOULD provide the text personal 268 name of the recipient, if known, in a quoted phrase. The name MUST be 269 in the form "last, first, mi." From [822] 271 Example: 273 To: "User, Sam S." <2145551213@mycompany.com> 275 Cc 277 The CC header contains additional recipients' fully-qualified domain 278 addresses. Many voice mail systems are not capable of storing or 279 reporting the full list of recipients to the receiver. 281 Systems conformant to this profile SHOULD provide the text personal 282 name of the recipient, if known, in a quoted phrase. The name MUST be 283 in the form "last, first, mi." From [822] 285 Example: 287 To: "User, Sam S." <2145551213@mycompany.com> 289 Systems conformant to this profile may discard the CC list of incoming 290 messages as necessary. Systems conformant to this profile should 291 provide a complete list of recipients when possible. 293 Date 295 The Date header contains the date, time, and time zone in which the 296 message was sent by the originator. Conforming implementations SHOULD 297 be able to convert RFC 822 date and time stamps into local time. 299 Example: 301 Date: Wed, 28 Jul 93 10:08:49 PST 303 The sending system MUST report the time the message was sent. From 304 [822] 306 Sender 308 The Sender header contains the actual address of the originator if the 309 message is sent by an agent on behalf of the author indicated in the 310 From: field. Support for this field cannot be assumed when talking to 311 a voice system and SHOULD NOT be generated by a conforming 312 implementation. 314 The Sender field often contains the name of an Internet-style mailing 315 list administrator and is the destination address for reporting errors 316 if the ESMTP MAIL FROM address is not available. 318 While it may not be possible to save this information in some voice 319 mail machines, discarding this information or the ESMTP MAIL FROM 320 address will make it difficult to send an error message to the proper 321 destination. From [822] 323 Message-id 325 The Message-id header contains a unique per-message identifier. A 326 unique message-id MUST be generated for each message sent from a 327 conforming implementation. 329 The message-id is not required to be stored on the receiving system. 330 This identifier MAY be used for tracking, auditing, and returning 331 read-receipt reports. From [822] 333 Example: 335 Message-id: <12345678@mycompany.com> 337 Received 339 The Received header contains trace information added to the beginning 340 of a RFC 822 message by message transport agents (MTA). This is the 341 only header permitted to be added by an MTA. Information in this 342 header is useful for debugging when using an ASCII message reader or a 343 header parsing tool. 345 A conforming system MUST add Received headers when acting as a gateway 346 and must not remove them. These headers MAY be ignored or deleted 347 when the message is received at the final destination. From [822] 349 MIME Version 351 The MIME-Version header indicates that the message is conformant to 352 the MIME message format specification. Systems conformant to the voice 353 messaging profile MUST include a comment with the words "(Voice 1.0)". 354 From [MIME] 356 Example: 358 MIME-Version: 1.0 (Voice 1.0) 360 Content-Type 362 The content-type header declares the type of content enclosed in the 363 message. One of the allowable contents is multipart, a mechanism for 364 bundling several message components into a single message. The 365 allowable contents are specified in the next section of this document. 366 From [MIME] 368 Content-Transfer-Encoding 370 Because Internet mail was initially specified to carry only 7-bit US- 371 ASCII text, it may be necessary to encode voice and fax data into a 372 representation suitable for that environment. The content-transfer- 373 encoding header describes this transformation if it is needed. 374 Conformant implementations MUST recognize and decode the standard 375 encodings, "Binary", "7bit, "8bit", "Base-64" and "Quoted-Printable". 376 The allowable content-transfer-encodings are specified in the next 377 section of this document. From [MIME] 379 Sensitivity 381 The Sensitivity header, if present, indicates the requested privacy 382 level. The case-insensitive values "Personal" and "Private" are 383 specified. If no privacy is requested, this field is omitted. 385 If a Sensitivity header is present in the message, a conformant system 386 MUST prohibit the recipient from forwarding this message to any other 387 user. If the receiving system does not support privacy and the 388 sensitivity is one of "Personal" or "Private", the message MUST be 389 returned to the sender with an appropriate error code indicating that 390 privacy could not be assured and that the message was not delivered. 392 Importance 394 Indicates the requested priority to be given by the receiving system. 395 The case-insensitive values "low", "normal" and "high" are specified. 396 If no special importance is requested, this header may be omitted and 397 the value assumed to be "normal". 399 Conformant implementations MAY use this header to indicate the 400 importance of a message and may order messages in a recipient's 401 mailbox. From: [X400] 403 Subject 405 The subject field is often provided by email systems but is not widely 406 supported on Voice Mail platforms. This field MAY be generated by a 407 conforming implementation and may be discarded if present by a 408 receiving system. 410 4.3 Message Content Types 412 MIME is a general-purpose message body format that is extensible to 413 carry a wide range of body parts. The basic protocol is described in 414 [MIME]. MIME also provides for encoding binary data so that it can be 415 transported over the 7-bit text-oriented SMTP protocol. This 416 transport encoding is independent of the audio encoding designed to 417 generate a binary object. 419 MIME defines two transport encoding mechanisms to transform binary 420 data into a 7 bit representation, one designed for text-like data 421 ("Quoted-Printable"), and one for arbitrary binary data ("Base-64"). 422 While Base-64 is dramatically more efficient for audio data, both will 423 work. Where binary transport is available, no transport encoding is 424 needed, and the data can be labeled as "Binary". 426 An implementation in conformance with this profile SHOULD send audio 427 data in binary form when binary message transport is available. When 428 binary transport is not available, implementations MUST encode the 429 message as Base-64. The detection and decoding of "Quoted-Printable", 430 "7bit", and "8bit" MUST be supported in order to meet MIME 431 requirements and to preserve interoperability with the fullest range 432 of possible devices. 434 The following content types are identified for use with this profile. 435 Note that each of these contents can be sent individually in a message 436 or wrapped in a multipart message to send multi-segment messages. 438 Message/RFC822 440 MIME requires support of the Message/RFC822 message encapsulation body 441 part. This body part is used in the Internet to forward complete 442 messages within a multipart/mixed message. Processing of this body 443 part entails trivial processing to decapsulate/encapsulate the 444 message. Systems conformant to this profile SHOULD NOT send this body 445 part but MUST accept if in conformance with basic MIME. Specific 446 handling depends on the platform, and interpretation of this content- 447 type is left as an implementation decision. From [MIME] 449 Text/Plain 451 MIME requires support of the basic Text/Plain content type. This 452 content type has no applicability within the voice messaging 453 environment. Conformant implementations MUST NOT send the Text/Plain 454 content-type. Conformant implementations MUST accept Text/Plain 455 messages, however, specific handling is left as an implementation 456 decision. One option is to return the message to the sender with a 457 media-unsupported error code. From [MIME] 459 Multipart/Mixed 461 MIME provides the facilities for enclosing several body parts in a 462 single message. Multipart/Mixed MAY be used for sending multi-segment 463 voice messages, that is, to preserve across the network the 464 distinction between an annotation and a forwarded message. Conformant 465 systems MUST accept multipart/mixed body parts. Systems MAY to 466 collapse such a multi-segment message into a single segment if multi- 467 segment messages are not supported on the receiving machine. From 468 [MIME] 470 Message/Notification 472 This MIME body part is used for sending machine-parsable delivery 473 status notifications. Conformant implementations must use the 474 Message/Notification construct when returning messages or sending 475 warnings. Conformant implementations must recognize and decode the 476 Message/Notification content type and present the reason for failure 477 to the user. From [NOTIFY] 479 Multipart/Report 481 The Multipart/Report is used for enclosing a Message/Notification body 482 part and any returned message content. This body type is a companion 483 to Message/Notification. Conformant implementations must use the 484 Multipart/Report construct when returning messages or sending 485 warnings. Conformant implementations must recognize and decode the 486 Multipart/Report content type. From [REPORT] 488 Audio/32KADPCM 490 CCITT Recommendation G.721 [G721] describes the algorithm recommended 491 for conversion of a 64 KB/s A-law or u-law PCM channel to and from a 492 32 KB/s channel. The conversion is applied to the PCM stream using an 493 Adaptive Differential Pulse Code Modulation (ADPCM) transcoding 494 technique. This algorithm will be registered with the IANA for MIME 495 use under the name Audio/32KADPCM. 497 An implementation conformant to this profile MUST use Audio/32KADPCM 498 by default. 500 Proprietary Voice Formats 502 Proprietary voice encoding formats or other standard formats may be 503 supported under this profile provided a unique identifier is 504 registered with the IANA prior to use. These encodings should be 505 registered as sub-types of Audio. 507 Use of any other encoding except Audio/32KADPCM reduces 508 interoperability in the absence of explicit manual system 509 configuration. A conformant implementation MAY use any other encoding 510 with explicit per-destination configuration. 512 Multipart/Voice-Message 514 This new MIME multipart structure provides a mechanism for packaging 515 the senders spoken name, a spoken subject and, the message. The 516 multipart provides for the packaging of three segments, the first is 517 the spoken name, the second is a spoken subject, and the third is the 518 message itself. Forwarded messages can be created by simply nesting 519 multipart content-types (this is also possible with Multipart/Mixed if 520 spoken name or spoken subject is not present). This type is defined 521 in an appendix to this document. 523 Conforming implementations MUST send the Multipart/Voice-Message if a 524 spoken name or spoken subject is available. Conforming 525 implementations SHOULD recognize the Multipart/Voice-Message and 526 separate the spoken name or spoken subject. 528 5. Message Transport Protocol 530 Messages are transported between voice mail machines using the 531 Internet Extended Simple Mail Transfer Protocol (ESMTP). All 532 information required for proper delivery of the message is included in 533 the ESMTP dialog. This information, including the sender and 534 recipient addresses, is commonly referred to as the message 535 "envelope". This information is equivalent to the message control 536 block in many analog voice networking protocols. 538 ESMTP is a general-purpose messaging protocol, designed both to send 539 mail and to allow terminal console messaging. Simple Mail Transport 540 Protocol (SMTP) was originally created for the exchange of US-ASCII 7- 541 bit text messages. Binary and 8-bit text messages have traditionally 542 been transported by encoding the messages into a 7-bit text-like form. 543 [ESMTP] was recently published and formalized an extension mechanism 544 for SMTP, and subsequent RFCs have defined 8-bit text networking, 545 binary networking, and extensions to permit the declaration of message 546 size for the efficient transmission of large messages such as multi- 547 minute voice mail. 549 A command streaming extension for high performance message 550 transmission has been defined. [PIPE] This extension reduces the 551 number of round-trip packet exchanges and makes it possible to 552 validate all recipient addresses in one operation. This extension is 553 optional but recommended. 555 The following sections list ESMTP commands, keywords, and parameters 556 that are required and those that are optional. 558 5.1 ESMTP Commands 560 HELO 562 Base SMTP greeting and identification of sender. This command is not 563 to be sent by conforming systems unless the more-capable EHLO command 564 is not accepted. It is included for compatibility with general SMTP 565 implementations. Conforming implementations MUST implement the HELO 566 command for backward compatibility but SHOULD NOT send it unless EHLO 567 is not supported. From [SMTP] 569 MAIL FROM (REQUIRED) 571 Originating mailbox. This address contains the mailbox to which 572 errors should be sent. This address may not be the same as the 573 message sender listed in the message header fields if the message was 574 received from a gateway or sent to an Internet-style mailing list. 575 Conforming implementations MUST implement the extended MAIL FROM 576 command. From [SMTP, ESMTP] 578 RCPT TO 580 Recipient's mailbox. This field contains only the addresses to which 581 the message should be delivered for this transaction. In the event 582 that multiple transport connections to multiple destination machines 583 are required for the same message, this list may not match the list of 584 recipients in the message header. Conforming implementations MUST 585 implement the extended RCPT TO command. From [SMTP, ESMTP] 587 DATA 589 Initiates the transfer of message data. Support for this command is 590 required in the event the binary mode command BDAT is not supported by 591 the remote system. Conforming implementations MUST implement the SMTP 592 DATA command for backwards compatibility. From [SMTP] 594 TURN 596 Requests a change-of-roles, that is, the client that opened the 597 connection offers to assume the role of server for any mail the remote 598 machine may wish to send. Because SMTP is not an authenticated 599 protocol, the TURN command presents an opportunity to improperly fetch 600 mail queued for another destination. Conforming implementations 601 SHOULD NOT implement the TURN command. From [SMTP] 603 QUIT 605 Requests that the connection be closed. If accepted, the remote 606 machine will reset and close the connection. Conforming 607 implementations MUST implement the QUIT command. From [SMTP] 609 RSET 611 Resets the connection to its initial state. Conforming 612 implementations MUST implement the RSET command. From [SMTP] 614 VRFY 616 Requests verification that this node can reach the listed recipient. 617 While this functionality is also included in the RCPT TO command, VRFY 618 allows the query without beginning a mail transfer transaction. This 619 command is useful for debugging and tracing problems. Conforming 620 implementations MAY implement the VRFY command. From [SMTP] 622 (Note that the implementation of VRFY may simplify the guessing of a 623 recipient's mailbox or automated sweeps for valid mailbox addresses, 624 resulting in a possible reduction in privacy. Various implementation 625 techniques may be used to reduce the threat, such as limiting the 626 number of queries per session.) From [SMTP] 628 EHLO 630 The enhanced mail greeting that enables a server to announce support 631 for extended messaging options. The extended messaging modes are 632 discussed in a later section of this document. Conformant 633 implementations MUST implement the ESMTP command and return the 634 capabilities indicated later in this memo. From [ESMTP] 635 BDAT 637 The BDAT command provides a higher efficiency alternative to the 638 earlier DATA command, especially for voice. The BDAT command provides 639 for native binary transport. Because voice messages are large binary 640 objects otherwise subject to BASE-64 encoding, BDAT will result in a 641 substantial improvement in transmission efficiency over DATA. 642 Conformant implementations SHOULD support binary transport using the 643 BDAT command.[BINARY] 645 5.2 ESMTP Capabilities 647 The following ESMTP keywords indicate extended features useful for 648 voice messaging. 650 PIPELINING 652 The "PIPELINING" keyword indicates ability of the receiving SMTP to 653 accept pipelined commands. Pipelining commands dramatically improves 654 the protocol performance over wide area networks. Conformant 655 implementations SHOULD support the command pipelining indicated by 656 this parameter. From [PIPE] 658 SIZE 660 The "SIZE" keyword provides a mechanism by which the receiving SMTP 661 can indicate the maximum size message supported. Conformant 662 implementations MUST provide the size capability and SHOULD honor any 663 size limitations when sending. From [SIZE] 665 CHUNKING 667 The "CHUNKING" keyword indicates that the receiver will support the 668 high-performance binary transport mode. Note that CHUNKING can be 669 used with any message format and does not imply support for binary 670 encoded messages. Conformant implementations SHOULD support binary 671 transport indicated by this capability. From [BINARY] 673 BINARYMIME 675 The "BINARYMIME" keyword indicates that the receiver SMTP can accept 676 binary encoded MIME messages. Conformant implementations should 677 support binary transport indicated by this capability. From [BINARY] 679 NOTIFY 681 The "NOTIFY" keyword indicates that the receiver SMTP will accept 682 explicit delivery status notification requests. Conformant 683 implementations MUST support the delivery notification extensions in 684 [DSN]. 686 5.3 ESMTP Parameters - MAIL FROM 688 BINARYMIME 689 The current message is a binary encoded MIME messages. Conformant 690 implementations SHOULD support binary transport indicated by this 691 parameter. From [BINARY] 693 5.4 ESMTP Parameters - RCPT TO 695 NOTIFY 697 The NOTIFY parameter indicates the conditions under which a delivery 698 report SHOULD be sent. Conformant implementations must honor this 699 request. From [DSN] 701 RET 703 The RET parameter indicates whether the content of the message should 704 be returned. Conformant systems SHOULD honor a request for returned 705 content. From [DSN] 707 6. Management Protocols 709 The Internet protocols provide a mechanism for the management of 710 messaging systems, from the management of the physical network through 711 the management of the message queues. SNMP should be supported on a 712 compliant message machine. 714 6.1 Network Management 716 The digital interface to the VM and the TCP/IP protocols SHOULD be 717 managed. MIB II SHOULD be implemented to provide basic statistics and 718 reporting of TCP and IP protocol performance. [MIB II] 720 6.2 Directory and Message Management 722 Conformant systems SHOULD provide for the management of message 723 traffic and queue monitoring based on the Message and Directory MIB. 724 [MADMAN] 726 7. References 728 [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail 729 Extensions", RFC 1521, Bellcore, Innosoft, Sept 1993. 731 [MSG822] Crocker, D., "Standard for the Format of ARPA Internet Text 732 Messages", STD 11, RFC 822, UDEL, August 1982. 734 [X400] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021 735 and RFC 822", RFC 1327, May 1992. 737 [PIPE] Freed, N., Klensin, J., "SMTP Service Extension for Command 738 Pipelining" Internet Draft 740 [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 741 Crocker, "SMTP Service Extensions" RFC 1651, United Nations 742 University, Innosoft International, Inc., Dover Beach Consulting, 743 Inc., Network Management Associates, Inc., The Branch Office, 744 February 1993. 746 [SIZE] Klensin, J, Freed, N., Moore, K, "SMTP Service Extensions for 747 Message Size Declaration" RFC 1653, United Nations University, 748 Innosoft International, Inc., Inc., February 1993. February 1993. 750 [8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E., D. Crocker, 751 "SMTP Service Extension for 8bit-MIMEtransport" RFC 1426, United 752 Nations University, Innosoft International, Inc., Dover Beach 753 Consulting, Inc., Network Management Associates, Inc., The Branch 754 Office, February 1993. 756 [DNS1] Mockapetris, P., "Domain names - implementation and 757 specification", RFC1035, Nov 1987. 759 [DNS2] Mockapetris, P., "Domain names - concepts and facilities", RFC 760 1034, Nov 1987. 762 [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 763 USC/Information Sciences Institute, August 1982. 765 [BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of 766 Large and Binary MIME Messages", Internet Draft 769 [NOTIFY] Vaudreuil, G., Moore, K., "An Extensible Message Format for 770 Delivery Status Notifications", Internet Draft 773 [REPORT] Vaudreuil, G., "Multipart/Report", Internet-Draft, 776 [DSN] Moore, K. "SMTP Service Extensions for Delivery Status 777 Notifications", Internet Draft . 779 [G721] CCITT Recommendation G.700-G.795 (1988), General Aspects of 780 Digital Transmission Systems, Terminal Equipment. Blue Book. 782 [MADMAN] N. Freed, S. Kille, "Mail Monitoring MIB", RFC 1566, Jan 1994. 784 [MIB II] M. Rose, "Management Information Base for Network Management 785 of TCP/IP-based internets: MIB-II", RFC 1158, May 1990. 787 8. Security Consideration 789 This document is a profile of existing Internet mail protocols. As 790 such, it does not create any security issues not already existing in 791 the profiled Internet mail protocols themselves. 793 9. Acknowledgments 795 The author would like to offer special thanks to Glenn Parsons/BNR for 796 his extensive review, helpful suggestions, and extensive editing 797 including the requirements matrix. 799 10. Author's Address 801 Gregory M. Vaudreuil 802 Octel Network Services 803 17080 Dallas Parkway 804 Dallas, TX 75248-1905 805 Phone/Fax: +1-214-733-2722 806 Greg.Vaudreuil@Octel.Com 808 11. Appendix - MIME/ESMTP Voice Profile Requirements Summary 810 | | | | |S| | 811 | | | | |H| |F 812 | | | | |O|M|o 813 | | |S| |U|U|o 814 | | |H| |L|S|t 815 | |M|O| |D|T|n 816 | |U|U|M| | |o 817 | |S|L|A|N|N|t 818 | |T|D|Y|O|O|t 819 FEATURE |SECTION | | | |T|T|e 820 -------------------------------------------|----------|-|-|-|-|-|- 821 | | | | | | | 822 Message Addressing Formats: | | | | | | | 823 Use DNS host names |4.1 |x| | | | | 824 Use only numbers in mailbox IDs |4.1 | |x| | | | 825 Use alpha-numeric mailbox IDs |4.1 | | |x| | | 826 Support of postmaster@domain |4.1 | |x| | | | 827 Support of loopback@domain |4.1 | |x| | | | 828 | | | | | | | 829 Message Header Fields: | | | | | | | 830 Encoding outbound messages | | | | | | | 831 From |4.2 |x| | | | | 832 Addition of text personal name |4.2 | |x| | | | 833 To |4.2 |x| | | | | 834 Addition of text personal name |4.2 | |x| | | | 835 CC |4.2 | | |x| | | 836 Date |4.2 |x| | | | | 837 Sender |4.2 | | | |x| | 838 Message-id |4.2 | |x| | | | 839 Received |4.2 |x| | | | | 840 MIME Version: 1.0 (Voice 1.0) |4.2 |x| | | | | 841 Content-Type |4.2 |x| | | | | 842 Content-Transfer-Encoding |4.2 |x| | | | | 843 Sensitivity |4.2 | | |x| | | 844 Importance |4.2 | | |x| | | 845 Subject |4.2 | | |x| | | 846 Detection & Decoding inbound messages | | | | | | | 847 From |4.2 |x| | | | | 848 Utilize text personal name |4.2 | |x| | | | 849 To |4.2 |x| | | | | 850 Utilize text personal name |4.2 | | |x| | | 851 CC |4.2 | | |x| | | 852 Utilize text personal name |4.2 | | |x| | | 853 Date |4.2 |x| | | | | 854 Conversion of Date to local time |4.2 | |x| | | | 855 Sender |4.2 | | | |x| | 856 Message ID |4.2 |x| | | | | 857 Received |4.2 | |x| | | | 858 MIME Version: 1.0 (Voice 1.0) |4.2 |x| | | | | 859 Content Type |4.2 |x| | | | | 860 Content-Transfer-Encoding |4.2 |x| | | | | 861 Sensitivity |4.2 |x| | | | |1 862 Importance |4.2 | | |x| | | 863 Subject |4.2 | | |x| | | 864 | | | | | | | 865 Binary Content Encoding: | | | | | | | 866 Encoding outbound messages | | | | | | | 867 7BITMIME |4.3 | | | | |x| 868 8BITMIME |4.3 | | | | |x| 869 Quoted Printable |4.3 | | | | |x| 870 Base-64 |4.3 |x| | | | |2 871 Binary |4.3 |x| | | | |3 872 Detection & decoding inbound messages | | | | | | | 873 7BITMIME |4.3 |x| | | | | 874 8BITMIME |4.3 |x| | | | | 875 Quoted Printable |4.3 |x| | | | | 876 Base-64 |4.3 |x| | | | | 877 Binary |4.3 |x| | | | | 878 | | | | | | | 879 Message Content Types: | | | | | | | 880 Inclusion in outbound messages | | | | | | | 881 Message/RFC822 |4.3 | | | |x| | 882 Text/plain |4.3 | | | | |x| 883 Multipart/Mixed |4.3 | | |x| | | 884 Message/Notification |4.3 |x| | | | | 885 Multipart/Report |4.3 |x| | | | | 886 Audio/32KADPCM |4.3 |x| | | | | 887 Audio/* (proprietary encodings) |4.3 | | |x| | | 888 Multipart/Voice-Message |4.3 |X| | | | | 889 Detection & decoding in inbound messages | | | | | | | 890 Message/RFC822 |4.3 |x| | | | | 891 Text/plain |4.3 |x| | | | | 892 Multipart/Mixed |4.3 |x| | | | | 893 Message/Notification |4.3 |x| | | | | 894 Multipart/Report |4.3 |x| | | | | 895 Audio/32KADPCM |4.3 |x| | | | | 896 Audio/* (proprietary encodings) |4.3 | | |x| | | 897 Multipart/Voice-Message |4.3 |X| | | | | 898 | | | | | | | 899 Message Transport Protocol: | | | | | | | 900 ESMTP Commands | | | | | | | 901 HELO |5.1 |x| | | | | 902 MAIL FROM |5.1 |x| | | | | 903 RCPT TO |5.1 |x| | | | | 904 DATA |5.1 |x| | | | | 905 TURN |5.1 | | | | |x| 906 QUIT |5.1 |x| | | | | 907 RSET |5.1 |x| | | | | 908 VRFY |5.1 | | |x| | | 909 EHLO |5.1 |x| | | | | 910 BDAT |5.1 | |x| | | |3 911 ESMTP Keywords | | | | | | | 912 STREAMING |5.2 | |x| | | | 913 SIZE |5.2 |x| | | | | 914 CHUNKING |5.2 | |x| | | | 915 BINARYMIME |5.2 | |x| | | | 916 NOTIFY |5.2 |x| | | | | 917 | | | | | | | 918 Management Protocols: | | | | | | | 919 Network management |6.1 | |x| | | | 920 Monitoring queues |6.2 | |x| | | | 921 -------------------------------------------|----------|-|-|-|-|-|- 923 1. If a sensitive message is received by a system that does not 924 support sensitivity, then it must be returned to the originator 925 with an appropriate error notification. 926 2. When binary transport is not available 927 3. When binary transport is available 929 12. Appendix - Example Voice Message 931 The following message is a full-featured, all-options-enabled message 932 addressed to two recipients. The message includes the sender's spoken 933 name and a short speech segment. The message is marked as important 934 and private. 936 To: 2145551212@vm1.mycompany.com 937 To: "Parsons, Glenn, W." 2145551234@VM1.mycompany.com 938 From: "Vaudreuil, Greg" 2175552345@VM2.mycompany.com 939 Date: Mon, 26 Aug 93 10:20:20 CST 940 MIME-Version: 1.0 (Voice 1.0) 941 Content-type: Multipart/Voice-Message; Boundary = "MessageBoundary" 942 Content-Transfer-Encoding: 7bit 943 Message-ID: VM2.mycompany.com-123456789 944 Sensitivity: Private 945 Importance: High 947 --MessageBoundary 948 Content-type: Audio/32KADPCM 949 Content-Transfer-Encoding: Base-64 951 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 952 (This is a sample of the base-64 Spoken Name data) fgdhgd 953 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW 954 dlkgpokpeowrit09== 956 --MessageBoundary 957 Content-type: Audio/32KADPCM 958 Content-Transfer-Encoding: Base-64 960 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 961 (This is a sample of the base-64 Spoken Subject data) fgdhgd 962 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW 963 dlkgpokpeowrit09== 965 --MessageBoundary 966 Content-type: Audio/32KADPCM 967 Content-Transfer-Encoding: Base-64 969 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 970 (This is a sample of the base-64 message data) fgdhgdfwgd 971 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW 972 dlkgpokpeowrit09== 974 --MessageBoundary-- 975 13. Appendix - Audio/32KADPCM Content Type 977 Mime type name: Audio 978 Mime Sub-Type name: 32KADPCM 979 Required Parameters: None 980 Optional Parameters: None 981 Encoding Considerations: Any encoding necessary for transport may be 982 used. 984 CCITT Recommendation G.721 [G721] describes the algorithm recommended 985 for conversion of a 64 KB/s A-law or u-law PCM channel to and from a 986 32 KB/s channel. The conversion is applied to the PCM stream using an 987 Adaptive Differential Pulse Code Modulation (ADPCM) transcoding 988 technique. 990 No header information shall be included before the audio data. When 991 this subtype is present, a sample rate of 8000 Hz and a single channel 992 is assumed. 994 13. Appendix - Multipart/Voice-Message 996 Mime type name: Multipart 997 Mime Sub-Type name: Voice-Message 998 Required Parameters: Boundary 999 Optional Parameters: None 1000 Encoding Considerations: Binary of 7 bit are sufficient. Base-64 and 1001 Quoted-Printable are prohibited on multipart content-types. 1003 The syntax of a Multipart/Voice-Message is identical to the 1004 Multipart/Mixed content type. The Voice-Message content-type contains 1005 three body parts. The first is an audio segment containing the spoken 1006 name of the originator, the second is an audio segment containing a 1007 spoken subject, and the third is the voice message itself. Forwarded 1008 voice messages can be created by simply nesting multipart content 1009 types. 1011 The spoken name segment shall contain the name of the message sender 1012 in the voice of the sender. The length of the spoken name segment 1013 must not exceed 12 seconds. If no spoken name is available, the 1014 segment must still be present but may be empty. 1016 The spoken subject segment shall contain the subject of the message 1017 sender in the voice of the sender. The length of the spoken subject 1018 segment must not exceed 20 seconds. If no spoken subject segment is 1019 available, the segment must still be present but may be empty. 1021 The voice message body part may contain any arbitrary content 1022 including a multipart/mixed collections of body parts, though will 1023 typically be an audio segment. 1025 The default handling of the Multipart/Voice-Message shall be to voice 1026 the spoken-name segment and then the spoken-subject prior to 1027 displaying or voicing the remainder of the message.