idnits 2.17.1 draft-ema-vpim-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-19) 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 39 longer pages, the longest (page 2) being 59 lines 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 354 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 321: '...x named "postmaster" MUST exist on all...' RFC 2119 keyword, line 330: '...named "loopback" SHOULD be designated ...' RFC 2119 keyword, line 332: '... to this mailbox MUST be returned back...' RFC 2119 keyword, line 334: '...returned address MUST be "postmaster" ...' RFC 2119 keyword, line 352: '...As a result, recipient information MAY...' (107 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: ---------------------------------------------------------------------------- -- 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 9, 1996) is 10084 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 256, but not defined ** Obsolete undefined reference: RFC 822 (Obsoleted by RFC 2822) == Missing Reference: 'DRPT' is mentioned on line 259, but not defined -- Looks like a reference, but probably isn't: '822' on line 555 == Missing Reference: 'X400' is mentioned on line 547, but not defined == Missing Reference: 'NOTARY' is mentioned on line 981, but not defined == Unused Reference: 'AMIS-A' is defined on line 1097, but no explicit reference was found in the text == Unused Reference: 'AMIS-D' is defined on line 1100, but no explicit reference was found in the text == Unused Reference: 'MSG822' is defined on line 1106, but no explicit reference was found in the text == Unused Reference: '8BIT' is defined on line 1124, but no explicit reference was found in the text == Unused Reference: 'DNS1' is defined on line 1130, but no explicit reference was found in the text == Unused Reference: 'DNS2' is defined on line 1133, but no explicit reference was found in the text == Unused Reference: 'MADMAN' is defined on line 1162, but no explicit reference was found in the text == Unused Reference: 'RELATED' is defined on line 1167, 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 1566 (ref. 'MADMAN') (Obsoleted by RFC 2249, RFC 2789) ** 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. 'MDN' -- 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: 29 errors (**), 0 flaws (~~), 15 warnings (==), 14 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 9, 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 4 53 2. SCOPE 5 55 2.1 Voice Messaging System Limitations 5 57 2.2 Design Goals 6 59 3. PROTOCOL RESTRICTIONS 7 61 4. VOICE MESSAGE INTERCHANGE FORMAT 8 63 4.1 Message Addressing Formats 8 65 4.2 Message Header Fields 10 67 4.3 Message Content Types 15 69 4.4 Forwarded Messages 20 71 5. MESSAGE TRANSPORT PROTOCOL 21 73 5.1 ESMTP Commands 21 75 5.2 ESMTP Keywords 23 77 5.3 ESMTP Parameters - MAIL FROM 24 79 5.4 ESMTP Parameters - RCPT TO 24 81 5.5 ESMTP - SMTP Downgrading 24 83 6. DIRECTORY ADDRESS RESOLUTION 25 85 7. IMAP 25 87 8. MANAGEMENT PROTOCOLS 25 89 8.1 Network Management 25 91 9. CONFORMANCE REQUIREMENTS 26 92 10. REFERENCES 27 94 11. SECURITY CONSIDERATION 29 96 12. ACKNOWLEDGMENTS 29 98 13. AUTHORS' ADDRESSES 29 100 14. APPENDIX A - VPIM REQUIREMENTS SUMMARY 30 102 15. APPENDIX B - EXAMPLE VOICE MESSAGES 34 104 16. APPENDIX C - EXAMPLE ERROR VOICE PROCESSING ERROR CODES 37 106 17. APPENDIX D - AUDIO/32KADPCM CONTENT TYPE 38 108 18. APPENDIX E - IMAGE/TIFF CONTENT TYPE 39 110 18.1 References 39 112 18.2 TIFF Class F 39 114 19. APPENDIX F - CHANGE HISTORY: RFC 1911 TO THIS DOCUMENT 42 116 20. APPENDIX G -- OPEN ISSUES 43 117 1. Abstract 119 A class of special-purpose computers has evolved to provide voice 120 messaging services. These machines generally interface to a telephone 121 switch and provide call answering and voice messaging services. 122 Traditionally, messages sent to a non-local machine are transported 123 using analog networking protocols based on DTMF signaling and analog 124 voice playback. As the demand for networking increases, there is a 125 need for a standard high-quality digital protocol to connect these 126 machines. The following document is a profile of the Internet 127 standard MIME and ESMTP protocols for use as a digital voice messaging 128 networking protocol. 130 This profile is based on an earlier effort in the Audio Message 131 Interchange Specification (AMIS) group to define a voice messaging 132 protocol based on X.400 technology. This protocol is intended to 133 satisfy the user requirements statement from that earlier work with 134 the industry standard ESMTP/MIME mail protocol infrastructures already 135 used within corporate intranets. This Internet Draft will be referred 136 to as VPIM (Voice Profile for Internet Mail) in this document. This 137 second version of VPIM is based on implementation experience and 138 obsoletes RFC 1911 which describes version 1 of the profile. 140 2. Scope 142 MIME is the Internet multipurpose, multimedia messaging standard. 143 This document explicitly recognizes its capabilities and provides a 144 mechanism for the exchange of various messaging technologies, 145 highlighting voice and facsimile. 147 This document specifies a restricted profile of the Internet 148 multimedia messaging protocols for use between voice processing 149 platforms. These platforms have historically been special-purpose 150 computers and often do not have the same facilities normally 151 associated with a traditional Internet Email-capable computer. As a 152 result, VPIM also specifies additional functionality as it is needed. 153 This profile is intended to specify the minimum common set of features 154 to allow interworking between compliant systems. 156 2.1 Voice Messaging System Limitations 158 The following are typical limitations of voice messaging platform 159 which were considered in creating this baseline profile. 161 1) Text messages are not normally received and often cannot be 162 displayed or viewed. They can often be processed only via text-to- 163 speech or text-to-fax features not currently present in many of 164 these machines. 166 2) Voice mail machines usually act as an integrated Message 167 Transfer Agent, Message Store and User Agent. There is no relaying 168 of messages and RFC 822 header fields may have limited use in the 169 context of the limited messaging features currently deployed. 171 3) VM message stores are generally not capable of preserving the 172 full semantics of an Internet message. As such, use of a voice 173 mail machine for gatewaying is not supported. In particular, 174 storage of "CC" lists, "Received" lines, and "Message-ID" may be 175 limited. 177 4) Internet-style distribution/exploder mailing lists are not 178 typically supported. Voice mail machines often implement only 179 local alias lists, with error-to-sender and reply-to-sender 180 behavior. Reply-all capabilities using a CC list is not generally 181 available. 183 5) Error reports must be machine-parsable so that helpful responses 184 can be voiced to users whose only access mechanism is a telephone. 186 6) The voice mail systems generally limit address entry to 16 or 187 fewer numeric characters, and normally do not support alphanumeric 188 mailbox names. Alpha characters are not generally used for mailbox 189 identification as they cannot be easily entered from a telephone 190 terminal. 192 2.2 Design Goals 194 It is a goal of this effort to make as few restrictions and additions 195 to the existing Internet mail protocols as possible while satisfying 196 the requirements for interoperability with current generation voice 197 messaging systems. This goal is motivated by the desire to increase 198 the accessibility to digital messaging by enabling the use of proven 199 existing networking software for rapid development. 201 This specification is intended for use on a TCP/IP network, however, 202 it is possible to use the SMTP protocol suite over other transport 203 protocols. The necessary protocol parameters for such use is outside 204 the scope of this document. 206 This profile is intended to be robust enough to be used in an 207 environment such as the global Internet with installed base gateways 208 which do not understand MIME, though typical use is expected to be 209 within corporate intranets. Full functionality such, as reliable 210 error messages and binary transport, will require careful selection of 211 gateways (via MX records) to be used as VPIM forwarding agents. 212 Nothing in this document precludes use of a general purpose MIME email 213 packages to read and compose VPIM messages. While no special 214 configuration is required to receive VPIM compliant messages, some may 215 be required to originate compliant structures. 217 It is expected that a VPIM messaging system will be managed by a 218 system administrator who can perform TCP/IP network configuration. 219 When using facsimile or multiple voice encodings, it is suggested that 220 the system administrator maintain a list of the capabilities of the 221 networked mail machines to reduce the sending of undeliverable 222 messages due to lack of feature support. Configuration, 223 implementation and management of this directory listing capabilities 224 is a local matter. 226 3. Protocol Restrictions 228 This protocol does not limit the number of recipients per message. 229 Where possible, implementations should not restrict the number of 230 recipients in a single message. It is recognized that no 231 implementation supports unlimited recipients, and that the number of 232 supported recipients may be quite low. However, ESMTP currently does 233 not provide a mechanism for indicating the number of supported 234 recipients. 236 This protocol does not limit the maximum message length. Implementors 237 should understand that some machines will be unable to accept 238 excessively long messages. A mechanism is defined in the RFC 1425 239 SMTP service extensions to declare the maximum message size supported. 241 The message size indicated in the ESMTP SIZE command is in bytes, not 242 minutes or seconds. The number of bytes varies by voice encoding 243 format and must include the MIME wrapper overhead. If the length must 244 be known before sending, an approximate translation into minutes or 245 seconds can be performed if the voice encoding is known. 247 The following sections describe the restrictions and additions to 248 Internet mail that are required to be compliant with this VPIM v2 249 profile. A table in Appendix A summarizes the details. 251 4. Voice Message Interchange Format 253 The voice message interchange format is a profile of the Internet Mail 254 Protocol Suite. As such, this document assumes an understanding of 255 these specifications. Specifically, VPIM references components from 256 the message format standard for Internet messages [RFC822], the 257 Multipurpose Internet Message Extensions [MIME], the X.400 gateway 258 specification [X.400], delivery status notification 259 [DRPT][NOTIFY][STATUS], the message disposition notifications [MDN], 260 and the electronic business card [DIRECTORY][VCARD]. 262 4.1 Message Addressing Formats 264 RFC 822 addresses are based on the domain name system. This naming 265 system has two components: the local part, used for username or 266 mailbox identification; and the host part, used for global machine 267 identification. 269 4.1.1 VPIM Addresses 271 The local part of the address shall be a US-ASCII string uniquely 272 identifying a mailbox on a destination system. For voice messaging, 273 the local part is a printable string containing the mailbox ID of the 274 originator or recipient. While alpha characters and long mailbox 275 identifiers are permitted, most voice mail networks rely on numeric 276 mailbox identifiers to retain compatibility with the limited 10 digit 277 telephone keypad. The use of the domain naming system should be 278 transparent to the user. It is the responsibility of the voice mail 279 machine to lookup the fully-qualified domain name (FQDN) based on the 280 address entered by the user (see Section 6). 282 In the absence of a global directory, specification of the local part 283 is expected to conform to international or private telephone numbering 284 plans. It is likely that private numbering plans will prevail and 285 these are left for local definition. However, public telephone 286 numbers will be noted according to the international numbering plan 287 described in [E.164] and will be preceded by a `+'. The specification 288 of the local part of a VPIM address can be split into the four groups 289 described below: 291 1) mailbox number 292 - for use as a private numbering plan (any number of digits) 293 - e.g. 2722@octel.com 295 2) mailbox number+extension 296 - for use as a private numbering plan with extensions 297 any number of digits, use of `+' as separator 298 - e.g. 2722+111@octel.com 300 3) +international number 301 - for international telephone numbers conforming to E.164 302 maximum of 15 digits 303 - e.g. +16137637582@vm.nortel.ca 305 4) +international number+extension 306 - for international telephone numbers conforming to E.164 307 maximum of 15 digits, with an extension (e.g. behind a 308 PBX) that has a maximum of 15 digits. 309 - e.g. +17035245550+230@ema.org 311 4.1.2 Special Addresses 313 Special addresses are provided for compatibility with the conventions 314 of Internet mail and to facilitate testing. These addresses do not 315 use numeric local addresses, both to conform to current Internet 316 practice and to avoid conflict with existing numeric addressing plans. 317 Two special addresses are RESERVED for use as follows: 319 Postmaster@domain 321 By convention, a special mailbox named "postmaster" MUST exist on all 322 systems. This address is used for diagnostics and should be checked 323 regularly by the system manager. This mailbox is particularly likely 324 to receive text messages, which is not normal on a voice processing 325 platform. The specific handling of these messages is an individual 326 implementation choice. 328 Loopback@domain 330 A special mailbox name named "loopback" SHOULD be designated for 331 loopback testing. If supported, all messages (including content) sent 332 to this mailbox MUST be returned back to the address listed in the 333 From: address as a new message. The originating address of the 334 returned address MUST be "postmaster" to prevent mail loops. 336 4.1.3 Distribution Lists 338 There are many ways to handle distribution list (DL) expansions and 339 none are 'standard'. Simple alias is a behavior closest to what most 340 voice mail systems do today and what is to be used with VPIM messages. 341 That is: 343 Reply to the originator - (Address in the RFC822 From field) 344 Errors to the submitter - (Address in the MAIL FROM: field of the 345 ESMTP exchange and the Return-Path: 346 RFC 822 field) 348 Some proprietary voice messaging protocols include only the recipient 349 of the particular copy in the envelope and include no "headers" except 350 date and per-message features. Most voice messaging systems do not 351 provide for "Header Information" in their messaging queues and only 352 include delivery information. As a result, recipient information MAY 353 be in either the To or CC headers. Other recipients MAY optionally be 354 included, however it is often not accurate enough for the reply-all 355 capability. 357 4.2 Message Header Fields 359 Internet messages contain a header information block. This header 360 block contains information required to identify the sender, the list 361 of recipients, the message send time, and other information intended 362 for user presentation. Except for specialized gateway and mailing 363 list cases, headers do not indicate delivery options for the transport 364 of messages. 366 Exploder lists are noted for modifying or adding to the headers of 367 messages that pass through them. VPIM systems MUST be able to accept 368 and ignore headers that are not defined here. 370 The following header lines are permitted for use with VPIM voice 371 messages: 373 4.2.1 From 375 The originator's fully-qualified domain address (a mailbox address 376 followed by the fully-qualified domain name). The user listed in this 377 field should be presented in the voice message envelope as the 378 originator of the message. 380 Systems compliant with this profile SHOULD provide the text personal 381 name of the sender in a quoted phrase if the name is available. To 382 facilitate storage of the text name in a local dial-by-name cache 383 directory, the first and last name names must be separable. Text 384 names of persons in voice messages MUST be represented in the form 385 "last, first, mi." and MUST be the same as found in the Vcard (section 386 4.3.4), if present. Text names of corporate or positional mailboxes 387 MAY be provided as a simple string. From [822] 389 Example: 391 From: "User, Joe, S." <2145551212@mycompany.com> 393 From: "Technical Support" <611@serviceprovider.com> 395 If a From: address is present, it MAY be used to construct a reply 396 message to the sender. 398 4.2.2 To 400 The To header contains the recipient's fully-qualified domain address. 401 There may be one or more To: fields in any message. 403 Example: 405 To: 2145551213@mycompany.com 407 Systems compliant to this profile SHOULD provide a list of recipients 408 only if all recipients can be provided. The To header MUST NOT be 409 included in the message if the sending message transport agent (MTA) 410 cannot resolve all the addresses in it, e.g. if an address is a DL 411 alias for which the expansion is unknown (see section 4.1.3). If 412 present, the addresses in the To header MAY be uses for a reply 413 message to all primary recipients. 415 4.2.3 cc 417 The cc header contains additional recipients' fully-qualified domain 418 addresses. Many voice mail systems maintain only sufficient envelope 419 information for message delivery and are not capable of storing or 420 providing a complete list of recipients. Systems compliant to this 421 profile SHOULD provide a list of recipients only if all disclosed 422 recipients can be provided. The list of disclosed recipients does not 423 include those sent via a blind copy. If not, systems SHOULD omit the 424 CC headers to indicate that the full list of recipients is unknown. 426 Example: 428 cc: 2145551213@mycompany.com 430 Systems compliant to this profile MAY discard the cc addresses of 431 incoming messages as necessary. If a list of CC addresses is 432 present, these addresses MAY be used for a reply message to all 433 recipients. 435 4.2.4 Date 437 The Date header contains the date, time, and time zone in which the 438 message was sent by the originator. The time zone SHOULD be 439 represented in a four-digit time zone offset, such as -0600 for North 440 American Eastern Standard Time. This may be supplemented by a time 441 zone name in parentheses, e.g., "-0800 (PDT)". Compliant 442 implementations SHOULD be able to convert RFC 822 date and time stamps 443 into local time. 445 Example: 447 Date: Wed, 28 Jul 96 10:08:49 -0900 (PST) 449 The sending system MUST report the time the message was sent. From 450 [822] 452 4.2.5 Sender 454 The Sender header contains the actual address of the originator if the 455 message is sent by an agent on behalf of the author indicated in the 456 From: field and MAY be present in a VPIM message. 458 While it may not be possible to save this information in some voice 459 mail machines, discarding this information or the ESMTP MAIL FROM 460 address will make it difficult to send an error message to the proper 461 destination. From [822] 463 4.2.6 Message-id 465 The Message-id header contains a unique per-message identifier. A 466 unique message-id MUST be generated for each message sent from a 467 compliant implementation. 469 The message-id is not required to be stored on the receiving system. 470 This identifier MAY be used for tracking, auditing, and returning 471 read-receipt reports. From [822] 473 Example: 475 Message-id: <12345678@mycompany.com> 477 4.2.7 Received 479 The Received header contains trace information added to the beginning 480 of a RFC 822 message by MTAs. This is the only header permitted to be 481 added by an MTA. Information in this header is useful for debugging 482 when using an US-ASCII message reader or a header parsing tool. 484 A compliant system MUST add Received headers when acting as a gateway 485 and MUST NOT remove any. These headers MAY be ignored or deleted when 486 the message is received at the final destination. From [822] 488 4.2.8 MIME Version 490 The MIME-Version header indicates that the message conforms to the 491 MIME message format specification. Systems compliant with this 492 specification MUST include a comment with the words "(Voice 2.0)". RFC 493 1911 defines an earlier version of this profile and uses the token 494 (Voice 1.0). From [MIME][VPIM1] 496 Example: 498 MIME-Version: 1.0 (Voice 2.0) 500 4.2.9 Content-Type 502 The content-type header declares the type of content enclosed in the 503 message. One of the allowable contents is multipart/mixed, a 504 mechanism for bundling several message components into a single 505 message. The allowable contents are detaileded in the section 4.3 of 506 this document. From [MIME] 508 4.2.10 Content-Transfer-Encoding 510 Because Internet mail was initially specified to carry only 7-bit US- 511 ASCII text, it may be necessary to encode voice and fax data into a 512 representation suitable for that environment. The content-transfer- 513 encoding header describes this transformation if it is needed. 514 Compliant implementations MUST recognize and decode the standard 515 encodings, "Binary", "7bit, "8bit", "Base64" and "Quoted-Printable". 516 The allowable content-transfer-encodings are specified in section 4.3. 517 From [MIME] 519 4.2.11 Sensitivity 521 The sensitivity header, if present, indicates the requested privacy 522 level. The case-insensitive values "Personal" and "Private" are 523 specified. If no privacy is requested, this field is omitted. 525 If a sensitivity header is present in the message, a compliant system 526 MUST prohibit the recipient from forwarding this message to any other 527 user. A compliant system, however, SHOULD allow the user to reply to 528 a sensitive message, but SHOULD NOT include the original message 529 content. The sensitivity of the reply message MAY be set by the user. 531 If the receiving system does not support privacy and the sensitivity 532 is one of "Personal" or "Private", the message MUST be returned to the 533 sender with an appropriate error code indicating that privacy could 534 not be assured and that the message was not delivered. A non-delivery 535 notification to a private message need not be tagged private since it 536 will be sent to the originator. From: [X.400] 538 4.2.12 Importance 540 Indicates the requested priority to be given by the receiving system. 541 The case-insensitive values "low", "normal" and "high" are specified. 542 If no special importance is requested, this header may be omitted and 543 the value assumed to be "normal". 545 Compliant implementations MAY use this header to indicate the 546 importance of a message and may order messages in a recipient's 547 mailbox. From: [X400] 549 4.2.13 Subject 551 The subject field is often provided by email systems but is not widely 552 supported on Voice Mail platforms. For compatibility with text based 553 mailbox interfaces, a text subject field SHOULD be generated by a 554 compliant implementation but MAY be discarded if present by a 555 receiving system. From [822] 557 It is recommended that voice messaging systems that do not support any 558 text user interfaces (e.g. access only by a telephone) insert a 559 generic subject header of "VPIM Message" for the benefit of text 560 enabled recipients. 562 4.3 Message Content Types 564 MIME, introduced in [MIME], is a general-purpose message body format 565 that is extensible to carry a wide range of body parts. It provides 566 for encoding binary data so that it can be transported over the 7-bit 567 text-oriented SMTP protocol. This transport encoding is in addition 568 to the audio encoding required to generate a binary object. 570 MIME defines two transport encoding mechanisms to transform binary 571 data into a 7 bit representation, one designed for text-like data 572 ("Quoted-Printable"), and one for arbitrary binary data ("Base64"). 573 While Base64 is dramatically more efficient for audio data, both will 574 work. Where binary transport is available, no transport encoding is 575 needed, and the data can be labeled as "Binary". 577 An implementation in compliance with this profile SHOULD send audio 578 and/or facsimile data in binary form when binary message transport is 579 available. When binary transport is not available, implementations 580 MUST encode the audio and/or facsimile data as Base64. The detection 581 and decoding of "Quoted-Printable", "7bit", and "8bit" MUST be 582 supported in order to meet MIME requirements and to preserve 583 interoperability with the fullest range of possible devices. However, 584 if a content is received that cannot be rendered to the user, an 585 appropriate non-delivery notifcation MUST be sent. 587 The content types described in this section are identified for use 588 with this profile. Each of these contents can be sent individually in 589 a VPIM message or wrapped in a multipart/mixed to form a more complex 590 structure (several examples are given in Appendix B). When mulitple 591 contents are present, they SHOULD be presented to the user in the 592 order that they appear in the message. 594 4.3.1 Text/Plain 596 MIME requires support of the basic Text/Plain content type. This 597 content type has limited applicability within the voice messaging 598 environment. Compliant implementations SHOULD NOT send the Text/Plain 599 content-type and SHOULD only send this content if the recipient system 600 is known to support it. Compliant implementations MUST accept 601 Text/Plain messages, however, specific handling is left as an 602 implementation decision. From [MIME] 604 There are several mechanisms that can be used to support text on voice 605 messaging systems including text-to-speech and text-to-fax 606 conversions. If no rendering of the text is possible (i.e. it is not 607 possible to determine if the text is a critical part of the message), 608 the entire message MUST be non-delivered and returned to the sender 609 with a media-unsupported error code. 611 4.3.2 Multipart/Mixed 613 MIME provides the facilities for enclosing several body parts in a 614 single message. Multipart/Mixed SHOULD be used for sending multi- 615 segment voice messages, that is, to preserve across the network the 616 distinction between an annotation and a forwarded message, or between 617 a spoken subject and the voice message. Compliant systems MUST accept 618 multipart/mixed body parts. Systems MAY collapse such a multi-segment 619 voice or fax message into a single segment if multi-segment messages 620 are not supported on the receiving machine. From [MIME] 622 While any valid MIME body header MAY be used, the following header has 623 specific semantics when included with this body part: 625 4.3.2.1 Content-Description: 627 This field SHOULD be present to allow the text identification of 628 this body part as being a VPIM message. This is particulary useful 629 for identification when using a simple MIME mail package. If there 630 are multiple multipart/mixed bodies present, then this header MUST 631 be present to allow differentiation. It is recommended that the 632 value `VPIM Message' be used to identify content compliant with 633 this document. 635 4.3.3 Message/RFC822 637 MIME requires support of the Message/RFC822 message encapsulation body 638 part. This body part is used within a multipart/mixed message to 639 forward complete messages (see section 4.4) or to reply with original 640 content. From [MIME] 642 4.3.4 Application/Directory 644 The spoken name and the spelled name of the message sender SHOULD be 645 sent with each message in an Application/Directory content type 646 [DIRECTORY]. If included in a message, the Versit VCARD profile MUST 647 be used [VCARD] and MUST specify at least the following attributes: 649 TEL - telephone number (various types, typically VOICE) 650 EMAIL - email address (various types, typically INTERNET) 652 The following attributes SHOULD be specified: 654 N - Family Name, Given Name, Additional Names, Honorific Prefixes, 655 and Suffixes (all present components in the From text name MUST 656 match) 657 ROLE - alternative to `N' attribute when sender is a corporate or 658 positional mailbox 659 SOUND - sound data (various types, typically 32KADPCM) 660 REV - Revision of Vcard in ISO 8601 date format 662 The content MAY use the other types (e.g. capabilities) as defined in 663 [VCARD]. 665 The spoken name SHOULD be denoted by a content ID pointing to an 666 audio/* content elsewhere in the VPIM message. Alternatively, the 667 spoken name MAY be included inline in the "SOUND" type using a Base64 668 encoding of typically 32KADPCM. However, it MUST NOT be denoted using 669 an URL. 671 For the Vcard to be identified as the sender's, it MUST include the 672 EMAIL token 'VPIM' and match the address in the From: header. The 673 Name, if present, SHOULD NOT be used for comparison since the Vcard 674 has more components. 676 There MUST only be one Vcard per VPIM message. If more than one is 677 present it is an error condition, all Vcards not associated with with 678 the sender may be discarded. 680 Example: 682 BEGIN: vCard 683 N: Parsons;Glenn 684 ORG: Nortel Technology 685 TEL;TYPE=VOICE,MSG,WORK: +1-613-763-7582 686 EMAIL;TYPE=INTERNET: glenn.parsons@nortel.ca 687 EMAIL;TYPE=INTERNET,VPIM: 6137637582@vm.nortel.ca 688 SOUND;TYPE=32KADPCM;ENCODE=BASE64;VALUE=INLINE: 689 iIiIiIjMzN3czdze3s7d7fwfHhcvESJVe/4yEhLz8/FOQjVFRERCESL/zqrq 690 (This is the Spoken Name audio data) 3Or/zrPCzxv43u3L7buR3b0 691 AAEAAAAIAAAAFQEDAAEAAAABAAAAFgEEAAEAAACqCAAAFwEEAAEAAAD1uQEA 692 GgEFAAEAAAAIugEAGwEFAAEAAAAQugEAJAEEAAEAAAAEAAAAAAAAAA== 693 REV: 19960831T103310Z 694 END: vCard 696 4.3.5 Audio/32KADPCM 698 CCITT Recommendation G.726 [G726] describes the algorithm recommended 699 for conversion of a 64 kbit/s A-law or u-law PCM channel to and from a 700 32 kbit/s channel (this is the same algorithm as the deprecated 701 G.721). The conversion is applied to the PCM stream using an Adaptive 702 Differential Pulse Code Modulation (ADPCM) transcoding technique. 704 An implementation compliant to this profile MUST use Audio/32KADPCM by 705 default for voice. Typically this body contains several minutes of 706 message content, however if used for spoken name or subject the 707 content should be considerably shorter (i.e. about 10 and 20 seconds 708 respectively). 710 While any valid MIME body header MAY be used, several headers have the 711 following semantics when included with this body part: 713 4.3.5.1 Content-Description: 715 This field SHOULD be present to allow the parsable text 716 identification of these body parts. If more than one 717 Audio/32KADPCM body occurs within a single multipart/mixed, then 718 this header MUST be present to allow differentiation. It is 719 recommended that the following text values be used as appropriate: 721 Voice Message - the primary voice message, 722 Originator Spoken Name - the spoken name of the originator, 723 Recipient Spoken Name - the spoken name of the recipient if 724 available to the originator and present if there is ONLY one 725 recipient, 726 Spoken Subject.- the spoken subject of the message, typically 727 spoken by the originator 729 4.3.5.2 Content-Duration: 731 This field MAY be present to allow the specification of the length 732 of the bodypart in seconds. The use of this field on reception is 733 a local implementation issue. The formal BNF for this header is: 735 duration := "Content-Duration" ":" 1*6DIGIT "seconds" 737 Example: 739 Content-Duration: 33 seconds 741 4.3.5.3 Content-Language: 743 This field MAY be present to allow the specification of the spoken 744 language of the bodypart. The encoding is defined in [LANG] (e.g. 745 EN-UK for UK English). The use of this field on reception is a 746 local implementation issue. 748 4.3.6 Proprietary Voice Formats 750 Proprietary voice encoding formats or other standard formats may be 751 supported under this profile provided a unique identifier is 752 registered with the IANA prior to use. These voice encodings should 753 be registered as sub-types of Audio. 755 Use of any other encoding except Audio/32KADPCM reduces 756 interoperability in the absence of explicit manual system 757 configuration. A compliant implementation MAY use any other encoding 758 with explicit per-destination configuration. 760 4.3.7 Image/TIFF 762 All implementations MUST generate and read TIFF-F [TIFF][S100] 763 compatible facsimile contents. The tags that MUST be supported by 764 systems complying to this recommendation are described in the 765 Enterprise Computer Telephony Forum's S.100 API specification [S100]. 766 The TIFF-F content, originally from [TPC.INT] has been refined to 767 reflect this common practice, and is summarized in Appendix E for 768 completeness. 770 4.3.8 Multipart/report 772 An implementation MAY send this fax content in VPIM messages and MUST 773 be able to recognize it in received messages. If a fax message is 774 received that cannot be rendered to the user, then the system MUST 775 non-deliver the entire message with a media not supported error. 776 Multipart/Report 778 The Multipart/Report is used for enclosing a Message/Notification and 779 Message/Disposition-notification body parts and any returned message 780 content. Compliant implementations MUST use the Multipart/Report 781 construct when returning messages, sending warnings, or issuing read 782 receipts. Compliant implementations MUST recognize and decode the 783 Multipart/Report content type. From [REPORT] 785 4.3.9 Message/Notification 787 This MIME body part is used for sending machine-parsable delivery 788 status notifications. Compliant implementations must use the 789 Message/Notification construct when returning messages or sending 790 warnings. Compliant implementations must recognize and decode the 791 Message/Notification content type and present the reason for failure 792 to the user. From [NOTIFY] 794 4.3.10 Message/Disposition-notification 796 This MIME body part is used for sending machine-parsable read-receipt 797 and extended-absence status notifications. Compliant implementations 798 must use the Message/Disposition-notification construct when sending 799 post-delivery message status notifications. Compliant implementations 800 must recognize and decode the Message/Disposition-notification content 801 type and present the reason for failure to the user. From [MDN] 803 4.4 Forwarded Messages 805 VPIM version 2 explicitly supports the forwarding of voice and fax 806 content with voice or fax annotation. Forwarded VPIM messages SHOULD 807 be sent as a multipart/mixed with the entire original message enclosed 808 in a message/rfc822 content type and the annotation as a separate 809 Audio/* body part. 811 In the event that the RFC822 headers are not available for the 812 forwarded content, simulated headers with information as available 813 SHOULD be constructed to indicate the original sending timestamp, and 814 the original sender as indicated in the "From" line. The 815 message/rfc822 content MUST include at least the MIME-Version: 1.0 816 (Voice 2.0), the MIME content type and MIME content-encoding header as 817 necessary. 819 In the event that forwarding information is lost through concatenation 820 of the original message and the forwarding annotation, such as must be 821 done in an AMIS to VPIM gateway, the entire content MAY be sent as a 822 single Audio/* segment without including any forwarding semantics. 824 5. Message Transport Protocol 826 Messages are transported between voice mail machines using the 827 Internet Extended Simple Mail Transfer Protocol (ESMTP). All 828 information required for proper delivery of the message is included in 829 the ESMTP dialog. This information, including the sender and 830 recipient addresses, is commonly referred to as the message 831 "envelope". This information is equivalent to the message control 832 block in many analog voice networking protocols. 834 ESMTP is a general-purpose messaging protocol, designed both to send 835 mail and to allow terminal console messaging. Simple Mail Transport 836 Protocol (SMTP) was originally created for the exchange of US-ASCII 7- 837 bit text messages. Binary and 8-bit text messages have traditionally 838 been transported by encoding the messages into a 7-bit text-like form. 839 [ESMTP] formalized an extension mechanism for SMTP, and subsequent 840 RFCs have defined 8-bit text networking, command streaming, binary 841 networking, and extensions to permit the declaration of message size 842 for the efficient transmission of large messages such as multi-minute 843 voice mail. 845 The following sections list ESMTP commands, keywords, and parameters 846 that are required and those that are optional. 848 5.1 ESMTP Commands 850 5.1.1 HELO 852 Base SMTP greeting and identification of sender. This command is not 853 to be sent by compliant systems unless the more-capable EHLO command 854 is not accepted. It is included for compatibility with general SMTP 855 implementations. Compliant implementations MUST implement the HELO 856 command for backward compatibility but SHOULD NOT send it unless EHLO 857 is not supported. From [SMTP] 859 5.1.2 MAIL FROM (REQUIRED) 861 Originating mailbox. This address contains the mailbox to which 862 errors should be sent. This address may not be the same as the 863 message sender listed in the message header fields if the message was 864 received from a gateway or sent to an Internet-style mailing list. 865 Compliant implementations MUST implement the extended MAIL FROM 866 command. From [SMTP, ESMTP] 868 5.1.3 RCPT TO 870 Recipient's mailbox. This field contains only the addresses to which 871 the message should be delivered for this transaction. In the event 872 that multiple transport connections to multiple destination machines 873 are required for the same message, this list may not match the list of 874 recipients in the message header. Compliant implementations MUST 875 implement the extended RCPT TO command. From [SMTP, ESMTP] 877 5.1.4 DATA 879 Initiates the transfer of message data. Support for this command is 880 required in the event the binary mode command BDAT is not supported by 881 the remote system. Compliant implementations MUST implement the SMTP 882 DATA command for backwards compatibility. From [SMTP] 884 5.1.5 TURN 886 Requests a change-of-roles, that is, the client that opened the 887 connection offers to assume the role of server for any mail the remote 888 machine may wish to send. Because SMTP is not an authenticated 889 protocol, the TURN command presents an opportunity to improperly fetch 890 mail queued for another destination. Compliant implementations SHOULD 891 NOT implement the TURN command. From [SMTP] 893 5.1.6 QUIT 895 Requests that the connection be closed. If accepted, the remote 896 machine will reset and close the connection. Compliant 897 implementations MUST implement the QUIT command. From [SMTP] 899 5.1.7 RSET 901 Resets the connection to its initial state. Compliant implementations 902 MUST implement the RSET command. From [SMTP] 904 5.1.8 VRFY 906 Requests verification that this node can reach the listed recipient. 907 While this functionality is also included in the RCPT TO command, VRFY 908 allows the query without beginning a mail transfer transaction. This 909 command is useful for debugging and tracing problems. Compliant 910 implementations MAY implement the VRFY command. From [SMTP] 912 (Note that the implementation of VRFY may simplify the guessing of a 913 recipient's mailbox or automated sweeps for valid mailbox addresses, 914 resulting in a possible reduction in privacy. Various implementation 915 techniques may be used to reduce the threat, such as limiting the 916 number of queries per session.) From [SMTP] 918 5.1.9 EHLO 920 The enhanced mail greeting that enables a server to announce support 921 for extended messaging options. The extended messaging modes are 922 discussed in subsequent sections of this document. Compliant 923 implementations MUST implement the ESMTP command and return the 924 capabilities indicated later in this memo. From [ESMTP] 926 5.1.10 BDAT 928 The BDAT command provides a higher efficiency alternative to the 929 earlier DATA command, especially for voice. The BDAT command provides 930 for native binary transport of messages. Compliant implementations 931 SHOULD support binary transport using the BDAT command.[BINARY] 933 5.2 ESMTP Keywords 935 The following ESMTP keywords indicate extended features useful for 936 voice messaging. 938 5.2.1 PIPELINING 940 The "PIPELINING" keyword indicates ability of the receiving server to 941 accept pipelined commands. Pipelining commands dramatically improves 942 performance by reducing the number of round-trip packet exchanges and 943 makes it possible to validate all recipient addresses in one 944 operation. Compliant implementations SHOULD support the command 945 pipelining indicated by this parameter. From [PIPE] 947 5.2.2 SIZE 949 The "SIZE" keyword provides a mechanism by which the SMTP server can 950 indicate the maximum size message supported. Compliant 951 implementations MUST provide the size capability and SHOULD honor any 952 size limitations when sending. From [SIZE] 954 5.2.3 CHUNKING 956 The "CHUNKING" keyword indicates that the receiver will support the 957 high-performance binary transport mode. Note that CHUNKING can be 958 used with any message format and does not imply support for binary 959 encoded messages. Compliant implementations SHOULD support binary 960 transport indicated by this capability. From [BINARY] 962 5.2.4 BINARYMIME 964 The "BINARYMIME" keyword indicates that the SMTP server can accept 965 binary encoded MIME messages. Compliant implementations SHOULD support 966 binary transport indicated by this capability. From [BINARY] 968 5.2.5 NOTIFY 970 The "NOTIFY" keyword indicates that the SMTP server will accept 971 explicit delivery status notification requests. Compliant 972 implementations MUST support the delivery notification extensions in 973 [DSN]. 975 5.2.6 ENHANCEDSTATUSCODES 977 The "EHNAHCEDSTATUSCODES" keyword indicates that an SMTP server 978 augments its responses with the enhanced mail system status codes 979 [CODES]. These codes can then be used to provide more informative 980 explanations of error conditions, especially in the context of the 981 delivery status notifications format defined in [NOTARY]. Compliant 982 implementations SHOULD support this capability. From [STATUS] 984 5.3 ESMTP Parameters - MAIL FROM 986 5.3.1 BINARYMIME 988 The current message is a binary encoded MIME messages. Compliant 989 implementations SHOULD support binary transport indicated by this 990 parameter. From [BINARY] 992 5.4 ESMTP Parameters - RCPT TO 994 5.4.1 NOTIFY 996 The NOTIFY parameter indicates the conditions under which a delivery 997 report should be sent. Compliant implementations MUST honor this 998 request. From [DSN] 1000 5.4.2 RET 1002 The RET parameter indicates whether the content of the message should 1003 be returned. Compliant systems SHOULD honor a request for returned 1004 content. From [DSN] 1006 5.5 ESMTP - SMTP Downgrading 1008 To ensure a consistant 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. However, it is 1013 recommended that the downgrading system should continue to attempt to 1014 deliver the message via SMTP, but MUST send a delivery notification to 1015 the originator indicating that the message left an ESMTP host and was 1016 sent (unreliably) via SMTP. 1018 6. Directory Address Resolution 1020 It is the responsibility of a VPIM system to lookup the fully- 1021 qualified domain name (FQDN) based on the address entered by the user 1022 (if the entered address is not already a FQDN). This would typically 1023 be an issue on systems that offered only a telephone user interface. 1024 The mapping of the dialed target number to a routable address allowing 1025 delivery to the destination system can be accomplished through 1026 implementation-specific means. 1028 An implementations may wish to populate local directories with address 1029 information extracted from received messages. It is mandated that 1030 only address information from Vcard attachments to VPIM messages be 1031 used to populate such a directory when the Vcard is available. 1032 Stripping addresses from the headers of VPIM messages SHOULD NOT be 1033 used to populate directories as it only provides partial data. 1034 Alternatively, bilateral agreements could be made to allow the bulk 1035 transfer of Vcards between systems. 1037 7. IMAP 1039 The use of client/server desktop mailbox protocols like IMAP or POP to 1040 retrieve VPIM messages from a IMAP or POP message store is possible 1041 without any special modifications to this VPIM specification. Email 1042 clients (and web browsers) typically have a table for mapping from 1043 MIME type to displaying application. The audio/*, image/tiff and 1044 application/directory contents can be configured so that they invoke 1045 the correct player/recorder for rendering. In addition with IMAP 1046 clients, the first multipart/mixed content (if present) will not 1047 appear since it is generic. The user instead will be presented with a 1048 message that has (for example) audio and image contents. 1050 8. Management Protocols 1052 The Internet protocols provide a mechanism for the management of 1053 messaging systems, from the management of the physical network through 1054 the management of the message queues. SNMP should be supported on a 1055 compliant message machine. 1057 8.1 Network Management 1059 The digital interface to the VM and the TCP/IP protocols SHOULD be 1060 managed. MIB II SHOULD be implemented to provide basic statistics and 1061 reporting of TCP and IP protocol performance. [MIB II] 1063 Authors Note: Last time I checked, MADMAN was being rewritten for 1064 submission again as proposed standard. Without a profile, I don't 1065 think we should require this. Fine. Do you still want to require MIB 1066 II? 1068 9. Conformance Requirements 1070 In order to claim conformance to this document and be called `VPIM 1071 compliant', a voice messaging system must implement all mandatory 1072 features of this profile in each of three areas: Content, Transport, 1073 and Notifications. In addition, systems which conform to this profile 1074 must not send messages with features beyond this profile unless 1075 explicit per-destination configuration of these enhanced features is 1076 provided. Such configuration information could be stored in a 1077 directory, though the implementation of this is currently a local 1078 matter. 1080 It is also possible, though not encouraged, to claim conformance to 1081 only specific areas (e.g. VPIM content compliant) of this profile. 1082 The delineation of these areas is as follows: 1084 Content - Section 4.24, except REPORT, NOTIFY & MDN, and 1085 Section 6 1087 Transport - Section 5 except NOTIFY & RET, and Section 8 1089 Notifications - REPORT, NOTIFY & MDN from Section 4, NOTIFY & 1090 RET from Section 5 and all notification 1091 requirements. 1093 A summary of compliance requirements is contained in Appendix A. 1095 10. References 1097 [AMIS-A] Audio Messaging Interchange Specifications (AMIS) - Analog 1098 Protocol Version 1, Issue 2, February 1992 1100 [AMIS-D] Audio Messaging Interchange Specifications (AMIS) - Digital 1101 Protocol Version 1, Issue 3 August 1993 1103 [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail 1104 Extensions", RFC 1521, Bellcore, Innosoft, Sept 1993. 1106 [MSG822] Crocker, D., "Standard for the Format of ARPA Internet Text 1107 Messages", STD 11, RFC 822, UDEL, August 1982. 1109 [X.400] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021 1110 and RFC 822", RFC 1327, May 1992. 1112 [PIPE] Freed, N., Cargille, A., "SMTP Service Extension for Command 1113 Pipelining" RFC 1854, October 1995. 1115 [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, 1116 "SMTP Service Extensions" RFC 1869, United Nations University, 1117 Innosoft International, Inc., Dover Beach Consulting, Inc., Network 1118 Management Associates, Inc., The Branch Office, November 1995. 1120 [SIZE] Klensin, J, Freed, N., Moore, K, "SMTP Service Extensions for 1121 Message Size Declaration" RFC 1870, United Nations University, 1122 Innosoft International, Inc., November 1995. 1124 [8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E., D. Crocker, 1125 "SMTP Service Extension for 8bit-MIMEtransport" RFC 1426, United 1126 Nations University, Innosoft International, Inc., Dover Beach 1127 Consulting, Inc., Network Management Associates, Inc., The Branch 1128 Office, February 1993. 1130 [DNS1] Mockapetris, P., "Domain names - implementation and 1131 specification", RFC1035, Nov 1987. 1133 [DNS2] Mockapetris, P., "Domain names - concepts and facilities", RFC 1134 1034, Nov 1987. 1136 [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 1137 USC/Information Sciences Institute, August 1982. 1139 [BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of 1140 Large and Binary MIME Messages", RFC 1830, October 1995. 1142 [NOTIFY] Moore, K., Vaudreuil, G., "An Extensible Message Format for 1143 Delivery Status Notifications", RFC 1894, 01/15/1996. 1145 [REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the 1146 Reporting of Mail System Administrative Messages", RFC 1892, 1147 01/15/1996. 1149 [DSN] Moore, K. "SMTP Service Extensions for Delivery Status 1150 Notifications", RFC 1891, 01/15/1996 1152 [CODES] Vaudreuil, G. "Enhanced Mail System Status Codes", RFC 1893, 1153 01/15/1996. 1155 [STATUS] Freed, N. "SMTP Service Extension for Returning Enhanced Error 1156 Codes", Internet-Draft , July 1996. 1158 [G726] CCITT Recommendation G.726 (1990), General Aspects of Digital 1159 Transmission Systems, Terminal Equipment - 40, 32, 24,16 kbit/s 1160 Adaptive Differential Pulse Code Modulation (ADPCM). 1162 [MADMAN] N. Freed, S. Kille, "Mail Monitoring MIB", RFC 1566, Jan 1994. 1164 [MIB II] M. Rose, "Management Information Base for Network Management of 1165 TCP/IP-based internets: MIB-II", RFC 1158, May 1990. 1167 [RELATED] Levinson, E., "The MIME Multipart/Related Content-Type", RFC 1168 1872, Dec 1995 1170 [MDN] Fajman, Roger, "An Extensible Message Format for Message 1171 Disposition Notifications" 1173 [DIRECTORY] Howes, Tim, Smith, Mark, A MIME Content-Type for Directory 1174 Information" 1176 [VCARD] Dawson, Frank, Howes, Tim, "An Application/Directory MIME 1177 Content-Type Electronic Business Card Profile" 1180 [LANG] Alvestrand,H., "Tags for the Identification of Languages", RFC 1181 1766, Mar 1995 1183 [TPC.INT] C. Malamud, M. Rose, "Principles of Operation for the TPC.INT 1184 Subdomain: Remote Printing -- Technical Procedures", RFC 1528, 1185 10/06/1993 1187 [VPIM1] Vaudreuil, Greg, "Voice Profile for Internet Mail", RFC 1911, 1188 Feb 1996. 1190 [TIFF] Adobe Developers Association, TIFF (TM) Revision 6.0 - Final, 1191 June 3, 1992. 1193 [S100] Enterprise Computer Telephony Forum, S.100 Revision 1.0 - Media 1194 Services "C" Language - Application Programming Interfaces, February 1195 1996. 1197 11. Security Consideration 1199 This document is a profile of existing Internet mail protocols. As 1200 such, it does not create any security issues not already existing in 1201 the profiled Internet mail protocols themselves. 1203 Further, the profile specified in this document does not in any way 1204 preclude the use of any Internet mail security protocol to encrypt, 1205 authenticate, or non-repudiate the messages. 1207 12. Acknowledgments 1209 The authors would like to offer a special thanks to the Electronic 1210 Messaging Association, especially the members of the Voice Messaging 1211 Committee, for their support of the VPIM specification and the efforts 1212 they have made to ensure its success. 1214 13. Authors' Addresses 1216 Glenn W. Parsons 1217 Nortel Technology 1218 P.O. Box 3511, Station C 1219 Ottawa, ON K1Y 4H7 1220 Canada 1221 Phone: +1-613-763-7582 1222 Fax: +1-613-763-8385 1223 Glenn.Parsons@Nortel.ca 1225 Gregory M. Vaudreuil 1226 Octel Network Services 1227 17080 Dallas Parkway 1228 Dallas, TX 75248-1905 1229 United States 1230 Phone/Fax: +1-214-733-2722 1231 Greg.Vaudreuil@Octel.Com 1233 14. Appendix A - VPIM Requirements Summary 1235 The following table summarizes the profile of VPIM version 2 detailed 1236 in this document. For complete explanations of each feature it is 1237 recommended to read the accompanying text. The conformance table is 1238 separated into various columns: 1240 Feature - name of protocol feature 1242 Section - reference section in main text of this document 1244 Area - conformance area to which each feature applies: 1245 C - content 1246 T - transport 1247 N - notifications 1249 Status - whether the feature is mandatory, optional, or prohibited. 1250 There are three different degrees of optional used in this table: 1251 Must - mandatory 1252 Should - encouraged optional 1253 May - optional 1254 Should not - discouraged optional 1255 Must not - prohibited 1257 Footnote - special comment about conformance for a particular 1258 feature 1259 VPIM version 2 Conformance 1260 | | | | |S| | 1261 | | | | | |H| |F 1262 | | | | | |O|M|o 1263 | | | |S| |U|U|o 1264 | | | |H| |L|S|t 1265 | |A|M|O| |D|T|n 1266 | |R|U|U|M| | |o 1267 | |E|S|L|A|N|N|t 1268 | |A|T|D|Y|O|O|t 1269 FEATURE |SECTION | | | | |T|T|e 1270 -------------------------------------------|----------|-|-|-|-|-|-|- 1271 | | | | | | | | 1272 Message Addressing Formats: | | | | | | | | 1273 Use DNS host names |4.1 |C|x| | | | | 1274 Use only numbers in mailbox IDs |4.1.1 |C| |x| | | | 1275 Use alpha-numeric mailbox IDs |4.1.1 |C| | |x| | | 1276 Support of postmaster@domain |4.1.2 |C|x| | | | | 1277 Support of loopback@domain |4.1.2 |C| |x| | | | 1278 Support of distribution lists |4.1.3 |C| |x| | | | 1279 | | | | | | | | 1280 Message Header Fields: | | | | | | | | 1281 Encoding outbound messages | | | | | | | | 1282 From |4.2.1 |C|x| | | | | 1283 Addition of text name |4.2.1 |C| |x| | | | 1284 To |4.2.2 |C|x| | | | |1 1285 cc |4.2.3 |C| |x| | | |1 1286 Date |4.2.4 |C|x| | | | | 1287 Sender |4.2.5 |C| | | |x| | 1288 Message-id |4.2.6 |C|x| | | | | 1289 Received |4.2.7 |C|x| | | | | 1290 MIME Version: 1.0 (Voice 2.0) |4.2.8 |C|x| | | | | 1291 Content-Type |4.2.9 |C|x| | | | | 1292 Content-Transfer-Encoding |4.2.10 |C|x| | | | | 1293 Sensitivity |4.2.11 |C| | |x| | | 1294 Importance |4.2.12 |C| | |x| | | 1295 Subject |4.2.13 |C| |x| | | | 1296 | | | | | | | | 1297 Detection & Decoding inbound messages | | | | | | | | 1298 From |4.2.1 |C|x| | | | | 1299 Utilize text personal name |4.2.1 |C| |x| | | | 1300 To |4.2.2 |C|x| | | | | 1301 cc |4.2.3 |C| | |x| | | 1302 Date |4.2.4 |C|x| | | | | 1303 Conversion of Date to local time |4.2.4 |C| |x| | | | 1304 Sender |4.2.5 |C| | | |x| | 1305 Message ID |4.2.6 |C|x| | | | | 1306 Received |4.2.7 |C| | |x| | | 1307 MIME Version: 1.0 (Voice 2.0) |4.2.8 |C|x| | | | | 1308 Content Type |4.2.9 |C|x| | | | | 1309 Content-Transfer-Encoding |4.2.10 |C|x| | | | | 1310 Sensitivity |4.2.11 |C|x| | | | |2 1311 Importance |4.2.12 |C| | |x| | | 1312 Subject |4.2.13 |C| | |x| | | 1314 Message Content Encoding: | | | | | | | | 1315 Encoding outbound audio/fax contents | | | | | | | | 1316 7BITMIME |4.3 |C| | | | |x| 1317 8BITMIME |4.3 |C| | | | |x| 1318 Quoted Printable |4.3 |C| | | | |x| 1319 Base64 |4.3 |C|x| | | | |3 1320 Binary |4.3 |C| |x| | | |4 1321 Detection & decoding inbound messages | | | | | | | | 1322 7BITMIME |4.3 |C|x| | | | | 1323 8BITMIME |4.3 |C|x| | | | | 1324 Quoted Printable |4.3 |C|x| | | | | 1325 Base64 |4.3 |C|x| | | | | 1326 Binary |4.3 |C|x| | | | |4 1327 | | | | | | | | 1328 Message Content Types: | | | | | | | | 1329 Inclusion in outbound messages | | | | | | | | 1330 Text/plain |4.3.1 |C| | | |x| | 1331 Multipart/Mixed |4.3.2 |C| |x| | | | 1332 Content-Description |4.3.2.1 |C| |x| | | |5 1333 Message/RFC822 |4.3.3 |C| | |x| | | 1334 Application/Directory |4.3.4 |C| |x| | | | 1335 Audio/32KADPCM |4.3.5 |C|x| | | | | 1336 Content-Description |4.3.5.1 |C| |x| | | |5 1337 Content-Duration |4.3.5.2 |C| | |x| | | 1338 Content-Langauge |4.3.5.3 |C| | |x| | | 1339 Audio/* (other encodings) |4.3.6 |C| | |x| | | 1340 Image/TIFF |4.3.7 |C|x| | | | | 1341 Multipart/Report |4.3.8 |N|x| | | | | 1342 Message/Notification |4.3.9 |N|x| | | | | 1343 Message/Disposition-notification |4.3.10 |N|x| | | | | 1344 Detection & decoding in inbound messages | | | | | | | | 1345 Text/plain |4.3.1 |C|x| | | | |6 1346 Multipart/Mixed |4.3.2 |C|x| | | | | 1347 Content-Description |4.3.2.1 |C| | |x| | | 1348 Message/RFC822 |4.3.3 |C|x| | | | | 1349 Application/Directory |4.3.4 |C| |x| | | | 1350 Audio/32KADPCM |4.3.5 |C|x| | | | | 1351 Content-Description |4.3.5.1 |C| |x| | | | 1352 Content-Duration |4.3.5.2 |C| | |x| | | 1353 Content-Langauge |4.3.5.3 |C| | |x| | | 1354 Audio/* (other encodings) |4.3.6 |C| | |x| | | 1355 Image/TIFF |4.3.7 |C|x| | | | |6 1356 Multipart/Report |4.3.8 |N|x| | | | | 1357 Message/Notification |4.3.9 |N|x| | | | | 1358 Message/Disposition-notification |4.3.10 |N|x| | | | | 1359 Forwarded Messages | | | | | | | | 1360 use Message/RFC822 construct |4.4 |C| |x| | | | 1361 simulate headers if none available |4.4 |C| |x| | | | 1362 | | | | | | | | 1363 Message Transport Protocol: | | | | | | | | 1364 ESMTP Commands | | | | | | | | 1365 HELO |5.1.1 |T|x| | | | | 1366 MAIL FROM |5.1.2 |T|x| | | | | 1367 RCPT TO |5.1.3 |T|x| | | | | 1368 DATA |5.1.4 |T|x| | | | | 1369 TURN |5.1.5 |T| | | | |x| 1370 QUIT |5.1.6 |T|x| | | | | 1371 RSET |5.1.7 |T|x| | | | | 1372 VRFY |5.1.8 |T| | |x| | | 1373 EHLO |5.1.9 |T|x| | | | | 1374 BDAT |5.1.10 |T| |x| | | |4 1375 ESMTP Keywords & Parameters | | | | | | | | 1376 PIPELINING |5.2.1 |T| |x| | | | 1377 SIZE |5.2.2 |T|x| | | | | 1378 CHUNKING |5.2.3 |T| |x| | | | 1379 BINARYMIME |5.2.4,5.3.1|T| |x| | | | 1380 NOTIFY |5.2.5,5.4.1|N|x| | | | | 1381 ENHANCEDSTATUSCODES |5.2.6 |T| |x| | | | 1382 RET |5.4.2 |N| |x| | | | 1383 ESMTP-SMTP Downgrading | | | | | | | | 1384 send delivery report upon downgrade |5.5 |N|x| | | | | 1385 | | | | | | | | 1386 Directory Address Resolution | | | | | | | | 1387 provide facility to resolve addresses |6 |C| |x| | | | 1388 use Vcards to populate local directory |6 |C|x| | | | | 1389 use headers to populate local directory |6 |C| | | |x| | 1390 | | | | | | | | 1391 Management Protocols: | | | | | | | | 1392 Network management |8.1 |T| |x| | | | 1393 -------------------------------------------|----------|-|-|-|-|-|-|- 1395 1. MUST NOT include if all recipients are not known or resolvable. 1396 2. If a sensitive message is received by a system that does not 1397 support sensitivity, then it MUST be returned to the originator 1398 with an appropriate error notification. Also, a received 1399 sensitive message MUST NOT be forwarded to anyone. 1400 3. When binary transport is not available 1401 4. When binary transport is available 1402 5. If multiple contents are present in a message, this header MUST be 1403 present 1404 6. If the content cannot be presented in some form, the entire 1405 message MUST be non-delivered. 1407 15. Appendix B - Example Voice Messages 1409 The following message is a full-featured, all-options-enabled message 1410 addressed to two recipients. The message includes the sender's spoken 1411 name and a short speech segment. The message is marked as important 1412 and private. 1414 To: 2145551212@vm1.mycompany.com 1415 To: 2145551234@VM1.mycompany.com 1416 From: "Vaudreuil, Greg" <2175552345@VM2.mycompany.com> 1417 Date: Mon, 26 Aug 93 10:20:20 CST 1418 MIME-Version: 1.0 (Voice 2.0) 1419 Content-type: Multipart/Mixed; Boundary="MessageBoundary" 1420 Content-Transfer-Encoding: 7bit 1421 Message-ID: VM2.mycompany.com-123456789 1422 Sensitivity: Private 1423 Importance: High 1425 --MessageBoundary 1426 Content-type: Audio/32KADPCM 1427 Content-Transfer-Encoding: Base64 1428 Content-Description: Originator Spoken Name 1429 Content-Language: EN-US 1430 Content-ID: part1@VM2-4321 1432 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1433 (This is a sample of the base-64 Spoken Name data) fgdhgd 1434 dlkgpokpeowrit09== 1436 --MessageBoundary 1437 Content-type: Audio/32KADPCM 1438 Content-Transfer-Encoding: Base64 1439 Content-Description: VPIM Message 1440 Content-Duration: 25 seconds 1442 iIiIiIjMzN3czdze3s7d7fwfHhcvESJVe/4yEhLz8/FOQjVFRERCESL/zqrq 1443 (This is a sample of the base64 message data) zb8tFdLTQt1PXj 1444 u7wjOyRhws+krdns7Rju0t4tLF7cE0K0MxOTOnRW/Pn30c8uHi9== 1446 --MessageBoundary 1447 Content-type: Application/Directory 1448 Content-Transfer-Encoding: 7bit 1450 BEGIN: Vcard 1451 N: Vaudreuil;Greg;;Mr.; 1452 EMAIL;TYPE=INTERNET: 2175552345@VM2.mycompany.com 1453 TEL: +1-217-555-2345 1454 SOUND;TYPE=32KADPCM;ENCODE=BASE64;VALUE=CID: 1455 REV: 19951031T222710Z 1456 END: Vcard 1458 --MessageBoundary-- 1459 The following message is a forwarded single segment voice. 1461 To: 2145551212@vm1.mycompany.com 1462 From: "Vaudreuil, Greg" <2175552345@VM2.mycompany.com> 1463 Date: Mon, 26 Aug 93 10:20:20 CST 1464 MIME-Version: 1.0 (Voice 2.0) 1465 Content-type: Multipart/Mixed; Boundary="MessageBoundary" 1466 Content-Transfer-Encoding: 7bit 1467 Message-ID: VM2.mycompany.com-123456789 1469 --MessageBoundary 1470 Content-type: Audio/32KADPCM 1471 Content-Description: VPIM Message 1472 Content-Transfer-Encoding: Base64 1474 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1475 (This is the voiced introductory remarks encoded in base64) 1476 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW 1477 dlkgpokpeowrit09== 1479 --MessageBoundary 1480 Content-type: Message/RFC822 1481 Content-Transfer-Encoding: 7bit 1483 To: 2175552345@VM2.mycompany.com 1484 From: "Parsons, Glenn, W." <2145551234@VM1.mycompany.com> 1485 From: Date: Mon, 26 Aug 93 8:23:10 EST 1486 MIME-Version: 1.0 (Voice 2.0) 1487 Content-type: Audio/32KADPCM 1488 Content-Description: VPIM Message 1489 Content-Transfer-Encoding: Base64 1491 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1492 (This is the original message audio data) fgwersdfmniwrjj 1493 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW 1494 dlkgpokpeowrit09== 1496 --MessageBoundary 1497 Content-type: Application/Directory 1498 Content-Transfer-Encoding: 7bit 1500 BEGIN: Vcard 1501 N: Vaudreuil;Greg;;Mr.; 1502 SOUND;TYPE=32kbADPCM;ENCODE=BASE64;VALUE=INLINE: 1503 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1504 (This is the Spoken Name audio data) fgwersdfmniwrjjedfsa 1505 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW 1506 dlkgpokpeowrit09== 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: Any encoding necessary for transport may be 1598 used. 1600 ITU-T Recommendation G.726 [G726] (was G.721) describes the algorithm 1601 recommended for conversion of a single 64 kbit/s A-law or mu-law PCM 1602 channel encoded at 8000 samples/sec to and from a 32 kbit/s channel. 1603 The conversion is applied to the PCM stream using an Adaptive 1604 Differential Pulse Code Modulation (ADPCM) transcoding technique. 1606 No header information shall be included as part of the audio data. 1607 The 4-bit code words of the G.726 encoding MUST be packed into 1608 octets/bytes as follows: the first code word is placed in the four 1609 least significant bits of the first octet, with the least significant 1610 bit of the code word in the least significant bit of the octet; the 1611 second code word is placed in the four most significant bits of the 1612 first octet, with the most significant bit of the code word in the 1613 most significant bit of the octet. Subsequent pairs of the code words 1614 shall be packed in the same way into successive octets, with the first 1615 code word of each pair placed in the least significant four bits of 1616 the octet. It is prefered that the voice sample be extended with 1617 silence such that the encoded value comprises an even number of code 1618 words. However, if the voice sample comprises an odd number of code 1619 words, then the last code word shall be discarded. 1621 In the context of VPIM, the Content-Description header SHOULD be used 1622 to describe the contents of the audio body. The header must be able 1623 to be parsed to find these identifiying phrases: Voice Message, 1624 Originator Spoken Name, Recipient Spoken Name, or Spoken Subject. 1626 Other headers may be used with their defined semantics. 1628 18. Appendix E - image/TIFF Content Type 1630 Mime type name: image 1631 Mime Sub-Type name: TIFF 1632 Required Parameters: None 1633 Optional Parameters: None 1634 Encoding Considerations: Any encoding necessary for transport may be 1635 used. 1637 18.1 References 1639 TIFF (Tag Image File Format) is defined in: 1641 TIFF (TM) Revision 6.0 - Final - 1643 Adobe Developers Association 1645 Adobe Systems Incorporated 1646 1585 Charleston Road 1647 P.O. Box 7900 Mountain View, CA 94039-7900 1649 A copy of this specification can be found in: 1651 ftp://ftp.adobe.com/pub/adobe/DeveloperSupport/TechNotes/PDFfiles 1653 TIFF Class F has previously never been documented in a detailed 1654 fashion. However, it is clearly defined in Section 10.7.4 Spatial 1655 Media of: 1657 Enterprise Computer Telephony Forum 1658 S.100 Revision 1.0 1659 Media Services "C" Language 1660 Application Programming Interfaces 1662 THE ECT Forum 1663 303 Vintage Park Drive 1664 Foster City, CA 94404-1138 1666 A copy of this specification can be found in: 1668 http://www.ectf.org/ectf_s100.html 1670 18.2 TIFF Class F 1672 The essential parts of the ECTF S.100 definition are repeated here: 1674 The default TIFF tags which apply for reading (sending) and writing 1675 (receiving) are described in the sections below entitled TIFF Reader 1676 and TIFF Writer. The TIFF requirements below are broken into two 1677 sections, specifying the requirements for all TIFF reader 1678 implementations (Used for sending a FAX) and TIFF writer 1679 implementations (Used to receive a fax) that will be supported for 1680 use. 1682 18.2.1 TIFF Reader 1684 All implementations must be able to read (send) TIFF files meeting the 1685 requirements below. Image data must not have any coding errors. 1686 Implementations may also read any other formats as long as available 1687 formats can be disclosed to applications at run time. 1689 ByteOrder: MM,II (Either byte order is allowed) 1691 These tags shown below must be readable. If not present, reader must 1692 use default shown: 1694 TIFF Reader Tags 1696 Tag | Legal | Default |Comment 1697 ------------------|-------------|--------------|---------------------- 1698 BitsPerSample | 1 | 1 |one bit per sample 1699 CleanFaxData | 0 | 0 |data has no errors 1700 Compression | 3 | 3 |T.4 bi-level encoding, 1701 | | | MH 1702 FillOrder | 2,1 | 2 |LSB first or MSB first 1703 ImageWidth | 1728 | 1728 | 1704 ImageLength | >0 | |required 1705 NewSubFileType | 2 | 2 |single page of 1706 | | |multipage file 1707 Orientation | 1 | 1 |1st row=top left, 1708 | | | 1st col=top 1709 PageNumber | X/X | 0/1 |pg/tot, 0 base, 1710 | | | tot in 1st IFD 1711 PhotometricInterp | 0 | 0 |0 is white 1712 ResolutionUnit | 2 | 2 |inches 1713 RowsPerStrip |=ImageLength |=ImageLength | 1714 SamplesPerPixel | 1 | 1 |one sample per pixel 1715 StripByteCounts | >0 | |required 1716 StripOffsets | >0 | |required 1717 T4Options | 4 | 4 |MH, byte aligned EOL 1718 Xresolution | 204,200,77 | 204 | 1719 Yresolution | 196,98,100, | 196 | 1720 | 200,77,38.5 | | 1721 ------------------|-------------|--------------|---------------------- 1723 Other tags may be present, but must be of the sort that can be ignored 1724 safely by implementations (i.e. purely informational). 1726 18.2.2 TIFF Writer 1728 For fax writing (receiving), implementations are required to use the 1729 following TIFF format as a default. Image data must not have any 1730 coding errors. Implementations may write other formats as long as 1731 applications have selected from among those formats at run time. 1733 TIFF Writer Tags 1735 Tag | Legal Values | Comment 1736 ------------------|----------------|---------------------------------- 1737 ByteOrder | II | 1738 BitsPerSample | 1 | one bit per sample 1739 Compression | 3 | T.4 bi-level encoding, MH 1740 FillOrder | 2 | LSB first 1741 ImageWidth | 1728 | 1742 ImageLength | > 0 | 1743 NewSubFileType | 2 | single page of multi-page file 1744 PageNumber | X/X | pg/tot, 0 base, tot in 1st IFD 1745 PhotometricInterp | 0 | 0 is white 1746 ResolutionUnit | 2 | inches 1747 RowsPerStrip | >0 | must be same as ImageLength 1748 SamplesPerPixel | 1 | one sample per pixel 1749 StripByteCounts | >0 | as appropriate 1750 StripOffsets | >0 | as appropriate 1751 T4Options | 4 | MH, byte aligned EOL 1752 Xresolution | 204,200,77 | 1753 Yresolution | 196,98,100, | 1754 | 200,77,38.5 | 1755 ------------------|----------------|---------------------------------- 1757 Tags that are optional, but if present must contain the values as 1758 shown: 1760 Optional TIFF Writer Tags 1762 Tag | Legal Values | Comment 1763 ----------------|----------------|------------------------------------ 1764 CleanFaxData | 0 | data doesn't contain bad scan lines 1765 Orientation | 1 | 1st row = top left, 1st col = top 1766 ----------------|----------------|------------------------------------ 1768 Other tags may be present, but must be of the sort that can be ignored 1769 safely by applications (i.e. purely for information). 1771 Recommended informational tags are: 1773 Software, Datetime, BadFaxLines, ConsecutiveBadFaxLines 1775 19. Appendix F - Change History: RFC 1911 to this Document 1777 This update is based on the experience of a proof of concept 1778 demonstration of VPIM at EMA'96 in April 1996. This version of the 1779 profile is significantly different from the previous. These changes 1780 are detailed below: 1782 1. General 1784 - Various editorial updates to improve readability 1786 - Changed the Voice version to 2.0 1788 - Added Table of Contents and more examples 1790 - Refined audio/32KADPCM (nibble order) and image/TIFF (tag defaults) 1791 definitions 1793 2. Content 1795 - Deprecated multipart/voice-message content because of the removal of 1796 positional dependence of contents and the desire to interoperate with 1797 minimal MIME implementationsde 1799 - Explicitly defined the forwarding model using message/RFC822 1801 - Eliminated the text name in the "To" and "CC" headers. Edited the 1802 conformance to require last-name, first-name only for persons 1804 - Described handling of private messages 1806 - Profiled the Vcard in the application/directory body part for 1807 transport of directory information on the originator 1809 - Added support for facsimile using the refined image/TIFF content 1811 - Loosened text restriction 1813 - Added suggested addressing formats 1815 - Added additional details on delivery notifications 1817 3. Transport 1819 - Moved Binary support to optional 1821 - Added ESMTP keyword for Return of Status codes 1823 4. Compliance 1825 - Added an explicit section on conformance allowing conformance to all 1826 or any of three conformance areas 1828 - Improved conformance table 1830 20. Appendix G -- Open Issues 1832 1) Finalize changes appendix 1834 2) Sufficient examples 1836 3) Must date be included at an AMIS to VPIM gateway?