idnits 2.17.1 draft-ema-vpim-02.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 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 42 longer pages, the longest (page 32) being 61 lines == It seems as if not all pages are separated by form feeds - found 40 form feeds but 43 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 350 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 289: '...x named "postmaster" MUST exist on all...' RFC 2119 keyword, line 298: '...named "loopback" SHOULD be designated ...' RFC 2119 keyword, line 300: '... to this mailbox MUST be returned back...' RFC 2119 keyword, line 302: '...returned address MUST be "postmaster" ...' RFC 2119 keyword, line 320: '...As a result, recipient information MAY...' (113 more instances...) -- The abstract seems to indicate that this document obsoletes RFC1911, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1680 has weird spacing: '...ntation must ...' -- 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 (September 19, 1996) is 10079 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: 'RFC822' is mentioned on line 224, but not defined ** Obsolete undefined reference: RFC 822 (Obsoleted by RFC 2822) == Missing Reference: 'DRPT' is mentioned on line 227, but not defined == Missing Reference: 'MDN' is mentioned on line 227, but not defined == Missing Reference: '822' is mentioned on line 546, but not defined == Missing Reference: 'X400' is mentioned on line 538, but not defined == Missing Reference: 'NOTARY' is mentioned on line 962, but not defined == Unused Reference: 'AMIS-A' is defined on line 1095, but no explicit reference was found in the text == Unused Reference: 'AMIS-D' is defined on line 1098, but no explicit reference was found in the text == Unused Reference: 'MSG822' is defined on line 1104, but no explicit reference was found in the text == Unused Reference: '8BIT' is defined on line 1122, but no explicit reference was found in the text == Unused Reference: 'DNS1' is defined on line 1128, but no explicit reference was found in the text == Unused Reference: 'DNS2' is defined on line 1131, but no explicit reference was found in the text == Unused Reference: 'RELATED' is defined on line 1163, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AMIS-A' -- Possible downref: Non-RFC (?) normative reference: ref. 'AMIS-D' ** 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 1854 (ref. 'PIPE') (Obsoleted by RFC 2197) ** Obsolete normative reference: RFC 1869 (ref. 'ESMTP') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 1426 (ref. '8BIT') (Obsoleted by RFC 1652) ** Obsolete normative reference: RFC 821 (ref. 'SMTP') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 1830 (ref. 'BINARY') (Obsoleted by RFC 3030) ** Obsolete normative reference: RFC 1894 (ref. 'NOTIFY') (Obsoleted by RFC 3464) ** Obsolete normative reference: RFC 1892 (ref. 'REPORT') (Obsoleted by RFC 3462) ** Obsolete normative reference: RFC 1891 (ref. 'DSN') (Obsoleted by RFC 3461) ** Obsolete normative reference: RFC 1893 (ref. 'CODES') (Obsoleted by RFC 3463) -- Possible downref: Non-RFC (?) normative reference: ref. 'STATUS' -- Possible downref: Non-RFC (?) normative reference: ref. 'G726' ** Obsolete normative reference: RFC 1158 (ref. 'MIB II') (Obsoleted by RFC 1213) ** Obsolete normative reference: RFC 1872 (ref. 'RELATED') (Obsoleted by RFC 2112) -- Possible downref: Non-RFC (?) normative reference: ref. 'DIRECTORY' -- Possible downref: Non-RFC (?) normative reference: ref. 'VCARD' ** Obsolete normative reference: RFC 1766 (ref. 'LANG') (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 1911 (ref. 'VPIM1') (Obsoleted by RFC 2421, RFC 2422, RFC 2423) -- Possible downref: Non-RFC (?) normative reference: ref. 'TIFF' -- Possible downref: Non-RFC (?) normative reference: ref. 'S100' Summary: 28 errors (**), 0 flaws (~~), 18 warnings (==), 12 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 in six months Glenn Parsons 5 Obsoletes: RFC 1911 Nortel Technology 6 September 19, 1996 8 Voice Profile for Internet Mail - version 2 10 12 Status of this Memo 14 This document is an Internet Draft. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its Areas, 16 and its Working Groups. Note that other groups may also distribute 17 working documents as Internet Drafts. 19 Internet Drafts are valid for a maximum of six months and may be 20 updated, replaced, or obsoleted by other documents at any time. It is 21 inappropriate to use Internet Drafts as reference material or to cite 22 them other than as a "work in progress". 24 To learn the current status of any Internet-Draft, please check the 25 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Overview 32 This document profiles Internet mail for voice messaging. It 33 obsoletes RFC 1911 which describes version 1 of the profile. A list 34 of changes from that document are noted in Appedix F. As well, 35 Appendix G lists the open issues with this version of VPIM. 37 Please send comments on this document to the EMA VPIM Work Group 38 mailing list: 40 Working Group Summary 42 This profile was not reviewed by an active IETF working group. 43 However, it has been reviewed by the VPIM Work Group of the Electronic 44 Messaging Association (EMA). This work group, which has 45 representatives from most major voice mail vendors, has held an 46 interoperability demonstration between voice messaging vendors and 47 received comments from traditional messaging vendors. 49 Table of Contents 51 1. ABSTRACT 3 52 2. SCOPE 4 53 2.1 Voice Messaging System Limitations 4 54 2.2 Design Goals 5 55 3. PROTOCOL RESTRICTIONS 6 56 4. VOICE MESSAGE INTERCHANGE FORMAT 7 57 4.1 Message Addressing Formats 7 58 4.2 Message Header Fields 9 59 4.3 Message Content Types 15 60 4.4 Forwarded Messages 20 61 5. MESSAGE TRANSPORT PROTOCOL 21 62 5.1 ESMTP Commands 21 63 5.2 ESMTP Keywords 23 64 5.3 ESMTP Parameters - MAIL FROM 24 65 5.4 ESMTP Parameters - RCPT TO 24 66 5.5 ESMTP - SMTP Downgrading 24 67 6. DIRECTORY ADDRESS RESOLUTION 26 68 7. IMAP 26 69 8. MANAGEMENT PROTOCOLS 26 70 8.1 Network Management 26 71 9. CONFORMANCE REQUIREMENTS 27 72 10. REFERENCES 28 73 11. SECURITY CONSIDERATION 30 74 12. ACKNOWLEDGMENTS 30 75 13. AUTHORS' ADDRESSES 30 76 14. APPENDIX A - VPIM REQUIREMENTS SUMMARY 31 77 15. APPENDIX B - EXAMPLE VOICE MESSAGES 35 78 16. APPENDIX C _ EXAMPLE ERROR VOICE PROCESSING ERROR CODES 38 79 17. APPENDIX D - AUDIO/32KADPCM CONTENT TYPE 39 80 18. APPENDIX E - IMAGE/TIFF CONTENT TYPE 40 81 18.1 References 40 82 18.2 TIFF Class F 40 83 19. APPENDIX F - CHANGE HISTORY: RFC 1911 TO THIS DOCUMENT 42 84 20. APPENDIX G -- OPEN ISSUES 43 85 1. Abstract 87 A class of special-purpose computers has evolved to provide voice 88 messaging services. These machines generally interface to a telephone 89 switch and provide call answering and voice messaging services. 90 Traditionally, messages sent to a non-local machine are transported 91 using analog networking protocols based on DTMF signaling and analog 92 voice playback. As the demand for networking increases, there is a 93 need for a standard high-quality digital protocol to connect these 94 machines. The following document is a profile of the Internet 95 standard MIME and ESMTP protocols for use as a digital voice messaging 96 networking protocol. 98 This profile is based on an earlier effort in the Audio Message 99 Interchange Specification (AMIS) group to define a voice messaging 100 protocol based on X.400 technology. This protocol is intended to 101 satisfy the user requirements statement from that earlier work with 102 the industry standard ESMTP/MIME mail protocol infrastructures already 103 used within corporate intranets. This Internet Draft will be referred 104 to as VPIM (Voice Profile for Internet Mail) in this document. This 105 second version of VPIM is based on implementation experience and 106 obsoletes RFC 1911 which describes version 1 of the profile. 108 2. Scope 110 MIME is the Internet multipurpose, multimedia messaging standard. 111 This document explicitly recognizes its capabilities and provides a 112 mechanism for the exchange of various messaging technologies, 113 highlighting voice and facsimile. 115 This document specifies a restricted profile of the Internet 116 multimedia messaging protocols for use between voice processing 117 platforms. These platforms have historically been special-purpose 118 computers and often do not have the same facilities normally 119 associated with a traditional Internet Email-capable computer. As a 120 result, VPIM also specifies additional functionality as it is needed. 121 This profile is intended to specify the minimum common set of features 122 to allow interworking between compliant systems. 124 2.1 Voice Messaging System Limitations 126 The following are typical limitations of voice messaging platform 127 which were considered in creating this baseline profile. 129 1) Text messages are not normally received and often cannot be 130 displayed or viewed. They can often be processed only via text-to- 131 speech or text-to-fax features not currently present in many of 132 these machines. 134 2) Voice mail machines usually act as an integrated Message 135 Transfer Agent, Message Store and User Agent. There is no relaying 136 of messages and RFC 822 header fields may have limited use in the 137 context of the limited messaging features currently deployed. 139 3) VM message stores are generally not capable of preserving the 140 full semantics of an Internet message. As such, use of a voice 141 mail machine for gatewaying is not supported. In particular, 142 storage of "CC" lists, "Received" lines, and "Message-ID" may be 143 limited. 145 4) Internet-style distribution/exploder mailing lists are not 146 typically supported. Voice mail machines often implement only 147 local alias lists, with error-to-sender and reply-to-sender 148 behavior. Reply-all capabilities using a CC list is not generally 149 available. 151 5) Error reports must be machine-parsable so that helpful responses 152 can be voiced to users whose only access mechanism is a telephone. 154 6) The voice mail systems generally limit address entry to 16 or 155 fewer numeric characters, and normally do not support alphanumeric 156 mailbox names. Alpha characters are not generally used for mailbox 157 identification as they cannot be easily entered from a telephone 158 terminal. 160 2.2 Design Goals 162 It is a goal of this effort to make as few restrictions and additions 163 to the existing Internet mail protocols as possible while satisfying 164 the requirements for interoperability with current generation voice 165 messaging systems. This goal is motivated by the desire to increase 166 the accessibility to digital messaging by enabling the use of proven 167 existing networking software for rapid development. 169 This specification is intended for use on a TCP/IP network, however, 170 it is possible to use the SMTP protocol suite over other transport 171 protocols. The necessary protocol parameters for such use is outside 172 the scope of this document. 174 This profile is intended to be robust enough to be used in an 175 environment such as the global Internet with installed base gateways 176 which do not understand MIME, though typical use is expected to be 177 within corporate intranets. Full functionality such, as reliable 178 error messages and binary transport, will require careful selection of 179 gateways (via MX records) to be used as VPIM forwarding agents. 180 Nothing in this document precludes use of a general purpose MIME email 181 packages to read and compose VPIM messages. While no special 182 configuration is required to receive VPIM compliant messages, some may 183 be required to originate compliant structures. 185 It is expected that a VPIM messaging system will be managed by a 186 system administrator who can perform TCP/IP network configuration. 187 When using facsimile or multiple voice encodings, it is suggested that 188 the system administrator maintain a list of the capabilities of the 189 networked mail machines to reduce the sending of undeliverable 190 messages due to lack of feature support. Configuration, 191 implementation and management of this directory listing capabilities 192 is a local matter. 194 3. Protocol Restrictions 196 This protocol does not limit the number of recipients per message. 197 Where possible, implementations should not restrict the number of 198 recipients in a single message. It is recognized that no 199 implementation supports unlimited recipients, and that the number of 200 supported recipients may be quite low. However, ESMTP currently does 201 not provide a mechanism for indicating the number of supported 202 recipients. 204 This protocol does not limit the maximum message length. Implementers 205 should understand that some machines will be unable to accept 206 excessively long messages. A mechanism is defined in the RFC 1425 207 SMTP service extensions to declare the maximum message size supported. 209 The message size indicated in the ESMTP SIZE command is in bytes, not 210 minutes or seconds. The number of bytes varies by voice encoding 211 format and must include the MIME wrapper overhead. If the length must 212 be known before sending, an approximate translation into minutes or 213 seconds can be performed if the voice encoding is known. 215 The following sections describe the restrictions and additions to 216 Internet mail that are required to be compliant with this VPIM v2 217 profile. A table in Appendix A summarizes the details. 219 4. Voice Message Interchange Format 221 The voice message interchange format is a profile of the Internet Mail 222 Protocol Suite. As such, this document assumes an understanding of 223 these specifications. Specifically, VPIM references components from 224 the message format standard for Internet messages [RFC822], the 225 Multipurpose Internet Message Extensions [MIME], the X.400 gateway 226 specification [X.400], delivery status notification 227 [DRPT][NOTIFY][STATUS], the message disposition notifications [MDN], 228 and the electronic business card [DIRECTORY][VCARD]. 230 4.1 Message Addressing Formats 232 RFC 822 addresses are based on the domain name system. This naming 233 system has two components: the local part, used for username or 234 mailbox identification; and the host part, used for global machine 235 identification. 237 4.1.1 VPIM Addresses 239 The local part of the address shall be a US-ASCII string uniquely 240 identifying a mailbox on a destination system. For voice messaging, 241 the local part is a printable string containing the mailbox ID of the 242 originator or recipient. While alpha characters and long mailbox 243 identifiers are permitted, most voice mail networks rely on numeric 244 mailbox identifiers to retain compatibility with the limited 10 digit 245 telephone keypad. The use of the domain naming system should be 246 transparent to the user. It is the responsibility of the voice mail 247 machine to lookup the fully-qualified domain name (FQDN) based on the 248 address entered by the user (see Section 6). 250 In the absence of a global directory, specification of the local part 251 is expected to conform to international or private telephone numbering 252 plans. It is likely that private numbering plans will prevail and 253 these are left for local definition. However, public telephone 254 numbers will be noted according to the international numbering plan 255 described in [E.164] and will be preceded by a `+'. The specification 256 of the local part of a VPIM address can be split into the four groups 257 described below: 259 1) mailbox number 260 - for use as a private numbering plan (any number of digits) 261 - e.g. 2722@octel.com 263 2) mailbox number+extension 264 - for use as a private numbering plan with extensions 265 any number of digits, use of `+' as separator 266 - e.g. 2722+111@octel.com 268 3) +international number 269 - for international telephone numbers conforming to E.164 270 maximum of 15 digits 271 - e.g. +16137637582@vm.nortel.ca 273 4) +international number+extension 274 - for international telephone numbers conforming to E.164 275 maximum of 15 digits, with an extension (e.g. behind a 276 PBX) that has a maximum of 15 digits. 277 - e.g. +17035245550+230@ema.org 279 4.1.2 Special Addresses 281 Special addresses are provided for compatibility with the conventions 282 of Internet mail and to facilitate testing. These addresses do not 283 use numeric local addresses, both to conform to current Internet 284 practice and to avoid conflict with existing numeric addressing plans. 285 Two special addresses are RESERVED for use as follows: 287 Postmaster@domain 289 By convention, a special mailbox named "postmaster" MUST exist on all 290 systems. This address is used for diagnostics and should be checked 291 regularly by the system manager. This mailbox is particularly likely 292 to receive text messages, which is not normal on a voice processing 293 platform. The specific handling of these messages is an individual 294 implementation choice. 296 Loopback@domain 298 A special mailbox name named "loopback" SHOULD be designated for 299 loopback testing. If supported, all messages (including content) sent 300 to this mailbox MUST be returned back to the address listed in the 301 From: address as a new message. The originating address of the 302 returned address MUST be "postmaster" to prevent mail loops. 304 4.1.3 Distribution Lists 306 There are many ways to handle distribution list (DL) expansions and 307 none are 'standard'. Simple alias is a behavior closest to what most 308 voice mail systems do today and what is to be used with VPIM messages. 309 That is: 311 Reply to the originator - (Address in the RFC822 From field) 312 Errors to the submitter - (Address in the MAIL FROM: field of the 313 ESMTP exchange and the Return-Path: 314 RFC 822 field) 316 Some proprietary voice messaging protocols include only the recipient 317 of the particular copy in the envelope and include no "headers" except 318 date and per-message features. Most voice messaging systems do not 319 provide for "Header Information" in their messaging queues and only 320 include delivery information. As a result, recipient information MAY 321 be in either the To or CC headers. If all recipients cannot be 322 presented (e.g. unknown DL expansion) then the recipient headers MUST 323 be omitted to indicate that an accurate list of recipients (e.g. for 324 use with a reply-all capability) is not known. 326 4.2 Message Header Fields 328 Internet messages contain a header information block. This header 329 block contains information required to identify the sender, the list 330 of recipients, the message send time, and other information intended 331 for user presentation. Except for specialized gateway and mailing 332 list cases, headers do not indicate delivery options for the transport 333 of messages. 335 Exploder lists are noted for modifying or adding to the headers of 336 messages that pass through them. VPIM systems MUST be able to accept 337 and ignore headers that are not defined here. 339 The following header lines are permitted for use with VPIM voice 340 messages: 342 4.2.1 From 344 The originator's fully-qualified domain address (a mailbox address 345 followed by the fully-qualified domain name). The user listed in this 346 field should be presented in the voice message envelope as the 347 originator of the message. 349 Systems compliant with this profile SHOULD provide the text personal 350 name of the sender in a quoted phrase if the name is available. To 351 facilitate storage of the text name in a local dial-by-name cache 352 directory, the first and last name names must be separable. Text 353 names of persons in voice messages MUST be represented in the form 354 "last, first, mi." and MUST be the same as found in the Vcard (section 355 4.3.4), if present. Text names of corporate or positional mailboxes 356 MAY be provided as a simple string. From [822] 358 Example: 360 From: "User, Joe, S." <2145551212@mycompany.com> 362 From: Technical Support <611@serviceprovider.com> 364 If a From: address is present, it MAY be used to construct a reply 365 message to the sender. If it is not present, it has been omitted 366 either because the originator is unknown or not reachable. As a 367 result, a reply is not permitted. 369 4.2.2 To 371 The To header contains the recipient's fully-qualified domain address. 372 There may be one or more To: fields in any message. 374 Example: 376 To: 2145551213@mycompany.com 378 Systems compliant to this profile SHOULD provide a list of recipients 379 only if all recipients areprovided. The To header MUST NOT be 380 included in the message if the sending message transport agent (MTA) 381 cannot resolve all the addresses in it, e.g. if an address is a DL 382 alias for which the expansion is unknown (see section 4.1.3). If 383 present, the addresses in the To header MAY be used for a reply 384 message to all recipients. 386 Systems compliant to this profile MAY discard the To addresses of 387 incoming messages as necessary. 389 4.2.3 Cc 391 The cc header contains additional recipients' fully-qualified domain 392 addresses. Many voice mail systems maintain only sufficient envelope 393 information for message delivery and are not capable of storing or 394 providing a complete list of recipients. 396 Systems compliant to this profile SHOULD provide a list of recipients 397 only if all disclosed recipients can be provided. The list of 398 disclosed recipients does not include those sent via a blind copy. If 399 not, systems SHOULD omit the To and Cc headers to indicate that the 400 full list of recipients is unknown. 402 Example: 404 Cc: 2145551213@mycompany.com 406 Systems compliant to this profile MAY discard the Cc addresses of 407 incoming messages as necessary. If a list of Cc or to addresses is 408 present, these addresses MAY be used for a reply message to all 409 recipients. 411 4.2.4 Date 413 The Date header contains the date, time, and time zone in which the 414 message was sent by the originator. The time zone SHOULD be 415 represented in a four-digit time zone offset, such as -0600 for North 416 American Eastern Standard Time. This may be supplemented by a time 417 zone name in parentheses, e.g., "-0800 (PDT)". Compliant 418 implementations SHOULD be able to convert RFC 822 date and time stamps 419 into local time. 421 Example: 423 Date: Wed, 28 Jul 96 10:08:49 -0900 (PST) 425 The sending system MUST report the time the message was sent. If the 426 VPIM sender is relaying a message from a system which does not provide 427 a timestamp, the time of arrival at the VPIM system SHOULD be used as 428 the date. From [822] 430 4.2.5 Sender 432 The Sender header contains the actual address of the originator if the 433 message is sent by an agent on behalf of the author indicated in the 434 From: field and MAY be present in a VPIM message. 436 While it may not be possible to save this information in some voice 437 mail machines, discarding this information or the ESMTP MAIL FROM (see 438 4.2.6) address will make it difficult to send an error message to the 439 proper destination. From [822] 441 4.2.6 Return Path 443 The Return-path header contains the actual address of the last 444 submitter of the message from the MAIL FROM parameter of the ESMTP 445 exchange. The MAIL FROM: information MAY be passed as a local system 446 parameter or in a Return-Path: line inserted at the beginning of a 447 VPIM message. From [1123] 449 Error messages are sent to the address in the Sender header, if 450 present. However, if it is not (as is typical) then the ESMTP MAIL 451 FROM address that is commonly mapped to the Return-path header is 452 used. 454 4.2.7 Message-id 456 The Message-id header contains a unique per-message identifier. A 457 unique message-id MUST be generated for each message sent from a 458 compliant implementation. 460 The message-id is not required to be stored on the receiving system. 461 This identifier MAY be used for tracking, auditing, and returning 462 read-receipt reports. From [822] 464 Example: 466 Message-id: <12345678@mycompany.com> 468 4.2.8 Received 470 The Received header contains trace information added to the beginning 471 of a RFC 822 message by MTAs. This is the only header permitted to be 472 added by an MTA. Information in this header is useful for debugging 473 when using an US-ASCII message reader or a header parsing tool. 475 A compliant system MUST add Received headers when acting as a gateway 476 and MUST NOT remove any. These headers MAY be ignored or deleted when 477 the message is received at the final destination. From [822] 479 4.2.9 MIME Version 481 The MIME-Version header indicates that the message conforms to the 482 MIME message format specification. Systems compliant with this 483 specification MUST include a comment with the words "(Voice 2.0)". RFC 484 1911 defines an earlier version of this profile and uses the token 485 (Voice 1.0). From [MIME][VPIM1] 487 Example: 489 MIME-Version: 1.0 (Voice 2.0) 491 4.2.10 Content-Type 493 The content-type header declares the type of content enclosed in the 494 message. One of the allowable contents is multipart/mixed, a 495 mechanism for bundling several message components into a single 496 message. The allowable contents are detailed in the section 4.3 of 497 this document. From [MIME] 499 4.2.11 Content-Transfer-Encoding 501 Because Internet mail was initially specified to carry only 7-bit US- 502 ASCII text, it may be necessary to encode voice and fax data into a 503 representation suitable for that environment. The content-transfer- 504 encoding header describes this transformation if it is needed. 505 Compliant implementations MUST recognize and decode the standard 506 encodings, "Binary", "7bit, "8bit", "Base64" and "Quoted-Printable". 507 The allowable content-transfer-encodings are specified in section 4.3. 508 From [MIME] 510 4.2.12 Sensitivity 512 The sensitivity header, if present, indicates the requested privacy 513 level. The case-insensitive values "Personal" and "Private" are 514 specified. If no privacy is requested, this field is omitted. 516 If a sensitivity header is present in the message, a compliant system 517 MUST prohibit the recipient from forwarding this message to any other 518 user. A compliant system, however, SHOULD allow the user to reply to 519 a sensitive message, but SHOULD NOT include the original message 520 content. The sensitivity of the reply message MAY be set by the user. 522 If the receiving system does not support privacy and the sensitivity 523 is one of "Personal" or "Private", the message MUST be returned to the 524 sender with an appropriate error code indicating that privacy could 525 not be assured and that the message was not delivered. A non-delivery 526 notification to a private message need not be tagged private since it 527 will be sent to the originator. From: [X.400] 529 4.2.13 Importance 531 Indicates the requested priority to be given by the receiving system. 532 The case-insensitive values "low", "normal" and "high" are specified. 533 If no special importance is requested, this header may be omitted and 534 the value assumed to be "normal". 536 Compliant implementations MAY use this header to indicate the 537 importance of a message and may order messages in a recipient's 538 mailbox. From: [X400] 540 4.2.14 Subject 542 The subject field is often provided by email systems but is not widely 543 supported on Voice Mail platforms. For compatibility with text based 544 mailbox interfaces, a text subject field SHOULD be generated by a 545 compliant implementation but MAY be discarded if present by a 546 receiving system. From [822] 548 It is recommended that voice messaging systems that do not support any 549 text user interfaces (e.g. access only by a telephone) insert a 550 generic subject header of "VPIM Message" for the benefit of text 551 enabled recipients. 553 4.3 Message Content Types 555 MIME, introduced in [MIME], is a general-purpose message body format 556 that is extensible to carry a wide range of body parts. It provides 557 for encoding binary data so that it can be transported over the 7-bit 558 text-oriented SMTP protocol. This transport encoding is in addition 559 to the audio encoding required to generate a binary object. 561 MIME defines two transport encoding mechanisms to transform binary 562 data into a 7 bit representation, one designed for text-like data 563 ("Quoted-Printable"), and one for arbitrary binary data ("Base64"). 564 While Base64 is dramatically more efficient for audio data, both will 565 work. Where binary transport is available, no transport encoding is 566 needed, and the data can be labeled as "Binary". 568 An implementation in compliance with this profile SHOULD send audio 569 and/or facsimile data in binary form when binary message transport is 570 available. When binary transport is not available, implementations 571 MUST encode the audio and/or facsimile data as Base64. The detection 572 and decoding of "Quoted-Printable", "7bit", and "8bit" MUST be 573 supported in order to meet MIME requirements and to preserve 574 interoperability with the fullest range of possible devices. However, 575 if a content is received that cannot be rendered to the user, an 576 appropriate non-delivery notification MUST be sent. 578 The content types described in this section are identified for use 579 with this profile. Other contents MUST NOT be used without prior 580 explicit per-destination configuration. Each of these contents can be 581 sent individually in a VPIM message or wrapped in a multipart/mixed to 582 form a more complex structure (several examples are given in Appendix 583 B). When multiple contents are present, they SHOULD be presented to 584 the user in the order that they appear in the message. 586 4.3.1 Text/Plain 588 MIME requires support of the basic Text/Plain content type. This 589 content type has limited applicability within the voice messaging 590 environment. Compliant implementations SHOULD NOT send the Text/Plain 591 content-type and SHOULD only send this content if the recipient system 592 is known to support it. Compliant implementations MUST accept 593 Text/Plain messages, however, specific handling is left as an 594 implementation decision. From [MIME] 596 There are several mechanisms that can be used to support text on voice 597 messaging systems including text-to-speech and text-to-fax 598 conversions. If no rendering of the text is possible (i.e. it is not 599 possible to determine if the text is a critical part of the message), 600 the entire message MUST be non-delivered and returned to the sender 601 with a media-unsupported error code. 603 4.3.2 Multipart/Mixed 605 MIME provides the facilities for enclosing several body parts in a 606 single message. Multipart/Mixed SHOULD be used for sending multi- 607 segment voice messages, that is, to preserve across the network the 608 distinction between an annotation and a forwarded message, or between 609 a spoken subject and the voice message. Compliant systems MUST accept 610 multipart/mixed body parts. Systems MAY collapse such a multi-segment 611 voice or fax message into a single segment if multi-segment messages 612 are not supported on the receiving machine. From [MIME] 614 While any valid MIME body header MAY be used, the following header has 615 specific semantics when included with this body part: 617 4.3.2.1 Content-Description: 619 This field SHOULD be present to allow a text-based identification 620 of this body part as being a VPIM message. This is particularly 621 useful for identification when using a simple MIME mail package. 622 If there are multiple multipart/mixed bodies present on the same 623 level (i.e. not nested), then this header MUST be present to allow 624 differentiation. It is recommended that the value `VPIM Message' 625 be used to identify content compliant with this document. 627 4.3.3 Message/RFC822 629 MIME requires support of the Message/RFC822 message encapsulation body 630 part. This body part is used within a multipart/mixed message to 631 forward complete messages (see section 4.4) or to reply with original 632 content. From [MIME] 634 4.3.4 Application/Directory 636 The spoken name and the spelled name of the message sender SHOULD be 637 sent with each message in an Application/Directory content type 638 [DIRECTORY]. If included in a message, the Versit VCARD profile MUST 639 be used [VCARD] and MUST specify at least the following attributes: 641 TEL - telephone number in international format (various types, 642 typically VOICE) 643 EMAIL - email address (various types, typically INTERNET) 645 The following attributes SHOULD be specified: 647 N - Family Name, Given Name, Additional Names, Honorific Prefixes, 648 and Suffixes (all present components in the From text name MUST 649 match) 650 ROLE - alternative to `N' attribute when sender is a corporate or 651 positional mailbox 652 SOUND - sound data (various types, typically 32KADPCM) 653 REV - Revision of Vcard in ISO 8601 date format 655 The content MAY use the other types (e.g. capabilities) as defined in 656 [VCARD]. 658 If present, the spoken name MUST be denoted by a content ID pointing 659 to an audio/* content elsewhere in the VPIM message. 661 There MUST only be one Vcard per VPIM message. If more than one is 662 present it is an error condition. 664 Example: 666 BEGIN: vCard 667 N: Parsons;Glenn 668 ORG: Nortel Technology 669 TEL;TYPE=VOICE,MSG,WORK: +1 613 763 7582 670 EMAIL;TYPE=INTERNET: glenn.parsons@nortel.ca 671 EMAIL;TYPE=INTERNET,VPIM: 6137637582@vm.nortel.ca 672 SOUND;TYPE=32KADPCM;ENCODE=BASE64;VALUE=CID: 673 REV: 19960831T103310Z 674 END: vCard 676 4.3.5 Audio/32KADPCM 678 CCITT Recommendation G.726 [G726] describes the algorithm recommended 679 for conversion of a 64 kbit/s A-law or u-law PCM channel to and from a 680 32 kbit/s channel (this is the same algorithm as the deprecated 681 G.721). The conversion is applied to the PCM stream using an Adaptive 682 Differential Pulse Code Modulation (ADPCM) transcoding technique. 684 An implementation compliant to this profile MUST use Audio/32KADPCM by 685 default for voice. Typically this body contains several minutes of 686 message content, however if used for spoken name or subject the 687 content should be considerably shorter (i.e. about 10 and 20 seconds 688 respectively). 690 If an implementation can only handle one voice body, then multiple 691 voice bodies (if present) SHOULD be concatenated, and SHOULD NOT be 692 discarded. It is recommended that this be done in the same order as 693 they were sent. 695 While any valid MIME body header MAY be used, several headers have the 696 following semantics when included with this body part: 698 4.3.5.1 Content-Description: 700 This field SHOULD be present to allow the parsable text 701 identification of these body parts. If more than one 702 Audio/32KADPCM body occurs within a single multipart/mixed, then 703 this header MUST be present to allow differentiation. It is 704 recommended that the following text values be used as appropriate: 706 Voice Message - the primary voice message, 707 Originator Spoken Name - the spoken name of the originator, 708 Recipient Spoken Name - the spoken name of the recipient if 709 available to the originator and present if there is ONLY one 710 recipient, 711 Spoken Subject.- the spoken subject of the message, typically 712 spoken by the originator 714 Note that if an Originator Spoken Name audio body is and a VCARD is 715 present in a VPIM message, the VCARD MUST point to the audio body. 716 That is, there MUST NOT be more than one Originator Spoken Name. 718 4.3.5.2 Content-Duration: 720 This field MAY be present to allow the specification of the length 721 of the bodypart in seconds. The use of this field on reception is 722 a local implementation issue. The formal BNF for this header is: 724 duration := "Content-Duration" ":" 1*6DIGIT "seconds" 726 Example: 728 Content-Duration: 33 seconds 730 4.3.5.3 Content-Language: 732 This field MAY be present to allow the specification of the spoken 733 language of the bodypart. The encoding is defined in [LANG] (e.g. 734 EN-UK for UK English). The use of this field on reception is a 735 local implementation issue. 737 4.3.6 Proprietary Voice Formats 739 Proprietary voice encoding formats or other standard formats may be 740 supported under this profile provided a unique identifier is 741 registered with the IANA prior to use. These voice encodings should 742 be registered as sub-types of Audio. 744 Use of any other encoding except Audio/32KADPCM reduces 745 interoperability in the absence of explicit manual system 746 configuration. A compliant implementation MAY use any other encoding 747 with explicit per-destination configuration. 749 4.3.7 Image/TIFF 751 All implementations MUST generate and read TIFF-F [TIFF][S100] 752 compatible facsimile contents. The tags that MUST be supported by 753 systems complying to this recommendation are described in the 754 Enterprise Computer Telephony Forum's S.100 API specification [S100]. 755 The TIFF-F content, originally from [TPC.INT] has been refined to 756 reflect this common practice, and is summarized in Appendix E for 757 completeness. 759 4.3.8 Multipart/report 761 An implementation MAY send this fax content in VPIM messages and MUST 762 be able to recognize it in received messages. If a fax message is 763 received that cannot be rendered to the user, then the system MUST 764 non-deliver the entire message with a media not supported error. 765 Multipart/Report 767 The Multipart/Report is used for enclosing a Message/delivery-status 768 and Message/Disposition-notification body parts and any returned 769 message content. Compliant implementations MUST use the 770 Multipart/Report construct when returning messages, sending warnings, 771 or issuing read receipts. Compliant implementations MUST recognize 772 and decode the Multipart/Report content type. From [REPORT] 774 4.3.9 Message/delivery-status 776 This MIME body part is used for sending machine-parsable delivery 777 status notifications. Compliant implementations must use the 778 Message/delivery-status construct when returning messages or sending 779 warnings. Compliant implementations must recognize and decode the 780 Message/delivery-status content type and present the reason for 781 failure to the user. From [NOTIFY] 783 4.4 Forwarded Messages 785 VPIM version 2 explicitly supports the forwarding of voice and fax 786 content with voice or fax annotation. Forwarded VPIM messages SHOULD 787 be sent as a multipart/mixed with the entire original message enclosed 788 in a message/rfc822 content type and the annotation as a separate 789 Audio/* body part. 791 In the event that the RFC822 headers are not available for the 792 forwarded content, simulated headers with information as available 793 SHOULD be constructed to indicate the original sending timestamp, and 794 the original sender as indicated in the "From" line. The 795 message/rfc822 content MUST include at least the MIME-Version: 1.0 796 (Voice 2.0), the MIME content type and MIME content-encoding header as 797 necessary. 799 In the event that forwarding information is lost through concatenation 800 of the original message and the forwarding annotation, such as must be 801 done in an AMIS to VPIM gateway, the entire content MAY be sent as a 802 single Audio/* segment without including any forwarding semantics. 804 5. Message Transport Protocol 806 Messages are transported between voice mail machines using the 807 Internet Extended Simple Mail Transfer Protocol (ESMTP). All 808 information required for proper delivery of the message is included in 809 the ESMTP dialog. This information, including the sender and 810 recipient addresses, is commonly referred to as the message 811 "envelope". This information is equivalent to the message control 812 block in many analog voice networking protocols. 814 ESMTP is a general-purpose messaging protocol, designed both to send 815 mail and to allow terminal console messaging. Simple Mail Transport 816 Protocol (SMTP) was originally created for the exchange of US-ASCII 7- 817 bit text messages. Binary and 8-bit text messages have traditionally 818 been transported by encoding the messages into a 7-bit text-like form. 819 [ESMTP] formalized an extension mechanism for SMTP, and subsequent 820 RFCs have defined 8-bit text networking, command streaming, binary 821 networking, and extensions to permit the declaration of message size 822 for the efficient transmission of large messages such as multi-minute 823 voice mail. 825 The following sections list ESMTP commands, keywords, and parameters 826 that are required and those that are optional. 828 5.1 ESMTP Commands 830 5.1.1 HELO 832 Base SMTP greeting and identification of sender. This command is not 833 to be sent by compliant systems unless the more-capable EHLO command 834 is not accepted. It is included for compatibility with general SMTP 835 implementations. Compliant implementations MUST implement the HELO 836 command for backward compatibility but SHOULD NOT send it unless EHLO 837 is not supported. From [SMTP] 839 5.1.2 MAIL FROM (REQUIRED) 841 Originating mailbox. This address contains the mailbox to which 842 errors should be sent. This address may not be the same as the 843 message sender listed in the message header fields if the message was 844 received from a gateway or sent to an Internet-style mailing list. 845 Compliant implementations MUST implement the extended MAIL FROM 846 command. From [SMTP, ESMTP] 848 5.1.3 RCPT TO 850 Recipient's mailbox. This field contains only the addresses to which 851 the message should be delivered for this transaction. In the event 852 that multiple transport connections to multiple destination machines 853 are required for the same message, this list may not match the list of 854 recipients in the message header. Compliant implementations MUST 855 implement the extended RCPT TO command. From [SMTP, ESMTP] 857 5.1.4 DATA 859 Initiates the transfer of message data. Support for this command is 860 required in the event the binary mode command BDAT is not supported by 861 the remote system. Compliant implementations MUST implement the SMTP 862 DATA command for backwards compatibility. From [SMTP] 864 5.1.5 TURN 866 Requests a change-of-roles, that is, the client that opened the 867 connection offers to assume the role of server for any mail the remote 868 machine may wish to send. Because SMTP is not an authenticated 869 protocol, the TURN command presents an opportunity to improperly fetch 870 mail queued for another destination. Compliant implementations SHOULD 871 NOT implement the TURN command. From [SMTP] 873 5.1.6 QUIT 875 Requests that the connection be closed. If accepted, the remote 876 machine will reset and close the connection. Compliant 877 implementations MUST implement the QUIT command. From [SMTP] 879 5.1.7 RSET 881 Resets the connection to its initial state. Compliant implementations 882 MUST implement the RSET command. From [SMTP] 884 5.1.8 VRFY 886 Requests verification that this node can reach the listed recipient. 887 While this functionality is also included in the RCPT TO command, VRFY 888 allows the query without beginning a mail transfer transaction. This 889 command is useful for debugging and tracing problems. Compliant 890 implementations MAY implement the VRFY command. From [SMTP] 892 (Note that the implementation of VRFY may simplify the guessing of a 893 recipient's mailbox or automated sweeps for valid mailbox addresses, 894 resulting in a possible reduction in privacy. Various implementation 895 techniques may be used to reduce the threat, such as limiting the 896 number of queries per session.) From [SMTP] 898 5.1.9 EHLO 900 The enhanced mail greeting that enables a server to announce support 901 for extended messaging options. The extended messaging modes are 902 discussed in subsequent sections of this document. Compliant 903 implementations MUST implement the ESMTP command and return the 904 capabilities indicated later in this memo. From [ESMTP] 906 5.1.10 BDAT 908 The BDAT command provides a higher efficiency alternative to the 909 earlier DATA command, especially for voice. The BDAT command provides 910 for native binary transport of messages. Compliant implementations 911 SHOULD support binary transport using the BDAT command.[BINARY] 913 5.2 ESMTP Keywords 915 The following ESMTP keywords indicate extended features useful for 916 voice messaging. 918 5.2.1 PIPELINING 920 The "PIPELINING" keyword indicates ability of the receiving server to 921 accept new commands before issuing a response to the previous command. 922 Pipelining commands dramatically improves performance by reducing the 923 number of round-trip packet exchanges and makes it possible to 924 validate all recipient addresses in one operation. Compliant 925 implementations SHOULD support the command pipelining indicated by 926 this parameter. From [PIPE] 928 5.2.2 SIZE 930 The "SIZE" keyword provides a mechanism by which the SMTP server can 931 indicate the maximum size message supported. Compliant 932 implementations MUST provide the size capability and SHOULD honor any 933 size limitations when sending. From [SIZE] 935 5.2.3 CHUNKING 937 The "CHUNKING" keyword indicates that the receiver will support the 938 high-performance binary transport mode. Note that CHUNKING can be 939 used with any message format and does not imply support for binary 940 encoded messages. Compliant implementations SHOULD support binary 941 transport indicated by this capability. From [BINARY] 943 5.2.4 BINARYMIME 945 The "BINARYMIME" keyword indicates that the SMTP server can accept 946 binary encoded MIME messages. Compliant implementations SHOULD support 947 binary transport indicated by this capability. From [BINARY] 949 5.2.5 NOTIFY 951 The "NOTIFY" keyword indicates that the SMTP server will accept 952 explicit delivery status notification requests. Compliant 953 implementations MUST support the delivery notification extensions in 954 [DSN]. 956 5.2.6 ENHANCEDSTATUSCODES 958 The _ENHANCEDSTATUSCODES_ keyword indicates that an SMTP server 959 augments its responses with the enhanced mail system status codes 960 [CODES]. These codes can then be used to provide more informative 961 explanations of error conditions, especially in the context of the 962 delivery status notifications format defined in [NOTARY]. Compliant 963 implementations SHOULD support this capability. From [STATUS] 965 5.3 ESMTP Parameters - MAIL FROM 967 5.3.1 BINARYMIME 969 The current message is a binary encoded MIME messages. Compliant 970 implementations SHOULD support binary transport indicated by this 971 parameter. From [BINARY] 973 5.3.2 RET 975 The RET parameter indicates whether the content of the message should 976 be returned. Compliant systems SHOULD honor a request for returned 977 content. From [DSN] 979 5.3.3 ENVID 981 The ENVID keyword of the SMTP MAIL command is used to specify an 982 "envelope identifier" to be transmitted along with the message and 983 included in any DSNs issued for any of the recipients named in this 984 SMTP transaction. The purpose of the envelope identifier is to allow 985 the sender of a message to identify the transaction for which the DSN 986 was issued. Compliant implementations MAY use this parameter. From 987 [DSN] 989 5.4 ESMTP Parameters - RCPT TO 991 5.4.1 NOTIFY 993 The NOTIFY parameter indicates the conditions under which a delivery 994 report should be sent. Compliant implementations MUST honor this 995 request. From [DSN] 997 5.4.2 ORCPT 999 The ORCPT keyword of the RCPT command is used to specify an "original" 1000 recipient address that corresponds to the actual recipient to which 1001 the message is to be delivered. If the ORCPT esmtp-keyword is used, 1002 it MUST have an associated esmtp-value, which consists of the original 1003 recipient address, encoded according to the rules below. Compliant 1004 implementations MAY use this parameter. From [DSN] 1006 5.5 ESMTP - SMTP Downgrading 1008 To ensure a consistent level of service across an intranet or the 1009 global Internet, it is essential that VPIM compliant ESMTP be 1010 supported at all hops between a VPIM originating system and the 1011 recipient system. Unfortunately, in the situation where a `downgrade' 1012 is unavoidable the expected result is not defined. A downgrade is 1013 defined as the loss of VPIM transport features at some hop due to the 1014 lack of support. For example, a relay hop may be forced (by the next 1015 hop) to forward a VPIM using SMTP instead of ESMTP, or using DATA 1016 instead of BDAT. It is recommended that the downgrading system should 1017 continue to attempt to deliver the message, but MUST send a 1018 appropriate delivery notification to the originator, e.g. the message 1019 left an ESMTP host and was sent (unreliably) via SMTP. 1021 6. Directory Address Resolution 1023 It is the responsibility of a VPIM system to lookup the fully- 1024 qualified domain name (FQDN) based on the address entered by the user 1025 (if the entered address is not already a FQDN). This would typically 1026 be an issue on systems that offered only a telephone user interface. 1027 The mapping of the dialed target number to a routable address allowing 1028 delivery to the destination system can be accomplished through 1029 implementation-specific means. 1031 An implementations may wish to populate local directories with address 1032 information extracted from received messages. It is mandated that 1033 only address information from Vcard attachments to VPIM messages be 1034 used to populate such a directory when the Vcard is available. 1035 Stripping addresses from the headers of VPIM messages SHOULD NOT be 1036 used to populate directories as it only provides partial data. 1037 Alternatively, bilateral agreements could be made to allow the bulk 1038 transfer of Vcards between systems. 1040 7. IMAP 1042 The use of client/server desktop mailbox protocols like IMAP or POP to 1043 retrieve VPIM messages from a IMAP or POP message store is possible 1044 without any special modifications to this VPIM specification. Email 1045 clients (and web browsers) typically have a table for mapping from 1046 MIME type to displaying application. The audio/*, image/tiff and 1047 application/directory contents can be configured so that they invoke 1048 the correct player/recorder for rendering. In addition with IMAP 1049 clients, the first multipart/mixed content (if present) will not 1050 appear since it is generic. The user instead will be presented with a 1051 message that has (for example) audio and image contents. 1053 8. Management Protocols 1055 The Internet protocols provide a mechanism for the management of 1056 messaging systems, from the management of the physical network through 1057 the management of the message queues. SNMP should be supported on a 1058 compliant message machine. 1060 8.1 Network Management 1062 The digital interface to the VM and the TCP/IP protocols SHOULD be 1063 managed. MIB II SHOULD be implemented to provide basic statistics and 1064 reporting of TCP and IP protocol performance. [MIB II] 1066 9. Conformance Requirements 1068 In order to claim conformance to this document and be called `VPIM 1069 compliant', a voice messaging system must implement all mandatory 1070 features of this profile in each of three areas: Content, Transport, 1071 and Notifications. In addition, systems which conform to this profile 1072 must not send messages with features beyond this profile unless 1073 explicit per-destination configuration of these enhanced features is 1074 provided. Such configuration information could be stored in a 1075 directory, though the implementation of this is currently a local 1076 matter. 1078 It is also possible, though not encouraged, to claim conformance to 1079 only specific areas (e.g. VPIM content compliant) of this profile. 1080 The delineation of these areas is as follows: 1082 Content - Section 4, except REPORT, NOTIFY & MDN, and 1083 Section 6 1085 Transport - Section 5 except NOTIFY & RET, and Section 8 1087 Notifications - REPORT, NOTIFY & MDN from Section 4, NOTIFY, 1088 ENHANCEDSTATUSCODES & RET from Section 5 and 1089 all notification requirements. 1091 A summary of compliance requirements is contained in Appendix A. 1093 10. References 1095 [AMIS-A] Audio Messaging Interchange Specifications (AMIS) - Analog 1096 Protocol Version 1, Issue 2, February 1992 1098 [AMIS-D] Audio Messaging Interchange Specifications (AMIS) - Digital 1099 Protocol Version 1, Issue 3 August 1993 1101 [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail 1102 Extensions", RFC 1521, Bellcore, Innosoft, Sept 1993. 1104 [MSG822] Crocker, D., "Standard for the Format of ARPA Internet Text 1105 Messages", STD 11, RFC 822, UDEL, August 1982. 1107 [X.400] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021 1108 and RFC 822", RFC 1327, May 1992. 1110 [PIPE] Freed, N., Cargille, A., "SMTP Service Extension for Command 1111 Pipelining" RFC 1854, October 1995. 1113 [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, 1114 "SMTP Service Extensions" RFC 1869, United Nations University, 1115 Innosoft International, Inc., Dover Beach Consulting, Inc., Network 1116 Management Associates, Inc., The Branch Office, November 1995. 1118 [SIZE] Klensin, J, Freed, N., Moore, K, "SMTP Service Extensions for 1119 Message Size Declaration" RFC 1870, United Nations University, 1120 Innosoft International, Inc., November 1995. 1122 [8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E., D. Crocker, 1123 "SMTP Service Extension for 8bit-MIMEtransport" RFC 1426, United 1124 Nations University, Innosoft International, Inc., Dover Beach 1125 Consulting, Inc., Network Management Associates, Inc., The Branch 1126 Office, February 1993. 1128 [DNS1] Mockapetris, P., "Domain names - implementation and 1129 specification", RFC1035, Nov 1987. 1131 [DNS2] Mockapetris, P., "Domain names - concepts and facilities", RFC 1132 1034, Nov 1987. 1134 [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 1135 USC/Information Sciences Institute, August 1982. 1137 [BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of 1138 Large and Binary MIME Messages", RFC 1830, October 1995. 1140 [NOTIFY] Moore, K., Vaudreuil, G., "An Extensible Message Format for 1141 Delivery Status Notifications", RFC 1894, 01/15/1996. 1143 [REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the 1144 Reporting of Mail System Administrative Messages", RFC 1892, 1145 01/15/1996. 1147 [DSN] Moore, K. "SMTP Service Extensions for Delivery Status 1148 Notifications", RFC 1891, 01/15/1996 1150 [CODES] Vaudreuil, G. "Enhanced Mail System Status Codes", RFC 1893, 1151 01/15/1996. 1153 [STATUS] Freed, N. "SMTP Service Extension for Returning Enhanced Error 1154 Codes", Internet-Draft , July 1996. 1156 [G726] CCITT Recommendation G.726 (1990), General Aspects of Digital 1157 Transmission Systems, Terminal Equipment - 40, 32, 24,16 kbit/s 1158 Adaptive Differential Pulse Code Modulation (ADPCM). 1160 [MIB II] M. Rose, "Management Information Base for Network Management of 1161 TCP/IP-based internets: MIB-II", RFC 1158, May 1990. 1163 [RELATED] Levinson, E., "The MIME Multipart/Related Content-type", RFC 1164 1872, Dec 1995 1166 [DIRECTORY] Howes, Tim, Smith, Mark, "A MIME Content-Type for Directory 1167 Information" 1169 [VCARD] Dawson, Frank, Howes, Tim, "An Application/Directory MIME 1170 Content-Type Electronic Business Card Profile" 1173 [LANG] Alvestrand,H., "Tags for the Identification of Languages", RFC 1174 1766, Mar 1995 1176 [TPC.INT] C. Malamud, M. Rose, "Principles of Operation for the TPC.INT 1177 Subdomain: Remote Printing -- Technical Procedures", RFC 1528, 1178 10/06/1993 1180 [VPIM1] Vaudreuil, Greg, "Voice Profile for Internet Mail", RFC 1911, 1181 Feb 1996. 1183 [TIFF] Adobe Developers Association, TIFF (TM) Revision 6.0 - Final, 1184 June 3, 1992. 1186 [S100] Enterprise Computer Telephony Forum, S.100 Revision 1.0 - Media 1187 Services "C" Language - Application Programming Interfaces, February 1188 1996. 1190 [1123] Braden, R., "Requirements for Internet Hosts -- Application and 1191 Support", STD 3, RFC 1123, October 1989. 1193 11. Security Consideration 1195 This document is a profile of existing Internet mail protocols. As 1196 such, it does not create any security issues not already existing in 1197 the profiled Internet mail protocols themselves. 1199 Further, the profile specified in this document does not in any way 1200 preclude the use of any Internet mail security protocol to encrypt, 1201 authenticate, or non-repudiate the messages. 1203 12. Acknowledgments 1205 The authors would like to offer a special thanks to the Electronic 1206 Messaging Association, especially the members of the Voice Messaging 1207 Committee, for their support of the VPIM specification and the efforts 1208 they have made to ensure its success. 1210 13. Authors' Addresses 1212 Glenn W. Parsons 1213 Nortel Technology 1214 P.O. Box 3511, Station C 1215 Ottawa, ON K1Y 4H7 1216 Canada 1217 Phone: +1-613-763-7582 1218 Fax: +1-613-763-8385 1219 Glenn.Parsons@Nortel.ca 1221 Gregory M. Vaudreuil 1222 Octel Network Services 1223 17080 Dallas Parkway 1224 Dallas, TX 75248-1905 1225 United States 1226 Phone/Fax: +1-972-733-2722 1227 Greg.Vaudreuil@Octel.Com 1229 14. Appendix A - VPIM Requirements Summary 1231 The following table summarizes the profile of VPIM version 2 detailed 1232 in this document. For complete explanations of each feature it is 1233 recommended to read the accompanying text. The conformance table is 1234 separated into various columns: 1236 Feature - name of protocol feature 1238 Section - reference section in main text of this document 1240 Area - conformance area to which each feature applies: 1241 C - content 1242 T - transport 1243 N - notifications 1245 Status - whether the feature is mandatory, optional, or prohibited. 1246 There are three different degrees of optional used in this table: 1247 Must - mandatory 1248 Should - encouraged optional 1249 May - optional 1250 Should not - discouraged optional 1251 Must not - prohibited 1253 Footnote - special comment about conformance for a particular 1254 feature 1255 VPIM version 2 Conformance 1256 | | | | |S| | 1257 | | | | | |H| |F 1258 | | | | | |O|M|o 1259 | | | |S| |U|U|o 1260 | | | |H| |L|S|t 1261 | |A|M|O| |D|T|n 1262 | |R|U|U|M| | |o 1263 | |E|S|L|A|N|N|t 1264 | |A|T|D|Y|O|O|t 1265 FEATURE |SECTION | | | | |T|T|e 1266 -------------------------------------------|----------|-|-|-|-|-|-|- 1267 | | | | | | | | 1268 Message Addressing Formats: | | | | | | | | 1269 Use DNS host names |4.1 |C|x| | | | | 1270 Use only numbers in mailbox IDs |4.1.1 |C| |x| | | | 1271 Use alpha-numeric mailbox IDs |4.1.1 |C| | |x| | | 1272 Support of postmaster@domain |4.1.2 |C|x| | | | | 1273 Support of loopback@domain |4.1.2 |C| |x| | | | 1274 Support of distribution lists |4.1.3 |C| |x| | | | 1275 | | | | | | | | 1276 Message Header Fields: | | | | | | | | 1277 Encoding outbound messages | | | | | | | | 1278 From |4.2.1 |C|x| | | | | 1279 Addition of text name |4.2.1 |C| |x| | | | 1280 To |4.2.2 |C|x| | | | |1 1281 cc |4.2.3 |C| |x| | | |1 1282 Date |4.2.4 |C|x| | | | | 1283 Sender |4.2.5 |C| | |x| | | 1284 Return-Path |4.2.6 |C| | |x| | | 1285 Message-id |4.2.7 |C|x| | | | | 1286 Received |4.2.8 |C|x| | | | | 1287 MIME Version: 1.0 (Voice 2.0) |4.2.9 |C|x| | | | | 1288 Content-Type |4.2.10 |C|x| | | | | 1289 Content-Transfer-Encoding |4.2.11 |C|x| | | | | 1290 Sensitivity |4.2.12 |C| | |x| | | 1291 Importance |4.2.13 |C| | |x| | | 1292 Subject |4.2.14 |C| |x| | | | 1293 | | | | | | | | 1294 Detection & Decoding inbound messages | | | | | | | | 1295 From |4.2.1 |C|x| | | | | 1296 Utilize text personal name |4.2.1 |C| |x| | | | 1297 To |4.2.2 |C|x| | | | | 1298 cc |4.2.3 |C| | |x| | | 1299 Date |4.2.4 |C|x| | | | | 1300 Conversion of Date to local time |4.2.4 |C| |x| | | | 1301 Sender |4.2.5 |C| | |x| | | 1302 Return-Path |4.2.6 |C| | |x| | | 1303 Message ID |4.2.7 |C|x| | | | | 1304 Received |4.2.8 |C| | |x| | | 1305 MIME Version: 1.0 (Voice 2.0) |4.2.9 |C|x| | | | | 1306 Content Type |4.2.10 |C|x| | | | | 1307 Content-Transfer-Encoding |4.2.11 |C|x| | | | | 1308 Sensitivity |4.2.12 |C|x| | | | |2 1309 Importance |4.2.13 |C| | |x| | | 1310 Subject |4.2.14 |C| | |x| | | 1311 Message Content Encoding: | | | | | | | | 1312 Encoding outbound audio/fax contents | | | | | | | | 1313 7BITMIME |4.3 |C| | | | |x| 1314 8BITMIME |4.3 |C| | | | |x| 1315 Quoted Printable |4.3 |C| | | | |x| 1316 Base64 |4.3 |C|x| | | | |3 1317 Binary |4.3 |C| |x| | | |4 1318 Detection & decoding inbound messages | | | | | | | | 1319 7BITMIME |4.3 |C|x| | | | | 1320 8BITMIME |4.3 |C|x| | | | | 1321 Quoted Printable |4.3 |C|x| | | | | 1322 Base64 |4.3 |C|x| | | | | 1323 Binary |4.3 |C|x| | | | |4 1324 | | | | | | | | 1325 Message Content Types: | | | | | | | | 1326 Inclusion in outbound messages | | | | | | | | 1327 Text/plain |4.3.1 |C| | | |x| | 1328 Multipart/Mixed |4.3.2 |C| |x| | | | 1329 Content-Description |4.3.2.1 |C| |x| | | |5 1330 Message/RFC822 |4.3.3 |C| | |x| | | 1331 Application/Directory |4.3.4 |C| |x| | | | 1332 Audio/32KADPCM |4.3.5 |C|x| | | | | 1333 Content-Description |4.3.5.1 |C| |x| | | |5 1334 Content-Duration |4.3.5.2 |C| | |x| | | 1335 Content-Language |4.3.5.3 |C| | |x| | | 1336 Audio/* (other encodings) |4.3.6 |C| | |x| | | 1337 Image/TIFF |4.3.7 |C|x| | | | | 1338 Multipart/Report |4.3.8 |N|x| | | | | 1339 Message/delivery-status |4.3.9 |N|x| | | | | 1340 Detection & decoding in inbound messages | | | | | | | | 1341 Text/plain |4.3.1 |C|x| | | | | 1342 send NDN if unable to render |4.3.1 |N|x| | | | |6 1343 Multipart/Mixed |4.3.2 |C|x| | | | | 1344 Content-Description |4.3.2.1 |C| | |x| | | 1345 Message/RFC822 |4.3.3 |C|x| | | | | 1346 Application/Directory |4.3.4 |C| |x| | | | 1347 Audio/32KADPCM |4.3.5 |C|x| | | | | 1348 Content-Description |4.3.5.1 |C| |x| | | | 1349 Content-Duration |4.3.5.2 |C| | |x| | | 1350 Content-Language |4.3.5.3 |C| | |x| | | 1351 Audio/* (other encodings) |4.3.6 |C| | |x| | | 1352 Image/TIFF |4.3.7 |C|x| | | | | 1353 send NDN if unable to render |4.3.7 |N|x| | | | |6 1354 Multipart/Report |4.3.8 |N|x| | | | | 1355 Message/delivery-status |4.3.9 |N|x| | | | | 1356 Forwarded Messages | | | | | | | | 1357 use Message/RFC822 construct |4.4 |C| |x| | | | 1358 simulate headers if none available |4.4 |C| |x| | | | 1359 | | | | | | | | 1360 Message Transport Protocol: | | | | | | | | 1361 ESMTP Commands | | | | | | | | 1362 HELO |5.1.1 |T|x| | | | | 1363 MAIL FROM |5.1.2 |T|x| | | | | 1364 RCPT TO |5.1.3 |T|x| | | | | 1365 DATA |5.1.4 |T|x| | | | | 1366 TURN |5.1.5 |T| | | | |x| 1367 QUIT |5.1.6 |T|x| | | | | 1368 RSET |5.1.7 |T|x| | | | | 1369 VRFY |5.1.8 |T| | |x| | | 1370 EHLO |5.1.9 |T|x| | | | | 1371 BDAT |5.1.10 |T| |x| | | |4 1372 ESMTP Keywords & Parameters | | | | | | | | 1373 PIPELINING |5.2.1 |T| |x| | | | 1374 SIZE |5.2.2 |T|x| | | | | 1375 CHUNKING |5.2.3 |T| |x| | | | 1376 BINARYMIME |5.2.4,5.3.1|T| |x| | | | 1377 NOTIFY |5.2.5,5.4.1|N|x| | | | | 1378 ENHANCEDSTATUSCODES |5.2.6 |N| |x| | | | 1379 RET |5.3.2 |N| |x| | | | 1380 ENVID |5.3.3 |N| | |x| | | 1381 ORCPT |5.4.2 |N| | |x| | | 1382 ESMTP-SMTP Downgrading | | | | | | | | 1383 send delivery report upon downgrade |5.5 |N|x| | | | | 1384 | | | | | | | | 1385 Directory Address Resolution | | | | | | | | 1386 provide facility to resolve addresses |6 |C| |x| | | | 1387 use Vcards to populate local directory |6 |C|x| | | | | 1388 use headers to populate local directory |6 |C| | | |x| | 1389 | | | | | | | | 1390 Management Protocols: | | | | | | | | 1391 Network management |8.1 |T| |x| | | | 1392 -------------------------------------------|----------|-|-|-|-|-|-|- 1394 1. MUST NOT include if all recipients are not known or resolvable. 1395 2. If a sensitive message is received by a system that does not 1396 support sensitivity, then it MUST be returned to the originator 1397 with an appropriate error notification. Also, a received 1398 sensitive message MUST NOT be forwarded to anyone. 1399 3. When binary transport is not available 1400 4. When binary transport is available 1401 5. If multiple contents are present in a message, this header MUST be 1402 present 1403 6. If the content cannot be presented in some form, the entire 1404 message MUST be non-delivered. 1406 15. Appendix B - Example Voice Messages 1408 The following message is a full-featured, all-options-enabled message 1409 addressed to two recipients. The message includes the sender's spoken 1410 name and a short speech segment. The message is marked as important 1411 and private. 1413 To: 9725551212@vm1.mycompany.com 1414 To: 6135551234@VM1.mycompany.com 1415 From: "Parsons, Glenn" <2145551234@VM2.mycompany.com> 1416 Date: Mon, 26 Aug 93 10:20:20 CST 1417 MIME-Version: 1.0 (Voice 2.0) 1418 Content-type: Multipart/Mixed; Boundary="MessageBoundary" 1419 Content-Transfer-Encoding: 7bit 1420 Message-ID: VM2.mycompany.com-123456789 1421 Sensitivity: Private 1422 Importance: High 1424 --MessageBoundary 1425 Content-type: Audio/32KADPCM 1426 Content-Transfer-Encoding: Base64 1427 Content-Description: Originator Spoken Name 1428 Content-Language: EN-US 1429 Content-ID: part1@VM2-4321 1431 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1432 (This is a sample of the base-64 Spoken Name data) fgdhgd 1433 dlkgpokpeowrit09== 1435 --MessageBoundary 1436 Content-type: Audio/32KADPCM 1437 Content-Transfer-Encoding: Base64 1438 Content-Description: VPIM Message 1439 Content-Duration: 25 seconds 1441 iIiIiIjMzN3czdze3s7d7fwfHhcvESJVe/4yEhLz8/FOQjVFRERCESL/zqrq 1442 (This is a sample of the base64 message data) zb8tFdLTQt1PXj 1443 u7wjOyRhws+krdns7Rju0t4tLF7cE0K0MxOTOnRW/Pn30c8uHi9== 1445 --MessageBoundary 1446 Content-type: Application/Directory 1447 Content-Transfer-Encoding: 7bit 1449 BEGIN: Vcard 1450 N: Parsons;Glenn;;Mr.; 1451 EMAIL;TYPE=INTERNET: 2145551234@VM2.mycompany.com 1452 TEL: +1 217 555 1234 1453 SOUND;TYPE=32KADPCM;ENCODE=BASE64;VALUE=CID: 1454 REV: 19951031T222710Z 1455 END: Vcard 1457 --MessageBoundary-- 1458 The following message is a forwarded single segment voice. 1460 To: 2145551212@vm1.mycompany.com 1461 From: "Vaudreuil, Greg" <2175552345@VM2.mycompany.com> 1462 Date: Mon, 26 Aug 93 10:20:20 CST 1463 MIME-Version: 1.0 (Voice 2.0) 1464 Content-type: Multipart/Mixed; Boundary="MessageBoundary" 1465 Content-Transfer-Encoding: 7bit 1466 Message-ID: VM2.mycompany.com-123456789 1468 --MessageBoundary 1469 Content-type: Audio/32KADPCM 1470 Content-Description: VPIM Message 1471 Content-Transfer-Encoding: Base64 1473 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1474 (This is the voiced introductory remarks encoded in base64) 1475 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW 1476 dlkgpokpeowrit09== 1478 --MessageBoundary 1479 Content-type: Message/RFC822 1480 Content-Transfer-Encoding: 7bit 1482 To: 2175552345@VM2.mycompany.com 1483 From: "Parsons, Glenn, W." <2145551234@VM1.mycompany.com> 1484 From: Date: Mon, 26 Aug 93 8:23:10 EST 1485 MIME-Version: 1.0 (Voice 2.0) 1486 Content-type: Audio/32KADPCM 1487 Content-Description: VPIM Message 1488 Content-Transfer-Encoding: Base64 1490 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1491 (This is the original message audio data) fgwersdfmniwrjj 1492 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW 1493 dlkgpokpeowrit09== 1495 --MessageBoundary 1496 Content-type: Application/Directory 1497 Content-Transfer-Encoding: 7bit 1499 BEGIN: Vcard 1500 N: Vaudreuil;Greg;;Mr.; 1501 SOUND;TYPE=32kbADPCM;ENCODE=BASE64;VALUE=INLINE: 1502 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1503 (This is the Spoken Name audio data) fgwersdfmniwrjjedfsa 1504 dlkgpokpeowrit09== 1505 EMAIL;TYPE=INTERNET,VPIM: 2175552345@VM2.mycompany.com 1506 TEL: +1 217 555 2345 1507 REV: 19951031T222710Z 1508 END: Vcard 1510 --MessageBoundary_ 1511 The following example is for a message returned to the sender by a 1512 VPIM gateway at VM1.company.com for a mailbox which does not exist. 1514 Date: Thu, 7 Jul 1994 17:16:05 -0400 1515 From: Mail Delivery Subsystem 1516 Message-Id: <199407072116.RAA14128@vm1.company.com> 1517 Subject: Returned voice message 1518 To: 2175552345@VM2.mycompany.com 1519 MIME-Version: 1.0 (Voice 2.0) 1520 Content-Type: multipart/report; report-type=delivery-status; 1521 boundary="RAA14128.773615765/VM1.COMPANY.COM" 1523 --RAA14128.773615765/VM1.COMPANY.COM 1524 Content-type: Audio/32KADPCM 1525 Content-Transfer-Encoding: Base64 1527 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd 1528 (This is a voiced description of the error in base64) 1529 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW 1530 dlkgpokpeowrit09== 1532 --RAA14128.773615765/VM1.COMPANY.COM 1533 content-type: message/delivery-status 1535 Reporting-MTA: dns; vm1.company.com 1536 Original-Recipient: rfc822; 2145551234@VM1.mycompany.com 1537 Final-Recipient: rfc822; 2145551234@VM1.mycompany.com 1538 Action: failed 1539 Status: 5.1.1 1540 Diagnostic-Code: smtp; 550 Mailbox not found 1541 Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400 1543 --RAA14128.773615765/VM1.COMPANY.COM 1544 content-type: message/rfc822 1546 [original VPIM message goes here] 1548 --RAA14128.773615765/VM1.COMPANY.COM-- 1550 16. Appendix C _ Example Error Voice Processing Error Codes 1552 Error condition 1553 RFC 1893 Error codes and recommended comments 1555 Analog delivery failed because remote system is busy 1556 4.4.0 Persistent connection - other 1558 Analog delivery failed because remote system is ring-no-answer 1559 4.4.1 Persistent protocol - no answer from host 1561 Remote system did not answer "D" in response to "C" at connect time 1562 5.5.5 Permanent protocol - wrong version 1564 Mailbox does not exist 1565 5.1.1 Permanent mailbox - does not exist 1567 Mailbox full or over quota 1568 4.2.2 Persistent mailbox - is full 1570 Disk full 1571 4.3.1 Persistent system - is full 1573 Command out of sequence 1574 5.5.1 Permanent protocol - error 1576 Frame Error 1577 5.5.2 Permanent protocol - syntax error 1579 Mailbox does not support FAX 1580 5.6.1 Permanent media - not capable 1582 Mailbox does not support TEXT 1583 5.6.1 Permanent media - not capable 1585 Sender is not authorized 1586 5.7.1 Permanent security - sender not authorized 1588 Message marked private, but system is not private capable 1589 5.3.3 Permanent system - not private capable 1591 17. Appendix D - audio/32KADPCM Content Type 1593 Mime type name: audio 1594 Mime Sub-Type name: 32KADPCM 1595 Required Parameters: None 1596 Optional Parameters: None 1597 Encoding Considerations: Binary or Base-64 generally preferred 1599 ITU-T Recommendation G.726 [G726] (was G.721) describes the algorithm 1600 recommended for conversion of a single 64 kbit/s A-law or mu-law PCM 1601 channel encoded at 8000 samples/sec to and from a 32 kbit/s channel. 1602 The conversion is applied to the PCM stream using an Adaptive 1603 Differential Pulse Code Modulation (ADPCM) transcoding technique. 1605 No header information shall be included as part of the audio data. 1606 The 4-bit code words of the G.726 encoding MUST be packed into 1607 octets/bytes as follows: the first code word is placed in the four 1608 least significant bits of the first octet, with the least significant 1609 bit of the code word in the least significant bit of the octet; the 1610 second code word is placed in the four most significant bits of the 1611 first octet, with the most significant bit of the code word in the 1612 most significant bit of the octet. Subsequent pairs of the code words 1613 shall be packed in the same way into successive octets, with the first 1614 code word of each pair placed in the least significant four bits of 1615 the octet. It is preferred that the voice sample be extended with 1616 silence such that the encoded value comprises an even number of code 1617 words. However, if the voice sample comprises an odd number of code 1618 words, then the last code word shall be discarded. 1620 In the context of VPIM, the Content-Description header SHOULD be used 1621 to describe the contents of the audio body. The header must be able 1622 to be parsed to find these identifying phrases: Voice Message, 1623 Originator Spoken Name, Recipient Spoken Name, or Spoken Subject. 1625 Other headers may be used with their defined semantics. 1627 18. Appendix E - image/TIFF Content Type 1629 Mime type name: image 1630 Mime Sub-Type name: TIFF 1631 Required Parameters: None 1632 Optional Parameters: None 1633 Encoding Considerations: Binary or Base-64 generally preferred 1635 18.1 References 1637 TIFF (Tag Image File Format) is defined in: 1639 TIFF (TM) Revision 6.0 - Final _ June 3, 1992 1641 Adobe Developers Association 1643 Adobe Systems Incorporated 1644 1585 Charleston Road 1645 P.O. Box 7900 Mountain View, CA 94039-7900 1647 A copy of this specification can be found in: 1649 ftp://ftp.adobe.com/pub/adobe/DeveloperSupport/TechNotes/PDFfiles 1651 TIFF Class F has previously never been documented in a detailed 1652 fashion. However, it is clearly defined in Section 10.7.4 Spatial 1653 Media of: 1655 Enterprise Computer Telephony Forum 1656 S.100 Revision 1.0 1657 Media Services "C" Language 1658 Application Programming Interfaces 1660 THE ECT Forum 1661 303 Vintage Park Drive 1662 Foster City, CA 94404-1138 1664 A copy of this specification can be found in: 1666 http://www.ectf.org/ectf_s100.html 1668 18.2 TIFF Class F 1670 The essential parts of the ECTF S.100 definition are repeated here: 1672 All implementations must be able to read and write) TIFF files meeting 1673 the requirements below. Image data must not have any coding errors. 1674 Implementations may also read any other formats as long as available 1675 formats can be disclosed to applications at run time. 1677 ByteOrder: MM,II (Either byte order is allowed) 1679 These tags shown below must be readable. If not present, receiving 1680 implementation must use default shown: 1682 TIFF Tags 1684 Tag | Legal | Default |Comment 1685 ------------------|-------------|--------------|---------------------- 1686 BitsPerSample | 1 | 1 |one bit per sample 1687 CleanFaxData | 0 | 0 |data has no errors 1688 Compression | 3 | 3 |T.4 bi-level encoding, 1689 | | | MH 1690 FillOrder | 2,1 | 2 |LSB first or MSB first 1691 ImageWidth | 1728 | 1728 | 1692 ImageLength | >0 | |required 1693 NewSubFileType | 2 | 2 |single page of 1694 | | |multipage file 1695 Orientation | 1 | 1 |1st row=top left, 1696 | | | 1st col=top 1697 PageNumber | X/X | 0/1 |pg/tot, 0 base, 1698 | | | tot in 1st IFD 1699 PhotometricInterp | 0 | 0 |0 is white 1700 ResolutionUnit | 2 | 2 |inches 1701 RowsPerStrip |=ImageLength |=ImageLength | 1702 SamplesPerPixel | 1 | 1 |one sample per pixel 1703 StripByteCounts | >0 | |required 1704 StripOffsets | >0 | |required 1705 T4Options | 4 | 4 |MH, byte aligned EOL 1706 Xresolution | 204,200,77 | 204 | 1707 Yresolution | 196,98,100, | 196 | 1708 | 200,77,38.5 | | 1709 ------------------|-------------|--------------|---------------------- 1711 Other tags may be present, but must be of the sort that can be ignored 1712 safely by implementations (i.e. purely informational). 1714 Recommended informational tags are: 1716 Software, Datetime, BadFaxLines, ConsecutiveBadFaxLines 1718 19. Appendix F - Change History: RFC 1911 to this Document 1720 This update is based on the experience of a proof of concept 1721 demonstration of VPIM at EMA'96 in April 1996. This version of the 1722 profile is significantly different from the previous. These changes 1723 are detailed below: 1725 1. General 1727 - Various editorial updates to improve readability 1729 - Changed the Voice version to 2.0 1731 - Added Table of Contents and more examples 1733 - Refined audio/32KADPCM (nibble order) and image/TIFF (tag defaults) 1734 definitions 1736 2. Content 1738 - Deprecated multipart/voice-message content because of the removal of 1739 positional dependence of contents and the desire to interoperate with 1740 minimal MIME implementations 1742 - Explicitly defined the forwarding model using message/RFC822 1744 - Eliminated the text name in the "To" and "CC" headers. Edited the 1745 conformance to require last-name, first-name only for persons 1747 - Described handling of private messages 1749 - Profiled the Vcard in the application/directory body part for 1750 transport of directory information on the originator 1752 - Added support for facsimile using the refined image/TIFF content 1754 - Loosened text restriction 1756 - Added suggested addressing formats 1758 - Added additional details on delivery notifications 1760 3. Transport 1762 - Moved binary support to optional 1764 - Added ESMTP keyword for Return of Status codes 1766 4. Compliance 1768 - Added an explicit section on conformance allowing conformance to all 1769 or any of three conformance areas 1771 - Improved conformance table 1773 20. Appendix G -- Open Issues 1775 1) Finalize changes appendix 1777 2) Finalize Vcard references 1779 3) If there is no From: field should reply be prohibited? What is the 1780 value of the From field in the case of a telephone answering message. 1782 4) Should the spoken name be inline in the VCARD, in a separate body 1783 part, or both, or either. 1785 5) Read receipts are not mature enough to include. OK? 1787 6) Where do we draw the line on extensions for VPIM v2? (e.g. requests 1788 to add multipart/voice-message and now the multipart/alternative) 1790 7) Include TIFF G4 Options?