idnits 2.17.1 draft-umig-mime-voice-00.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-04-25) 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 document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** 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 18 longer pages, the longest (page 2) being 61 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** 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 an Authors' Addresses Section. ** There are 177 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 (April 25, 1994) is 10958 days in the past. Is this intentional? 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 section? 'RFC-MIME' on line 402 looks like a reference -- Missing reference section? 'MSG' on line 732 looks like a reference Summary: 15 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Greg Vaudreuil 2 Internet Draft Tigon Corporation 3 Expires: 10/25/94 April 25, 1994 5 MIME/ESMTP Profile for 6 Voice Messaging 8 10 ToDo: 12 1) Fix Bibliography, Make References in Text 14 Status of this Memo 16 This document is an Internet Draft. Internet Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its 18 Areas, and its Working Groups. Note that other groups may also 19 distribute working documents as Internet Drafts. 21 Internet Drafts are valid for a maximum of six months and may be 22 updated, replaced, or obsoleted by other documents at any time. 23 It is inappropriate to use Internet Drafts as reference material 24 or to cite them other than as a "work in progress". 26 1.Abstract 28 A class of special purpose computers have evolved to provide 29 voice messaging services. These machines generally interface to 30 a telephone switch and provide call answering and voice messaging 31 services. Traditionally messages sent to a non-local machine are 32 transported using analog networking protocols based on DTMF 33 signaling and analog voice playback. As the demand for 34 networking increases, there is a need for a standard high quality 35 digital protocol to interconnect these machines. 37 The following document is a profile of the Internet standard MIME 38 and EXMTP protocols for use as a digital voice networking 39 protocol. This profile is based on an earlier effort in the 40 Audio Message Interchange Specification (AMIS) group to define a 41 voice messaging protocol based on X.400 technology. This 42 protocol is intended to satisfy the user requirements statement 43 from that earlier work with the industry standard ESMTP/MIME mail 44 protocol infrastructures already used within corporate internets. 45 This profile will be called the voice profile in this document. 47 2.Scope and Design Goals 49 MIME is the Internet multipurpose, multimedia messaging standard. 50 This document explicitly recognizes these capabilities and 51 provides a mechanism for the exchange of various messaging 52 technologies including voice and facsimile. 54 It is not a goal to make the interoperation of the earlier X.400 55 based AMIS-Digital and this profile possible by the use of a 56 standard X.400 to MIME gateway. While the message encodings and 57 messages semantics are similar, the addressing and routing are 58 sufficiently customized that it cannot be mapped to the RFC 822 59 mail format in the standard manner. The voice profile is 60 necessarily incompatible because it is intended to use the 61 standard TCP/IP mail addressing formats. 63 It is a goal of this effort to make as few protocol changes to 64 the existing Internet mail protocols as possible while satisfying 65 the user requirements for Voice Networking. This goal is 66 motivated by the desire to increase the accessibility to digital 67 messaging by enabling the use of proven existing networking 68 software for rapid development. Using the native capabilities of 69 the internet mail system most user requirements listed in the 70 appendix can be met. 72 This specification is intended for use on a TCP/IP network. 73 While it is possible to use these protocols for simple point to 74 point networking, the specification is robust enough to be used 75 in an environment such as the global Internet with installed base 76 gateways which do not understand MIME. It is expected that a 77 messaging system will be managed by a system administrator who 78 can perform TCP/IP network configuration. When using facsimile 79 or multiple voice encodings, it is expected that the system 80 administrator will maintain a list of the capabilities of the 81 networked mail machines to reduce the sending of undeliverable 82 messages due to lack of feature support. 84 This specification is a profile of the relevant TCP/IP Internet 85 protocols. These technologies, as well as the specifications for 86 the internet mail protocols are defined in the Request for 87 Comment (RFC) document series. This series documents the 88 standards as well as the lore of the TCP/IP protocol suite. This 89 document should be read with the following RFC documents: RFC 90 821, the Simple Mail Transport Protocol, RFC 822, the Standard 91 for the format of ARPA Internet Messages, RFC 1521 and RFC 1522, 92 the Multipurpose Internet Mail Extensions, RFC 1425 and RFC 1427, 93 Extensions to the SMTP protocol (ESMTP), and RFC 882 and RFC 883, 94 the Domain Name System. Where additional functionality is 95 needed, it will be defined in this document or in an appendix. 97 3.Protocol Restrictions 99 The number of recipients per message is not limited by this 100 protocol. Where possible implementations should not restrict the 101 number of recipients that can be received in a single message. 103 The maximum message length is not limited by this protocol. 104 Implementors should understand that some machines will be unable 105 to accept excessively long messages. A mechanism is defined in 106 the RFC 1425 ESMTP extensions to declare the maximum message size 107 supported. (Units are in bytes, not minutes which can vary by 108 encoding format.) 110 4.Framework for the voice profile 111 This document specifies a profile of the TCP/IP multi-media 112 messaging protocols for use by special purpose voice processing 113 platforms. These platforms are not general purpose computers and 114 often do not have facilities normally associated with an Internet 115 Email capable computer. 117 The following are typical restrictions imposed by a voice 118 messaging platform. 120 1) Text messages are not normally received and often cannot be 121 displayed or viewed in the normal fashion. They can be 122 processed only via advanced text-to-speech or text-to-fax 123 features not currently present in these machines. 125 2) Voice mail machines act as an integrated Message Transfer 126 Agent and a User Agent. The VM is responsible for final 127 delivery and there is no forwarding of messages. RFC 822 128 header fields have limited use in the context of the simple 129 messaging features currently deployed. 131 3) Voice mail message stores are generally not capable of 132 preserving the full semantics of an Internet Message. As 133 such, use of a VM for general message forwarding and 134 gatewaying is not supported. Storage of Received lines and 135 Message-ID may be be limited. 137 4) Internet style mailing lists are not generally supported. 138 Distribution lists are implemented as local alias lists. 140 5) There is generally no human operator. Error reports must be 141 machine parsable so helpful responses can be given to users 142 whose only access mechanism is voice. 144 6) The system user names are limited to 16 or fewer numeric 145 characters. 147 5.Message Format Profile 149 The voice profile was written to be based on and be consistent 150 with the TCP/IP Protocol Suite as amended to support specific 151 services not provided in the TCP/IP protocol suite. This section 152 is intended to be an overview of the necessary protocols and a 153 profile of the applicable protocols as applied to the voice 154 messaging environment. 156 5.1. Message Addressing Formats 158 RFC 822 and SMTP addressing use the domain name system. This 159 naming system has two components, the local part, used for 160 username or mailbox identification and the host part, used for 161 machine or node identification. These two components are 162 separated by the commercial @ symbol. 164 The local part is an ASCII string uniquely identifying a mailbox 165 on a destination system. It is required to be unique with the 166 system of networked voice mail machines. The local part is 167 defined to be a printable string containing the mailbox number of 168 the originator or a recipient. Administration of this number 169 space is expected to be conformant with national or corporate 170 telephone numbering plans. 172 The domain part of the address is a hierarchical global name for 173 all machines. In the domain name system, a name is registered 174 with the Internet Assigned Number Authority (IANA). The IANA may 175 delegate the management of a branch of the naming space to be 176 administered by a company or service provider. For participation 177 in the international Internet network, or for integration within 178 a corporate internet, each voice mail (VM) machine is required to 179 be given a unique domain name. 181 For example, a compliant message may be 2145551212@mycompany.com. 182 It should be noted that while the example mailbox address is 183 based on the North American Numbering Plan any other corporate 184 numbering plan can be used. The use of the domain naming system 185 should be transparent to the user. It is the responsibility of 186 the VM to translate the dialed address to the fully qualified 187 domain name (FQDN). The mapping of dialed address to VM 188 destination is generally accomplished through implementation 189 specific means. 191 Mapping of the FQDN to a specific network destination is 192 generally performed by the Domain Name System. For networks with 193 a small number of machines, the use of a locally maintained host 194 table database can be used as a simpler alternative. 196 Special addresses are provided for compatibility with the 197 conventions of the Internet mail system and to facilitate 198 testing. These addresses do not use numeric local addresses both 199 to conform to current Internet practice and to avoid conflict 200 with existing numeric addressing plans. 202 Postmaster@domain 204 By convention, a special mailbox named postmaster 205 should exist on all systems. This address is used 206 for diagnostics and should be checked regularly by 207 the system manager. This mailbox is particularly 208 likely to receive text messages. This is not normal 209 on a voice processing platform and the specific 210 handling of these messages is up to specific 211 implementation. 213 Loopback@domain 215 A special mailbox name named "loopback" should be 216 designated for loopback testing. All messages sent 217 to this mailbox must be returned back to the sender 218 address. Because VMs do not use alpha-numeric 219 addresses, this will not conflict with any internal 220 numbering plan. Internal to VM, a specific numeric 221 address for DTMF entry can be mapped to "loopback". 223 Note that the loopback address can be abused to 224 route messages through a third party VM to avoid 225 toll charges. It is recommended that the loopback 226 feature be disabled except when testing the 227 networking between machines. 229 5.2. Message Header Fields 231 Internet messages contain a header information block. This 232 header block contains information required to identify the 233 sender, the list of recipients, the message send time and other 234 information intended for user presentation. Except for 235 specialized gateway and mailing list cases, headers are not used 236 to indicate delivery options for the transport of messages. 238 RFC 822 defines a set of standard message header fields. This 239 set is extended in several RFCs. 241 Note that the specific order of header lines is not specified. 242 The order cannot be expected to be preserved when sent through 243 intermediate gateways. The following header fields must be 244 supported. 246 From 248 The originators fully qualified domain address. 249 (This is a mailbox number followed by the fully 250 qualified domain name.) The user listed in this 251 field should be presented in the voice message 252 envelope as the originator of the message. 254 Example: 2145551212@mycompany.com 255 To 257 The recipient's fully qualified domain address. 258 There may be one or more To: fields in any message. 259 All recipients of a message must be listed in To 260 lines except when a recipient is specifically 261 intended to receive a blind carbon copy. Note that 262 many voice mail systems have no facilities for 263 storing or for reporting to the recipient the list 264 of recipients. These systems will generally discard 265 these headers when received. 267 It is recommended that all messages contain the text 268 personal name of the sender and the personal name of 269 the recipient in comment fields if available. 271 Cc 273 Additional recipients fully qualified domain 274 address. This field has no meaning beyond "To:" in 275 a VM and is not to be generated by an conforming 276 implementation. It is included for processing by the 277 receiver for compatibility with general Internet 278 mail agents which may not restrict the use of this 279 field. 281 If the VM supports the reporting of multiple 282 recipients, all names in the To: and Cc: fields 283 should be reported. 285 Date 287 The date, time, and time zone the message was 288 composed by the originator or the time specified by 289 the originator if the message is scheduled for 290 delayed delivery. Conforming implementations must 291 be able to convert RFC 822 date and time stamps into 292 local time. If the VM reports message sent time, 293 the value in this field should be used, not the time 294 the message was received at the destination system. 296 Example: Wed, 28 Jul 93 10:08:49 PDT 298 Sender 300 The actual address of the originator if the message 301 is sent by an agent on behalf of the author 302 indicated in the From: field.. This field is not to 303 be generated by an conforming implementation. It is 304 included for processing by the receiver for 305 compatibility with general internet mail software 306 which may generate this header. 308 The sender field often contains the name of a 309 Internet style mailing list administrator and is the 310 address to report errors in the event that the ESMTP 311 MAIL FROM address is not available. While it may 312 not be possible to save this information in some 313 Voice Mail machines, discarding this information or 314 the SMTP MAIL FROM address will make it difficuly to 315 send a error message to the proper destination. 317 Message-id 319 A unique per-message identifier must be included by 320 the originator for every message. Conforming systems 321 must use an identifier constructed by concatenating 322 with a dash the sending VMs FQDN and a 8 digit 323 serial message number which is unique on the sending 324 system. This identifier will be used for tracking, 325 auditing, and returning delivery reports. 327 Example: mycompany.com-12345678 329 Received 331 Received headers are special purpose trace 332 information added to the beginning of a RFC 822 333 message by message transport agents. This is the 334 only header which is permitted to be added by a MTA. 335 These headers are useful for debugging when using an 336 ASCII message reader or a header parsing tool. A 337 conforming system must add received headers when 338 acting as a gateway. These headers must not be 339 removed by a system when acting as a gateway. These 340 headers may be ignored or deleted when the message 341 is received at the final destination. 343 MIME Version 345 The Mime-Version: 1.0 header indicates that the 346 message is conformant to the RFC 1341 message format 347 specification. It must be present in any conforming 348 message. From RFC 1341 350 Content-Type 352 The content-type header declares the type of content 353 enclosed in the message. One of the allowable 354 contents is multipart, a mechanism for bundling 355 several message components into a single message. 356 The allowable contents are specified in the next 357 section. From RFC 1341 359 Content-Transfer-Encoding 360 Because Internet mail was initially specified to 361 carry only 7 bit US-ASCII text, it may be necessary 362 to encode voice and fax data into a representation 363 suitable for this environment. The content- 364 transfer-encoding header describes this 365 transformation if needed. From RFC 1341 367 Sensitivity 369 This field indicates the requested privacy. If this 370 field exists, regardless of the selected case 371 insensitive value "Personal" or "Private". If no 372 privacy is requested, this field is omitted. 374 If a sensitivity header is present in the message, 375 an conformant system is prohibited from forwarding 376 this message. If the receiving system does not 377 support privacy, and the sensitivity is one of 378 "Personal" or "Private", the message must be 379 returned to the sender with an appropriate error 380 message indicating that privacy could not be assured 381 and the message was not delivered. 383 The specific privacy values do not need to be 384 offered individually to users, but can be set on a 385 system wide basis. 387 Importance 389 This field indicates the requested priority to be 390 given by the receiving system. The case insensitive 391 values "low", "normal" and "high" are specified. If 392 no special importance is requested, this header may 393 be omitted and the value assumed to be "normal". 394 This field can be used to order messages in a 395 recipients mailbox and is equivalent to the AMIS 396 Priority indication. 398 5.3. Message Content Types 400 MIME is a general purpose message body format that is extensible 401 to carry a wide range of body parts. The basic protocol is 402 described in [RFC-MIME]. MIME also provides for encoding binary 403 data in such a manner that it can be transported over the 7 bit 404 text oriented SMTP protocol. This transport encoding is 405 independent of the audio encoding that is designed to generate a 406 binary object. 408 MIME defined two transport encoding mechanisms, one designed for 409 text-like data, "Quoted-Printable", and one for arbitrary binary 410 data, "Base-64". While base-64 is dramatically more efficient 411 for audio data, both will work. A null encoding of "Binary" was 412 specified for use in an environment where binary transport is 413 available. 415 An implementation in conformance with this profile is required to 416 send audio data encoded as binary where binary message transport 417 is available. Where binary transport is not available, 418 implementations must encode the message as Base-64. As required 419 by MIME, and to preserve interoperability with the fullest range 420 of possible devices, the detection of and decoding of quoted- 421 printable must also be supported. 423 The following content-types are profiled. Note that each of 424 these contents can be sent individually in a message or wrapped 425 in a multipart message to send multi-segment messages. 427 The following content types are identified for use with this 428 profile. 430 Audio/Basic(RECOMMENDED) 432 Audio/Basic was defined as 64Kbps u-law in the base 433 MIME protocol document. Support of Audio/Basic is 434 recommended for compatibility with current Internet 435 workstations but not required for conformance with 436 this profile. 438 Message/RFC822 (REQUIRED) 440 MIME requires support of the Message/RFC822 message 441 encapsulation body part. This body part is used in 442 the internet for forwarding complete messages within 443 a multipart/mixed message. Processing of this body 444 part entails trivial processing to unencapsulate- 445 encapsulate the message. It is not to be sent by a 446 system conformant to this profile but must be 447 accepted for conformance with basic MIME. 449 Text/Plain (REQUIRED) 451 MIME requires support of the basic text/plain 452 content type. This content has no applicability 453 within the voice messaging environment and should 454 not be sent. Behavior upon receipt of such a type 455 is dependent upon the platform and interpretation of 456 such a part is left as an implementation decision. 457 Options include dropping the body part and sending a 458 delivery report indicating the lack of support, 459 text-to-speech, and text-to-fax support. 461 Multipart/Mixed (REQUIRED) 463 MIME provides the facilities for enclosing several 464 body parts in a single message. Multipart/Mixed may 465 be used for sending multi-segment voice messages, 466 that is, to preserve across the network the 467 distinction between an annotation and a forwarded 468 message. Systems are permitted to collapse such a 469 multi-segnemt message into a single segment if they 470 are not supported on the receiving machine. 472 Text/Signature (RECOMMENDED) 474 Text/Signature provides a mechanism for the sending 475 of per-user directory information including the 476 spoken name and the supported mailbox capabilities. 477 When used with a caching mechanism, basic directory 478 services with entries for commonly used entries can 479 be maintained. This body part is to be used to 480 support spoken name confirmation and ASCII name for 481 dial-by-name applications. The Text/Signature can 482 be included with a message using the multipart/mixed 483 constructor type. From 491 Multipart/Notification (REQUIRED) 493 The Multipart/Delivery-Notification is used for 494 enclosing a text/delivery-notification body part and 495 any returned message content. This body type is a 496 companion to and is defined with the text/delivery- 497 report. Systems may optionally send a text 498 description 500 Audio/ADPCM (REQUIRED) 502 CCITT Draft Recommendation G.721 describes the 503 algorithm recommended for conversion of a 64 KB/s A- 504 law or -law PCM channel to and from a 32 KB/s 505 channel. The conversion is applied to the PCM 506 stream using an Adaptive Differential Pulse Code 507 Modulation (ADPCM) transcoding technique. This 508 algorithm will be registered with the Internet 509 Assigned Numbers Authority for MIME use under the 510 name Audio/ADPCM. 512 ADPCM is widely available. Support of Audio/ADPCM is 513 required for conformance with this profile. 515 Proprietary Voice Formats (OPTIONAL) 517 Proprietary voice encoding formats are supported 518 under this profile provided a unique identifier is 519 registered with the IANA prior to use. 521 Note that use of proprietary encodings reduces 522 interoperability in the absence of system 523 configuration. 525 6.Message Transport Protocol (ESMTP) 527 Messages are transported using the Internet Extended Simple Mail 528 Transport Protocol. This protocol is used to send messages 529 between voice mail machines. All information required for proper 530 delivery of the message is included in the ESMTP dialog. This 531 information, including the sender and recipient addresses is 532 commonly referred to as the message "envelope". This information 533 is equivalent to the message control block in many analog voice 534 networking protocols. 536 ESMTP is a general purpose messaging protocol, designed both to 537 send mail and to allow terminal console messaging. SMTP was 538 originally created for the exchange of US-ASCII 7 bit text 539 messages. Binary and 8 bit text messages have traditionally been 540 transported by encoding the messages into a 7 bit text-like form. 541 RFC 1425 was recently published and formalized an extension 542 mechanism for SMTP and subsequent RFCs have defined 8 bit text 543 networking and extensions to permit the declaration of message 544 size for the efficient transmission of large messages such as 545 multi-minute voice mail. 547 Binary transport is currently under development in the IETF. 548 When completed, the binary extensions to ESMTP will be required 549 for conformance with this profile. The current version of this 550 protocol is available in the public Internet Drafts directories 551 in the file 553 A command streaming extension for high performance message 554 transmission is under development in the IETF. This extension 555 reduced the number of round trip packet exchanges and makes it 556 possible to validate all recipient addresses in one operation. 557 This extension is optional but recommended. This document is 558 available in the public Internet Draft directories in the file 559 561 The following ESMTP commands may be supported. 563 6.1. ESMTP Commands 565 HELO (REQUIRED) 567 Base SMTP greeting and identification of sender. 568 This is not to be sent by conforming systems unless 569 the more capable EHLO command is not accepted. It 570 is included for compatibility with general SMTP 571 implementations. 573 MAIL FROM (REQUIRED) 575 Originating mailbox. This address contains the 576 mailbox to which errors should be sent. This 577 address may not be the same as the message sender 578 listed in the message header fields in the event 579 that the message was gatewayed or sent to a Internet 580 style mailing list. 582 RCPT TO (REQUIRED) 584 Recipients Mailbox. This field contains only the 585 addresses to which the message should be delivered 586 for this transaction. In the event that multiple 587 transport connections to multiple destination 588 machines are required for the same message, this 589 list may not match the list of recipients in the 590 message header. 592 DATA (REQUIRED) 594 The command to initiate the transfer of message 595 data. This command is required to be supported but 596 should only be used in the event the binary mode 597 command BDAT is not supported. 599 TURN (RECOMMENDED) 601 The turn command requests a change-of-roles, that 602 is, the client which opened the connection offers to 603 assume the role of server for any mail the remote 604 machine may which to send. This is useful to poll 605 for messages. 607 (Note the security implications of using the turn 608 command to fetch mail queued for another 609 destination. This is possible due the lack of 610 authentication of the sending VM by the protocol) 612 QUIT (REQUIRED) 614 QUIT requests that the connection be closed. If 615 accepted, the remote machine will reset and close 616 the connection. 618 RSET (REQUIRED) 620 Reset the connection to the initial state. 622 VRFY (OPTIONAL) 624 The VRFY command requests verification that the 625 listed recipient is reachable by this node. While 626 this functionality is also included in the RCPT TO 627 command, VRFY allows the query without beginning a 628 mail transfer transaction. This command is useful 629 for debugging and tracing problems. 631 (Note that the implementation may simplify the 632 guessing of a recipients mailbox or automated sweeps 633 for valid mailbox addresses resupting in a possible 634 reduction in privacy. Various implementation 635 techniques may be used to reduce the threat such as 636 limiting the number of queries per session.) 638 EHLO (REQUIRED) 640 EHLO is an enhanced mail greeting which enables a 641 server to announce the support for extended 642 messaging options. The extended messaging modes are 643 discussed in a later section. 645 BDAT (REQUIRED) 647 Initiate binary data transmission 649 The BDAT command is an alternative to the earlier 650 DATA command. The BDAT command does not require 651 encoding voice data into 7 bit line limited formats. 652 654 All other commands must be recognized and an appropriate error 655 code returned if not supported. 657 6.2. ESMTP Keywords 659 STREAMING (Optional) 661 The streaming keyword indicates the ability of the 662 receiving SMTP to accept pipelined SMTP commands. 663 (from Internet Draft 665 SIZE (Required) 667 The size indication provides a mechanism by which 668 the receiving SMTP can indicate the maximum size 669 message supported. (from RFC 1427) 671 CHUNKING (Required) 673 The chunking keyword indicates that the receiver 674 will support the high performance binary transport 675 mode. - Note that CHUNKING can be used with any 676 message format and does not imply support for binary 677 encoded messages. (from Internet-Draft 680 BINARYMIME (Required) 682 The binarymime keyword indicates that the receiver 683 SMTP can accept binary encoded MIME messages. Note 684 that CHUNKING mode must be supported for this 685 option, but that CHUNKING does not mean that binary 686 messages can be supported. (from Internet-Draft 687 689 6.3. ESMTP Parameters - MAIL FROM 691 BINARYMIME The binarymime parameter indicates that the current 692 message is a binary encoded MIME messages. 694 6.4. ESMTP Parameters - RCPT TO 696 NOTIFY The notify parameter specifies the conditions under 697 which a delivery report should be sent. From 700 RET The ret parameter indicates whether the content of 701 the message should be returned. From 704 PRIORITY This parameter indicates the requested priority to 705 be given by the transmission network. From 707 7.Management Protocols 709 The Internet protocols provide a mechanism for the management of 710 voice mail machines, from the management of the physical network 711 through the management of the message queues. SNMP should be 712 supported on a compliant message machine. 714 The digital interface to the VM and the TCP/IP protocols should 715 be managed. MIB II provides basic statistics and reporting of 716 the TCP/IP protocol performance and statistics. Media specific 717 MIBS are available for X.25, Ethernet, FDDI, Token Ring, Frame 718 Relay and other network technologies. This MIB provides 719 necessary information to diagnose faulty hardware, overloaded 720 network conditions, and excessive traffic conditions from a 721 remote management station. 723 Management of the machine resources and message queue monitoring 724 based on the host MIB and the Message and Directory MIB is 725 recommended but not required for conformance with this profile. 727 8.References 729 [MIME]Borenstein, N., and N. Freed, "Multipurpose Internet Mail 730 Extensions", RFC 1521, Bellcore, Innosoft, Sept 1993. 732 [MSG] Crocker, D., "Standard for the Format of ARPA Internet 733 Text Messages", STD 11, RFC 822, UDEL, August 1982. 735 3. Freed, N., "SMTP Service Extension for Command Pipelining" 736 Internet Draft Work in Progress - 10/19/93. 738 4. Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. 739 Crocker, "SMTP Service Extensions" RFC 1425, United Nations 740 University, Innosoft International, Inc., Dover Beach Consulting, 741 Inc., Network Management Associates, Inc., The Branch Office, 742 February 1993. 744 5. Klensin, J, Freed, N., Moore, K, "SMTP Service Extensions 745 for Message Size Declaration" RFC 1427, United Nations 746 University, Innosoft International, Inc., Inc., February 1993. 747 February 1993 749 6. Klensin, J., Freed, N., Rose, M., Stefferud, E., D. 750 Crocker, "SMTP Service Extension for 8bit-MIMEtransport" RFC 751 1426, United Nations University, Innosoft International, Inc., 752 Dover Beach Consulting, Inc., Network Management Associates, 753 Inc., The Branch Office, February 1993. 755 7. Mockapetris, P.,"Domain names - implementation and 756 specification", RFC1035, Nov 1987. 758 8. Mockapetris, P.,"Domain names - concepts and facilities", 759 RFC 1034, Nov 1987. 761 9. Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 762 821, USC/Information Sciences Institute, August 1982. 764 10. Vaudreuil, G., "Text/Signature", Internet Draft Work-in- 765 Progress - 11/22/93. 767 11. Vaudreuil, G., "SMTP Service Extensions for Transmission 768 of Large and Binary MIME Messages", Internet Draft Work-in- 769 Progress - 11/10/93. 771 12. Vaudreuil, G., "An Extensible Message Format for Delivery 772 Status Notifications", Internet Draft Work-in-Progress - 773 11/22/93. 775 9.Security Consideration 776 10. Author's Address 778 Gregory M. Vaudreuil 779 The Tigon Corporation 780 17080 Dallas Parkway 781 Dallas, TX 75248-1905 782 214-733-2722 783 Gvaudre@cnri.reston.va.us 784 11. Appendix - Example Voice Message 786 The following message is a full featured, all options enabled 787 message. It is addressed to two receipients. The message includes 788 the senders spoken name and a short speach segment. The message 789 is marked as important and private. read receipts and positive 790 delivery acknowledgement are requested. 792 To: 2145551212@vm1.mycompany.com 793 To: 2145551234@mv1.mycompany.com 794 From: 2175552345@VM2.mycompany.com 795 Date: Mon, 26 Aug 93 10:20:20 CST 796 MIME-Version: 1.0 (Voice Profile Version 1) 797 Content-type: Multipart/Mixed; Boundary = "MessageBoundary" 798 Content-Transfer-Encoding: 7bit 799 Return-content: Full 800 Message-ID: VM1.mycompany.co-123456789 801 Sensitivity: Private-if-Possible 802 Generate-Receipt-Notification: 803 Generate-Delivery-Notification: 804 Importance: High 806 --MessageBoundary 807 Content-type: Text/Signature 809 Name: User, Joe, R. (Joe Random User) 810 SpokenName: lslfdslsertiflkTfpgkTportrpkTpfgTpoiTpssdasddasdasd 811 (This is the base-64 encoded spoken name) 812 o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90geQ5tkjpokfgW 813 dlkgpokpeowrit09IpokporkgwI== 814 Capabilities: Audio/Basic, Audio/ADPCM, Application/Signature, 815 Image/G3Fax 817 --MessageBoundary 818 Content-type: Audio/ADPCM 819 Content-Transfer-Encoding: Base-64 821 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 822 (This is a sample of the base-64 message data) fgdhgdfgd 823 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW 824 dlkgpokpeowrit09== 826 --MessageBoundary-- 827 12. Appendix - Example ESMTP Transaction 829 The following ESMTP transaction represents the successful sending 830 of a simple message to a system which does not support extended 831 transport modes. Non-ESMTP protocol events are noted in Italics. 832 ESMTP commands and significant significant replies are in Bold. 833 Except for the replies to the EHLO command, the text following 834 the reply code is optional. 836 Sender Receipient 837 Wait for TCP 838 Connection 839 Initiate TCP Connection to Port 25 840 Accept TCP 841 Connection 842 220 ready 843 EHLO vm1.mycompany.com 844 250-hello 845 250 SIZE 100000 846 MAIL FROM: <2145551212@vm1.some.com> 847 250 Address OK 848 RCPT TO: <2145551234@vm2.some.com> 849 250 Address OK 850 DATA 851 354 Send Message 852 To: 2135551234@vm2.some.com 853 From: 2145551212@vm1.some.com 854 MIME-Version: 1.0 855 Content-Type: Audio/ADPCM 856 Content-Transfer-Encoding: Base64 858 JFsdfjlkdjflkjsd lfflskjslkfjslfkjlsk 859 ksdjlksjlfksjflkjsljsldkfjlskfjlskjff 860 lkjsdlkfjslkdjflskksjfsdfsdf= 861 . 863 250 OK 864 QUIT 865 250 Goodby 866 Receiver closes TCP 867 connection