idnits 2.17.1 draft-ema-vpim-06.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): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 51 longer pages, the longest (page 2) being 112 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 507 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 abstract seems to indicate that this document obsoletes RFC1911, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 914 has weird spacing: '...message that ...' == Line 1562 has weird spacing: '...for the purpo...' == Line 2163 has weird spacing: '...eturned displ...' == Line 2165 has weird spacing: '...mailbox man...' == Line 2168 has weird spacing: '...mailbox man...' == (1 more instance...) == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The From address may be used for replies (see 4.6). However, if the From address contains , the user SHOULD not be offered the option to reply, nor should notifications be sent to this address. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: In some cases, a reply message is not possible, such as with a message created by telephone answering (i.e. classic voice mail). In this case, the From field MUST contain the special address non-mail-user@domain (see 4.1.2). The use of a null ESMTP MAIL FROM address SHOULD also be used in this case (see 5.1.2). A receiving VPIM system SHOULD not offer the user the option to reply to this kind of message. -- 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 (November 21, 1997) is 9647 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: 'MIME' is mentioned on line 241, but not defined == Unused Reference: '8BIT' is defined on line 1395, but no explicit reference was found in the text == Unused Reference: 'AMIS-A' is defined on line 1405, but no explicit reference was found in the text == Unused Reference: 'AMIS-D' is defined on line 1408, but no explicit reference was found in the text == Unused Reference: 'DNS1' is defined on line 1425, but no explicit reference was found in the text == Unused Reference: 'DNS2' is defined on line 1428, but no explicit reference was found in the text == Unused Reference: 'E164' is defined on line 1441, but no explicit reference was found in the text == Unused Reference: 'G726' is defined on line 1450, but no explicit reference was found in the text == Unused Reference: 'MIME3' is defined on line 1475, but no explicit reference was found in the text == Unused Reference: 'MIME5' is defined on line 1483, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1426 (ref. '8BIT') (Obsoleted by RFC 1652) -- Possible downref: Non-RFC (?) normative reference: ref. 'ADPCM' -- Possible downref: Non-RFC (?) normative reference: ref. 'AMIS-A' -- Possible downref: Non-RFC (?) normative reference: ref. 'AMIS-D' ** Obsolete normative reference: RFC 1830 (ref. 'BINARY') (Obsoleted by RFC 3030) ** Obsolete normative reference: RFC 1893 (ref. 'CODES') (Obsoleted by RFC 3463) -- Possible downref: Non-RFC (?) normative reference: ref. 'DIRECTORY' ** Obsolete normative reference: RFC 1806 (ref. 'DISP') (Obsoleted by RFC 2183) ** Obsolete normative reference: RFC 1891 (ref. 'DRPT') (Obsoleted by RFC 3461) ** Obsolete normative reference: RFC 1894 (ref. 'DSN') (Obsoleted by RFC 3464) -- Possible downref: Non-RFC (?) normative reference: ref. 'DUR' -- Possible downref: Non-RFC (?) normative reference: ref. 'E164' ** Obsolete normative reference: RFC 1869 (ref. 'ESMTP') (Obsoleted by RFC 2821) -- Possible downref: Non-RFC (?) normative reference: ref. 'G726' ** Obsolete normative reference: RFC 1766 (ref. 'LANG') (Obsoleted by RFC 3066, RFC 3282) -- Possible downref: Non-RFC (?) normative reference: ref. 'MDN' ** Obsolete normative reference: RFC 1158 (ref. 'MIB II') (Obsoleted by RFC 1213) ** Obsolete normative reference: RFC 2048 (ref. 'MIME4') (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 1854 (ref. 'PIPE') (Obsoleted by RFC 2197) ** Obsolete normative reference: RFC 1892 (ref. 'REPORT') (Obsoleted by RFC 3462) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 821 (ref. 'SMTP') (Obsoleted by RFC 2821) -- Possible downref: Non-RFC (?) normative reference: ref. 'TIFF-F' -- Possible downref: Non-RFC (?) normative reference: ref. 'TIFFREG' -- Possible downref: Non-RFC (?) normative reference: ref. 'V-MSG' -- Possible downref: Non-RFC (?) normative reference: ref. 'VCARD' ** Obsolete normative reference: RFC 1911 (ref. 'VPIM1') (Obsoleted by RFC 2421, RFC 2422, RFC 2423) Summary: 25 errors (**), 0 flaws (~~), 22 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Greg Vaudreuil 3 Internet Draft Lucent Technologies 4 Expires in six months Glenn Parsons 5 Obsoletes: RFC 1911 Northern Telcom 6 November 21, 1997 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 Copyright Notice 32 Copyright (C) The Internet Society (1997). All Rights Reserved. 34 Overview 36 This document profiles Internet mail for voice messaging. It 37 obsoletes RFC 1911 which describes version 1 of the profile. A list 38 of changes from that document are noted in Appendix D. As well, 39 Appendix A summarizes the protocol profiles of this version of VPIM. 41 Please send comments on this document to the EMA VPIM Work Group 42 mailing list: 43 Working Group Summary 45 This profile is not the product of an IETF working group, though 46 several have reviewed the document. It is instead the product of the 47 VPIM Work Group of the Electronic Messaging Association (EMA). This 48 work group, which has representatives from most major voice mail 49 vendors and several email vendors, has held several interoperability 50 demonstrations between voice messaging vendors and is currently 51 promoting VPIM trials and deployment. 53 Table of Contents 55 1. ABSTRACT ............................................................4 56 2. SCOPE ...............................................................5 57 2.1 Voice Messaging System Limitations ...............................5 58 2.2 Design Goals .....................................................6 59 3. PROTOCOL RESTRICTIONS ...............................................7 60 4. VOICE MESSAGE INTERCHANGE FORMAT ....................................8 61 4.1 Message Addressing Formats .......................................8 62 4.2 Message Header Fields ...........................................10 63 4.3 Voice Message Content Types .....................................16 64 4.4 Other Message Content Types .....................................21 65 4.5 Forwarded Messages ..............................................23 66 4.6 Reply Messages ..................................................23 67 4.7 Notification Messages ...........................................24 68 5. MESSAGE TRANSPORT PROTOCOL .........................................25 69 5.1 ESMTP Commands ..................................................25 70 5.2 ESMTP Keywords ..................................................27 71 5.3 ESMTP Parameters - MAIL FROM ....................................28 72 5.4 ESMTP Parameters - RCPT TO ......................................28 73 5.5 ESMTP - SMTP Downgrading ........................................29 74 6. DIRECTORY ADDRESS RESOLUTION .......................................29 75 7. IMAP ...............................................................30 76 8. MANAGEMENT PROTOCOLS ...............................................30 77 8.1 Network Management ..............................................30 78 9. CONFORMANCE REQUIREMENTS ...........................................30 79 10. REFERENCES ........................................................32 80 11. SECURITY CONSIDERATION ............................................35 81 12. ACKNOWLEDGMENTS ...................................................35 82 13. COPYRIGHT NOTICE ..................................................35 83 14. AUTHORS' ADDRESSES ................................................36 84 15. APPENDIX A - VPIM REQUIREMENTS SUMMARY ............................37 85 16. APPENDIX B - EXAMPLE VOICE MESSAGES ...............................43 86 17. APPENDIX C - EXAMPLE ERROR VOICE PROCESSING ERROR CODES ...........48 87 18. APPENDIX D - EXAMPLE VOICE PROCESSING DISPOSITION TYPES ...........49 88 19. APPENDIX E - CHANGE HISTORY: RFC 1911 TO THIS DOCUMENT ............50 89 1. Abstract 91 A class of special-purpose computers has evolved to provide voice 92 messaging services. These machines generally interface to a telephone 93 switch and provide call answering and voice messaging services. 94 Traditionally, messages sent to a non-local machine are transported 95 using analog networking protocols based on DTMF signaling and analog 96 voice playback. As the demand for networking increases, there is a 97 need for a standard high-quality digital protocol to connect these 98 machines. The following document is a profile of the Internet 99 standard MIME and ESMTP protocols for use as a digital voice messaging 100 networking protocol. The profile is referred to as VPIM (Voice Profile 101 for Internet Mail) in this document. 103 This profile is based on earlier work in the Audio Message Interchange 104 Specification (AMIS) group that defined a voice messaging protocol 105 based on X.400 technology. This profile is intended to satisfy the 106 user requirements statement from that earlier work with the industry 107 standard ESMTP/MIME mail protocol infrastructures already used within 108 corporate intranets. This second version of VPIM is based on 109 implementation experience and obsoletes RFC 1911 which describes 110 version 1 of the profile. 112 2. Scope 114 MIME is the Internet multipurpose, multimedia messaging standard. 115 This document explicitly recognizes its capabilities and provides a 116 mechanism for the exchange of various messaging technologies, 117 primarily voice and facsimile. 119 This document specifies a restricted profile of the Internet 120 multimedia messaging protocols for use between voice processing server 121 platforms. These platforms have historically been special-purpose 122 computers and often do not have the same facilities normally 123 associated with a traditional Internet Email-capable computer. As a 124 result, VPIM also specifies additional functionality as it is needed. 125 This profile is intended to specify the minimum common set of features 126 to allow interworking between compliant systems. 128 2.1 Voice Messaging System Limitations 130 The following are typical limitations of voice messaging platform 131 which were considered in creating this baseline profile. 133 1) Text messages are not normally received and often cannot be 134 easily displayed or viewed. They can often be processed only via 135 text-to-speech or text-to-fax features not currently present in 136 many of these machines. 138 2) Voice mail machines usually act as an integrated Message 139 Transfer Agent, Message Store and User Agent. There is no relaying 140 of messages, and RFC 822 header fields may have limited use in the 141 context of the limited messaging features currently deployed. 143 3) Voice mail message stores are generally not capable of 144 preserving the full semantics of an Internet message. As such, use 145 of a voice mail machine for gatewaying is not supported. In 146 particular, storage of recipient lists, "Received" lines, and 147 "Message-ID" may be limited. 149 4) Internet-style distribution/exploder mailing lists are not 150 typically supported. Voice mail machines often implement only 151 local alias lists, with error-to-sender and reply-to-sender 152 behavior. Reply-all capabilities using a CC list is not generally 153 available. 155 5) Error reports must be machine-parsable so that helpful responses 156 can be voiced to users whose only access mechanism is a telephone. 158 6) The voice mail systems generally limit address entry to 16 or 159 fewer numeric characters, and normally do not support alphanumeric 160 mailbox names. Alpha characters are not generally used for mailbox 161 identification as they cannot be easily entered from a telephone 162 terminal. 164 2.2 Design Goals 166 It is a goal of this profile to make as few restrictions and additions 167 to the existing Internet mail protocols as possible while satisfying 168 the requirements for interoperability with current generation voice 169 messaging systems. This goal is motivated by the desire to increase 170 the accessibility to digital messaging by enabling the use of proven 171 existing networking software for rapid development. 173 This specification is intended for use on a TCP/IP network, however, 174 it is possible to use the SMTP protocol suite over other transport 175 protocols. The necessary protocol parameters for such use is outside 176 the scope of this document. 178 This profile is intended to be robust enough to be used in an 179 environment, such as the global Internet with installed-base gateways 180 which do not understand MIME, though typical use is expected to be 181 within corporate intranets. Full functionality, such as reliable 182 error messages and binary transport, will require careful selection of 183 gateways (e.g., via MX records) to be used as VPIM forwarding agents. 184 Nothing in this document precludes use of a general purpose MIME email 185 packages to read and compose VPIM messages. While no special 186 configuration is required to receive VPIM compliant messages, some may 187 be required to originate compliant structures. 189 It is expected that a VPIM messaging system will be managed by a 190 system administrator who can perform TCP/IP network configuration. 191 When using facsimile or multiple voice encodings, it is suggested that 192 the system administrator maintain a list of the capabilities of the 193 networked mail machines to reduce the sending of undeliverable 194 messages due to lack of feature support. Configuration, 195 implementation and management of this directory listing capabilities 196 is a local matter. 198 3. Protocol Restrictions 200 This protocol does not limit the number of recipients per message. 201 Where possible, implementations should not restrict the number of 202 recipients in a single message. It is recognized that no 203 implementation supports unlimited recipients, and that the number of 204 supported recipients may be quite low. However, ESMTP currently does 205 not provide a mechanism for indicating the number of supported 206 recipients. 208 This protocol does not limit the maximum message length. Implementors 209 should understand that some machines will be unable to accept 210 excessively long messages. A mechanism is defined in the RFC 1425 211 SMTP service extensions to declare the maximum message size supported. 213 The message size indicated in the ESMTP SIZE command is in bytes, not 214 minutes or seconds. The number of bytes varies by voice encoding 215 format and must include the MIME wrapper overhead. If the length must 216 be known before sending, an approximate translation into minutes or 217 seconds can be performed if the voice encoding is known. 219 The following sections describe the restrictions and additions to 220 Internet mail protocols that are required to be compliant with this 221 VPIM v2 profile. Though various SMTP, ESMTP and MIME features are 222 described here, the implementor is referred to the relevant RFCs for 223 complete details. It is also advisable to check for IETF drafts of 224 various Internet Mail specifications that are later than the most 225 recent RFCs since, for example, MIME has yet to be published as a full 226 IETF Standard. The table in Appendix A summarizes the protocol details 227 of this profile. 229 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 230 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 231 document are to be interpreted as described in [REQ]. 233 4. Voice Message Interchange Format 235 The voice message interchange format is a profile of the Internet Mail 236 Protocol Suite. Any Internet Mail message containing the format 237 defined in this section is referred to as a VPIM Message in this 238 document. As a result, this document assumes an understanding of the 239 Internet Mail specifications. Specifically, VPIM references 240 components from the message format standard for Internet messages 241 [RFC822], the Multipurpose Internet Message Extensions [MIME], the 242 X.400 gateway specification [X.400], delivery status and message 243 disposition notifications [REPORT][DSN][DRPT][STATUS][MDN], and the 244 electronic business card [DIRECTORY][VCARD]. 246 4.1 Message Addressing Formats 248 RFC 822 addresses are based on the domain name system. This naming 249 system has two components: the local part, used for username or 250 mailbox identification; and the host part, used for global machine 251 identification. 253 4.1.1 VPIM Addresses 255 The local part of the address shall be a US-ASCII string uniquely 256 identifying a mailbox on a destination system. For voice messaging, 257 the local part is a printable string containing the mailbox ID of the 258 originator or recipient. While alpha characters and long mailbox 259 identifiers are permitted, most voice mail networks rely on numeric 260 mailbox identifiers to retain compatibility with the limited 10 digit 261 telephone keypad. As a result, some voice messaging systems may only 262 be able to handle a numeric local part. The reception of alphanumeric 263 local parts on these systems may result in the address being mapped to 264 some locally unique (but confusing to the recipient) number or, in the 265 worst case the address could be deleted making the message un- 266 replyable. Additionally, it may be difficult to create messages on 267 these systems with an alphanumeric local part without complex key 268 sequences or some form of directory lookup (see 6). 270 The use of the domain naming system should be transparent to the user. 271 It is the responsibility of the voice mail machine to lookup the 272 fully-qualified domain name (FQDN) based on the address entered by the 273 user (see 6). 275 In the absence of a global directory, specification of the local part 276 is expected to conform to international or private telephone numbering 277 plans. It is likely that private numbering plans will prevail and 278 these are left for local definition. However, it is recommended that 279 public telephone numbers be noted according to the international 280 numbering plan described in [E.164]. The indication that the local 281 part is a public telephone number is given by a preceding `+' (the `+' 282 would not be entered from a telephone keypad, it is added by the 283 system as a flag). Since the primary information in the numeric 284 scheme is contained by the digits, other character separators (e.g. `- 285 ') may be ignored (i.e. to allow parsing of the numeric local mailbox) 286 or may be used to recognize distinct portions of the telephone number 287 (e.g. country code). The specification of the local part of a VPIM 288 address can be split into the four groups described below: 290 1) mailbox number 291 - for use as a private numbering plan (any number of digits) 292 - e.g. 2722@lucent.com 294 2) mailbox number+extension 295 - for use as a private numbering plan with extensions 296 any number of digits, use of `+' as separator 297 - e.g. 2722+111@Lucent.com 299 3) +international number 300 - for international telephone numbers conforming to E.164 301 maximum of 15 digits 302 - e.g. +16137637582@vm.nortel.ca 304 4) +international number+extension 305 - for international telephone numbers conforming to E.164 306 maximum of 15 digits, with an extension (e.g. behind a 307 PBX) that has a maximum of 15 digits. 308 - e.g. +17035245550+230@ema.org 310 4.1.2 Special Addresses 312 Special addresses are provided for compatibility with the conventions 313 of Internet mail. These addresses do not use numeric local addresses, 314 both to conform to current Internet practice and to avoid conflict 315 with existing numeric addressing plans. Two special addresses are 316 RESERVED for use as follows: 318 postmaster@domain 320 By convention, a special mailbox named "postmaster" MUST exist on all 321 systems. This address is used for diagnostics and should be checked 322 regularly by the system manager. This mailbox is particularly likely 323 to receive text messages, which is not normal on a voice processing 324 platform. The specific handling of these messages is an individual 325 implementation choice. 327 non-mail-user@domain 328 If a reply to a message is not possible, such as a telephone answering 329 message, then the special address _non-mail-user_ must be used as the 330 originator's address. Any text name such as "Telephone Answering," or 331 the telephone number if it is available, is permitted. This special 332 address is used as a token to indicate an unreachable originator. For 333 compatibility with the installed base of mail user agents, 334 implementations that generate this special address MUST send a non- 335 delivery notification for reply messages sent to the undeliverable 336 address. The status code for such NDN's is 5.1.1 "Mailbox does not 337 exist". 339 Example: 341 From: Telephone Answering 343 4.1.3 Distribution Lists 345 There are many ways to handle distribution list (DL) expansions and 346 none are 'standard'. Simple alias is a behavior closest to what most 347 voice mail systems do today and what is to be used with VPIM messages. 348 That is: 350 Reply to the originator - (Address in the RFC822 Reply-to or From 351 field) 352 Errors to the submitter - (Address in the MAIL FROM: field of the 353 ESMTP exchange and the Return-Path: 354 RFC 822 field) 356 Some proprietary voice messaging protocols include only the recipient 357 of the particular copy in the envelope and include no "headers" except 358 date and per-message features. Most voice messaging systems do not 359 provide for "Header Information" in their messaging queues and only 360 include delivery information. As a result, recipient information MAY 361 be in either the To or CC headers. If all recipients cannot be 362 presented (e.g. unknown DL expansion) then the recipient headers MUST 363 be omitted to indicate that an accurate list of recipients (e.g. for 364 use with a reply-all capability) is not known. 366 4.2 Message Header Fields 368 Internet messages contain a header information block. This header 369 block contains information required to identify the sender, the list 370 of recipients, the message send time, and other information intended 371 for user presentation. Except for specialized gateway and mailing 372 list cases, headers do not indicate delivery options for the transport 373 of messages. 375 Exploder lists are noted for modifying or adding to the headers of 376 messages that pass through them. VPIM systems MUST be able to accept 377 and ignore headers that are not defined here. 379 The following header lines are permitted for use with VPIM voice 380 messages: 382 4.2.1 From 384 The originator's fully-qualified domain address (a mailbox address 385 followed by the fully-qualified domain name). The user listed in this 386 field should be presented in the voice message envelope as the 387 originator of the message. 389 Systems compliant with this profile SHOULD provide the text personal 390 name of the voice message originator in a quoted phrase, if the name 391 is available. Text names of corporate or positional mailboxes MAY be 392 provided as a simple string. From [RFC822] 394 Example: 396 From: "Joe S. User" <12145551212@mycompany.com> 398 From: Technical Support <611@serviceprovider.com> 400 The From address may be used for replies (see 4.6). However, if the 401 From address contains , the user SHOULD not be 402 offered the option to reply, nor should notifications be sent to this 403 address. 405 4.2.2 To 407 The To header contains the recipient's fully-qualified domain address. 408 There may be one or more To: fields in any message. 410 Example: 412 To: +12145551213@mycompany.com 414 Systems compliant to this profile SHOULD provide a list of recipients 415 only if all recipients are provided. The To header MUST NOT be 416 included in the message if the sending message transport agent (MTA) 417 cannot resolve all the addresses in it, e.g. if an address is a DL 418 alias for which the expansion is unknown (see 4.1.3). If present, the 419 addresses in the To header MAY be used for a reply message to all 420 recipients. 422 Systems compliant to this profile MAY also discard the To addresses of 423 incoming messages because of the inability to store the information. 424 This would, of course, make a reply-to-all capability impossible. 426 4.2.3 Cc 428 The cc header contains additional recipients' fully-qualified domain 429 addresses. Many voice mail systems maintain only sufficient envelope 430 information for message delivery and are not capable of storing or 431 providing a complete list of recipients. 433 Systems compliant to this profile SHOULD provide a list of recipients 434 only if all disclosed recipients can be provided. The list of 435 disclosed recipients does not include those sent via a blind copy. If 436 not, systems SHOULD omit the To and Cc headers to indicate that the 437 full list of recipients is unknown. 439 Example: 441 Cc: +12145551213@mycompany.com 443 Systems compliant to this profile MAY discard the Cc addresses of 444 incoming messages as necessary. If a list of Cc or to addresses is 445 present, these addresses MAY be used for a reply message to all 446 recipients. 448 4.2.4 Date 450 The Date header contains the date, time, and time zone in which the 451 message was sent by the originator. The time zone SHOULD be 452 represented in a four-digit time zone offset, such as -0500 for North 453 American Eastern Standard Time. This may be supplemented by a time 454 zone name in parentheses, e.g., "-0900 (PDT)". Compliant 455 implementations SHOULD be able to convert RFC 822 date and time stamps 456 into local time. 458 Example: 460 Date: Wed, 28 Jul 96 10:08:49 -0800 (PST) 462 The sending system MUST report the time the message was sent. If the 463 VPIM sender is relaying a message from a system which does not provide 464 a timestamp, the time of arrival at the VPIM system SHOULD be used as 465 the date. From [RFC822] 467 4.2.5 Sender 469 The Sender header contains the actual address of the originator if the 470 message is sent by an agent on behalf of the author indicated in the 471 From: field and MAY be present in a VPIM message. 473 While it may not be possible to save this information in some voice 474 mail machines, discarding this information or the ESMTP MAIL FROM (see 475 4.2.6) address will make it difficult to send an error message to the 476 proper destination. From [RFC822] 478 4.2.6 Return Path 480 The Return-path header is added by the final delivering SMTP server. 481 If present, it contains the address from the MAIL FROM parameter of 482 the ESMTP exchange (see 5.1.2) to which error messages MUST be sent to 483 this address (see [DRPT] for additional details). Note that if the 484 Return-path is null ("<>"), e.g. no path, loop prevention or 485 confidential, a notification MUST NOT be sent. If the Return path 486 address is not available (either from this header or the MAIL FROM 487 parameter) the Sender or From addresses may be used to deliver 488 notifications. 490 4.2.7 Message-id 492 The Message-id header contains a unique per-message identifier. A 493 unique message-id MUST be generated for each message sent from a 494 compliant implementation. 496 The message-id is not required to be stored on the receiving system. 497 This identifier MAY be used for tracking, auditing, and returning 498 read-receipt reports. From [RFC822] 500 Example: 502 Message-id: <12345678@mycompany.com> 504 4.2.8 Reply-To 506 If present, the reply-to header provides a preferred address to which 507 reply messages should be sent (see 4.6). If a reply-to header is 508 present, a reply-to sender message MUST be sent to the address 509 specified. From [RFC822] This preferred address of the originator 510 must also be provided in the originator's vCard EMAIL attribute, if 511 present (see 4.3.3). 513 4.2.9 Received 515 The Received header contains trace information added to the beginning 516 of a RFC 822 message by MTAs. This is the only header permitted to be 517 added by an MTA. Information in this header is useful for debugging 518 when using an US-ASCII message reader or a header parsing tool. 520 A compliant system MUST add Received headers when acting as a gateway 521 and MUST NOT remove any. These headers MAY be ignored or deleted when 522 the message is received at the final destination. From [RFC822] 524 4.2.10 MIME Version 526 The MIME-Version header indicates that the message conforms to the 527 MIME message format specification. Systems compliant with this 528 specification SHOULD include a comment with the words "(Voice 2.0)". 529 RFC 1911 defines an earlier version of this profile and uses the token 530 (Voice 1.0). From [MIME1][VPIM1] 531 Example: 533 MIME-Version: 1.0 (Voice 2.0) 535 This identifier is intended for information only and SHOULD NOT be 536 used to semantically identify the message as being a VPIM message. 537 Instead, the presence of the content defined in [V-MSG] SHOULD be used 538 if identification is necessary. 540 4.2.11 Content-Type 542 The content-type header declares the type of content enclosed in the 543 message. The typical top level content in a VPIM Message SHOULD be 544 multipart/voice-message, a mechanism for bundling several components 545 into a single identifiable voice message. The allowable contents are 546 detailed in section 4.3 of this document. From [MIME2] 548 4.2.12 Content-Transfer-Encoding 550 Because Internet mail was initially specified to carry only 7-bit US- 551 ASCII text, it may be necessary to encode voice and fax data into a 552 representation suitable for that environment. The content-transfer- 553 encoding header describes this transformation if it is needed. 554 Compliant implementations MUST recognize and decode the standard 555 encodings, "Binary", "7bit, "8bit", "Base64" and "Quoted-Printable". 556 The allowable content-transfer-encodings are specified in section 4.3. 557 From [MIME1] 559 4.2.13 Sensitivity 561 The sensitivity header, if present, indicates the requested privacy 562 level. The case-insensitive values "Personal" and "Private" are 563 specified. If no privacy is requested, this field is omitted. 565 If a sensitivity header is present in the message, a compliant system 566 MUST prohibit the recipient from forwarding this message to any other 567 user. A compliant system, however, SHOULD allow the user to reply to 568 a sensitive message, but SHOULD NOT include the original message 569 content. The sensitivity of the reply message MAY be set by the user. 571 If the receiving system does not support privacy and the sensitivity 572 is one of "Personal" or "Private", the message MUST be returned to the 573 sender with an appropriate error code indicating that privacy could 574 not be assured and that the message was not delivered. A non-delivery 575 notification to a private message need not be tagged private since it 576 will be sent to the originator. From: [X.400] 578 4.2.14 Importance 580 Indicates the requested priority to be given by the receiving system. 581 The case-insensitive values "low", "normal" and "high" are specified. 582 If no special importance is requested, this header may be omitted and 583 the value assumed to be "normal". 585 Compliant implementations MAY use this header to indicate the 586 importance of a message and may order messages in a recipient's 587 mailbox. From: [X.400] 589 4.2.15 Subject 591 The subject field is often provided by email systems but is not widely 592 supported on Voice Mail platforms. For compatibility with text based 593 mailbox interfaces, a text subject field SHOULD be generated by a 594 compliant implementation but MAY be discarded if present by a 595 receiving system. From [RFC822] 597 It is recommended that voice messaging systems that do not support any 598 text user interfaces (e.g. access only by a telephone) insert a 599 generic subject header of "VPIM Message" for the benefit of text 600 enabled recipients. 602 4.2.16 Disposition-Notification-To 604 This header MAY be present to indicate that the sender is requesting a 605 receipt notification from the receiving user agent. This message 606 disposition notification (MDN) is typically sent by the user agent 607 after the user has listened to the message and consented to an MDN 608 being sent 610 Example: 612 Disposition-notification-to: +12145551213@mycompany.com 614 The presence of a Disposition-notification-to header in a message is 615 merely a request for an MDN described in 4.4.5. The recipients' user 616 agents are always free to silently ignore such a request so this 617 header does not burden any system that does not support it. From 618 [MDN]. 620 4.2.17 Disposition-Notification-Options 622 This header MAY be present to define future extensions parameters for 623 an MDN requested by the presence of the header in the previous 624 section. Currently no parameters are defined by this document or by 625 [MDN]. However, this header MUST be parsed if present, if MDNs are 626 supported. If it contains a extension parameter that is required for 627 proper MDN generation (noted with "=required"), then an MDN MUST NOT 628 be sent if the parameter is not understood. See [MDN] for complete 629 details. 631 Example: 633 Disposition-notification-options: 634 whizzbang=required,foo 636 4.3 Voice Message Content Types 638 MIME, introduced in [MIME1], is a general-purpose message body format 639 that is extensible to carry a wide range of body parts. It provides 640 for encoding binary data so that it can be transported over the 7-bit 641 text-oriented SMTP protocol. This transport encoding is in addition 642 to the audio encoding required to generate a binary object. 644 MIME defines two transport encoding mechanisms to transform binary 645 data into a 7 bit representation, one designed for text-like data 646 ("Quoted-Printable"), and one for arbitrary binary data ("Base64"). 647 While Base64 is dramatically more efficient for audio data, both will 648 work. Where binary transport is available, no transport encoding is 649 needed, and the data can be labeled as "Binary". 651 An implementation in compliance with this profile SHOULD send audio 652 and/or facsimile data in binary form when binary message transport is 653 available. When binary transport is not available, implementations 654 MUST encode the audio and/or facsimile data as Base64. The detection 655 and decoding of "Quoted-Printable", "7bit", and "8bit" MUST be 656 supported in order to meet MIME requirements and to preserve 657 interoperability with the fullest range of possible devices. However, 658 if a content is received in a transfer encoding that cannot be 659 rendered to the user, an appropriate non-delivery notification MUST be 660 sent. 662 The content types described in this section are identified for use 663 within the multipart/voice-message content. This content, which is 664 the fundamental part of a VPIM message, is referred to as a VPIM voice 665 message in this document. 667 Only the contents profiled subsequently can be sent within a VPIM 668 voice message construct to form a simple or a more complex structure 669 (several examples are given in Appendix B). The presence of other 670 contents within a VPIM voice message is an error condition and SHOULD 671 result in a non-delivery notification. When multiple contents are 672 present within the multipart/voice-message, they SHOULD be presented 673 to the user in the order that they appear in the message. 675 4.3.1 Multipart/Voice-Message 677 This MIME multipart structure provides a mechanism for packaging a 678 voice message into one container that is tagged as VPIM v2 compliant. 679 The semantic of multipart/Voice-Message (defined in [V-MSG]) is 680 identical to multipart/mixed and may be interpreted as that by systems 681 that do not recognize this content-type. 683 The Multipart/Voice-Message content-type MUST only contain the 684 profiled media and content types specified in this section (i.e. 685 audio/*, image/*, message/rfc822 and text/directory). The most common 686 will be: spoken name, spoken subject, the message itself, attached fax 687 and directory info. Forwarded messages are created by simply using 688 the message/rfc822 construct. 690 Conformant implementations MUST send the Multipart/Voice-Message in a 691 VPIM message. In most cases, this Multipart/Voice-Message content 692 will be the top level (i.e. in the Content-Type header). Conformant 693 implementations MUST recognize the Multipart/Voice-Message content 694 (whether it is a top level content or below a mulitpart/mixed) and be 695 able to separate the contents (e.g. spoken name or spoken subject). 697 4.3.2 Message/RFC822 699 MIME requires support of the Message/RFC822 message encapsulation body 700 part. This body part is used within a multipart/voice-message to 701 forward complete messages (see 4.5) or to reply with original content 702 (see 4.6). From [MIME2] 704 4.3.3 Text/Directory 706 This content allows for the inclusion of a Versit vCard [VCARD] 707 electronic business card within a VPIM message. The format is 708 suitable as an interchange format between applications or systems, and 709 is defined independent of the method used to transport it. It 710 provides a useful mechanism to transport information about the 711 originator that can be used by the receiving VPIM system (see 6) or 712 other local applications 714 Each vCard MUST be contained within a Text/Directory content type 715 [DIRECTORY] within a VPIM message. [DIRECTORY] requires that the 716 character set MUST be defined as a parameter value (typically us-ascii 717 for VPIM) and that the profile SHOULD be defined (the value MUST be 718 vCard within VPIM messages). 720 Each VPIM message SHOULD be created with a Text/Directory (vCard 721 profile) content type that MUST contain the preferred address and 722 telephone number of the message originator and SHOULD contain the 723 spoken name and the spelled name of the originator. The intent is 724 that the vCard be used as the source of information to contact the 725 originator (e.g. reply, call). 727 If included in a VPIM message, the vCard profile [VCARD] MUST be used 728 and MUST specify at least the following attributes: 730 TEL - Public switched telephone number in international (E.164) 731 format (various types, typically VOICE) 732 EMAIL - email address (various types, typically INTERNET; the type 733 VPIM is optionally used to denote the address that supports 734 VPIM messages) 736 The following attributes SHOULD be specified: 738 N - Family Name, Given Name, Additional Names, Honorific 739 Prefixes, and Suffixes (all present components in the From 740 text name MUST match) 741 ROLE - the role of the person identified in `N', but may be used 742 as an alternative to the `N' attribute when the sender is a 743 corporate or positional mailbox 744 SOUND - spoken name sound data (various types, typically 32KADPCM) 745 REV - Revision of vCard in ISO 8601 date format 747 The vCard MAY use other attributes as defined in [VCARD] or extensions 748 attributes not yet defined (e.g. capabilities). 750 If present, the spoken name attribute MUST be denoted by a content ID 751 pointing to an audio/* content elsewhere in the VPIM message. 753 A typical VPIM message (i.e. no forwarded parts), MUST only contain 754 one vCard -- more than one is an error condition. A VPIM message that 755 contains forwarded messages, though, may contain multiple vCards. 756 However, these vCards MUST be associated with the originator(s) of the 757 forwarded message(s) and the originator of the forwarding message. As 758 a result, all forwarded vCards will be contained in message/rfc822 759 contents -- only the vCard of forwarding originator will be at the 760 top-level. 762 Example: 764 Content-Type: text/directory; charset=us-ascii; profile=vCard 765 Content-Transfer-Encoding: 7bit 767 BEGIN:VCARD 768 N:Parsons;Glenn 769 ORG:Nortel Technology 770 TEL;TYPE=VOICE;MSG;WORK:+1-613-763-7582 771 EMAIL;TYPE=INTERNET:glenn.parsons@nortel.ca 772 EMAIL;TYPE=INTERNET;VPIM:6137637582@vm.nortel.ca 773 SOUND;TYPE=32KADPCM;ENCODING=URI: CID: 774 REV:19960831T103310Z 775 END:VCARD 777 4.3.4 Audio/32KADPCM 779 An implementation compliant to this profile MUST use Audio/32KADPCM by 780 default for voice [ADPCM]. Typically this body contains several 781 minutes of message content, however if used for spoken name or subject 782 the content should be considerably shorter (i.e. about 10 and 20 783 seconds respectively). 785 If an implementation can only handle one voice body, then multiple 786 voice bodies (if present) SHOULD be concatenated, and SHOULD NOT be 787 discarded. It is recommended that this be done in the same order as 788 they were sent. Note that if an Originator Spoken Name audio body and 789 a vCard are both present in a VPIM message, the vCard SOUND attribute 790 MUST point to this audio body (see 4.3.3). 792 While any valid MIME body header MAY be used, several headers have the 793 following semantics when included with this body part: 795 4.3.4.1 Content-Description: 797 This field MAY be present to facilitate the text identification of 798 these body parts in simple email readers. Any values may be used, 799 though it may be useful to use values similar to those for Content- 800 Disposition. 802 Example: 804 Content-Description: Big Telco Voice Message 806 4.3.4.2 Content-Disposition: 808 This field MUST be present to allow the parsable identification of 809 these body parts. This is especially useful if, as is typical, 810 more than one Audio/32KADPCM body occurs within a single level 811 (e.g. multipart/voice-message). Since a VPIM voice message is 812 intended to be automatically played upon display of the message, in 813 the order in which the audio contents occur, the audio contents 814 must always be of type inline. However, it is still useful to 815 include a filename value, so this should be present if this 816 information is available. From [DISP] 818 In order to distinguish between the various types of audio contents 819 in a VPIM voice message a new disposition parameter "voice" is 820 defined with the following values to be used as appropriate (note 821 that there SHOULD only be one instance of each of these types of 822 audio contents per message level. Additional instances of a given 823 types within a forwarded voice message may be included): 825 Voice-Message - the primary voice message, 826 Voice-Message-Notification - a spoken delivery notification 827 or spoken disposition notification, 828 Originator-Spoken-Name - the spoken name of the originator, 829 Recipient-Spoken-Name - the spoken name of the recipient if 830 available to the originator and present if there is ONLY one 831 recipient, 832 Spoken-Subject- the spoken subject of the message, typically 833 spoken by the originator 835 Implementations that do not understand the "voice" parameter (or 836 the Content-Disposition header) can safely ignore it, and will 837 present the audio bodyparts in order (but will not be able to 838 distinguish between them). 840 Example: 842 Content-Disposition: inline; voice=spoken-subject; 843 filename=msg001.726 845 4.3.4.3 Content-Duration: 847 This field MAY be present to allow the specification of the length 848 of the audio bodypart in seconds. The use of this field on 849 reception is a local implementation issue. From [DUR] 851 Example: 853 Content-Duration: 33 855 4.3.4.4 Content-Language: 857 This field MAY be present to allow the specification of the spoken 858 language of the audio bodypart. The encoding is defined in [LANG]. 859 The use of this field on reception is a local implementation issue. 861 Example for UK English: 863 Content-Language: EN-UK 865 4.3.5 Image/Tiff 867 A common image encoding for facsimile, known as TIFF-F, is a 868 derivative of the Tag Image File Format (TIFF) and is described in 869 several documents. For the purposes of VPIM, the TIFF-F file format 870 is defined in [TIFF-F] and the image/tiff MIME content type is defined 871 in [TIFFREG]. While there are several formats of TIFF, only TIFF-F is 872 profiled for use in a VPIM voice message. Further, since the TIFF-F 873 file format is used in a store-and-forward mode with VPIM, the image 874 MUST be encoded so that there is only one strip per facsimile page. 876 All VPIM implementations that support facsimile MUST generate and read 877 TIFF-F compatible facsimile contents in the image/tiff; application=F 878 sub-type encoding by default. An implementation MAY send this fax 879 content in VPIM voice messages and MUST be able to recognize it in 880 received messages. If a fax message is received that cannot be 881 rendered to the user (e.g. the receiving VPIM system does not support 882 fax), then the system MUST non-deliver the entire message with a media 883 not supported error. 885 While any valid MIME body header MAY be used (e.g., Content-Dispostion 886 to indicate the filename), none are specified to have special 887 semantics for VPIM and MAY be ignored. Note that the content type 888 paramater application=F MUST be included in outbound messages. 889 However, inbound messages with or without this parameter MUST be 890 rendered to the user (if the rendering software encounters an error in 891 the file format, some form of non-delivery notification MUST be sent 892 to the originator). 894 4.3.6 Proprietary Voice or Fax Formats 896 Proprietary voice or fax encoding formats or other standard formats 897 may be supported under this profile provided a unique identifier is 898 registered with the IANA prior to use (see [MIME4]). The voice 899 encodings should be registered as sub-types of Audio and the fax 900 encodings should be registered as sub-types of Image 902 Use of any other encoding except audio/32kadpcm or image/tiff; 903 application=F reduces interoperability in the absence of explicit 904 manual system configuration. A compliant implementation MAY use any 905 other encoding with explicit per-destination configuration. 907 4.4 Other Message Content Types 909 An implementation compliant with this profile MAY send additional 910 contents in a VPIM message, but ONLY outside of the multipart/voice- 911 message. The content types described in this section are identified 912 for use with this profile. Contents not defined here MUST NOT be used 913 without prior explicit per-destination configuration. If an 914 implementation receives a VPIM message that contains content types 915 not specified in this profile, their handling is a local 916 implementation issue (e.g. the unknown contents MAY be discarded if 917 they cannot be presented to the recipient). Conversely, if an 918 implementation receives a non-VPIM message with any of the contents 919 defined in 4.3 & 4.4, it SHOULD deliver those contents, but the full 920 message handling is a local issue (e.g. the unknown contents _or_ the 921 entire message MAY be discarded). It is recommended that 922 implementations issue delivery notifications to the originator when 923 any form of non-delivery to the recipient occurs. 925 Each of the contents defined below can be sent individually in a VPIM 926 message or wrapped in a multipart/mixed to form a more complex 927 structure (several examples are given in Appendix B). When multiple 928 contents are present, they SHOULD be presented to the user in the 929 order that they appear in the message. 931 4.4.1 Multipart/Mixed 933 MIME provides the facilities for enclosing several body parts in a 934 single message. Multipart/Mixed SHOULD only be used for sending 935 complex voice or multimedia messages. That is, as the top level 936 Content-Type when sending one of the following contents (in addition 937 to the VPIM voice message) in a VPIM message. Compliant systems MUST 938 accept multipart/mixed body parts. From [MIME2] 940 4.4.2 Text/Plain 942 MIME requires support of the basic Text/Plain content type. This 943 content type has limited applicability within the voice messaging 944 environment. Compliant implementations SHOULD NOT send the Text/Plain 945 content-type, but SHOULD only send this content if the recipient 946 system is known to support it. Compliant implementations MUST accept 947 Text/Plain messages, however, specific handling is left as an 948 implementation decision. From [MIME2] 950 There are several mechanisms that can be used to support text on voice 951 messaging systems including text-to-speech and text-to-fax 952 conversions. If no rendering of the text is possible (i.e. it is not 953 possible for the recipient to determine if the text is a critical part 954 of the message), the entire message MUST be non-delivered and returned 955 to the sender with a media-unsupported error code. 957 4.4.3 Multipart/Report 959 The Multipart/Report is used for enclosing human-readable and machine 960 parsable notification (e.g. Message/delivery-status) body parts and 961 any returned message content. Compliant implementations MUST use the 962 Multipart/Report construct when returning messages, sending warnings, 963 or issuing read receipts. Compliant implementations MUST recognize 964 and decode the Multipart/Report content type. From [REPORT] 966 Multipart/Report messages from VPIM implementations SHOULD include the 967 human-readable description of the error as a spoken audio/* content 968 (this speech SHOULD also be made available to the notification 969 recipient). As well, VPIM implementations MUST be able to handle (and 970 MAY generate) Multipart/Report messages that encode the human-readable 971 description of the error as text. 973 4.4.4 Message/Delivery-status 975 This MIME body part is used for sending machine-parsable delivery 976 status notifications. Compliant implementations must use the 977 Message/delivery-status construct when returning messages or sending 978 warnings. Compliant implementations must recognize and decode the 979 Message/delivery-status content type and present the reason for 980 failure to the user. From [DSN] 982 4.4.5 Message/Disposition-notification 984 This MIME body part is used for sending machine-parsable read-receipt 985 message disposition notifications. Conforming implementations should 986 use the Message/Disposition-notification construct when sending post- 987 delivery message status notifications. These MDNs, however, MUST only 988 be sent in response to the presence of the Disposition-notification-to 989 header in 4.2.16. Conforming implementations should recognize and 990 decode the Message/Disposition-notification content type and present 991 the notification to the user. From [MDN] 993 4.5 Forwarded Messages 995 VPIM version 2 explicitly supports the forwarding of voice and fax 996 content with voice or fax annotation. However, only the two 997 constructs described below are acceptable in a VPIM message. Since 998 only the first (i.e. message/rfc822) can be recognized as a forwarded 999 message (or even multiple forwarded messages), it is recommended that 1000 this construct be used whenever possible. 1002 Forwarded VPIM messages SHOULD be sent as a multipart/voice-message 1003 with the entire original message enclosed in a message/rfc822 content 1004 type and the annotation as a separate Audio/* or image/* body part. 1005 If the RFC822 headers are not available for the forwarded content, 1006 simulated headers with available information SHOULD be constructed to 1007 indicate the original sending timestamp, and the original sender as 1008 indicated in the "From" line. However, note that at least one of 1009 "From", "Subject", or "Date" MUST be present. As well, the 1010 message/rfc822 content MUST include at least the "MIME-Version", 1011 "Content-Type" headers, and MAY include the "Content-Transfer- 1012 Encoding" header. From [MIME2] 1014 In the event that forwarding information is lost through concatenation 1015 of the original message and the forwarding annotation, such as must be 1016 done in a gateway between VPIM and the AMIS voice messaging protocol, 1017 the entire content MAY be sent as a single Audio/* segment without 1018 including any forwarding semantics. 1020 4.6 Reply Messages 1022 Replies to VPIM messages (and Internet mail messages) are addressed to 1023 the address noted in the reply-to header (see 4.2.8) if it is present, 1024 else the From address (see 4.2.1) is used. The vCard EMAIL attribute, 1025 if present, SHOULD be the same as the reply-to address and may be the 1026 same as the From address. While the vCard is the senders preferred 1027 address it SHOULD NOT be used to generate a reply. Also, the Return- 1028 path address should not be used for replies. 1030 Support of multiple originator headers is often not possible on voice 1031 messaging systems, so it may be necessary to choose only one. 1032 However, implementors should note that this may make it impossible to 1033 send error messages and replies to the proper destination. 1035 In some cases, a reply message is not possible, such as with a message 1036 created by telephone answering (i.e. classic voice mail). In this 1037 case, the From field MUST contain the special address non-mail- 1038 user@domain (see 4.1.2). The use of a null ESMTP MAIL FROM address 1039 SHOULD also be used in this case (see 5.1.2). A receiving VPIM system 1040 SHOULD not offer the user the option to reply to this kind of message. 1042 4.7 Notification Messages 1044 VPIM Delivery Notification messages (4.4.4) must be sent to the 1045 originator of the message when any form of non-delivery of the subject 1046 message or its components occurs. These error messages must be sent 1047 to the return path (4.2.6) if present, else the sender (4.2.5) or From 1048 (4.2.1) address may be used (in that order). 1050 VPIM Receipt Notification messages (4.4.5) should be sent to the 1051 sender specified in the MDN header (4.2.16), only if the header is 1052 present, and typically after the user has initiated the notification 1053 by some action (like listening to the message). 1055 VPIM Notification messages may be positive or negative, and can 1056 indicate delivery at the server or receipt by the client. However, 1057 the notification MUST be contained in a multipart/report container 1058 (4.4.3) and SHOULD contain a spoken error message. It is recommended 1059 that systems that do not support the notification format SHOULD still 1060 send some form of error message when non-delivery occurs. 1062 If a VPIM system receives a message with contents that are not 1063 understood (see 4.3 & 4.4), its handling is a local matter, though any 1064 VPIM voice message content SHOULD be delivered. A delivery status 1065 notification SHOULD be generated if the message could not be delivered 1066 because of unknown contents (e.g., on traditional voice processing 1067 systems). In some cases, the message may be delivered (with a 1068 positive DSN sent) to a mailbox before the determination of rendering 1069 can be made. In this case, however, an MDN can only be sent to 1070 indicate that the message could not be rendered if it was requested. 1072 5. Message Transport Protocol 1074 Messages are transported between voice mail machines using the 1075 Internet Extended Simple Mail Transfer Protocol (ESMTP). All 1076 information required for proper delivery of the message is included in 1077 the ESMTP dialog. This information, including the sender and 1078 recipient addresses, is commonly referred to as the message 1079 "envelope". This information is equivalent to the message control 1080 block in many analog voice networking protocols. 1082 ESMTP is a general-purpose messaging protocol, designed both to send 1083 mail and to allow terminal console messaging. Simple Mail Transport 1084 Protocol (SMTP) was originally created for the exchange of US-ASCII 7- 1085 bit text messages. Binary and 8-bit text messages have traditionally 1086 been transported by encoding the messages into a 7-bit text-like form. 1087 [ESMTP] formalized an extension mechanism for SMTP, and subsequent 1088 RFCs have defined 8-bit text networking, command streaming, binary 1089 networking, and extensions to permit the declaration of message size 1090 for the efficient transmission of large messages such as multi-minute 1091 voice mail. 1093 The following sections list ESMTP commands, keywords, and parameters 1094 that are required and those that are optional for conformance to this 1095 profile. 1097 5.1 ESMTP Commands 1099 5.1.1 HELO 1101 Base SMTP greeting and identification of sender. This command is not 1102 to be sent by compliant systems unless the more-capable EHLO command 1103 is not accepted. It is included for compatibility with general SMTP 1104 implementations. Compliant implementations MUST implement the HELO 1105 command for backward compatibility but SHOULD NOT send it unless EHLO 1106 is not supported. From [SMTP] 1108 5.1.2 MAIL FROM (REQUIRED) 1110 Originating mailbox. This address contains the mailbox to which 1111 errors should be sent. This address may not be the same as the 1112 message sender listed in the message header fields if the message was 1113 received from a gateway or sent to an Internet-style mailing list. 1114 Compliant implementations MUST implement the extended MAIL FROM 1115 command. From [SMTP, ESMTP] 1117 The MAIL FROM address MAY be passed as a local system parameter or 1118 placed in a Return-Path: line inserted at the beginning of a VPIM 1119 message. From [HOSTREQ] 1121 Since error messages MUST be sent to the MAIL FROM address, the use of 1122 the null address ("<>") is often used to prevent looping of error 1123 notifications. This null address MAY also be used to note that a 1124 particular message has no return path (e.g. a telephone answer 1125 message). From [SMTP] 1127 5.1.3 RCPT TO 1129 Recipient's mailbox. This field contains only the addresses to which 1130 the message should be delivered for this transaction. In the event 1131 that multiple transport connections to multiple destination machines 1132 are required for the same message, this list may not match the list of 1133 recipients in the message header. Compliant implementations MUST 1134 implement the extended RCPT TO command. From [SMTP, ESMTP] 1136 5.1.4 DATA 1138 Initiates the transfer of message data. Support for this command is 1139 required in the event the binary mode command BDAT is not supported by 1140 the remote system. Compliant implementations MUST implement the SMTP 1141 DATA command for backwards compatibility. From [SMTP] 1143 5.1.5 TURN 1145 Requests a change-of-roles, that is, the client that opened the 1146 connection offers to assume the role of server for any mail the remote 1147 machine may wish to send. Because SMTP is not an authenticated 1148 protocol, the TURN command presents an opportunity to improperly fetch 1149 mail queued for another destination. Compliant implementations SHOULD 1150 NOT implement the TURN command. From [SMTP] 1152 5.1.6 QUIT 1154 Requests that the connection be closed. If accepted, the remote 1155 machine will reset and close the connection. Compliant 1156 implementations MUST implement the QUIT command. From [SMTP] 1158 5.1.7 RSET 1160 Resets the connection to its initial state. Compliant implementations 1161 MUST implement the RSET command. From [SMTP] 1163 5.1.8 VRFY 1165 Requests verification that this node can reach the listed recipient. 1166 While this functionality is also included in the RCPT TO command, VRFY 1167 allows the query without beginning a mail transfer transaction. This 1168 command is useful for debugging and tracing problems. Compliant 1169 implementations MAY implement the VRFY command. From [SMTP] 1171 (Note that the implementation of VRFY may simplify the guessing of a 1172 recipient's mailbox or automated sweeps for valid mailbox addresses, 1173 resulting in a possible reduction in privacy. Various implementation 1174 techniques may be used to reduce the threat, such as limiting the 1175 number of queries per session.) From [SMTP] 1177 5.1.9 EHLO 1179 The enhanced mail greeting that enables a server to announce support 1180 for extended messaging options. The extended messaging modes are 1181 discussed in subsequent sections of this document. Compliant 1182 implementations MUST implement the ESMTP command and return the 1183 capabilities indicated later in this memo. From [ESMTP] 1185 5.1.10 BDAT 1187 The BDAT command provides a higher efficiency alternative to the 1188 earlier DATA command, especially for voice. The BDAT command provides 1189 for native binary transport of messages. Compliant implementations 1190 SHOULD support binary transport using the BDAT command.[BINARY] 1192 5.2 ESMTP Keywords 1194 The following ESMTP keywords indicate extended features useful for 1195 voice messaging. 1197 5.2.1 PIPELINING 1199 The "PIPELINING" keyword indicates ability of the receiving server to 1200 accept new commands before issuing a response to the previous command. 1201 Pipelining commands dramatically improves performance by reducing the 1202 number of round-trip packet exchanges and makes it possible to 1203 validate all recipient addresses in one operation. Compliant 1204 implementations SHOULD support the command pipelining indicated by 1205 this parameter. From [PIPE] 1207 5.2.2 SIZE 1209 The "SIZE" keyword provides a mechanism by which the SMTP server can 1210 indicate the maximum size message supported. Compliant 1211 implementations MUST provide the size capability and SHOULD honor any 1212 size limitations when sending. From [SIZE] 1214 5.2.3 CHUNKING 1216 The "CHUNKING" keyword indicates that the receiver will support the 1217 high-performance binary transport mode. Note that CHUNKING can be 1218 used with any message format and does not imply support for binary 1219 encoded messages. Compliant implementations SHOULD support binary 1220 transport indicated by this capability. From [BINARY] 1222 5.2.4 BINARYMIME 1224 The "BINARYMIME" keyword indicates that the SMTP server can accept 1225 binary encoded MIME messages. Compliant implementations SHOULD support 1226 binary transport indicated by this capability. Note that support for 1227 this feature requires support of CHUNKING. From [BINARY] 1229 5.2.5 DSN 1231 The "DSN" keyword indicates that the SMTP server will accept explicit 1232 delivery status notification requests. Compliant implementations MUST 1233 support the delivery notification extensions in [DRPT]. 1235 5.2.6 ENHANCEDSTATUSCODES 1237 The "ENHANCEDSTATUSCODES" keyword indicates that an SMTP server 1238 augments its responses with the enhanced mail system status codes 1239 [CODES]. These codes can then be used to provide more informative 1240 explanations of error conditions, especially in the context of the 1241 delivery status notifications format defined in [DSN]. Compliant 1242 implementations SHOULD support this capability. From [STATUS] 1244 5.3 ESMTP Parameters - MAIL FROM 1246 5.3.1 BINARYMIME 1248 The current message is a binary encoded MIME messages. Compliant 1249 implementations SHOULD support binary transport indicated by this 1250 parameter. From [BINARY] 1252 5.3.2 RET 1254 The RET parameter indicates whether the content of the message should 1255 be returned. Compliant systems SHOULD honor a request for returned 1256 content. From [DRPT] 1258 5.3.3 ENVID 1260 The ENVID keyword of the SMTP MAIL command is used to specify an 1261 "envelope identifier" to be transmitted along with the message and 1262 included in any DSNs issued for any of the recipients named in this 1263 SMTP transaction. The purpose of the envelope identifier is to allow 1264 the sender of a message to identify the transaction for which the DSN 1265 was issued. Compliant implementations MAY use this parameter. From 1266 [DRPT] 1268 5.4 ESMTP Parameters - RCPT TO 1270 5.4.1 NOTIFY 1272 The NOTIFY parameter indicates the conditions under which a delivery 1273 report should be sent. Compliant implementations MUST honor this 1274 request. From [DRPT] 1276 5.4.2 ORCPT 1278 The ORCPT keyword of the RCPT command is used to specify an "original" 1279 recipient address that corresponds to the actual recipient to which 1280 the message is to be delivered. If the ORCPT esmtp-keyword is used, 1281 it MUST have an associated esmtp-value, which consists of the original 1282 recipient address, encoded according to the rules below. Compliant 1283 implementations MAY use this parameter. From [DRPT] 1285 5.5 ESMTP - SMTP Downgrading 1287 To ensure a consistent level of service across an intranet or the 1288 global Internet, it is essential that VPIM compliant ESMTP be 1289 supported at all hops between a VPIM originating system and the 1290 recipient system. Unfortunately, in the situation where a `downgrade' 1291 is unavoidable the expected result is not defined. A downgrade is 1292 defined as the loss of VPIM transport features at some hop due to the 1293 lack of support. For example, a relay hop may be forced (by the next 1294 hop) to forward a VPIM using SMTP instead of ESMTP, or using DATA 1295 instead of BDAT. It is recommended that the downgrading system should 1296 continue to attempt to deliver the message, but MUST send an 1297 appropriate delivery notification to the originator, e.g. the message 1298 left an ESMTP host and was sent (unreliably) via SMTP. 1300 6. Directory Address Resolution 1302 It is the responsibility of a VPIM system to lookup the fully- 1303 qualified domain name (FQDN) based on the address entered by the user 1304 (if the entered address is not already a FQDN). This would typically 1305 be an issue on systems that offered only a telephone user interface. 1306 The mapping of the dialed target number to a routable FQDN address 1307 allowing delivery to the destination system can be accomplished 1308 through implementation-specific means. 1310 To facilitate a local dial-by-name cache, an implementation may wish 1311 to populate local directories with the first and last names, as well 1312 as the address information extracted from received messages. It is 1313 mandated that only address information from vCard attachments to VPIM 1314 messages be used to populate such a directory when the vCard is 1315 available. Addresses or names parsed from the headers of VPIM messages 1316 SHOULD NOT be used to populate directories as it only provides partial 1317 data. Alternatively, bilateral agreements could be made to allow the 1318 bulk transfer of vCards between systems. 1320 7. IMAP 1322 The use of client/server desktop mailbox protocols like IMAP or POP to 1323 retrieve VPIM messages from a IMAP or POP message store is possible 1324 without any special modifications to this VPIM specification. Email 1325 clients (and web browsers) typically have a table for mapping from 1326 MIME type to displaying application. The audio/*, image/tiff and 1327 text/directory contents can be configured so that they invoke the 1328 correct player/recorder for rendering. In addition with IMAP clients, 1329 the first multipart/mixed content (if present) will not appear since 1330 it is a generic part. The user instead will be presented with a 1331 message that has (for example) audio and image contents. 1333 8. Management Protocols 1335 The Internet protocols provide a mechanism for the management of 1336 messaging systems, from the management of the physical network through 1337 the management of the message queues. SNMP should be supported on a 1338 compliant message machine. 1340 8.1 Network Management 1342 The digital interface to the VM and the TCP/IP protocols SHOULD be 1343 managed. MIB II SHOULD be implemented to provide basic statistics and 1344 reporting of TCP and IP protocol performance. [MIB II] 1346 9. Conformance Requirements 1348 VPIM is a messaging application which must be supported in several 1349 environments and be supported on differing devices. These 1350 environments include traditional voice processing systems, desktop 1351 voice messaging systems, store and forward relays, and protocol 1352 translation gateways. 1354 In order to accommodate all environments, this document defines two 1355 areas of conformance: transport and content. 1357 Transport conformant systems will pass VPIM messages in a store and 1358 forward manner with assured delivery notifications and without the 1359 loss of information. It is expected that most store and forward 1360 Internet mail based messaging systems will be VPIM transport 1361 compliant. 1363 Content conformant systems will generate and interpret VPIM messages. 1364 Conformance in the generation of VPIM messages indicates that the 1365 restrictions of this profile are honored. Only contents specified in 1366 this profile or extensions agreed to by bilateral agreement may be 1367 sent. Conformance in the interpretation of VPIM messages indicates 1368 that all VPIM content types and constructs can be received; that all 1369 mandatory VPIM content types can be decoded and presented to the 1370 recipient in an appropriate manner; and that any unrenderable contents 1371 result in the appropriate notification. 1373 A summary of the compliance requirements is contained in Appendix A. 1375 VPIM end systems are expected to be both transport and content 1376 conformant. They should generate conforming content, reliably send it 1377 to the next hop system, receive a message, decode the message and 1378 present it to the user. Voice messaging systems and protocol 1379 conversion gateways are considered end systems. 1381 Relay systems are expected to be transport compliant in order to 1382 receive and send conforming messages. However, they must also create 1383 VPIM conforming delivery status notifications in the event of delivery 1384 problems. 1386 Desktop Email clients that support VPIM and are expected to be content 1387 conformant. Desktop email clients use various protocols and API's for 1388 exchanging messages with the local message store and message transport 1389 system. While these clients may benefit from VPIM transport 1390 capabilities, specific client-server requirements are out-of-scope for 1391 this document. 1393 10. References 1395 [8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E., D. Crocker, 1396 "SMTP Service Extension for 8bit-MIMEtransport" RFC 1426, United 1397 Nations University, Innosoft International, Inc., Dover Beach 1398 Consulting, Inc., Network Management Associates, Inc., The Branch 1399 Office, February 1993. 1401 [ADPCM] G. Vaudreuil and G. Parsons, "Toll Quality Voice - 32 kbit/s 1402 ADPCM: MIME Sub-type Registration", Work In Progress, , November 1997. 1405 [AMIS-A] Audio Messaging Interchange Specifications (AMIS) - Analog 1406 Protocol Version 1, Issue 2, February 1992. 1408 [AMIS-D] Audio Messaging Interchange Specifications (AMIS) - Digital 1409 Protocol Version 1, Issue 3 August 1993. 1411 [BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of 1412 Large and Binary MIME Messages", RFC 1830, October 1995. 1414 [CODES] Vaudreuil, G. "Enhanced Mail System Status Codes", RFC 1893, 1415 01/15/1996. 1417 [DIRECTORY] F. Dawson, T. Howes, & M. Smith, "A MIME Content-Type for 1418 Directory Information", Work In Progress, , November 1997 1421 [DISP] R. Troost and S. Dorner, Communicating Presentation Information 1422 in Internet Messages: The Content-Disposition Header, RFC 1806, June 1423 1995 1425 [DNS1] Mockapetris, P., "Domain names - implementation and 1426 specification", RFC1035, Nov 1987. 1428 [DNS2] Mockapetris, P., "Domain names - concepts and facilities", RFC 1429 1034, Nov 1987. 1431 [DRPT] Moore, K. "SMTP Service Extensions for Delivery Status 1432 Notifications", RFC 1891, 01/15/1996 1434 [DSN] Moore, K., Vaudreuil, G., "An Extensible Message Format for 1435 Delivery Status Notifications", RFC 1894, 01/15/1996. 1437 [DUR] G. Parsons and G. Vaudreuil, "Content Duration MIME Header 1438 Definition", Work In Progress, , November 1439 1997. 1441 [E164] CCITT Recommendation E.164 (1991), Telephone Network and ISDN 1442 Operation, Numbering, Routing and Mobile Service - Numbering Plan 1443 for the ISDN Era. 1445 [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, 1446 "SMTP Service Extensions" RFC 1869, United Nations University, 1447 Innosoft International, Inc., Dover Beach Consulting, Inc., Network 1448 Management Associates, Inc., The Branch Office, November 1995. 1450 [G726] CCITT Recommendation G.726 (1990), General Aspects of Digital 1451 Transmission Systems, Terminal Equipment - 40, 32, 24,16 kbit/s 1452 Adaptive Differential Pulse Code Modulation (ADPCM). 1454 [HOSTREQ] Braden, R., "Requirements for Internet Hosts -- Application 1455 and Support", STD 3, RFC 1123, October 1989. 1457 [LANG] Alvestrand,H., "Tags for the Identification of Languages", RFC 1458 1766, Mar 1995 1460 [MDN] Fajman, Roger, "An Extensible Message Format for Message 1461 Disposition Notifications" Work In Progress, , November 1997 1464 [MIB II] M. Rose, "Management Information Base for Network Management of 1465 TCP/IP-based internets: MIB-II", RFC 1158, May 1990. 1467 [MIME1] N. Freed and N. Borenstein, "Multipurpose Internet Mail 1468 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 1469 2045, Innosoft, First Virtual, Nov 1996. 1471 [MIME2] N. Freed and N. Borenstein, "Multipurpose Internet Mail 1472 Extensions (MIME) Part Two: Media Types ", RFC 2046, Innosoft, First 1473 Virtual, Nov 1996. 1475 [MIME3] K. Moore, "Multipurpose Internet Mail Extensions (MIME) Part 1476 Three: Message Header Extensions for Non-ASCII Text ", RFC 2047, 1477 University of Tennessee, Nov 1996. 1479 [MIME4] N. Freed, J. Klensin and J. Postel, "Multipurpose Internet Mail 1480 Extensions (MIME) Part Four: Registration Procedures", RFC 2048, 1481 Innosoft, MCI, ISI, Nov 1996. 1483 [MIME5] N. Freed and N. Borenstein, "Multipurpose Internet Mail 1484 Extensions (MIME) Part Five: Conformance Criteria and Examples ", RFC 1485 2049, Innosoft, First Virtual, Nov 1996. 1487 [PIPE] Freed, N., Cargille, A., "SMTP Service Extension for Command 1488 Pipelining" RFC 1854, October 1995. 1490 [REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the 1491 Reporting of Mail System Administrative Messages", RFC 1892, 1492 01/15/1996. 1494 [REQ] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1495 Levels", RFC 2119, March 1997. 1497 [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text 1498 Messages", STD 11, RFC 822, UDEL, August 1982. 1500 [SIZE] Klensin, J, Freed, N., Moore, K, "SMTP Service Extensions for 1501 Message Size Declaration" RFC 1870, United Nations University, 1502 Innosoft International, Inc., November 1995. 1504 [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 1505 USC/Information Sciences Institute, August 1982. 1507 [STATUS] Freed, N. "SMTP Service Extension for Returning Enhanced Error 1508 Codes", RFC 2034, 10/30/1996. 1510 [TIFF-F] G. Parsons and J. Rafferty, "Tag Image File Format: 1511 Application F", , November 1997. 1513 [TIFFREG] G. Parsons, J. Rafferty & S. Zilles, "Tag Image File Format: 1514 image/tiff - MIME sub-type registraion", , 1515 September 1997. 1517 [V-MSG] G. Vaudreuil and G. Parsons, "VPIM Voice Message: MIME Sub-type 1518 Registration", Work In Progress, , 1519 November 1997. 1521 [VCARD] Dawson, Frank, Howes, Tim, "vCard MIME Directory Profile" 1522 , November 1997. 1524 [VPIM1] Vaudreuil, Greg, "Voice Profile for Internet Mail", RFC 1911, 1525 Feb 1996. 1527 [X.400] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021 1528 and RFC 822", RFC 1327, May 1992. 1530 11. Security Consideration 1532 This document is a profile of existing Internet mail protocols. As 1533 such, it does not create any security issues not already existing in 1534 the profiled Internet mail protocols themselves. 1536 Further, the profile specified in this document does not in any way 1537 preclude the use of any Internet mail security protocol to encrypt, 1538 authenticate, or non-repudiate the messages. 1540 12. Acknowledgments 1542 The authors would like to offer a special thanks to the Electronic 1543 Messaging Association (EMA), especially the members of the Voice 1544 Messaging Committee and the VPIM Work Group, for their support of the 1545 VPIM specification and the efforts they have made to ensure its 1546 success. 1548 The EMA hosts the VPIM web page at http://www.ema.org/vpim. 1550 13. Copyright Notice 1552 "Copyright (C) The Internet Society (date). All Rights Reserved. 1554 This document and translations of it may be copied and furnished to 1555 others, and derivative works that comment on or otherwise explain it 1556 or assist in its implmentation may be prepared, copied, published and 1557 distributed, in whole or in part, without restriction of any kind, 1558 provided that the above copyright notice and this paragraph are 1559 included on all such copies and derivative works. However, this 1560 document itself may not be modified in any way, such as by removing 1561 the copyright notice or references to the Internet Society or other 1562 Internet organizations, except as needed for the purpose of 1563 developing Internet standards in which case the procedures for 1564 copyrights defined in the Internet Standards process must be followed, 1565 or as required to translate it into languages other than English. 1567 The limited permissions granted above are perpetual and will not be 1568 revoked by the Internet Society or its successors or assigns. 1570 This document and the information contained herein is provided on an 1571 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1572 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1573 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 1574 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1575 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1577 14. Authors' Addresses 1579 Glenn W. Parsons 1580 Northern Telecom 1581 P.O. Box 3511, Station C 1582 Ottawa, ON K1Y 4H7 1583 Canada 1584 Phone: +1-613-763-7582 1585 Fax: +1-613-763-4461 1586 Glenn.Parsons@Nortel.ca 1588 Gregory M. Vaudreuil 1589 Lucent Technologies, 1590 Octel Messaging Division 1591 17080 Dallas Parkway 1592 Dallas, TX 75248-1905 1593 United States 1594 Phone/Fax: +1-972-733-2722 1595 GregV@Lucent.Com 1597 15. Appendix A - VPIM Requirements Summary 1599 The following table summarizes the profile of VPIM version 2 detailed 1600 in this document. Since in many cases it is not possible to simplify 1601 the qualifications for supporting each feature, the reader is 1602 recommended to read the complete explanations in the referenced 1603 section. The text in the previous sections shall be deemed 1604 authoritative if any item in this table is ambiguous. 1606 The conformance table is separated into various columns: 1608 Feature - name of protocol feature (note that the indenting 1609 indicates a hierarchy of conformance, i.e. the 1610 conformance of a lower feature is only relevant if there 1611 is conformance to the higher feature) 1613 Section - reference section in main text of this document 1615 Area - conformance area to which each feature applies: 1616 C - content 1617 T - transport 1619 Status - whether the feature is mandatory, optional, or prohibited. 1620 The key words used in this table are to be interpreted as described 1621 in [REQ], though the following list gives a quick overview of the 1622 different degrees of feature conformance: 1623 Must - mandatory 1624 Should - encouraged optional 1625 May - optional 1626 Should not - discouraged optional 1627 Must not - prohibited 1629 Footnote - special comment about conformance for a particular 1630 feature 1631 VPIM version 2 Conformance 1632 | | | | |S| | 1633 | | | | | |H| |F 1634 | | | | | |O|M|o 1635 | | | |S| |U|U|o 1636 | | | |H| |L|S|t 1637 | |A|M|O| |D|T|n 1638 | |R|U|U|M| | |o 1639 | |E|S|L|A|N|N|t 1640 | |A|T|D|Y|O|O|t 1641 FEATURE |SECTION | | | | |T|T|e 1642 -------------------------------------------|----------|-|-|-|-|-|-|- 1643 | | | | | | | | 1644 Message Addressing Formats: | | | | | | | | 1645 Use DNS host names |4.1 |C|x| | | | | 1646 Use only numbers in mailbox IDs |4.1.1 |C| |x| | | | 1647 Use alpha-numeric mailbox IDs |4.1.1 |C| | |x| | | 1648 Support of postmaster@domain |4.1.2 |C|x| | | | | 1649 Support of non-mail-user@domain |4.1.2 |C| |x| | | | 1650 Support of distribution lists |4.1.3 |C| |x| | | | 1651 | | | | | | | | 1652 Message Header Fields: | | | | | | | | 1653 Encoding outbound messages | | | | | | | | 1654 From |4.2.1 |C|x| | | | | 1655 Addition of text name |4.2.1 |C| |x| | | | 1656 To |4.2.2 |C|x| | | | |1 1657 cc |4.2.3 |C| |x| | | |1 1658 Date |4.2.4 |C|x| | | | | 1659 Sender |4.2.5 |C| | |x| | | 1660 Return-Path |4.2.6 |C| | |x| | | 1661 Message-id |4.2.7 |C|x| | | | | 1662 Reply-To |4.2.8 |C| | |x| | | 1663 Received |4.2.9 |C|x| | | | | 1664 MIME Version: 1.0 (Voice 2.0) |4.2.10 |C| |x| | | | 1665 Content-Type |4.2.11 |C|x| | | | | 1666 Content-Transfer-Encoding |4.2.12 |C|x| | | | | 1667 Sensitivity |4.2.13 |C| | |x| | | 1668 Importance |4.2.14 |C| | |x| | | 1669 Subject |4.2.15 |C| |x| | | | 1670 Disposition-notification-to |4.2.16 |C| | |x| | | 1671 Disposition-notification-options |4.2.17 |C| | |x| | | 1672 Other Headers |4.2 |C| | |x| | | 1673 | | | | | | | | 1674 | | | | |S| | 1675 | | | | | |H| |F 1676 | | | | | |O|M|o 1677 | | | |S| |U|U|o 1678 | | | |H| |L|S|t 1679 | |A|M|O| |D|T|n 1680 | |R|U|U|M| | |o 1681 | |E|S|L|A|N|N|t 1682 | |A|T|D|Y|O|O|t 1683 FEATURE |SECTION | | | | |T|T|e 1684 -------------------------------------------|----------|-|-|-|-|-|-|- 1685 Detection & Decoding inbound messages | | | | | | | | 1686 From |4.2.1 |C|x| | | | | 1687 Present text personal name |4.2.1 |C| | |x| | | 1688 To |4.2.2 |C|x| | | | | 1689 cc |4.2.3 |C| | |x| | | 1690 Date |4.2.4 |C|x| | | | | 1691 Conversion of Date to local time |4.2.4 |C| |x| | | | 1692 Sender |4.2.5 |C| | |x| | | 1693 Return-Path |4.2.6 |C| | |x| | | 1694 Message ID |4.2.7 |C|x| | | | | 1695 Reply-To |4.2.8 |C|x| | | | | 1696 Received |4.2.9 |C| | |x| | | 1697 MIME Version: 1.0 (Voice 2.0) |4.2.10 |C| |x| | | | 1698 Content Type |4.2.11 |C|x| | | | | 1699 Content-Transfer-Encoding |4.2.12 |C|x| | | | | 1700 Sensitivity |4.2.13 |C|x| | | | |2 1701 Importance |4.2.14 |C| | |x| | | 1702 Subject |4.2.15 |C| | |x| | | 1703 Disposition-notification-to |4.2.16 |C| | |x| | | 1704 Disposition-notification-options |4.2.17 |C| | |x| | | 1705 Other Headers |4.2 |C|x| | | | |3 1706 | | | | | | | | 1707 Message Content Encoding: | | | | | | | | 1708 Encoding outbound audio/fax contents | | | | | | | | 1709 7BITMIME |4.3 |C| | | | |x| 1710 8BITMIME |4.3 |C| | | | |x| 1711 Quoted Printable |4.3 |C| | | | |x| 1712 Base64 |4.3 |C|x| | | | |4 1713 Binary |4.3 |C| |x| | | |5 1714 Detection & decoding inbound messages | | | | | | | | 1715 7BITMIME |4.3 |C|x| | | | | 1716 8BITMIME |4.3 |C|x| | | | | 1717 Quoted Printable |4.3 |C|x| | | | | 1718 Base64 |4.3 |C|x| | | | | 1719 Binary |4.3 |C|x| | | | |5 1720 | | | | | | | | 1721 | | | | |S| | 1722 | | | | | |H| |F 1723 | | | | | |O|M|o 1724 | | | |S| |U|U|o 1725 | | | |H| |L|S|t 1726 | |A|M|O| |D|T|n 1727 | |R|U|U|M| | |o 1728 | |E|S|L|A|N|N|t 1729 | |A|T|D|Y|O|O|t 1730 FEATURE |SECTION | | | | |T|T|e 1731 -------------------------------------------|----------|-|-|-|-|-|-|- 1732 Message Content Types: | | | | | | | | 1733 Inclusion in outbound messages | | | | | | | | 1734 Multipart/Voice-Message |4.3.1 |C|x| | | | | 1735 Message/RFC822 |4.3.2 |C| | |x| | | 1736 Text/Directory |4.3.3 |C| |x| | | | 1737 include TEL, EMAIL |4.3.3 |C|x| | | | | 1738 include N, ROLE, SOUND, REV |4.3.3 |C| |x| | | | 1739 only one per level |4.3.3 |C|x| | | | | 1740 Audio/32KADPCM |4.3.4 |C|x| | | | | 1741 Content-Description |4.3.4.1 |C| | |x| | | 1742 Content-Disposition |4.3.4.2 |C|x| | | | | 1743 Content-Duration |4.3.4.3 |C| | |x| | | 1744 Content-Langauge |4.3.4.4 |C| | |x| | | 1745 Image/tiff; application=F |4.3.5 |C| | |x| | | 1746 Audio/* or Image/* (other encodings) |4.3.6 |C| | |x| | | 1747 Multipart/Mixed |4.4.1 |C| | |x| | | 1748 Text/plain |4.4.2 |C| | | |x| | 1749 Multipart/Report |4.4.3 |C|x| | | | | 1750 human-readable part is voice |4.4.3 |C| |x| | | | 1751 human-readable part is text |4.4.3 |C| | |x| | | 1752 Message/delivery-status |4.4.4 |C|x| | | | | 1753 Message/disposition-notification |4.4.5 |C| |x| | | | 1754 Other contents |4.4 |C| | | |x| |6 1755 | | | | | | | | 1756 Detection & decoding in inbound messages | | | | | | | | 1757 Multipart/Voice-Message |4.3.1 |C|x| | | | | 1758 Message/RFC822 |4.3.2 |C|x| | | | | 1759 Text/Directory |4.3.3 |C| |x| | | | 1760 recognize TEL, EMAIL |4.3.3 |C|x| | | | | 1761 recognize N, ROLE, SOUND, REV |4.3.3 |C| |x| | | | 1762 Audio/32KADPCM |4.3.4 |C|x| | | | | 1763 Content-Description |4.3.4.1 |C| | |x| | | 1764 Content-Disposition |4.3.4.2 |C| |x| | | | 1765 Content-Duration |4.3.4.3 |C| | |x| | | 1766 Content-Langauge |4.3.4.4 |C| | |x| | | 1767 Image/tiff; application=F |4.3.5 |C| |x| | | | 1768 send NDN if unable to render |4.3.5 |C|x| | | | |7 1769 Audio/* or Image/* (other encodings) |4.3.6 |C| | |x| | | 1770 Multipart/Mixed |4.4.1 |C|x| | | | | 1771 Text/plain |4.4.2 |C|x| | | | | 1772 send NDN if unable to render |4.4.2 |C|x| | | | | 1774 | | | | | |S| | 1775 | | | | | |H| |F 1776 | | | | | |O|M|o 1777 | | | |S| |U|U|o 1778 | | | |H| |L|S|t 1779 | |A|M|O| |D|T|n 1780 | |R|U|U|M| | |o 1781 | |E|S|L|A|N|N|t 1782 | |A|T|D|Y|O|O|t 1783 FEATURE |SECTION | | | | |T|T|e 1784 ------------------------------------------|-----------|-|-|-|-|-|-|- 1785 | | | | | | | | 1786 Multipart/Report |4.4.3 |C|x| | | | | 1787 human-readable part is voice |4.4.3 |C| |x| | | | 1788 human-readable part is text |4.4.3 |C|x| | | | | 1789 Message/delivery-status |4.4.4 |C|x| | | | | 1790 Message/disposition-notification |4.4.5 |C| |x| | | | 1791 Other contents |4.4 |C| | | |x| |6 1792 send NDN if unable to render |4.4 |C| |x| | | | 1793 | | | | | | | | 1794 Forwarded Messages | | | | | | | | 1795 use Message/RFC822 construct |4.5 |C| |x| | | | 1796 simulate headers if none available |4.5 |C| |x| | | | 1797 | | | | | | | | 1798 Reply Messages | | | | | | | | 1799 send to Reply-to, else From address |4.6 |C|x| | | | | 1800 do not send to non-mail-user |4.6 |C|x| | | | | 1801 | | | | | | | | 1802 Notifications | | | | | | | | 1803 use multipart/report format |4.7 |C|x| | | | | 1804 always send error on non-delivery |4.7 |C| |x| | | | 1805 | | | | | | | | 1806 Message Transport Protocol: | | | | | | | | 1807 ESMTP Commands | | | | | | | | 1808 HELO |5.1.1 |T|x| | | | | 1809 MAIL FROM |5.1.2 |T|x| | | | | 1810 support null address |5.1.2 |T|x| | | | | 1811 RCPT TO |5.1.3 |T|x| | | | | 1812 DATA |5.1.4 |T|x| | | | | 1813 TURN |5.1.5 |T| | | | |x| 1814 QUIT |5.1.6 |T|x| | | | | 1815 RSET |5.1.7 |T|x| | | | | 1816 VRFY |5.1.8 |T| | |x| | | 1817 EHLO |5.1.9 |T|x| | | | | 1818 BDAT |5.1.10 |T| |x| | | |5 1819 | | | | |S| | 1820 | | | | | |H| |F 1821 | | | | | |O|M|o 1822 | | | |S| |U|U|o 1823 | | | |H| |L|S|t 1824 | |A|M|O| |D|T|n 1825 | |R|U|U|M| | |o 1826 | |E|S|L|A|N|N|t 1827 | |A|T|D|Y|O|O|t 1828 FEATURE |SECTION | | | | |T|T|e 1829 -------------------------------------------|----------|-|-|-|-|-|-|- 1830 | | | | | | | | 1831 ESMTP Keywords & Parameters | | | | | | | | 1832 PIPELINING |5.2.1 |T| |x| | | | 1833 SIZE |5.2.2 |T|x| | | | | 1834 CHUNKING |5.2.3 |T| |x| | | | 1835 BINARYMIME |5.2.4,5.3.1|T| |x| | | | 1836 DSN |5.2.5 |T|x| | | | | 1837 ENHANCEDSTATUSCODES |5.2.6 |T| |x| | | | 1838 RET |5.3.2 |T| |x| | | | 1839 ENVID |5.3.3 |T| | |x| | | 1840 NOTIFY |5.4.1 |T|x| | | | | 1841 ORCPT |5.4.2 |T| | |x| | | 1842 | | | | | | | | 1843 ESMTP-SMTP Downgrading | | | | | | | | 1844 send delivery report upon downgrade | 1845 5.5 |T|x| | | | | 1846 | | | | | | | | 1847 Directory Address Resolution | | | | | | | | 1848 provide facility to resolve addresses |6 |C| |x| | | | 1849 use vCards to populate local directory |6 |C|x| | | | |8 1850 use headers to populate local directory |6 |C| | | |x| | 1851 | | | | | | | | 1852 Management Protocols: | | | | | | | | 1853 Network management |8.1 |T| |x| | | | 1854 -------------------------------------------|----------|-|-|-|-|-|-|- 1856 Footnotes: 1858 1. MUST NOT include if all recipients are not known or resolvable. 1859 2. If a sensitive message is received by a system that does not 1860 support sensitivity, then it MUST be returned to the originator 1861 with an appropriate error notification. Also, a received 1862 sensitive message MUST NOT be forwarded to anyone. 1863 3. If the addtional headers are not understood they MAY be ignored 1864 4. When binary transport is not available 1865 5. When binary transport is available 1866 6. Other un-profiled contents must only be sent by bilateral 1867 agreement. 1868 7. If the content cannot be presented in some form, the entire 1869 message MUST be non-delivered. 1870 8. When the vCard is present in a message 1872 16. Appendix B - Example Voice Messages 1874 The following message is a full-featured message addressed to two 1875 recipients. The message includes the sender's spoken name and a short 1876 speech segment. The message is marked as important and private. 1878 To: +19725551212@vm1.mycompany.com 1879 To: +16135551234@VM1.mycompany.com 1880 From: "Parsons, Glenn" <12145551234@VM2.mycompany.com> 1881 Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT) 1882 MIME-Version: 1.0 (Voice 2.0) 1883 Content-type: Multipart/Voice-Message; Version=2.0; 1884 Boundary="MessageBoundary" 1885 Content-Transfer-Encoding: 7bit 1886 Message-ID: 123456789@VM2.mycompany.com 1887 Sensitivity: Private 1888 Importance: High 1890 --MessageBoundary 1891 Content-type: Audio/32KADPCM 1892 Content-Transfer-Encoding: Base64 1893 Content-Disposition: inline; voice=Originator-Spoken-Name 1894 Content-Language: EN-US 1895 Content-ID: part1@VM2-4321 1897 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1898 (This is a sample of the base-64 Spoken Name data) 1899 fgdhgddlkgpokpeowrit09== 1901 --MessageBoundary 1902 Content-type: Audio/32KADPCM 1903 Content-Transfer-Encoding: Base64 1904 Content-Description: Brand X Voice Message 1905 Content-Disposition: inline; voice=Voice-Message; filename=msg1.726 1906 Content-Duration: 25 1908 iIiIiIjMzN3czdze3s7d7fwfHhcvESJVe/4yEhLz8/FOQjVFRERCESL/zqrq 1909 (This is a sample of the base64 message data) zb8tFdLTQt1PXj 1910 u7wjOyRhws+krdns7Rju0t4tLF7cE0K0MxOTOnRW/Pn30c8uHi9== 1912 --MessageBoundary 1913 Content-type: text/directory; charset=us-ascii; profile=vCard 1914 Content-Transfer-Encoding: 7bit 1916 BEGIN:VCARD 1917 N:Parsons;Glenn;;Mr.; 1918 EMAIL;TYPE=INTERNET:+12145551234@VM2.mycompany.com 1919 TEL:+1-217-555-1234 1920 SOUND;TYPE=32KADPCM;ENCODING=URI: CID: 1921 REV:19951031T222710Z 1922 END:VCARD 1924 --MessageBoundary_ 1925 The following message is a forwarded single segment voice. Both the 1926 forwarded message and the forwarding message contain VCARDs with 1927 spoken names. 1929 To: +12145551212@vm1.mycompany.com 1930 From: "Vaudreuil, Greg" <+19725552345@VM2.mycompany.com> 1931 Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT) 1932 MIME-Version: 1.0 (Voice 2.0) 1933 Content-type: Multipart/Voice-Message; Version=2.0; 1934 Boundary="MessageBoundary" 1935 Content-Transfer-Encoding: 7bit 1936 Message-ID: ABCD-123456789@VM2.mycompany.com 1938 --MessageBoundary 1939 Content-type: Audio/32KADPCM 1940 Content-Transfer-Encoding: Base64 1941 Content-Disposition: inline; voice=Originator-Spoken-Name 1942 Content-Language: EN-US 1943 Content-ID: part3@VM2-4321 1945 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1946 (This is a sample of the base-64 Spoken Name data) 1947 fgdhgd dlkgpokpeowrit09== 1949 --MessageBoundary 1950 Content-type: Audio/32KADPCM 1951 Content-Description: Forwarded Message Annotation 1952 Content-Disposition: inline; voice=Voice-Message 1953 Content-Transfer-Encoding: Base64 1955 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1956 (This is the voiced introductory remarks encoded in base64) 1957 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW 1958 dlkgpokpeowrit09== 1960 --MessageBoundary 1961 Content-type: Message/RFC822 1962 Content-Transfer-Encoding: 7bit 1964 To: +19725552345@VM2.mycompany.com 1965 From: "Parsons, Glenn, W." <+16135551234@VM1.mycompany.com> 1966 Date: Mon, 26 Aug 93 8:23:10 -0500 (EST) 1967 Content-type: Multipart/Voice-Message; Version=2.0; 1968 Boundary="MessageBoundary2" 1969 Content-Transfer-Encoding: 7bit 1970 MIME-Version: 1.0 (Voice 2.0) 1971 --MessageBoundary2 1972 Content-type: Audio/32KADPCM 1973 Content-Transfer-Encoding: Base64 1974 Content-Disposition: inline; voice=Originator-Spoken-Name 1975 Content-Language: EN-US 1976 Content-ID: part6@VM2-4321 1978 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1979 (This is a sample of the base-64 Spoken Name data) fgdhgd 1980 dlkgpokpeowrit09== 1982 --MessageBoundary2 1983 Content-type: Audio/32KADPCM 1984 Content-Disposition: inline; voice=Voice-Message 1985 Content-Transfer-Encoding: Base64 1987 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1988 (This is the original message audio data) fgwersdfmniwrjj 1989 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW 1990 dlkgpokpeowrit09== 1992 --MessageBoundary2 1993 Content-type: text/directory; charset=us-ascii 1994 Content-Transfer-Encoding: 7bit 1996 BEGIN:VCARD 1997 N:Parsons;Glenn;W;Mr.; 1998 EMAIL;TYPE=INTERNET:+16135551234@VM2.mycompany.com 1999 TEL:+1-613-555-1234 2000 SOUND;TYPE=32KADPCM;ENCODING=URI: CID: 2001 REV:19951031T222710Z 2002 END:VCARD 2004 --MessageBoundary2-- 2006 --MessageBoundary 2007 Content-type: text/directory; charset=us-ascii 2008 Content-Transfer-Encoding: 7bit 2010 BEGIN:VCARD 2011 N:Vaudreuil;Greg;;Mr.; 2012 SOUND;TYPE=32KADPCM;ENCODING=URI: CID: 2013 EMAIL;TYPE=INTERNET;VPIM:+19725552345@VM2.mycompany.com 2014 TEL:+1-972-555-2345 2015 REV:19951031T222710Z 2016 END:VCARD 2018 --MessageBoundary-- 2019 The following example is for a message returned to the sender by a 2020 VPIM gateway at VM1.company.com for a mailbox which does not exist. 2022 Date: Thu, 7 Jul 1994 17:16:05 -0400 2023 From: Mail Delivery Subsystem 2024 Message-Id: <199407072116.RAA14128@vm1.company.com> 2025 Subject: Returned voice message 2026 To: 2175552345@VM2.mycompany.com 2027 MIME-Version: 1.0 (Voice 2.0) 2028 Content-Type: multipart/report; report-type=delivery-status; 2029 Boundary="RAA14128.773615765/VM1.COMPANY.COM" 2031 --RAA14128.773615765/VM1.COMPANY.COM 2032 Content-type: Audio/32KADPCM 2033 Content-Description: Spoken Delivery Status Notification 2034 Content-Disposition: inline; voice= Voice-Message-Notification 2035 Content-Transfer-Encoding: Base64 2037 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd 2038 (This is a voiced description of the error in base64) 2039 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW 2040 dlkgpokpeowrit09== 2042 --RAA14128.773615765/VM1.COMPANY.COM 2043 Content-type: message/delivery-status 2045 Reporting-MTA: dns; vm1.company.com 2046 Original-Recipient: rfc822; 2145551234@VM1.mycompany.com 2047 Final-Recipient: rfc822; 2145551234@VM1.mycompany.com 2048 Action: failed 2049 Status: 5.1.1 (User does not exist) 2050 Diagnostic-Code: smtp; 550 Mailbox not found 2051 Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400 2053 --RAA14128.773615765/VM1.COMPANY.COM 2054 content-type: message/rfc822 2056 [original VPIM message goes here] 2058 --RAA14128.773615765/VM1.COMPANY.COM-- 2059 The following example is for a read receipt sent to the original 2060 sender for a message which has been played. This delivered VPIM 2061 message was received by a corporate gateway and relayed to a 2062 unified mailbox. 2064 Date: Thu, 7 Jul 1994 17:16:05 -0400 2065 From: "Greg Vaudreuil" <22722@vm.company.com> 2066 Message-Id: <199407072116.RAA14128@exchange.company.com> 2067 Subject: Voice message played 2068 To: 2175552345@VM2.mycompany.com 2069 MIME-Version: 1.0 (Voice 2.0) 2070 Content-Type: multipart/report; 2071 Report-type=disposition-notification; 2072 Boundary="RAA14128.773615765/EXCHANGE.COMPANY.COM" 2074 --RAA14128.773615765/EXCHANGE.COMPANY.COM 2075 Content-type: Audio/32KADPCM 2076 Content-Description: Spoken Disposition Notification 2077 Content-Disposition: inline; voice= Voice-Message-Notification 2078 Content-Transfer-Encoding: Base64 2080 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd 2081 (Voiced description of the disposition action in base64) 2082 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW 2083 dlkgpokpeowrit09== 2085 --RAA14128.773615765/EXCHANGE.COMPANY.COM 2086 Content-type: message/disposition-notification 2088 Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0) 2089 Original-Recipient: rfc822;22722@vm.company.com 2090 Final-Recipient: rfc822;Greg.Vaudreuil@foomail.company.com 2091 Original-Message-ID: <199509192301.12345@vm2.mycompany.com > 2092 Disposition: manual-action/MDN-sent-automatically; displayed 2094 --RAA14128.773615765/EXCHANGE.COMPANY.COM 2095 Content-type: message/rfc822 2097 [original VPIM message goes here] 2099 --RAA14128.773615765/EXCHANGE.COMPANY.COM-- 2101 17. Appendix C - Example Error Voice Processing Error Codes 2103 The following common voice processing errors and their corresponding 2104 status codes are given as examples. Text after the error codes are 2105 intended only for reference to describe the error code. 2106 Implementations should provide implementation specific informative 2107 comments after the error code rather than the text below. 2109 Error condition RFC 1893 Error codes 2110 ----------------------------- -------------------------------- 2112 Analog delivery failed 4.4.0 Persistent connection error 2113 because remote system is busy - other 2115 Analog delivery failed 4.4.1 Persistent protocol error 2116 because remote system is - no answer from host 2117 ring-no-answer 2119 Remote system did not answer 5.5.5 Permanent protocol error 2120 AMIS-Analog handshake ("D" in - wrong version 2121 response to "C" at connect 2122 time) 2124 Mailbox does not exist 5.1.1 Permanent mailbox error 2125 - does not exist 2127 Mailbox full or over quota 4.2.2 Persistent mailbox error 2128 - full 2130 Disk full 4.3.1 Persistent system error 2131 - full 2133 Command out of sequence 5.5.1 Permanent protocol error 2134 - invalid command 2136 Frame Error 5.5.2 Permanent protocol error 2137 - syntax error 2139 Mailbox does not support FAX 5.6.1 Permanent media error 2140 - not supported 2142 Mailbox does not support TEXT 5.6.1 Permanent media error 2143 - not supported 2145 Sender is not authorized 5.7.1 Permanent security error 2146 - sender not authorized 2148 Message marked private, but 5.3.3 Permanent system error 2149 system is not private capable - not feature capable 2151 18. Appendix D - Example Voice Processing Disposition Types 2153 The following common voice processing disposition conditions and their 2154 corresponding MDN Disposition (which contains the disposition mode, 2155 type and modifier, if applicable) are given as examples. Implementors 2156 should refer to [MDN] for a full description of the format of message 2157 disposition notifications. 2159 Notification event MDN Disposition mode, type & modifier 2160 ------------------------------ ------------------------------------- 2162 Message played by recipient, manual-action/MDN-sent-automatically; 2163 receipt automatically returned displayed 2165 Message deleted from mailbox manual-action/MDN-sent-automatically; 2166 by user without listening deleted 2168 Message cleared when mailbox manual-action/MDN-sent-automatically; 2169 deleted by admin deleted/mailbox-terminated 2171 Message automatically deleted automatic-action/ 2172 when older than administrator MDN-sent-automatically; deleted/ 2173 set threshold expired 2175 Message processed, however manual-action/MDN-sent-automatically; 2176 audio encoding unknown - processed/error 2177 unable to play to user Error: unknown audio encoding 2179 19. Appendix E - Change History: RFC 1911 to this Document 2181 The updated profile in this document is based on the experience of a 2182 proof of concept demonstration of VPIM at EMA'96 in April 1996 and a 2183 subsequent demonstration of products at EMA'97 in April 1997. This 2184 version of the profile is significantly different from the previous 2185 described in [VPIM1]. The changes are categorized as general, 2186 content, transport and conformance. They are detailed below: 2188 1. General 2190 - All definitions are now contained in separate documents that are 2191 referenced by this profile. The new documents include: 2193 - a refined multipart/voice-message definition 2195 - a refined (i.e. added nibble order) audio/32KADPCM definition 2197 - the definition of TIFF-F and image/tiff for fax images 2199 - the Content-Duration definition 2201 - Changed the Voice version to 2.0 2203 - Added Table of Contents and more examples 2205 - Various editorial updates to improve readability 2207 2. Content 2209 - Modified multipart/voice-message content type by dropping the 2210 positional dependence of contents while restricting its contents to 2211 voice message specific content types 2213 - Explicitly indicated other contents that may be present ina 2214 multipart/mixed content type 2216 - Explicitly defined the forwarding model using message/RFC822 2218 - Explained the use of reply-to and from headers for addressing 2219 message replies 2221 - Deprecated the special "loopback" address because of security 2222 concerns and its use only for testing 2224 - Defined the non-mail-user reserved address to support the case in 2225 which replies to the originator are not possible 2227 - Eliminated the text name in the "To" and "CC" headers. 2228 Deprecated ordering of text names in the "From" header. 2230 - Added support for facsimile using TIFF-F in a image/tiff; 2231 application=F content type 2232 - Profiled the vCard in the text/directory body part for transport 2233 of directory information about the originator 2235 - Loosened text restriction 2237 - Added additional details on delivery and receipt notifications 2239 - Added support for message disposition notifications, also known 2240 as read receipts. 2242 - Added suggested addressing formats 2244 - Described handling of private messages 2246 - Described the handling of non-profiled contents in VPIM messages 2248 - Described the use of Content-Disposition to semantically identify 2249 audio contents 2251 3. Transport 2253 - Moved binary support to optional 2255 - Added optional ESMTP keywords for return of content, enhanced 2256 status codes, original recipient, and envelope ID 2258 - Described use of null MAIL FROM address 2260 4. Compliance 2262 - Added an explicit section on conformance specifying conformance 2263 to content or transport 2265 - Improved conformance table in Appendix A