idnits 2.17.1 draft-umig-mime-voice-01.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-24) 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 15 longer pages, the longest (page 1) being 411 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.) ** There are 428 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 73 has weird spacing: '... as few chang...' == Line 349 has weird spacing: '... as few chang...' == Line 527 has weird spacing: '... do not indic...' -- 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 (January 26, 1995) is 10681 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? '822' on line 630 looks like a reference -- Missing reference section? 'MIME' on line 979 looks like a reference -- Missing reference section? 'X400' on line 985 looks like a reference -- Missing reference section? 'SIG' on line 1016 looks like a reference -- Missing reference section? 'NOTIFY' on line 1023 looks like a reference -- Missing reference section? 'NOTIFY2' on line 1027 looks like a reference -- Missing reference section? 'ESMTP' on line 991 looks like a reference -- Missing reference section? 'PIPE' on line 988 looks like a reference -- Missing reference section? 'SMTP' on line 1013 looks like a reference -- Missing reference section? 'BIN' on line 1019 looks like a reference -- Missing reference section? 'SIZE' on line 997 looks like a reference -- Missing reference section? 'DSN' on line 1030 looks like a reference -- Missing reference section? 'MSG822' on line 982 looks like a reference -- Missing reference section? '8BIT' on line 1001 looks like a reference -- Missing reference section? 'DNS1' on line 1007 looks like a reference -- Missing reference section? 'DNS2' on line 1010 looks like a reference Summary: 14 errors (**), 0 flaws (~~), 5 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Greg Vaudreuil 2 Internet Draft Octel Network Services 3 Expires: May 1, 1995 January 26, 1995 5 MIME/ESMTP Profile for 6 Voice Messaging 8 10 Changes From the previous version 12 1) A large number of textual clarifications were made, including 13 discussion of X.440. 15 2) The reference section was updated. 17 3) Examples were fixed to reflect the current text. 19 Status of this Memo 21 This document is an Internet Draft. Internet Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its 23 Areas, and its Working Groups. Note that other groups may also 24 distribute working documents as Internet Drafts. 26 Internet Drafts are valid for a maximum of six months and may be 27 updated, replaced, or obsoleted by other documents at any time. 28 It is inappropriate to use Internet Drafts as reference material 29 or to cite them other than as a "work in progress". 31 1.Abstract 33 A class of special-purpose computers has evolved to provide voice 34 messaging services. These machines generally interface to a 35 telephone switch and provide call answering and voice messaging 36 services. Traditionally, messages sent to a non-local machine 37 are transported using analog networking protocols based on DTMF 38 signaling and analog voice playback. As the demand for 39 networking increases, there is a need for a standard high-quality 40 digital protocol to connect these machines. The following 41 document is a profile of the Internet standard MIME and ESMTP 42 protocols for use as a digital voice networking protocol. 44 This profile is based on an earlier effort in the Audio Message 45 Interchange Specification (AMIS) group to define a voice 46 messaging protocol based on X.400 technology. This protocol is 47 intended to satisfy the user requirements statement from that 48 earlier work with the industry standard ESMTP/MIME mail protocol 49 infrastructures already used within corporate internets. This 50 profile will be called the voice profile in this document. 52 2.Scope and Design Goals 54 MIME is the Internet multipurpose, multimedia messaging standard. 55 This document explicitly recognizes its capabilities and provides 56 a mechanism for the exchange of various messaging technologies 57 including voice and facsimile. 59 It is not a goal to make interoperability possible between the 60 earlier X.400-based AMIS-Digital and this profile using a 61 standard X.400-to-MIME gateway. While the message encodings and 62 messages semantics are similar, the addressing and routing are 63 not. The X.400-based AMIS-Digital addressing format is 64 sufficiently customized so that it cannot be mapped to the RFC 65 822 mail format in the standard manner. The voice profile is 66 necessarily incompatible because it is intended to use the 67 standard TCP/IP mail addressing formats. 69 Because the 1988 X.400 based X.440 does not restrict the range of 70 addressing possible in X.400, translation to this protocol should 71 be possible using the standard X.400 to MIME gateway. 73 It is a goal of this effort to make as few changes to the 74 existing Internet mail protocols as possible while satisfying the 75 user requirements for Voice Networking. This goal is motivated 76 by the desire to increase the accessibility to digital messaging 77 by enabling the use of proven existing networking software for 78 rapid development. 80 This specification is intended for use on a TCP/IP network. 81 While it is possible to use these protocols for simple point-to- 82 point networking, the specification is robust enough to be used 83 in an environment such as the global Internet with installed base 84 gateways which do not understand MIME. It is expected that a 85 messaging system will be managed by a system administrator who 86 can perform TCP/IP network configuration. When using facsimile 87 or multiple voice encodings, it is expected that the system 88 administrator will maintain a list of the capabilities of the 89 networked mail machines to reduce the sending of undeliverable 90 messages due to lack of feature support. 92 This specification is a profile of the relevant TCP/IP Internet 93 protocols. These technologies, as well as the specifications for 94 the Internet mail protocols, are defined in the Request for 95 Comment (RFC) document series. That series documents the 96 standards as well as the lore of the TCP/IP protocol suite. This 97 document should be read with the following RFC documents: RFC 98 821, the Simple Mail Transport Protocol; RFC 822, the Standard 99 for the format of ARPA Internet Messages; RFC 1521 and RFC 1522, 100 the Multipurpose Internet Mail Extensions; RFC 1425 and RFC 1427, 101 Extensions to the SMTP protocol (ESMTP); and RFC 882 and RFC 883, 102 the Domain Name System. Where additional functionality is 103 needed, it will be defined in this document or in an appendix. 105 Vaudreuil Expires 5/1/95 ] 106 3.Protocol Restrictions 108 This protocol does not limit the number of recipients per 109 message. Where possible, implementations should not restrict the 110 number of recipients in a single message. 112 Recognising that no implementation supports unlimited 113 recipients, and that the number of supported recipients may 114 be quite low, ESMTP should be extended to provide a 115 mechanism for indicating the number of supported recipients. 117 This protocol does not limit the maximum message length. 118 Implementors should understand that some machines will be unable 119 to accept excessively long messages. A mechanism is defined in 120 the RFC 1425 ESMTP extensions to declare the maximum message size 121 supported. 123 The message size indicatd in the ESMTP SIZE command is in 124 bytes, not minutes. The number of bytes varies by voice 125 encoding format and must include the MIME wrapper overhead. 126 Translation into minutes, can be performed by simple 127 multiplication if the voice encoding is know from the system 128 configuration file. 130 Framework for the voice profile 132 This document specifies a profile of the TCP/IP multimedia 133 messaging protocols for use by special-purpose voice processing 134 platforms. These platforms are not general-purpose computers and 135 often do not have facilities normally associated with an Internet 136 Email-capable computer. 138 The following are typical restrictions imposed by a voice 139 messaging platform: 141 1) Text messages are not normally received and often cannot be 142 displayed or viewed in the normal fashion. They can be 143 processed only via advanced text-to-speech or text-to-fax 144 features not currently present in these machines. 146 Voice mail (VM) machines act as an integr 147 Transfer Agent and a User Agent. The VM is responsible for 148 final delivery, and there is no forwarding of messages. RFC 149 822 header fields have limited use in the context of the 150 simple messaging features currently deployed. 152 3) VM message stores are generally not capable of preserving the 153 full semantics of an Internet message. As such, use of a VM 154 for general message forwarding and gatewaying is not 155 supported. Storage of "Received" lines and "Message-ID" may 156 be limited. 158 Nothing in this document precludes use of a general purpose 159 email gateway from providing these services. However, severe 161 Vaudreuil Expires 5/1/95 3] 162 performance degradation may result if the email gateway does 163 not support the advanced ESMTP options required by this 164 document. 166 Internet-style mailing lists are not generally supported. 167 Distribution lists are implemented as local alias lists. 169 5) There is generally no human operator. Error reports must be 170 machine-parsable so that helpful responses can be given to 171 users whose only access mechanism is a telephone. 173 The system user names are limited to 16 or fewer numeric 174 characters. 176 Vaudreuil Expires 5/1/95 ] 177 5.Message Format Profile 179 The voice profile was written to be based on and be consistent 180 with the TCP/IP Email Protocol Suite with newly standardized 181 options for enhanced functionality and performance. This section 182 is an overview of the necessary protocols and a profile of the 183 applicable protocols as applied to the voice messaging 184 environment. 186 5.1. Message Addressing Formats 188 RFC 822 and SMTP addressing uses the domain name system. This 189 naming system has two components: the local part, used for 190 username or mailbox identification; and the host part, used for 191 machine or node identification. These two components are 192 separated by the commercial "@" symbol. 194 The local part of the address is an ASCII string uniquely 195 identifying a mailbox on a destination system. The local part is 196 a printable string containing the mailbox number of the 197 originator or a recipient. Administration of this number space 198 is expected to be conform to national or corporate private 199 telephone numbering plans. 201 The domain part of the address is a hierarchical global name for 202 all machines. For participation in the international Internet 203 network or for integration within a corporate internet, each VM 204 machine is required to have a unique domain name. In the domain 205 name system, a name is registered with the Internet Assigned 206 Number Authority (IANA). The IANA may delegate the management of 207 a branch of the naming space to a company or service provider. 209 For example, a compliant message may contain the address 210 2145551212@mycompany.com. It should be noted that while the 211 example mailbox address is based on the North American Numbering 212 Plan, any other corporate numbering plan can be used. The use of 213 the domain naming system should be transparent to the user. It 214 is the responsibility of the VM to translate the dialed address 215 to the fully-qualified domain name (FQDN). The mapping of dialed 216 address to VM destination is generally accomplished through 217 implementation-specific means, usually a local table. 219 Mapping of the FQDN to a specific network destination is 220 generally performed by the Domain Name System. For networks with 221 a small number of machines, a locally-maintained host table 222 database can be used as a simpler alternative. 224 Special addresses are provided for compatibility with the 225 conventions of the Internet mail system and to facilitate 226 testing. These addresses do not use numeric local addresses, 227 both to conform to current Internet practice and to avoid 228 conflict with existing numeric addressing plans. Some special 229 addresses are as follows: 231 Vaudreuil Expires 5/1/95 ] 232 Postmaster@domain 234 By convention, a special mailbox named "postmaster" 235 should exist on all systems. This address is used 236 for diagnostics and should be checked regularly by 237 the system manager. This mailbox is particularly 238 likely to receive text messages, which is not normal 239 on a voice processing platform; the specific 240 handling of these messages is a individual 241 implementation choice. 243 Loopback@domain 245 A special mailbox name named "loopback" should be 246 designated for loopback testing. All messages sent 247 to this mailbox must be returned back to the sender 248 as a new message. The originating address should be 249 "postmaster". 251 Because VMs do not use alpha-numeric addresses, this 252 address will not conflict with any internal 253 numbering plan. Internal to VM, a specific numeric 254 address for DTMF entry can be mapped to "loopback". 256 Note that without network level authentication, the 257 loopback address can be abused by routing messages 258 through a third-party VM to spoof another device or 259 to avoid toll charges. It is recommended that the 260 loopback feature be disabled except when testing the 261 networking between machines. 263 5.2. Message Header Fields 265 Internet messages contain a header information block. This 266 header block contains information required to identify the 267 sender, the list of recipients, the message send time, and other 268 information intended for user presentation. Except for 269 specialized gateway and mailing list cases, headers do not 270 indicate delivery options for the transport of messages. 272 RFC 822 defines a set of standard message header fields. This 273 set is extended in several RFCs. 275 Note that the specific order of header lines is not specified. 276 The order cannot be expected to be preserved when sent through 277 intermediate gateways. The following header fields must be 278 supported. 280 Network Working Group Greg Vaudreuil 281 Internet Draft Octel Network Services 282 Expires: May 1, 1995 January 26, 1995 284 MIME/ESMTP Profile for 285 Voice Messaging 287 289 Changes From the previous version 291 1) A large number of textual clarifications were made, including discussion 292 of X.440. 294 2) The reference section was updated. 296 3) Examples were fixed to reflect the current text. 298 Status of this Memo 300 This document is an Internet Draft. Internet Drafts are working documents 301 of the Internet Engineering Task Force (IETF), its Areas, and its Working 302 Groups. Note that other groups may also distribute working documents as 303 Internet Drafts. 305 Internet Drafts are valid for a maximum of six months and may be updated, 306 replaced, or obsoleted by other documents at any time. It is inappropriate 307 to use Internet Drafts as reference material or to cite them other than as 308 a "work in progress". 310 1.Abstract 312 A class of special-purpose computers has evolved to provide voice messaging 313 services. These machines generally interface to a telephone switch and 314 provide call answering and voice messaging services. Traditionally, 315 messages sent to a non-local machine are transported using analog 316 networking protocols based on DTMF signaling and analog voice playback. As 317 the demand for networking increases, there is a need for a standard high- 318 quality digital protocol to connect these machines. The following document 319 is a profile of the Internet standard MIME and ESMTP protocols for use as a 320 digital voice networking protocol. 322 This profile is based on an earlier effort in the Audio Message Interchange 323 Specification (AMIS) group to define a voice messaging protocol based on 324 X.400 technology. This protocol is intended to satisfy the user 325 requirements statement from that earlier work with the industry standard 326 ESMTP/MIME mail protocol infrastructures already used within corporate 327 internets. This profile will be called the voice profile in this document. 329 2.Scope and Design Goals 331 MIME is the Internet multipurpose, multimedia messaging standard. This 332 document explicitly recognizes its capabilities and provides a mechanism 333 for the exchange of various messaging technologies including voice and 334 facsimile. 336 It is not a goal to make interoperability possible between the earlier 337 X.400-based AMIS-Digital and this profile using a standard X.400-to-MIME 338 gateway. While the message encodings and messages semantics are similar, 339 the addressing and routing are not. The X.400-based AMIS-Digital 340 addressing format is sufficiently customized so that it cannot be mapped to 341 the RFC 822 mail format in the standard manner. The voice profile is 342 necessarily incompatible because it is intended to use the standard TCP/IP 343 mail addressing formats. 345 Because the 1988 X.400 based X.440 does not restrict the range of 346 addressing possible in X.400, translation to this protocol should be 347 possible using the standard X.400 to MIME gateway. 349 It is a goal of this effort to make as few changes to the existing 350 Internet mail protocols as possible while satisfying the user requirements 351 for Voice Networking. This goal is motivated by the desire to increase the 352 accessibility to digital messaging by enabling the use of proven existing 353 networking software for rapid development. 355 This specification is intended for use on a TCP/IP network. While it is 356 possible to use these protocols for simple point-to-point networking, the 357 specification is robust enough to be used in an environment such as the 358 global Internet with installed base gateways which do not understand MIME. 359 It is expected that a messaging system will be managed by a system 360 administrator who can perform TCP/IP network configuration. When using 361 facsimile or multiple voice encodings, it is expected that the system 362 administrator will maintain a list of the capabilities of the networked 363 mail machines to reduce the sending of undeliverable messages due to lack 364 of feature support. 366 This specification is a profile of the relevant TCP/IP Internet protocols. 367 These technologies, as well as the specifications for the Internet mail 368 protocols, are defined in the Request for Comment (RFC) document series. 369 That series documents the standards as well as the lore of the TCP/IP 370 protocol suite. This document should be read with the following RFC 371 documents: RFC 821, the Simple Mail Transport Protocol; RFC 822, the 372 Standard for the format of ARPA Internet Messages; RFC 1521 and RFC 1522, 373 the Multipurpose Internet Mail Extensions; RFC 1425 and RFC 1427, 374 Extensions to the SMTP protocol (ESMTP); and RFC 882 and RFC 883, the 375 Domain Name System. Where additional functionality is needed, it will be 376 defined in this document or in an appendix. 378 3.Protocol Restrictions 380 This protocol does not limit the number of recipients per message. Where 381 possible, implementations should not restrict the number of recipients in a 382 single message. 384 Recognising that no implementation supports unlimited recipients, and 385 that the number of supported recipients may be quite low, ESMTP should 387 Vaudreuil es 5/1/95 388 be extended to provide a mechanism for indicating the number of 389 supported recipients. 391 This protocol does not limit the maximum message length. Implementors 392 should understand that some machines will be unable to accept excessively 393 long messages. A mechanism is defined in the RFC 1425 ESMTP extensions to 394 declare the maximum message size supported. 396 The message size indicatd in the ESMTP SIZE command is in bytes, not 397 minutes. The number of bytes varies by voice encoding format and must 398 include the MIME wrapper overhead. Translation into minutes, can be 399 performed by simple multiplication if the voice encoding is know from 400 the system configuration file. 402 Framework for the voice profile 404 This document specifies a profile of the TCP/IP multimedia messaging 405 protocols for use by special-purpose voice processing platforms. These 406 platforms are not general-purpose computers and often do not have 407 facilities normally associated with an Internet Email-capable computer. 409 The following are typical restrictions imposed by a voice messaging 410 platform: 412 Text messages are not normally received and often cannot be displayed 413 or viewed in the normal fashion. They can be processed only via 414 advanced text-to-speech or text-to-fax features not currently present 415 in these machines. 417 2) Voice mail (VM) machines act as an integrated Message Transfer Agent 418 and a User Agent. The VM is responsible for final delivery, and there 419 is no forwarding of messages. RFC 822 header fields have limited use 420 in the context of the simple messaging features currently deployed. 422 3) VM message stores are generally not capable of preserving the full 423 semantics of an Internet message. As such, use of a VM for general 424 message forwarding and gatewaying is not supported. Storage of 425 "Received" lines and "Message-ID" may be limited. 427 Nothing in this document precludes use of a general purpose email 428 gateway from providing these services. However, severe performance 429 degradation may result if the email gateway does not support the 430 advanced ESMTP options required by this document. 432 4) Internet-style mailing lists are not generally supported. Distribution 433 lists are implemented as local alias lists. 435 There is generally no human operator. Error reports must be machine- 436 parsable so that helpful responses can be given to users whose only 437 access mechanism is a telephone. 439 The system user names are limited to 16 or fewer numeric characters. 441 Vaudreuil Expires 5/1/95 3] 442 5.Message Format Profile 444 The voice profile was written to be based on and be consistent with the 445 TCP/IP Email Protocol Suite with newly standardized options for enhanced 446 functionality and performance. This section is an overview of the necessary 447 protocols and a profile of the applicable protocols as applied to the voice 448 messaging environment. 450 5.1. Message Addressing Formats 452 RFC 822 and SMTP addressing uses the domain name system. This naming 453 system has two components: the local part, used for username or mailbox 454 identification; and the host part, used for machine or node identification. 455 These two components are separated by the commercial "@" symbol. 457 The local part of the address is an ASCII string uniquely identifying a 458 mailbox on a destination system. The local part is a printable string 459 containing the mailbox number of the originator or a recipient. 460 Administration of this number space is expected to be conform to national 461 or corporate private telephone numbering plans. 463 The domain part of the address is a hierarchical global name for all 464 machines. For participation in the international Internet network or for 465 integration within a corporate internet, each VM machine is required to 466 have a unique domain name. In the domain name system, a name is registered 467 with the Internet Assigned Number Authority (IANA). The IANA may delegate 468 the management of a branch of the naming space to a company or service 469 provider. 471 For example, a compliant message may contain the address 472 2145551212@mycompany.com. It should be noted that while the example mailbox 473 address is based on the North American Numbering Plan, any other corporate 474 numbering plan can be used. The use of the domain naming system should be 475 transparent to the user. It is the responsibility of the VM to translate 476 the dialed address to the fully-qualified domain name (FQDN). The mapping 477 of dialed address to VM destination is generally accomplished through 478 implementation-specific means, usually a local table. 480 Mapping of the FQDN to a specific network destination is generally 481 performed by the Domain Name System. For networks with a small number of 482 machines, a locally-maintained host table database can be used as a simpler 483 alternative. 485 Special addresses are provided for compatibility with the conventions of 486 the Internet mail system and to facilitate testing. These addresses do not 487 use numeric local addresses, both to conform to current Internet practice 488 and to avoid conflict with existing numeric addressing plans. Some special 489 addresses are as follows: 491 Postmaster@domain 493 By convention, a special mailbox named "postmaster" should 494 exist on all systems. This address is used for diagnostics 495 and should be checked regularly by the system manager. This 497 Vaudreuil es 5/1/95 498 mailbox is particularly likely to receive text messages, which 499 is not normal on a voice processing platform; the specific 500 handling of these messages is a individual implementation 501 choice. 503 Loopback@domain 505 A special mailbox name named "loopback" should be designated 506 for loopback testing. All messages sent to this mailbox must 507 be returned back to the sender as a new message. The 508 originating address should be "postmaster". 510 Because VMs do not use alpha-numeric addresses, this address 511 will not conflict with any internal numbering plan. Internal 512 to VM, a specific numeric address for DTMF entry can be mapped 513 to "loopback". 515 Note that without network level authentication, the loopback 516 address can be abused by routing messages through a third- 517 party VM to spoof another device or to avoid toll charges. It 518 is recommended that the loopback feature be disabled except 519 when testing the networking between machines. 521 5.2. Message Header Fields 523 Internet messages contain a header information block. This header block 524 contains information required to identify the sender, the list of 525 recipients, the message send time, and other information intended for user 526 presentation. Except for specialized gateway and mailing list cases, 527 headers do not indicate delivery options for the transport of messages. 529 RFC 822 defines a set of standard message header fields. This set is 530 extended in several RFCs. 532 Note that the specific order of header lines is not specified. The order 533 cannot be expected to be preserved when sent through intermediate gateways. 534 The following header fields must be supported. 536 From 538 The originator's fully-qualified domain address (a mailbox 539 number followed by the fully-qualified domain name). The user 540 listed in this field should be presented in the voice message 541 envelope as the originator of the message. 543 It is recommended that all messages contain the text personal 544 name of the sender in a quoted phrase if available. From 545 [822] 547 Example: 549 From: "Joe S. User" <2145551212@mycompany.com> 551 To 553 Vaudreuil es 5/1/95 554 The recipient's fully-qualified domain address. There may be 555 one or more To: fields in any message. All recipients of a 556 message must be listed in To lines except when a recipient is 557 specifically intended to receive a blind carbon copy. Note 558 that many VM systems have no facilities for storing or 559 reporting to the recipient the list of recipients. These 560 systems will generally discard these headers when received. 562 It is recommended that all messages contain the text personal 563 name of the recipient in a quoted phrase if available. From 564 [822] 566 Cc 568 Additional recipients' fully-qualified domain address. This 569 field has no meaning beyond "To:" in a VM and is not to be 570 generated by a conforming implementation. It is included for 571 processing by the receiver for compatibility with general 572 Internet mail agents that may not restrict the use of this 573 field. 575 If the VM supports the reporting of multiple recipients, all 576 names in the To: and Cc: fields should be reported. From [822] 578 Date 580 The date, time, and time zone the message was composed by the 581 originator, or the time specified by the originator if the 582 message is scheduled for delayed delivery. Conforming 583 implementations must be able to convert RFC 822 date and time 584 stamps into local time. If the VM reports message-sent time, 585 the value in the Date field should be used, not the time the 586 message was received at the destination system. From [822] 588 Example: Wed, 28 Jul 93 10:08:49 PDT 590 Sender 592 The actual address of the originator if the message is sent by 593 an agent on behalf of the author indicated in the From: field. 594 This field is not to be generated by a conforming 595 implementation. It is included for processing by the receiver 596 for compatibility with general Internet mail software that may 597 generate this header. 599 The Sender field often contains the name of an Internet-style 600 mailing list administrator and is the destination address for 601 reporting errors if the ESMTP MAIL FROM address is not 602 available. While it may not be possible to save this 603 information in some VM machines, discarding this information 604 or the SMTP MAIL FROM address will make it difficult to send 605 an error message to the proper destination. From [822] 607 Message-id 609 Vaudreuil es 5/1/95 610 A unique per-message identifier. Conforming systems must use 611 an identifier constructed by concatenating a unique 8-digit 612 serial message number and the sending VM's FQDN with the 613 commercial @ symbol. This identifier will be used for 614 tracking, auditing, and returning delivery reports. From 615 [822] 617 Example: 619 Message-id: <12345678@mycompany.com> 621 Received 623 Special-purpose trace information added to the beginning of a 624 RFC 822 message by message transport agents (MTA). This is 625 the only header permitted to be added by an MTA. Information 626 in this header is useful for debugging when using an ASCII 627 message reader or a header parsing tool. A conforming system 628 must add Received headers when acting as a gateway and must 629 not remove them. These headers may be ignored or deleted when 630 the message is received at the final destination. From [822] 632 MIME Version 634 Indicates that the message is conformant to the MIME message 635 format specification. This header must be present in any 636 conforming message. Systems conformant to this profile will 637 include a comment with the words "(VOICE 1.0)". From [MIME] 639 Example: 641 MIME-Version: 1.0 (VOICE 1.0) 642 Content-Type 644 The content-type header declares the type of content enclosed 645 in the message. One of the allowable contents is multipart, a 646 mechanism for bundling several message components into a 647 single message. The allowable contents are specified in the 648 next section of this document. From [MIME] 650 Content-Transfer-Encoding 652 Because Internet mail was initially specified to carry only 7- 653 bit US-ASCII text, it may be necessary to encode voice and fax 654 data into a representation suitable for that environment. The 655 content-transfer-encoding header describes this transformation 656 if it is needed. From [MIME] 658 Sensitivity 659 The requested privacy level. If this field exists, regardless 660 of the selected case-insensitive value "Personal" or 661 "Private". If no privacy is requested, this field is omitted. 663 Vaudreuil Expires 5/1/95 7 664 If a Sensitivity header is present in the message, a 665 conformant system is prohibited from forwarding this message. 666 If the receiving system does not support privacy and the 667 sensitivity is one of "Personal" or "Private", the message 668 must be returned to the sender with an appropriate error 669 message indicating that privacy could not be assured and that 670 the message was not delivered. 672 The specific privacy values do not need to be offered 673 individually to users but can be set on a system-wide basis. 674 From [X400] 676 Importance 678 Indicates the requested priority to be given by the receiving 679 system. The case-insensitive values "low", "normal" and 680 "high" are specified. If no special importance is requested, 681 this header may be omitted and the value assumed to be 682 "normal". This field can be used to order messages in a 683 recipient's mailbox and is equivalent to the AMIS-Digital 684 Priority indication. From [X400] 686 5.3. Message Content Types 688 MIME is a general-purpose message body format that is extensible to carry a 689 wide range of body parts. The basic protocol is described in [MIME]. MIME 690 also provides for encoding binary data so that it can be transported over 691 the 7-bit text-oriented SMTP protocol. This transport encoding is 692 independent of the audio encoding designed to generate a binary object. 694 MIME defines two transport encoding mechanisms to transform binary data 695 into a 7 bit representation, one designed for text-like data ("Quoted- 696 Printable"), and one for arbitrary binary data ("Base-64"). While Base-64 697 is dramatically more efficient for audio data, both will work. Where 698 binary transport is available, not transport encoding is needed, and the 699 data can be labled as "Binary". 701 An implementation in conformance with this profile is required to send 702 audio data in binary form when binary message transport is available. When 703 binary transport is not available, implementations must encode the message 704 as Base-64. The detection and decoding of "Quoted-Printable", "7bit", and 705 "8bit" must also be supported in order to meet MIME requirements and to 706 preserve interoperability with the fullest range of possible devices. 707 Bullet this list.... 709 The following content types are identified for use with this profile. Note 710 that each of these contents can be sent individually in a message or 711 wrapped in a multipart message to send multi-segment messages. 713 Message/RFC822 (REQUIRED) 715 MIME requires support of the Message/RFC822 message 716 encapsulation body part. This body part is used in the 717 Internet to forward complete messages within a multipart/mixed 719 Vaudreuil Expires 5/1/95 ] 720 message. Processing of this body part entails trivial 721 processing to unencapsulate/encapsulate the message. It is 722 not to be sent by a system conformant to this profile but must 723 be accepted for conformance with basic MIME. From [MIME] 725 Text/Plain (REQUIRED) 727 MIME requires support of the basic text/plain content type. 728 This content type has no applicability within the voice 729 messaging environment and should not be sent. Specific 730 handling depends on the platform, and interpretation of this 731 content-type is left as an implementation decision. Options 732 include dropping the body part and sending a delivery report 733 indicating the lack of support, text-to-speech, and text-to- 734 fax support. From [MIME] 736 Multipart/Mixed (REQUIRED) 738 MIME provides the facilities for enclosing several body parts 739 in a single message. Multipart/Mixed may be used for sending 740 multi-segment voice messages, that is, to preserve across the 741 network the distinction between an annotation and a forwarded 742 message. Systems are permitted to collapse such a multi- 743 segment message into a single segment if multi-segment 744 messages are not supported on the receiving machine. From 745 [MIME] 747 Text/Signature (RECOMMENDED) 749 Text/Signature provides a mechanism for the sending of per- 750 user directory information including the spoken name and the 751 supported mailbox capabilities. When used with a caching 752 mechanism, basic directory services with entries for commonly 753 used entries can be maintained. This body part is intended to 754 be used to support spoken name confirmation. The 755 Text/Signature can be included with a message using the 756 multipart/mixed constructor type. From [SIG] 758 Message/Notification (REQUIRED) 760 This new MIME body part is used for sending machine parsable 761 delivery status notifications. From [NOTIFY] 763 Multipart/Report (REQUIRED) 765 The Multipart/Report is used for enclosing a 766 Message/Notification body part and any returned message 767 content. This body type is a companion to 768 Message/Notification. From [NOTIFY2] 770 Audio/ADPCM (REQUIRED) 772 CCITT Recommendation G.721 describes the algorithm recommended 773 for conversion of a 64 KB/s A-law or u-law PCM channel to and 775 Vaudreuil es 5/1/95 776 from a 32 KB/s channel. The conversion is applied to the PCM 777 stream using an Adaptive Differential Pulse Code Modulation 778 (ADPCM) transcoding technique. This algorithm will be 779 registered with the IANA for MIME use under the name 780 Audio/ADPCM. 782 Support of Audio/ADPCM is required for conformance with this 783 profile. 785 Proprietary Voice Formats (OPTIONAL) 787 Proprietary voice encoding formats are supported under this 788 profile provided a unique identifier is registered with the 789 IANA prior to use. 791 Note that use of proprietary encodings reduces 792 interoperability in the absence of explicit manual system 793 configuration. 795 Vaudreuil es 5/1/95 796 6. Message Transport Protocol 798 Messages are transported between VM machines using the Internet Extended 799 Simple Mail Transport Protocol (ESMTP). All information required for 800 proper delivery of the message is included in the ESMTP dialog. This 801 information, including the sender and recipient addresses, is commonly 802 referred to as the message "envelope". This information is equivalent to 803 the message control block in many analog voice networking protocols. 805 ESMTP is a general-purpose messaging protocol, designed both to send mail 806 and to allow terminal console messaging. Simple Mail Transport Protocol 807 (SMTP) was originally created for the exchange of US-ASCII 7-bit text 808 messages. Binary and 8-bit text messages have traditionally been 809 transported by encoding the messages into a 7-bit text-like form. [ESMTP] 810 was recently published and formalized an extension mechanism for SMTP, and 811 subsequent RFCs have defined 8-bit text networking, binary networking, and 812 extensions to permit the declaration of message size for the efficient 813 transmission of large messages such as multi-minute voice mail. 815 A command streaming extension for high performance message transmission has 816 been defined. [PIPE] This extension reduces the number of round-trip 817 packet exchanges and makes it possible to validate all recipient addresses 818 in one operation. This extension is optional but recommended. 820 The following sections list ESMTP commands, keywords, and parameters that 821 are required and those that are optional. 823 6.1. ESMTP Commands 825 HELO (REQUIRED) 827 Base SMTP greeting and identification of sender. This command 828 is not to be sent by conforming systems unless the more- 829 capable EHLO command is not accepted. It is included for 830 compatibility with general SMTP implementations. From [SMTP] 832 MAIL FROM (REQUIRED) 834 Originating mailbox. This address contains the mailbox to 835 which errors should be sent. This address may not be the same 836 as the message sender listed in the message header fields if 837 the message was gatewayed or sent to an Internet-style mailing 838 list. From [SMTP] 840 RCPT TO (REQUIRED) 842 Recipient's mailbox. This field contains only the addresses 843 to which the message should be delivered for this transaction. 844 In the event that multiple transport connections to multiple 845 destination machines are required for the same message, this 846 list may not match the list of recipients in the message 847 header. From [SMTP] 849 DATA (REQUIRED) 850 Initiates the transfer of message data. This command is 851 required to be supported but should only be used in the event 852 the binary mode command BDAT is not supported. From [SMTP] 854 TURN (RECOMMENDED) 856 Requests a change-of-roles, that is, the client that opened 857 the connection offers to assume the role of server for any 858 mail the remote machine may wish to send. This command is 859 useful to poll for messages. 861 (Note the security implications of using the turn command to 862 fetch mail queued for another destination. This fetching is 863 possible because of the lack of authentication of the sending 864 VM by the protocol). From [SMTP] 866 QUIT (REQUIRED) 868 Requests that the connection be closed. If accepted, the 869 remote machine will reset and close the connection. From 870 [SMTP] 872 RSET (REQUIRED) 874 Resets the connection to its initial state. From [SMTP] 876 VRFY (OPTIONAL) 878 Requests verification that this node can reach the listed 879 recipient. While this functionality is also included in the 880 RCPT TO command, VRFY allows the query without beginning a 881 mail transfer transaction. This command is useful for 882 debugging and tracing problems. From [SMTP] 884 (Note that the implementation of VRFY may simplify the 885 guessing of a recipient's mailbox or automated sweeps for 886 valid mailbox addresses, resulting in a possible reduction in 887 privacy. Various implementation techniques may be used to 888 reduce the threat, such as limiting the number of queries per 889 session.) From [SMTP] 891 EHLO (REQUIRED) 893 Enhanced mail greeting that enables a server to announce 894 support for extended messaging options. The extended 895 messaging modes are discussed in a later section of this 896 document. From [ESMTP] 898 BDAT (REQUIRED) 900 Initiates binary data transmission. 902 Vaudreuil es 5/1/95 903 The BDAT command is an alternative to the earlier DATA 904 command. The BDAT command does not require encoding voice 905 data into 7-bit line-limited formats. 907 All other commands must be recognized and an appropriate 908 error code returned if not supported. From [BIN] 910 6.2. ESMTP Keywords 912 STREAMING (Optional) 914 The "STREAMING" keyword indicates ability of the receiving 915 SMTP to accept pipelined SMTP commands. From [PIPE] 917 SIZE (Required) 919 The "SIZE" keyword provides a mechanism by which the receiving 920 SMTP can indicate the maximum size message supported. From 921 [SIZE] 923 CHUNKING (Required) 925 The "CHUNKING" keyword indicates that the receiver will 926 support the high-performance transport mode. Note that 927 CHUNKING can be used with any message format and does not 928 imply support for binary encoded messages. From [BIN] 930 BINARYMIME (Required) 932 The "BINARYMIME" keyword indicates that the receiver SMTP can 933 accept binary encoded MIME messages. Note that CHUNKING mode 934 must be supported for this option, but CHUNKING does not mean 935 that binary messages can be supported. From [BIN] 937 NOTIFY (Required) 939 The "NOTIFY" keywork indicates that the receiver SMTP will 940 accept explicit delivery status notification requests. From 941 [DSN] 943 6.3. ESMTP Parameters - MAIL FROM 945 BINARYMIME The current message is a binary encoded MIME messages. From 946 [BIN] 948 6.4. ESMTP Parameters - RCPT TO 950 NOTIFY The conditions under which a delivery report should be sent. 951 From [DSN] 953 RET Whether the content of the message should be returned. From 954 [DSN] 956 Vaudreuil Expires 5/1/95 957 7.Management Protocols 959 The Internet protocols provide a mechanism for the management of VM 960 machines, from the management of the physical network through the 961 management of the message queues. SNMP should be supported on a compliant 962 message machine. 964 The digital interface to the VM and the TCP/IP protocols should be managed 965 by the standard network Managed Information Bases (MIBs). MIB II provides 966 basic statistics and reporting of the TCP/IP protocol performance and 967 statistics. Media-specific MIBs are available for X.25, Ethernet, FDDI, 968 Token Ring, Frame Relay, and other network technologies. This MIB provides 969 necessary information to diagnose faulty hardware, overloaded network 970 conditions, and excessive traffic conditions from a remote management 971 station. 973 Management of the machine resources and message queue monitoring based on 974 the host MIB and the Message and Directory MIB is recommended but not 975 required for conformance with this profile. 977 8.References 979 [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail 980 Extensions", RFC 1521, Bellcore, Innosoft, Sept 1993. 982 [MSG822] Crocker, D., "Standard for the Format of ARPA Internet Text 983 Messages", STD 11, RFC 822, UDEL, August 1982. 985 [X400] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021 986 and RFC 822", RFC 1327, May 1992. 988 [PIPE] Freed, N., Klensin, J., "SMTP Service Extension for Command 989 Pipelining" Internet Draft 991 [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, 992 "SMTP Service Extensions" RFC 1425, United Nations University, 993 Innosoft International, Inc., Dover Beach Consulting, Inc., 994 Network Management Associates, Inc., The Branch Office, February 995 1993. 997 [SIZE] Klensin, J, Freed, N., Moore, K, "SMTP Service Extensions for 998 Message Size Declaration" RFC 1427, United Nations University, 999 Innosoft International, Inc., Inc., February 1993. February 1993. 1001 [8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E., D. Crocker, 1002 "SMTP Service Extension for 8bit-MIMEtransport" RFC 1426, United 1003 Nations University, Innosoft International, Inc., Dover Beach 1004 Consulting, Inc., Network Management Associates, Inc., The Branch 1005 Office, February 1993. 1007 [DNS1] Mockapetris, P.,"Domain names - implementation and 1008 specification", RFC1035, Nov 1987. 1010 [DNS2] Mockapetris, P.,"Domain names - concepts and facilities", RFC 1011 1034, Nov 1987. 1013 [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 1014 USC/Information Sciences Institute, August 1982. 1016 [SIG] Vaudreuil, G., "Text/Signature", Internet Draft 1019 [BIN] Vaudreuil, G., "SMTP Service Extensions for Transmission of Large 1020 and Binary MIME Messages", Internet Draft 1023 [NOTIFY] Vaudreuil, G., Moore, K., "An Extensible Message Format for 1024 Delivery Status Notifications", Internet Draft 1027 [NOTIFY2] Vaudreuil, G., "Multipart/Report", Internet-Draft, 1030 [DSN] Moore, K. "SMTP Service Extensions for Delivery Status 1031 Notifications", Internet Draft . 1034 9.Security Consideration 1036 This document is a profile of existing Internet mail protcools. As such, 1037 it does create any security issues not already existing in the profiled 1038 Internet mail protocols themselves. 1040 10. Author's Address 1042 Gregory M. Vaudreuil 1043 Octel Communications Corporation 1044 Network Services Divison 1045 17080 Dallas Parkway 1046 Dallas, TX 75248-1905 1047 214-733-2722 1048 Greg.Vaudreuil@ONS.Octel.Com 1049 11. Appendix - Example Voice Message 1051 The following message is a full-featured, all-options-enabled message 1052 addressed to two recipients. The message includes the sender's spoken name 1053 and a short speech segment. The message is marked as important and 1054 private. Read receipts and positive delivery acknowledgment are requested. 1056 To: 2145551212@vm1.mycompany.com 1057 To: 2145551234@mv1.mycompany.com 1058 From: 2175552345@VM2.mycompany.com 1059 Date: Mon, 26 Aug 93 10:20:20 CST 1060 MIME-Version: 1.0 (Voice Profile Version 1) 1061 Content-type: Multipart/Mixed; Boundary = "MessageBoundary" 1062 Content-Transfer-Encoding: 7bit 1063 Message-ID: VM1.mycompany.co-123456789 1064 Sensitivity: PrivateImportance: High 1066 --MessageBoundary 1067 Content-type: Text/Signature 1069 Name: User, Joe, R. (Joe Random User) 1070 SpokenName: lslfdslsertiflkTfpgkTportrpkTpfgTpoiTpssdasddasdasd 1071 (This is the base-64 encoded spoken name) 1072 o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90geQ5tkjpokfgW 1073 dlkgpokpeowrit09IpokporkgwI== 1074 Capabilities: Audio/Basic, Audio/ADPCM, Application/Signature, 1075 Image/G3Fax 1077 --MessageBoundary 1078 Content-type: Audio/ADPCM 1079 Content-Transfer-Encoding: Base-64 1081 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1082 (This is a sample of the base-64 message data) fgdhgdfgd 1083 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW 1084 dlkgpokpeowrit09== 1086 --MessageBoundary--