idnits 2.17.1 draft-ema-vpim-07.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 52 longer pages, the longest (page 21) being 60 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 534 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 932 has weird spacing: '...message that ...' == Line 1630 has weird spacing: '...for the purpo...' == Line 2232 has weird spacing: '...eturned displ...' == Line 2234 has weird spacing: '...mailbox man...' == Line 2237 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 (March 12, 1998) is 9504 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 245, but not defined == Unused Reference: '8BIT' is defined on line 1473, but no explicit reference was found in the text == Unused Reference: 'AMIS-A' is defined on line 1483, but no explicit reference was found in the text == Unused Reference: 'AMIS-D' is defined on line 1486, but no explicit reference was found in the text == Unused Reference: 'DNS1' is defined on line 1503, but no explicit reference was found in the text == Unused Reference: 'DNS2' is defined on line 1506, but no explicit reference was found in the text == Unused Reference: 'E164' is defined on line 1519, but no explicit reference was found in the text == Unused Reference: 'G726' is defined on line 1528, but no explicit reference was found in the text == Unused Reference: 'MIME3' is defined on line 1553, but no explicit reference was found in the text == Unused Reference: 'MIME5' is defined on line 1561, 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. 'MIMEDIR' ** 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: 24 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 March 12, 1998 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 (1998). 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 F. 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. SECURITY CONSIDERATIONS ...........................................31 80 10.1 General Directive ..............................................31 81 10.2 Threats and Problems ...........................................31 82 10.3 Security Techniques ............................................32 83 11. REFERENCES ........................................................33 84 12. ACKNOWLEDGMENTS ...................................................35 85 13. COPYRIGHT NOTICE ..................................................35 86 14. AUTHORS' ADDRESSES ................................................36 87 15. APPENDIX A - VPIM REQUIREMENTS SUMMARY ............................37 88 16. APPENDIX B - EXAMPLE VOICE MESSAGES ...............................43 89 17. APPENDIX C - EXAMPLE ERROR VOICE PROCESSING ERROR CODES ...........48 90 18. APPENDIX D - EXAMPLE VOICE PROCESSING DISPOSITION TYPES ...........49 91 19. APPENDIX E - IANA REGISTRATIONS ...................................50 92 20. APPENDIX F - CHANGE HISTORY: RFC 1911 TO THIS DOCUMENT ............52 93 1. Abstract 95 A class of special-purpose computers has evolved to provide voice 96 messaging services. These machines generally interface to a telephone 97 switch and provide call answering and voice messaging services. 98 Traditionally, messages sent to a non-local machine are transported 99 using analog networking protocols based on DTMF signaling and analog 100 voice playback. As the demand for networking increases, there is a 101 need for a standard high-quality digital protocol to connect these 102 machines. The following document is a profile of the Internet 103 standard MIME and ESMTP protocols for use as a digital voice messaging 104 networking protocol. The profile is referred to as VPIM (Voice Profile 105 for Internet Mail) in this document. 107 This profile is based on earlier work in the Audio Message Interchange 108 Specification (AMIS) group that defined a voice messaging protocol 109 based on X.400 technology. This profile is intended to satisfy the 110 user requirements statement from that earlier work with the industry 111 standard ESMTP/MIME mail protocol infrastructures already used within 112 corporate intranets. This second version of VPIM is based on 113 implementation experience and obsoletes RFC 1911 which describes 114 version 1 of the profile. 116 2. Scope 118 MIME is the Internet multipurpose, multimedia messaging standard. 119 This document explicitly recognizes its capabilities and provides a 120 mechanism for the exchange of various messaging technologies, 121 primarily voice and facsimile. 123 This document specifies a restricted profile of the Internet 124 multimedia messaging protocols for use between voice processing server 125 platforms. These platforms have historically been special-purpose 126 computers and often do not have the same facilities normally 127 associated with a traditional Internet Email-capable computer. As a 128 result, VPIM also specifies additional functionality as it is needed. 129 This profile is intended to specify the minimum common set of features 130 to allow interworking between compliant systems. 132 2.1 Voice Messaging System Limitations 134 The following are typical limitations of voice messaging platform 135 which were considered in creating this baseline profile. 137 1) Text messages are not normally received and often cannot be 138 easily displayed or viewed. They can often be processed only via 139 text-to-speech or text-to-fax features not currently present in 140 many of these machines. 142 2) Voice mail machines usually act as an integrated Message 143 Transfer Agent, Message Store and User Agent. There is no relaying 144 of messages, and RFC 822 header fields may have limited use in the 145 context of the limited messaging features currently deployed. 147 3) Voice mail message stores are generally not capable of 148 preserving the full semantics of an Internet message. As such, use 149 of a voice mail machine for gatewaying is not supported. In 150 particular, storage of recipient lists, "Received" lines, and 151 "Message-ID" may be limited. 153 4) Internet-style distribution/exploder mailing lists are not 154 typically supported. Voice mail machines often implement only 155 local alias lists, with error-to-sender and reply-to-sender 156 behavior. Reply-all capabilities using a CC list is not generally 157 available. 159 5) Error reports must be machine-parsable so that helpful responses 160 can be voiced to users whose only access mechanism is a telephone. 162 6) The voice mail systems generally limit address entry to 16 or 163 fewer numeric characters, and normally do not support alphanumeric 164 mailbox names. Alpha characters are not generally used for mailbox 165 identification as they cannot be easily entered from a telephone 166 terminal. 168 2.2 Design Goals 170 It is a goal of this profile to make as few restrictions and additions 171 to the existing Internet mail protocols as possible while satisfying 172 the requirements for interoperability with current generation voice 173 messaging systems. This goal is motivated by the desire to increase 174 the accessibility to digital messaging by enabling the use of proven 175 existing networking software for rapid development. 177 This specification is intended for use on a TCP/IP network, however, 178 it is possible to use the SMTP protocol suite over other transport 179 protocols. The necessary protocol parameters for such use is outside 180 the scope of this document. 182 This profile is intended to be robust enough to be used in an 183 environment, such as the global Internet with installed-base gateways 184 which do not understand MIME, though typical use is expected to be 185 within corporate intranets. Full functionality, such as reliable 186 error messages and binary transport, will require careful selection of 187 gateways (e.g., via MX records) to be used as VPIM forwarding agents. 188 Nothing in this document precludes use of a general purpose MIME email 189 packages to read and compose VPIM messages. While no special 190 configuration is required to receive VPIM compliant messages, some may 191 be required to originate compliant structures. 193 It is expected that a VPIM messaging system will be managed by a 194 system administrator who can perform TCP/IP network configuration. 195 When using facsimile or multiple voice encodings, it is suggested that 196 the system administrator maintain a list of the capabilities of the 197 networked mail machines to reduce the sending of undeliverable 198 messages due to lack of feature support. Configuration, 199 implementation and management of this directory listing capabilities 200 is a local matter. 202 3. Protocol Restrictions 204 This protocol does not limit the number of recipients per message. 205 Where possible, implementations should not restrict the number of 206 recipients in a single message. It is recognized that no 207 implementation supports unlimited recipients, and that the number of 208 supported recipients may be quite low. However, ESMTP currently does 209 not provide a mechanism for indicating the number of supported 210 recipients. 212 This protocol does not limit the maximum message length. Implementors 213 should understand that some machines will be unable to accept 214 excessively long messages. A mechanism is defined in the RFC 1425 215 SMTP service extensions to declare the maximum message size supported. 217 The message size indicated in the ESMTP SIZE command is in bytes, not 218 minutes or seconds. The number of bytes varies by voice encoding 219 format and must include the MIME wrapper overhead. If the length must 220 be known before sending, an approximate translation into minutes or 221 seconds can be performed if the voice encoding is known. 223 The following sections describe the restrictions and additions to 224 Internet mail protocols that are required to be compliant with this 225 VPIM v2 profile. Though various SMTP, ESMTP and MIME features are 226 described here, the implementor is referred to the relevant RFCs for 227 complete details. It is also advisable to check for IETF drafts of 228 various Internet Mail specifications that are later than the most 229 recent RFCs since, for example, MIME has yet to be published as a full 230 IETF Standard. The table in Appendix A summarizes the protocol details 231 of this profile. 233 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 234 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 235 document are to be interpreted as described in [REQ]. 237 4. Voice Message Interchange Format 239 The voice message interchange format is a profile of the Internet Mail 240 Protocol Suite. Any Internet Mail message containing the format 241 defined in this section is referred to as a VPIM Message in this 242 document. As a result, this document assumes an understanding of the 243 Internet Mail specifications. Specifically, VPIM references 244 components from the message format standard for Internet messages 245 [RFC822], the Multipurpose Internet Message Extensions [MIME], the 246 X.400 gateway specification [X.400], delivery status and message 247 disposition notifications [REPORT][DSN][DRPT][STATUS][MDN], and the 248 electronic business card [MIMEDIR][VCARD]. 250 4.1 Message Addressing Formats 252 RFC 822 addresses are based on the domain name system. This naming 253 system has two components: the local part, used for username or 254 mailbox identification; and the host part, used for global machine 255 identification. 257 4.1.1 VPIM Addresses 259 The local part of the address shall be a US-ASCII string uniquely 260 identifying a mailbox on a destination system. For voice messaging, 261 the local part is a printable string containing the mailbox ID of the 262 originator or recipient. While alpha characters and long mailbox 263 identifiers are permitted, most voice mail networks rely on numeric 264 mailbox identifiers to retain compatibility with the limited 10 digit 265 telephone keypad. As a result, some voice messaging systems may only 266 be able to handle a numeric local part. The reception of alphanumeric 267 local parts on these systems may result in the address being mapped to 268 some locally unique (but confusing to the recipient) number or, in the 269 worst case the address could be deleted making the message un- 270 replyable. Additionally, it may be difficult to create messages on 271 these systems with an alphanumeric local part without complex key 272 sequences or some form of directory lookup (see 6). 274 The use of the domain naming system should be transparent to the user. 275 It is the responsibility of the voice mail machine to lookup the 276 fully-qualified domain name (FQDN) based on the address entered by the 277 user (see 6). 279 In the absence of a global directory, specification of the local part 280 is expected to conform to international or private telephone numbering 281 plans. It is likely that private numbering plans will prevail and 282 these are left for local definition. However, it is recommended that 283 public telephone numbers be noted according to the international 284 numbering plan described in [E.164]. The indication that the local 285 part is a public telephone number is given by a preceding `+' (the `+' 286 would not be entered from a telephone keypad, it is added by the 287 system as a flag). Since the primary information in the numeric 288 scheme is contained by the digits, other character separators (e.g. `- 289 ') may be ignored (i.e. to allow parsing of the numeric local mailbox) 290 or may be used to recognize distinct portions of the telephone number 291 (e.g. country code). The specification of the local part of a VPIM 292 address can be split into the four groups described below: 294 1) mailbox number 295 - for use as a private numbering plan (any number of digits) 296 - e.g. 2722@lucent.com 298 2) mailbox number+extension 299 - for use as a private numbering plan with extensions 300 any number of digits, use of `+' as separator 301 - e.g. 2722+111@Lucent.com 303 3) +international number 304 - for international telephone numbers conforming to E.164 305 maximum of 15 digits 306 - e.g. +16137637582@vm.nortel.ca 308 4) +international number+extension 309 - for international telephone numbers conforming to E.164 310 maximum of 15 digits, with an extension (e.g. behind a 311 PBX) that has a maximum of 15 digits. 312 - e.g. +17035245550+230@ema.org 314 4.1.2 Special Addresses 316 Special addresses are provided for compatibility with the conventions 317 of Internet mail. These addresses do not use numeric local addresses, 318 both to conform to current Internet practice and to avoid conflict 319 with existing numeric addressing plans. Two special addresses are 320 RESERVED for use as follows: 322 postmaster@domain 324 By convention, a special mailbox named "postmaster" MUST exist on all 325 systems. This address is used for diagnostics and should be checked 326 regularly by the system manager. This mailbox is particularly likely 327 to receive text messages, which is not normal on a voice processing 328 platform. The specific handling of these messages is an individual 329 implementation choice. 331 non-mail-user@domain 333 If a reply to a message is not possible, such as a telephone answering 334 message, then the special address _non-mail-user_ must be used as the 335 originator's address. Any text name such as "Telephone Answering," or 336 the telephone number if it is available, is permitted. This special 337 address is used as a token to indicate an unreachable originator. For 338 compatibility with the installed base of mail user agents, 339 implementations that generate this special address MUST send a non- 340 delivery notification for reply messages sent to the undeliverable 341 address. The status code for such NDN's is 5.1.1 "Mailbox does not 342 exist". 344 Example: 346 From: Telephone Answering 348 4.1.3 Distribution Lists 350 There are many ways to handle distribution list (DL) expansions and 351 none are 'standard'. Simple alias is a behavior closest to what most 352 voice mail systems do today and what is to be used with VPIM messages. 353 That is: 355 Reply to the originator - (Address in the RFC822 Reply-to or From 356 field) 357 Errors to the submitter - (Address in the MAIL FROM: field of the 358 ESMTP exchange and the Return-Path: 359 RFC 822 field) 361 Some proprietary voice messaging protocols include only the recipient 362 of the particular copy in the envelope and include no "headers" except 363 date and per-message features. Most voice messaging systems do not 364 provide for "Header Information" in their messaging queues and only 365 include delivery information. As a result, recipient information MAY 366 be in either the To or CC headers. If all recipients cannot be 367 presented (e.g. unknown DL expansion) then the recipient headers MUST 368 be omitted to indicate that an accurate list of recipients (e.g. for 369 use with a reply-all capability) is not known. 371 4.2 Message Header Fields 373 Internet messages contain a header information block. This header 374 block contains information required to identify the sender, the list 375 of recipients, the message send time, and other information intended 376 for user presentation. Except for specialized gateway and mailing 377 list cases, headers do not indicate delivery options for the transport 378 of messages. 380 Exploder lists are noted for modifying or adding to the headers of 381 messages that pass through them. VPIM systems MUST be able to accept 382 and ignore headers that are not defined here. 384 The following header lines are permitted for use with VPIM voice 385 messages: 387 4.2.1 From 389 The originator's fully-qualified domain address (a mailbox address 390 followed by the fully-qualified domain name). The user listed in this 391 field should be presented in the voice message envelope as the 392 originator of the message. 394 Systems compliant with this profile SHOULD provide the text personal 395 name of the voice message originator in a quoted phrase, if the name 396 is available. Text names of corporate or positional mailboxes MAY be 397 provided as a simple string. From [RFC822] 399 Example: 401 From: "Joe S. User" <12145551212@mycompany.com> 403 From: Technical Support <611@serviceprovider.com> 405 The From address may be used for replies (see 4.6). However, if the 406 From address contains , the user SHOULD not be 407 offered the option to reply, nor should notifications be sent to this 408 address. 410 4.2.2 To 412 The To header contains the recipient's fully-qualified domain address. 413 There may be one or more To: fields in any message. 415 Example: 417 To: +12145551213@mycompany.com 419 Systems compliant to this profile SHOULD provide a list of recipients 420 only if all recipients are provided. The To header MUST NOT be 421 included in the message if the sending message transport agent (MTA) 422 cannot resolve all the addresses in it, e.g. if an address is a DL 423 alias for which the expansion is unknown (see 4.1.3). If present, the 424 addresses in the To header MAY be used for a reply message to all 425 recipients. 427 Systems compliant to this profile MAY also discard the To addresses of 428 incoming messages because of the inability to store the information. 429 This would, of course, make a reply-to-all capability impossible. 431 4.2.3 Cc 433 The cc header contains additional recipients' fully-qualified domain 434 addresses. Many voice mail systems maintain only sufficient envelope 435 information for message delivery and are not capable of storing or 436 providing a complete list of recipients. 438 Systems compliant to this profile SHOULD provide a list of recipients 439 only if all disclosed recipients can be provided. The list of 440 disclosed recipients does not include those sent via a blind copy. If 441 not, systems SHOULD omit the To and Cc headers to indicate that the 442 full list of recipients is unknown. 444 Example: 446 Cc: +12145551213@mycompany.com 448 Systems compliant to this profile MAY discard the Cc addresses of 449 incoming messages as necessary. If a list of Cc or to addresses is 450 present, these addresses MAY be used for a reply message to all 451 recipients. 453 4.2.4 Date 455 The Date header contains the date, time, and time zone in which the 456 message was sent by the originator. The time zone SHOULD be 457 represented in a four-digit time zone offset, such as -0500 for North 458 American Eastern Standard Time. This may be supplemented by a time 459 zone name in parentheses, e.g., "-0900 (PDT)". Compliant 460 implementations SHOULD be able to convert RFC 822 date and time stamps 461 into local time. 463 Example: 465 Date: Wed, 28 Jul 96 10:08:49 -0800 (PST) 467 The sending system MUST report the time the message was sent. If the 468 VPIM sender is relaying a message from a system which does not provide 469 a time stamp, the time of arrival at the VPIM system SHOULD be used as 470 the date. From [RFC822] 472 4.2.5 Sender 474 The Sender header contains the actual address of the originator if the 475 message is sent by an agent on behalf of the author indicated in the 476 From: field and MAY be present in a VPIM message. 478 While it may not be possible to save this information in some voice 479 mail machines, discarding this information or the ESMTP MAIL FROM (see 480 4.2.6) address will make it difficult to send an error message to the 481 proper destination. From [RFC822] 483 4.2.6 Return Path 485 The Return-path header is added by the final delivering SMTP server. 486 If present, it contains the address from the MAIL FROM parameter of 487 the ESMTP exchange (see 5.1.2) to which error messages MUST be sent to 488 this address (see [DRPT] for additional details). Note that if the 489 Return-path is null ("<>"), e.g. no path, loop prevention or 490 confidential, a notification MUST NOT be sent. If the Return path 491 address is not available (either from this header or the MAIL FROM 492 parameter) the Sender or From addresses may be used to deliver 493 notifications. 495 4.2.7 Message-id 497 The Message-id header contains a unique per-message identifier. A 498 unique message-id MUST be generated for each message sent from a 499 compliant implementation. 501 The message-id is not required to be stored on the receiving system. 502 This identifier MAY be used for tracking, auditing, and returning 503 read-receipt reports. From [RFC822] 505 Example: 507 Message-id: <12345678@mycompany.com> 509 4.2.8 Reply-To 511 If present, the reply-to header provides a preferred address to which 512 reply messages should be sent (see 4.6). Typically, voice mail 513 systems can only support one originator of a message so it is unlikely 514 that this field can be supported. A compliant system SHOULD NOT send 515 a Reply-To header. However, if a reply-to header is present, a reply- 516 to sender message SHOULD be sent to the address specified (that is, 517 overwriting From). From [RFC822] This preferred address of the 518 originator must also be provided in the originator's vCard EMAIL 519 attribute, if present (see 4.3.3). 521 4.2.9 Received 523 The Received header contains trace information added to the beginning 524 of a RFC 822 message by MTAs. This is the only header permitted to be 525 added by an MTA. Information in this header is useful for debugging 526 when using an US-ASCII message reader or a header parsing tool. 528 A compliant system MUST add Received headers when acting as a gateway 529 and MUST NOT remove any. These headers MAY be ignored or deleted when 530 the message is received at the final destination. From [RFC822] 532 4.2.10 MIME Version 534 The MIME-Version header indicates that the message conforms to the 535 MIME message format specification. Systems compliant with this 536 specification SHOULD include a comment with the words "(Voice 2.0)". 537 RFC 1911 defines an earlier version of this profile and uses the token 538 (Voice 1.0). From [MIME1][VPIM1] 540 Example: 542 MIME-Version: 1.0 (Voice 2.0) 544 This identifier is intended for information only and SHOULD NOT be 545 used to semantically identify the message as being a VPIM message. 546 Instead, the presence of the content defined in [V-MSG] SHOULD be used 547 if identification is necessary. 549 4.2.11 Content-Type 551 The content-type header declares the type of content enclosed in the 552 message. The typical top level content in a VPIM Message SHOULD be 553 multipart/voice-message, a mechanism for bundling several components 554 into a single identifiable voice message. The allowable contents are 555 detailed in section 4.3 of this document. From [MIME2] 557 4.2.12 Content-Transfer-Encoding 559 Because Internet mail was initially specified to carry only 7-bit US- 560 ASCII text, it may be necessary to encode voice and fax data into a 561 representation suitable for that environment. The content-transfer- 562 encoding header describes this transformation if it is needed. 563 Compliant implementations MUST recognize and decode the standard 564 encodings, "Binary", "7bit, "8bit", "Base64" and "Quoted-Printable". 565 The allowable content-transfer-encodings are specified in section 4.3. 566 From [MIME1] 568 4.2.13 Sensitivity 570 The sensitivity header, if present, indicates the requested privacy 571 level. The case-insensitive values "Personal" and "Private" are 572 specified. If no privacy is requested, this field is omitted. 574 If a sensitivity header is present in the message, a compliant system 575 MUST prohibit the recipient from forwarding this message to any other 576 user. A compliant system, however, SHOULD allow the user to reply to 577 a sensitive message, but SHOULD NOT include the original message 578 content. The sensitivity of the reply message MAY be set by the user. 580 If the receiving system does not support privacy and the sensitivity 581 is one of "Personal" or "Private", the message MUST be returned to the 582 sender with an appropriate error code indicating that privacy could 583 not be assured and that the message was not delivered. A non-delivery 584 notification to a private message need not be tagged private since it 585 will be sent to the originator. From: [X.400] 587 4.2.14 Importance 589 Indicates the requested priority to be given by the receiving system. 590 The case-insensitive values "low", "normal" and "high" are specified. 591 If no special importance is requested, this header may be omitted and 592 the value assumed to be "normal". 594 Compliant implementations MAY use this header to indicate the 595 importance of a message and may order messages in a recipient's 596 mailbox. From: [X.400] 598 4.2.15 Subject 600 The subject field is often provided by email systems but is not widely 601 supported on Voice Mail platforms. For compatibility with text based 602 mailbox interfaces, a text subject field SHOULD be generated by a 603 compliant implementation but MAY be discarded if present by a 604 receiving system. From [RFC822] 606 It is recommended that voice messaging systems that do not support any 607 text user interfaces (e.g. access only by a telephone) insert a 608 generic subject header of "VPIM Message" for the benefit of text 609 enabled recipients. 611 4.2.16 Disposition-Notification-To 613 This header MAY be present to indicate that the sender is requesting a 614 receipt notification from the receiving user agent. This message 615 disposition notification (MDN) is typically sent by the user agent 616 after the user has listened to the message and consented to an MDN 617 being sent 619 Example: 621 Disposition-notification-to: +12145551213@mycompany.com 623 The presence of a Disposition-notification-to header in a message is 624 merely a request for an MDN described in 4.4.5. The recipients' user 625 agents are always free to silently ignore such a request so this 626 header does not burden any system that does not support it. From 627 [MDN]. 629 4.2.17 Disposition-Notification-Options 631 This header MAY be present to define future extensions parameters for 632 an MDN requested by the presence of the header in the previous 633 section. Currently no parameters are defined by this document or by 634 [MDN]. However, this header MUST be parsed if present, if MDNs are 635 supported. If it contains a extension parameter that is required for 636 proper MDN generation (noted with "=required"), then an MDN MUST NOT 637 be sent if the parameter is not understood. See [MDN] for complete 638 details. 640 Example: 642 Disposition-notification-options: 643 whizzbang=required,foo 645 4.3 Voice Message Content Types 647 MIME, introduced in [MIME1], is a general-purpose message body format 648 that is extensible to carry a wide range of body parts. It provides 649 for encoding binary data so that it can be transported over the 7-bit 650 text-oriented SMTP protocol. This transport encoding is in addition 651 to the audio encoding required to generate a binary object. 653 MIME defines two transport encoding mechanisms to transform binary 654 data into a 7 bit representation, one designed for text-like data 655 ("Quoted-Printable"), and one for arbitrary binary data ("Base64"). 656 While Base64 is dramatically more efficient for audio data, both will 657 work. Where binary transport is available, no transport encoding is 658 needed, and the data can be labeled as "Binary". 660 An implementation in compliance with this profile SHOULD send audio 661 and/or facsimile data in binary form when binary message transport is 662 available. When binary transport is not available, implementations 663 MUST encode the audio and/or facsimile data as Base64. The detection 664 and decoding of "Quoted-Printable", "7bit", and "8bit" MUST be 665 supported in order to meet MIME requirements and to preserve 666 interoperability with the fullest range of possible devices. However, 667 if a content is received in a transfer encoding that cannot be 668 rendered to the user, an appropriate non-delivery notification MUST be 669 sent. 671 The content types described in this section are identified for use 672 within the multipart/voice-message content. This content, which is 673 the fundamental part of a VPIM message, is referred to as a VPIM voice 674 message in this document. 676 Only the contents profiled subsequently can be sent within a VPIM 677 voice message construct to form a simple or a more complex structure 678 (several examples are given in Appendix B). The presence of other 679 contents within a VPIM voice message is an error condition and SHOULD 680 result in a non-delivery notification. When multiple contents are 681 present within the multipart/voice-message, they SHOULD be presented 682 to the user in the order that they appear in the message. 684 4.3.1 Multipart/Voice-Message 686 This MIME multipart structure provides a mechanism for packaging a 687 voice message into one container that is tagged as VPIM v2 compliant. 688 The semantic of multipart/Voice-Message (defined in [V-MSG]) is 689 identical to multipart/mixed and may be interpreted as that by systems 690 that do not recognize this content-type. 692 The Multipart/Voice-Message content-type MUST only contain the 693 profiled media and content types specified in this section (i.e. 695 audio/*, image/*, message/rfc822 and text/directory). The most common 696 will be: spoken name, spoken subject, the message itself, attached fax 697 and directory info. Forwarded messages are created by simply using 698 the message/rfc822 construct. 700 Conformant implementations MUST send the Multipart/Voice-Message in a 701 VPIM message. In most cases, this Multipart/Voice-Message content 702 will be the top level (i.e. in the Content-Type header). Conformant 703 implementations MUST recognize the Multipart/Voice-Message content 704 (whether it is a top level content or below a mulitpart/mixed) and be 705 able to separate the contents (e.g. spoken name or spoken subject). 707 4.3.2 Message/RFC822 709 MIME requires support of the Message/RFC822 message encapsulation body 710 part. This body part is used within a multipart/voice-message to 711 forward complete messages (see 4.5) or to reply with original content 712 (see 4.6). From [MIME2] 714 4.3.3 Text/Directory 716 This content allows for the inclusion of a Versit vCard [VCARD] 717 electronic business card within a VPIM message. The format is 718 suitable as an interchange format between applications or systems, and 719 is defined independent of the method used to transport it. It 720 provides a useful mechanism to transport information about the 721 originator that can be used by the receiving VPIM system (see 6) or 722 other local applications 724 Each vCard MUST be contained within a Text/Directory content type 725 [MIMEDIR] within a VPIM message. [MIMEDIR] requires that the 726 character set MUST be defined as a parameter value (typically us-ascii 727 for VPIM) and that the profile SHOULD be defined (the value MUST be 728 vCard within VPIM messages). 730 Each VPIM message SHOULD be created with a Text/Directory (vCard 731 profile) content type that MUST contain the preferred email address, 732 telephone number, and text name of the message originator as well as 733 the vCard version. The vCard SHOULD contain the spoken name and role 734 of the originator, as well as the revision date. Any other vCard 735 attribute MAY also be present. The intent is that the vCard be used 736 as the source of information to contact the originator (e.g., reply, 737 call).If the text/directory content-type is included in a VPIM 738 message, the vCard profile [VCARD] MUST be used and MUST specify at 739 least the following attributes: 741 TEL - Public switched telephone number in international (E.164) 742 format (various types, typically VOICE) 743 EMAIL - email address (various types, typically INTERNET; the 744 typeVPIM is optionally used to denote the address that 745 supports VPIM messages(see 19.1)) 746 VERSION - Indicates the version of the vCard profile. Version 3.0 747 [VCARD] MUST be used. 749 The following attributes SHOULD be specified: 751 N - Family Name, Given Name, Additional Names, Honorific 752 Prefixes, and Suffixes (all present components in the 753 From text name MUST match) 754 ROLE - the role of the person identified in `N', but may be used 755 as an alternative to the `N' attribute when the sender is a 756 corporate or positional mailbox 757 SOUND - spoken name sound data (various types, typically 32KADPCM) 758 REV - Revision of vCard in ISO 8601 date format 760 The vCard MAY use other attributes as defined in [VCARD] or extensions 761 attributes not yet defined (e.g. capabilities). 763 If present, the spoken name attribute MUST be denoted by a content ID 764 pointing to an audio/* content elsewhere in the VPIM message. 766 A typical VPIM message (i.e. no forwarded parts), MUST only contain 767 one vCard -- more than one is an error condition. A VPIM message that 768 contains forwarded messages, though, may contain multiple vCards. 769 However, these vCards MUST be associated with the originator(s) of the 770 forwarded message(s) and the originator of the forwarding message. As 771 a result, all forwarded vCards will be contained in message/rfc822 772 contents -- only the vCard of forwarding originator will be at the 773 top-level. 775 Example: 777 Content-Type: text/directory; charset=us-ascii; profile=vCard 778 Content-Transfer-Encoding: 7bit 780 BEGIN:VCARD 781 N:Parsons;Glenn 782 ORG:Northern Telecom 783 TEL;TYPE=VOICE;MSG;WORK:+1-613-763-7582 784 EMAIL;TYPE=INTERNET:glenn.parsons@nortel.ca 785 EMAIL;TYPE=INTERNET;VPIM:6137637582@vm.nortel.ca 786 SOUND;TYPE=32KADPCM;ENCODING=URI: CID: 787 REV:19960831T103310Z 788 VERSION: 3.0 789 END:VCARD 791 4.3.4 Audio/32KADPCM 793 An implementation compliant to this profile MUST use Audio/32KADPCM by 794 default for voice [ADPCM]. Typically this body contains several 795 minutes of message content, however if used for spoken name or subject 796 the content should be considerably shorter (i.e. about 10 and 20 797 seconds respectively). 799 If an implementation can only handle one voice body, then multiple 800 voice bodies (if present) SHOULD be concatenated, and SHOULD NOT be 801 discarded. It is recommended that this be done in the same order as 802 they were sent. Note that if an Originator Spoken Name audio body and 803 a vCard are both present in a VPIM message, the vCard SOUND attribute 804 MUST point to this audio body (see 4.3.3). 806 While any valid MIME body header MAY be used, several headers have the 807 following semantics when included with this body part: 809 4.3.4.1 Content-Description: 811 This field MAY be present to facilitate the text identification of 812 these body parts in simple email readers. Any values may be used, 813 though it may be useful to use values similar to those for Content- 814 Disposition. 816 Example: 818 Content-Description: Big Telco Voice Message 820 4.3.4.2 Content-Disposition: 822 This field MUST be present to allow the parsable identification of 823 these body parts. This is especially useful if, as is typical, 824 more than one Audio/32KADPCM body occurs within a single level 825 (e.g. multipart/voice-message). Since a VPIM voice message is 826 intended to be automatically played upon display of the message, in 827 the order in which the audio contents occur, the audio contents 828 must always be of type inline. However, it is still useful to 829 include a filename value, so this should be present if this 830 information is available. From [DISP] 832 In order to distinguish between the various types of audio contents 833 in a VPIM voice message a new disposition parameter "voice" is 834 defined with the parameter values below to be used as appropriate 835 (see 19.2): 837 Voice-Message - the primary voice message, 838 Voice-Message-Notification - a spoken delivery notification 839 or spoken disposition notification, 840 Originator-Spoken-Name - the spoken name of the originator, 841 Recipient-Spoken-Name - the spoken name of the recipient if 842 available to the originator and present if there is ONLY one 843 recipient, 844 Spoken-Subject- the spoken subject of the message, typically 845 spoken by the originator 847 Note that there SHOULD only be one instance of each of these types 848 of audio contents per message level. Additional instances of a 849 given type (i.e., parameter value) may occur within an attached 850 forwarded voice message. 852 Implementations that do not understand the "voice" parameter (or 853 the Content-Disposition header) can safely ignore it, and will 854 present the audio bodyparts in order (but will not be able to 855 distinguish between them). 857 Example: 859 Content-Disposition: inline; voice=spoken-subject; 860 filename=msg001.726 862 4.3.4.3 Content-Duration: 864 This field MAY be present to allow the specification of the length 865 of the audio bodypart in seconds. The use of this field on 866 reception is a local implementation issue. From [DUR] 868 Example: 870 Content-Duration: 33 872 4.3.4.4 Content-Language: 874 This field MAY be present to allow the specification of the spoken 875 language of the audio bodypart. The encoding is defined in [LANG]. 876 The use of this field on reception is a local implementation issue. 878 Example for UK English: 880 Content-Language: EN-UK 882 4.3.5 Image/Tiff 884 A common image encoding for facsimile, known as TIFF-F, is a 885 derivative of the Tag Image File Format (TIFF) and is described in 886 several documents. For the purposes of VPIM, the F Profile of TIFF 887 for Facsimile (TIFF-F) is defined in [TIFF-F] and the image/tiff MIME 888 content type is defined in [TIFFREG]. While there are several formats 889 of TIFF, only TIFF-F is profiled for use in a VPIM voice message. 890 Further, since the TIFF-F file format is used in a store-and-forward 891 mode with VPIM, the image MUST be encoded so that there is only one 892 image strip per facsimile page. 894 All VPIM implementations that support facsimile MUST generate and read 895 TIFF-F compatible facsimile contents in the image/tiff; 896 application=faxbw sub-type encoding by default. An implementation MAY 897 send this fax content in VPIM voice messages and MUST be able to 898 recognize it in received messages. If a fax message is received that 899 cannot be rendered to the user (e.g. the receiving VPIM system does 900 not support fax), then the system MUST non-deliver the entire message 901 with a media not supported error. 903 While any valid MIME body header MAY be used (e.g., Content-Dispostion 904 to indicate the filename), none are specified to have special 905 semantics for VPIM and MAY be ignored. Note that the content type 906 paramater application=faxbw MUST be included in outbound messages. 907 However, inbound messages with or without this parameter MUST be 908 rendered to the user (if the rendering software encounters an error in 909 the file format, some form of non-delivery notification MUST be sent 910 to the originator). 912 4.3.6 Proprietary Voice or Fax Formats 914 Proprietary voice or fax encoding formats or other standard formats 915 may be supported under this profile provided a unique identifier is 916 registered with the IANA prior to use (see [MIME4]). The voice 917 encodings should be registered as sub-types of Audio and the fax 918 encodings should be registered as sub-types of Image 920 Use of any other encoding except audio/32kadpcm or image/tiff; 921 application=faxbw reduces interoperability in the absence of explicit 922 manual system configuration. A compliant implementation MAY use any 923 other encoding with explicit per-destination configuration. 925 4.4 Other Message Content Types 927 An implementation compliant with this profile MAY send additional 928 contents in a VPIM message, but ONLY outside of the multipart/voice- 929 message. The content types described in this section are identified 930 for use with this profile. Contents not defined here MUST NOT be used 931 without prior explicit per-destination configuration. If an 932 implementation receives a VPIM message that contains content types 933 not specified in this profile, their handling is a local 934 implementation issue (e.g. the unknown contents MAY be discarded if 935 they cannot be presented to the recipient). Conversely, if an 936 implementation receives a non-VPIM message with any of the contents 937 defined in 4.3 & 4.4, it SHOULD deliver those contents, but the full 938 message handling is a local issue (e.g. the unknown contents _or_ the 939 entire message MAY be discarded). It is recommended that 940 implementations issue delivery notifications to the originator when 941 any form of non-delivery to the recipient occurs. 943 The multipart contents defined below may be sent as the top level of a 944 VPIM message (with other noted contents below them as required.) As 945 well, the multipart/mixed content can be used to form a more complex 946 structure (several examples are given in Appendix B). When multiple 947 contents are present, they SHOULD be presented to the user in the 948 order that they appear in the message. 950 4.4.1 Multipart/Mixed 952 MIME provides the facilities for enclosing several body parts in a 953 single message. Multipart/Mixed SHOULD only be used for sending 954 complex voice or multimedia messages. That is, as the top level 955 Content-Type when sending one of the following contents (in addition 956 to the VPIM voice message) in a VPIM message. Compliant systems MUST 957 accept multipart/mixed body parts. From [MIME2] 959 4.4.2 Text/Plain 961 MIME requires support of the basic Text/Plain content type. This 962 content type has limited applicability within the voice messaging 963 environment. Compliant implementations SHOULD NOT send the Text/Plain 964 content-type, but SHOULD only send this content if the recipient 965 system is known to support it. Compliant implementations MUST accept 966 Text/Plain messages, however, specific handling is left as an 967 implementation decision. From [MIME2] 969 There are several mechanisms that can be used to support text on voice 970 messaging systems including text-to-speech and text-to-fax 971 conversions. If no rendering of the text is possible (i.e. it is not 972 possible for the recipient to determine if the text is a critical part 973 of the message), the entire message MUST be non-delivered and returned 974 to the sender with a media-unsupported error code. 976 4.4.3 Multipart/Report 978 The Multipart/Report is used for enclosing human-readable and machine 979 parsable notification (e.g. Message/delivery-status) body parts and 980 any returned message content. Compliant implementations MUST use the 981 Multipart/Report construct when returning messages, sending warnings, 982 or issuing read receipts. Compliant implementations MUST recognize 983 and decode the Multipart/Report content type and its components in 984 order to present the report to the user. From [REPORT] 986 Multipart/Report messages from VPIM implementations SHOULD include the 987 human-readable description of the error as a spoken audio/* content 988 (this speech SHOULD also be made available to the notification 989 recipient). As well, VPIM implementations MUST be able to handle (and 990 MAY generate) Multipart/Report messages that encode the human-readable 991 description of the error as text. Note that per [DSN] the human- 992 readable part MUST always be present. 994 4.4.4 Message/Delivery-status 996 This MIME body part is used for sending machine-parsable delivery 997 status notifications. Compliant implementations must use the 998 Message/delivery-status construct when returning messages or sending 999 warnings. Compliant implementations must recognize and decode the 1000 Message/delivery-status content type and present the reason for 1001 failure to the user. From [DSN] 1003 4.4.5 Message/Disposition-notification 1005 This MIME body part is used for sending machine-parsable read-receipt 1006 message disposition notifications. Conforming implementations should 1007 use the Message/Disposition-notification construct when sending post- 1008 delivery message status notifications. These MDNs, however, MUST only 1009 be sent in response to the presence of the Disposition-notification-to 1010 header in 4.2.16. Conforming implementations should recognize and 1011 decode the Message/Disposition-notification content type and present 1012 the notification to the user. From [MDN] 1014 4.5 Forwarded Messages 1016 VPIM version 2 explicitly supports the forwarding of voice and fax 1017 content with voice or fax annotation. However, only the two 1018 constructs described below are acceptable in a VPIM message. Since 1019 only the first (i.e. message/rfc822) can be recognized as a forwarded 1020 message (or even multiple forwarded messages), it is recommended that 1021 this construct be used whenever possible. 1023 Forwarded VPIM messages SHOULD be sent as a multipart/voice-message 1024 with the entire original message enclosed in a message/rfc822 content 1025 type and the annotation as a separate Audio/* or image/* body part. 1026 If the RFC822 headers are not available for the forwarded content, 1027 simulated headers with available information SHOULD be constructed to 1028 indicate the original sending timestamp, and the original sender as 1029 indicated in the "From" line. However, note that at least one of 1030 "From", "Subject", or "Date" MUST be present. As well, the 1031 message/rfc822 content MUST include at least the "MIME-Version", 1032 "Content-Type" headers, and MAY include the "Content-Transfer- 1033 Encoding" header. From [MIME2] 1035 In the event that forwarding information is lost through concatenation 1036 of the original message and the forwarding annotation, such as must be 1037 done in a gateway between VPIM and the AMIS voice messaging protocol, 1038 the entire content MAY be sent as a single Audio/* segment without 1039 including any forwarding semantics. 1041 4.6 Reply Messages 1043 Replies to VPIM messages (and Internet mail messages) are addressed to 1044 the address noted in the reply-to header (see 4.2.8) if it is present, 1045 else the From address (see 4.2.1) is used. The vCard EMAIL attribute, 1046 if present, SHOULD be the same as the reply-to address and may be the 1047 same as the From address. While the vCard is the senders preferred 1048 address it SHOULD NOT be used to generate a reply. Also, the Return- 1049 path address should not be used for replies. 1051 Support of multiple originator headers is often not possible on voice 1052 messaging systems, so it may be necessary to choose only one. 1053 However, implementors should note that this may make it impossible to 1054 send error messages and replies to the proper destination. 1056 In some cases, a reply message is not possible, such as with a message 1057 created by telephone answering (i.e. classic voice mail). In this 1058 case, the From field MUST contain the special address non-mail- 1059 user@domain (see 4.1.2). The use of a null ESMTP MAIL FROM address 1060 SHOULD also be used in this case (see 5.1.2). A receiving VPIM system 1061 SHOULD not offer the user the option to reply to this kind of message. 1063 4.7 Notification Messages 1065 VPIM Delivery Notification messages (4.4.4) must be sent to the 1066 originator of the message when any form of non-delivery of the subject 1067 message or its components occurs. These error messages must be sent 1068 to the return path (4.2.6) if present, else the sender (4.2.5) or From 1069 (4.2.1) address may be used (in that order). 1071 VPIM Receipt Notification messages (4.4.5) should be sent to the 1072 sender specified in the MDN header (4.2.16), only if the header is 1073 present, and typically after the user has initiated the notification 1074 by some action (like listening to the message). 1076 VPIM Notification messages may be positive or negative, and can 1077 indicate delivery at the server or receipt by the client. However, 1078 the notification MUST be contained in a multipart/report container 1079 (4.4.3) and SHOULD contain a spoken error message. It is recommended 1080 that systems that do not support the notification format SHOULD still 1081 send some form of error message when non-delivery occurs. 1083 If a VPIM system receives a message with contents that are not 1084 understood (see 4.3 & 4.4), its handling is a local matter, though any 1085 VPIM voice message content SHOULD be delivered. A delivery status 1086 notification SHOULD be generated if the message could not be delivered 1087 because of unknown contents (e.g., on traditional voice processing 1088 systems). In some cases, the message may be delivered (with a 1089 positive DSN sent) to a mailbox before the determination of rendering 1090 can be made. In this case, however, an MDN can only be sent to 1091 indicate that the message could not be rendered if it was requested. 1093 5. Message Transport Protocol 1095 Messages are transported between voice mail machines using the 1096 Internet Extended Simple Mail Transfer Protocol (ESMTP). All 1097 information required for proper delivery of the message is included in 1098 the ESMTP dialog. This information, including the sender and 1099 recipient addresses, is commonly referred to as the message 1100 "envelope". This information is equivalent to the message control 1101 block in many analog voice networking protocols. 1103 ESMTP is a general-purpose messaging protocol, designed both to send 1104 mail and to allow terminal console messaging. Simple Mail Transport 1105 Protocol (SMTP) was originally created for the exchange of US-ASCII 7- 1106 bit text messages. Binary and 8-bit text messages have traditionally 1107 been transported by encoding the messages into a 7-bit text-like form. 1108 [ESMTP] formalized an extension mechanism for SMTP, and subsequent 1109 RFCs have defined 8-bit text networking, command streaming, binary 1110 networking, and extensions to permit the declaration of message size 1111 for the efficient transmission of large messages such as multi-minute 1112 voice mail. 1114 The following sections list ESMTP commands, keywords, and parameters 1115 that are required and those that are optional for conformance to this 1116 profile. 1118 5.1 ESMTP Commands 1120 5.1.1 HELO 1122 Base SMTP greeting and identification of sender. This command is not 1123 to be sent by compliant systems unless the more-capable EHLO command 1124 is not accepted. It is included for compatibility with general SMTP 1125 implementations. Compliant implementations MUST implement the HELO 1126 command for backward compatibility but SHOULD NOT send it unless EHLO 1127 is not supported. From [SMTP] 1129 5.1.2 MAIL FROM (REQUIRED) 1131 Originating mailbox. This address contains the mailbox to which 1132 errors should be sent. This address may not be the same as the 1133 message sender listed in the message header fields if the message was 1134 received from a gateway or sent to an Internet-style mailing list. 1135 Compliant implementations MUST implement the extended MAIL FROM 1136 command. From [SMTP, ESMTP] 1138 The MAIL FROM address MAY be passed as a local system parameter or 1139 placed in a Return-Path: line inserted at the beginning of a VPIM 1140 message. From [HOSTREQ] 1142 Since error messages MUST be sent to the MAIL FROM address, the use of 1143 the null address ("<>") is often used to prevent looping of error 1144 notifications. This null address MAY also be used to note that a 1145 particular message has no return path (e.g. a telephone answer 1146 message). From [SMTP] 1148 5.1.3 RCPT TO 1150 Recipient's mailbox. This field contains only the addresses to which 1151 the message should be delivered for this transaction. In the event 1152 that multiple transport connections to multiple destination machines 1153 are required for the same message, this list may not match the list of 1154 recipients in the message header. Compliant implementations MUST 1155 implement the extended RCPT TO command. From [SMTP, ESMTP] 1157 5.1.4 DATA 1159 Initiates the transfer of message data. Support for this command is 1160 required in the event the binary mode command BDAT is not supported by 1161 the remote system. Compliant implementations MUST implement the SMTP 1162 DATA command for backwards compatibility. From [SMTP] 1164 5.1.5 TURN 1166 Requests a change-of-roles, that is, the client that opened the 1167 connection offers to assume the role of server for any mail the remote 1168 machine may wish to send. Because SMTP is not an authenticated 1169 protocol, the TURN command presents an opportunity to improperly fetch 1170 mail queued for another destination. Compliant implementations SHOULD 1171 NOT implement the TURN command. From [SMTP] 1173 5.1.6 QUIT 1175 Requests that the connection be closed. If accepted, the remote 1176 machine will reset and close the connection. Compliant 1177 implementations MUST implement the QUIT command. From [SMTP] 1179 5.1.7 RSET 1181 Resets the connection to its initial state. Compliant implementations 1182 MUST implement the RSET command. From [SMTP] 1184 5.1.8 VRFY 1186 Requests verification that this node can reach the listed recipient. 1187 While this functionality is also included in the RCPT TO command, VRFY 1188 allows the query without beginning a mail transfer transaction. This 1189 command is useful for debugging and tracing problems. Compliant 1190 implementations MAY implement the VRFY command. From [SMTP] 1192 (Note that the implementation of VRFY may simplify the guessing of a 1193 recipient's mailbox or automated sweeps for valid mailbox addresses, 1194 resulting in a possible reduction in privacy. Various implementation 1195 techniques may be used to reduce the threat, such as limiting the 1196 number of queries per session.) From [SMTP] 1198 5.1.9 EHLO 1200 The enhanced mail greeting that enables a server to announce support 1201 for extended messaging options. The extended messaging modes are 1202 discussed in subsequent sections of this document. Compliant 1203 implementations MUST implement the ESMTP command and return the 1204 capabilities indicated later in this memo. From [ESMTP] 1206 5.1.10 BDAT 1208 The BDAT command provides a higher efficiency alternative to the 1209 earlier DATA command, especially for voice. The BDAT command provides 1210 for native binary transport of messages. Compliant implementations 1211 SHOULD support binary transport using the BDAT command.[BINARY] 1213 5.2 ESMTP Keywords 1215 The following ESMTP keywords indicate extended features useful for 1216 voice messaging. 1218 5.2.1 PIPELINING 1220 The "PIPELINING" keyword indicates ability of the receiving server to 1221 accept new commands before issuing a response to the previous command. 1222 Pipelining commands dramatically improves performance by reducing the 1223 number of round-trip packet exchanges and makes it possible to 1224 validate all recipient addresses in one operation. Compliant 1225 implementations SHOULD support the command pipelining indicated by 1226 this parameter. From [PIPE] 1228 5.2.2 SIZE 1230 The "SIZE" keyword provides a mechanism by which the SMTP server can 1231 indicate the maximum size message supported. Compliant 1232 implementations MUST provide the size capability and SHOULD honor any 1233 size limitations when sending. From [SIZE] 1235 5.2.3 CHUNKING 1237 The "CHUNKING" keyword indicates that the receiver will support the 1238 high-performance binary transport mode. Note that CHUNKING can be 1239 used with any message format and does not imply support for binary 1240 encoded messages. Compliant implementations SHOULD support binary 1241 transport indicated by this capability. From [BINARY] 1243 5.2.4 BINARYMIME 1245 The "BINARYMIME" keyword indicates that the SMTP server can accept 1246 binary encoded MIME messages. Compliant implementations SHOULD support 1247 binary transport indicated by this capability. Note that support for 1248 this feature requires support of CHUNKING. From [BINARY] 1250 5.2.5 DSN 1252 The "DSN" keyword indicates that the SMTP server will accept explicit 1253 delivery status notification requests. Compliant implementations MUST 1254 support the delivery notification extensions in [DRPT]. 1256 5.2.6 ENHANCEDSTATUSCODES 1258 The "ENHANCEDSTATUSCODES" keyword indicates that an SMTP server 1259 augments its responses with the enhanced mail system status codes 1260 [CODES]. These codes can then be used to provide more informative 1261 explanations of error conditions, especially in the context of the 1262 delivery status notifications format defined in [DSN]. Compliant 1263 implementations SHOULD support this capability. From [STATUS] 1265 5.3 ESMTP Parameters - MAIL FROM 1267 5.3.1 BINARYMIME 1269 The current message is a binary encoded MIME messages. Compliant 1270 implementations SHOULD support binary transport indicated by this 1271 parameter. From [BINARY] 1273 5.3.2 RET 1275 The RET parameter indicates whether the content of the message should 1276 be returned. Compliant systems SHOULD honor a request for returned 1277 content. From [DRPT] 1279 5.3.3 ENVID 1281 The ENVID keyword of the SMTP MAIL command is used to specify an 1282 "envelope identifier" to be transmitted along with the message and 1283 included in any DSNs issued for any of the recipients named in this 1284 SMTP transaction. The purpose of the envelope identifier is to allow 1285 the sender of a message to identify the transaction for which the DSN 1286 was issued. Compliant implementations MAY use this parameter. From 1287 [DRPT] 1289 5.4 ESMTP Parameters - RCPT TO 1291 5.4.1 NOTIFY 1293 The NOTIFY parameter indicates the conditions under which a delivery 1294 report should be sent. Compliant implementations MUST honor this 1295 request. From [DRPT] 1297 5.4.2 ORCPT 1299 The ORCPT keyword of the RCPT command is used to specify an "original" 1300 recipient address that corresponds to the actual recipient to which 1301 the message is to be delivered. If the ORCPT esmtp-keyword is used, 1302 it MUST have an associated esmtp-value, which consists of the original 1303 recipient address, encoded according to the rules below. Compliant 1304 implementations MAY use this parameter. From [DRPT] 1306 5.5 ESMTP - SMTP Downgrading 1308 To ensure a consistent level of service across an intranet or the 1309 global Internet, it is essential that VPIM compliant ESMTP be 1310 supported at all hops between a VPIM originating system and the 1311 recipient system. Unfortunately, in the situation where a `downgrade' 1312 is unavoidable the expected result is not defined. A downgrade is 1313 defined as the loss of VPIM transport features at some hop due to the 1314 lack of support. For example, a relay hop may be forced (by the next 1315 hop) to forward a VPIM using SMTP instead of ESMTP, or using DATA 1316 instead of BDAT. It is recommended that the downgrading system should 1317 continue to attempt to deliver the message, but MUST send an 1318 appropriate delivery notification to the originator, e.g. the message 1319 left an ESMTP host and was sent (unreliably) via SMTP. 1321 6. Directory Address Resolution 1323 It is the responsibility of a VPIM system to lookup the fully- 1324 qualified domain name (FQDN) based on the address entered by the user 1325 (if the entered address is not already a FQDN). This would typically 1326 be an issue on systems that offered only a telephone user interface. 1327 The mapping of the dialed target number to a routable FQDN address 1328 allowing delivery to the destination system can be accomplished 1329 through implementation-specific means. 1331 To facilitate a local dial-by-name cache, an implementation may wish 1332 to populate local directories with the first and last names, as well 1333 as the address information extracted from received messages. It is 1334 mandated that only address information from vCard attachments to VPIM 1335 messages be used to populate such a directory when the vCard is 1336 available. Addresses or names parsed from the headers of VPIM messages 1337 SHOULD NOT be used to populate directories as it only provides partial 1338 data. Alternatively, bilateral agreements could be made to allow the 1339 bulk transfer of vCards between systems. 1341 7. IMAP 1343 The use of client/server desktop mailbox protocols like IMAP or POP to 1344 retrieve VPIM messages from a IMAP or POP message store is possible 1345 without any special modifications to this VPIM specification. Email 1346 clients (and web browsers) typically have a table for mapping from 1347 MIME type to displaying application. The audio/*, image/tiff and 1348 text/directory contents can be configured so that they invoke the 1349 correct player/recorder for rendering. In addition with IMAP clients, 1350 the first multipart/mixed content (if present) will not appear since 1351 it is a generic part. The user instead will be presented with a 1352 message that has (for example) audio and image contents. 1354 8. Management Protocols 1356 The Internet protocols provide a mechanism for the management of 1357 messaging systems, from the management of the physical network through 1358 the management of the message queues. SNMP should be supported on a 1359 compliant message machine. 1361 8.1 Network Management 1363 The digital interface to the VM and the TCP/IP protocols SHOULD be 1364 managed. MIB II SHOULD be implemented to provide basic statistics and 1365 reporting of TCP and IP protocol performance. [MIB II] 1367 9. Conformance Requirements 1369 VPIM is a messaging application which must be supported in several 1370 environments and be supported on differing devices. These 1371 environments include traditional voice processing systems, desktop 1372 voice messaging systems, store and forward relays, and protocol 1373 translation gateways. 1375 In order to accommodate all environments, this document defines two 1376 areas of conformance: transport and content. 1378 Transport conformant systems will pass VPIM messages in a store and 1379 forward manner with assured delivery notifications and without the 1380 loss of information. It is expected that most store and forward 1381 Internet mail based messaging systems will be VPIM transport 1382 compliant. 1384 Content conformant systems will generate and interpret VPIM messages. 1385 Conformance in the generation of VPIM messages indicates that the 1386 restrictions of this profile are honored. Only contents specified in 1387 this profile or extensions agreed to by bilateral agreement may be 1388 sent. Conformance in the interpretation of VPIM messages indicates 1389 that all VPIM content types and constructs can be received; that all 1390 mandatory VPIM content types can be decoded and presented to the 1391 recipient in an appropriate manner; and that any unrenderable contents 1392 result in the appropriate notification. 1394 A summary of the compliance requirements is contained in Appendix A. 1396 VPIM end systems are expected to be both transport and content 1397 conformant. They should generate conforming content, reliably send it 1398 to the next hop system, receive a message, decode the message and 1399 present it to the user. Voice messaging systems and protocol 1400 conversion gateways are considered end systems. 1402 Relay systems are expected to be transport compliant in order to 1403 receive and send conforming messages. However, they must also create 1404 VPIM conforming delivery status notifications in the event of delivery 1405 problems. 1407 Desktop Email clients that support VPIM and are expected to be content 1408 conformant. Desktop email clients use various protocols and API's for 1409 exchanging messages with the local message store and message transport 1410 system. While these clients may benefit from VPIM transport 1411 capabilities, specific client-server requirements are out-of-scope for 1412 this document. 1414 10. Security Considerations 1416 10.1 General Directive 1418 This document is a profile of existing Internet mail protocols. To 1419 maintain interoperability with Internet mail, any security to be 1420 provided should be part of the of the Internet security 1421 infrastructure, rather than a new mechanism or some other mechanism 1422 outside of the Internet infrastructure. 1424 10.2 Threats and Problems 1426 Both Internet mail and voice messaging have their own set of threats 1427 and countermeasures. As such, this specification does not create any 1428 security issues not already existing in the profiled Internet mail and 1429 voice mail protocols themselves. This section attends only to the set 1430 of additional threats which ensue from integrating the two services. 1432 10.2.1 Spoofed sender 1434 The actual sender of the voice message might not be the same as that 1435 specified in the Sender or From fields of the message content headers 1436 or the MAIL FROM address from the SMTP envelope. In a tightly 1437 constrained environment, sufficient physical and software controls may 1438 be able to ensure prevention of this problem. In addition, the 1439 recognition of the senders voice may provide confidence of the 1440 sender's identity irrespecitve of that specified in Sender or From. 1441 It should be recognized that SMTP implementations do not provide 1442 inherent authentication of the senders of messages,nor are sites under 1443 obligation to provide such authentication. 1445 10.2.2 Spam 1447 Assigning an Internet mail address to a voice mailbox opens the 1448 possiblity of receiving unsolicited messages (either text or voice 1449 mail). Traditionally voice mail systems operated in closed 1450 environments and were not susceptable to unknown senders. Voice mail 1451 users have a higher expectation of mailbox privacy and may consider 1452 such messages as a security breach. Many Internet mail systems are 1453 choosing to block all messages from spam sources in an attempt to curb 1454 this problem. 1456 10.2.3 Message disclosure 1458 Users of voice messaging systems have an expectation of a level of 1459 message privacy which is higher than the level provided by Internet 1460 mail without security enhancements. This expectation of privacy by 1461 users SHOULD be preserved as much as possible. 1463 10.3 Security Techniques 1465 Sufficient physical and software control may be acceptable in 1466 constrained environments. Further, the profile specified in this 1467 document does not in any way preclude the use of any Internet object 1468 or channel security protocol to encrypt, authenticate, or non- 1469 repudiate the messages. 1471 References 1473 [8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E., D. Crocker, 1474 "SMTP Service Extension for 8bit-MIMEtransport" RFC 1426, United 1475 Nations University, Innosoft International, Inc., Dover Beach 1476 Consulting, Inc., Network Management Associates, Inc., The Branch 1477 Office, February 1993. 1479 [ADPCM] G. Vaudreuil and G. Parsons, "Toll Quality Voice - 32 kbit/s 1480 ADPCM: MIME Sub-type Registration", Work In Progress, , November 1997. 1483 [AMIS-A] Audio Messaging Interchange Specifications (AMIS) - Analog 1484 Protocol Version 1, Issue 2, February 1992. 1486 [AMIS-D] Audio Messaging Interchange Specifications (AMIS) - Digital 1487 Protocol Version 1, Issue 3 August 1993. 1489 [BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of 1490 Large and Binary MIME Messages", RFC 1830, October 1995. 1492 [CODES] Vaudreuil, G. "Enhanced Mail System Status Codes", RFC 1893, 1493 01/15/1996. 1495 [MIMEDIR] F. Dawson, T. Howes, & M. Smith, "A MIME Content-Type for 1496 Directory Information", Work In Progress, , March 1998 1499 [DISP] R. Troost and S. Dorner, Communicating Presentation Information 1500 in Internet Messages: The Content-Disposition Header, RFC 2183, 1501 August 1997 1503 [DNS1] Mockapetris, P., "Domain names - implementation and 1504 specification", RFC1035, Nov 1987. 1506 [DNS2] Mockapetris, P., "Domain names - concepts and facilities", RFC 1507 1034, Nov 1987. 1509 [DRPT] Moore, K. "SMTP Service Extensions for Delivery Status 1510 Notifications", RFC 1891, 01/15/1996 1512 [DSN] Moore, K., Vaudreuil, G., "An Extensible Message Format for 1513 Delivery Status Notifications", RFC 1894, 01/15/1996. 1515 [DUR] G. Parsons and G. Vaudreuil, "Content Duration MIME Header 1516 Definition", Work In Progress, , November 1517 1997. 1519 [E164] CCITT Recommendation E.164 (1991), Telephone Network and ISDN 1520 Operation, Numbering, Routing and Mobile Service - Numbering Plan 1521 for the ISDN Era. 1523 [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, 1524 "SMTP Service Extensions" RFC 1869, United Nations University, 1525 Innosoft International, Inc., Dover Beach Consulting, Inc., Network 1526 Management Associates, Inc., The Branch Office, November 1995. 1528 [G726] CCITT Recommendation G.726 (1990), General Aspects of Digital 1529 Transmission Systems, Terminal Equipment - 40, 32, 24,16 kbit/s 1530 Adaptive Differential Pulse Code Modulation (ADPCM). 1532 [HOSTREQ] Braden, R., "Requirements for Internet Hosts -- Application 1533 and Support", STD 3, RFC 1123, October 1989. 1535 [LANG] Alvestrand,H., "Tags for the Identification of Languages", RFC 1536 1766, Mar 1995 1538 [MDN] Fajman, Roger, "An Extensible Message Format for Message 1539 Disposition Notifications" Work In Progress, , January 1998 1542 [MIB II] M. Rose, "Management Information Base for Network Management of 1543 TCP/IP-based internets: MIB-II", RFC 1158, May 1990. 1545 [MIME1] N. Freed and N. Borenstein, "Multipurpose Internet Mail 1546 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 1547 2045, Innosoft, First Virtual, Nov 1996. 1549 [MIME2] N. Freed and N. Borenstein, "Multipurpose Internet Mail 1550 Extensions (MIME) Part Two: Media Types ", RFC 2046, Innosoft, First 1551 Virtual, Nov 1996. 1553 [MIME3] K. Moore, "Multipurpose Internet Mail Extensions (MIME) Part 1554 Three: Message Header Extensions for Non-ASCII Text ", RFC 2047, 1555 University of Tennessee, Nov 1996. 1557 [MIME4] N. Freed, J. Klensin and J. Postel, "Multipurpose Internet Mail 1558 Extensions (MIME) Part Four: Registration Procedures", RFC 2048, 1559 Innosoft, MCI, ISI, Nov 1996. 1561 [MIME5] N. Freed and N. Borenstein, "Multipurpose Internet Mail 1562 Extensions (MIME) Part Five: Conformance Criteria and Examples ", RFC 1563 2049, Innosoft, First Virtual, Nov 1996. 1565 [PIPE] Freed, N., Cargille, A., "SMTP Service Extension for Command 1566 Pipelining" RFC 1854, October 1995. 1568 [REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the 1569 Reporting of Mail System Administrative Messages", RFC 1892, 1570 01/15/1996. 1572 [REQ] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1573 Levels", RFC 2119, March 1997. 1575 [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text 1576 Messages", STD 11, RFC 822, UDEL, August 1982. 1578 [SIZE] Klensin, J, Freed, N., Moore, K, "SMTP Service Extensions for 1579 Message Size Declaration" RFC 1870, United Nations University, 1580 Innosoft International, Inc., November 1995. 1582 [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 1583 USC/Information Sciences Institute, August 1982. 1585 [STATUS] Freed, N. "SMTP Service Extension for Returning Enhanced Error 1586 Codes", RFC 2034, 10/30/1996. 1588 [TIFF-F] G. Parsons and J. Rafferty, "Tag Image File Format: 1589 Application F", , February 1998. 1591 [TIFFREG] G. Parsons, J. Rafferty & S. Zilles, "Tag Image File Format: 1592 image/tiff - MIME sub-type registraion", , February 1998. 1595 [V-MSG] G. Vaudreuil and G. Parsons, "VPIM Voice Message: MIME Sub-type 1596 Registration", Work In Progress, , 1597 November 1997. 1599 [VCARD] Dawson, Frank, Howes, Tim, "vCard MIME Directory Profile" 1600 , March 1998. 1602 [VPIM1] Vaudreuil, Greg, "Voice Profile for Internet Mail", RFC 1911, 1603 Feb 1996. 1605 [X.400] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021 1606 and RFC 822", RFC 1327, May 1992. 1608 12. Acknowledgments 1610 The authors would like to offer a special thanks to the Electronic 1611 Messaging Association (EMA), especially the members of the Voice 1612 Messaging Committee and the VPIM Work Group, for their support of the 1613 VPIM specification and the efforts they have made to ensure its 1614 success. 1616 The EMA hosts the VPIM web page at http://www.ema.org/vpim. 1618 13. Copyright Notice 1620 "Copyright (C) The Internet Society (1998). All Rights Reserved. 1622 This document and translations of it may be copied and furnished to 1623 others, and derivative works that comment on or otherwise explain it 1624 or assist in its implmentation may be prepared, copied, published and 1625 distributed, in whole or in part, without restriction of any kind, 1626 provided that the above copyright notice and this paragraph are 1627 included on all such copies and derivative works. However, this 1628 document itself may not be modified in any way, such as by removing 1629 the copyright notice or references to the Internet Society or other 1630 Internet organizations, except as needed for the purpose of 1631 developing Internet standards in which case the procedures for 1632 copyrights defined in the Internet Standards process must be followed, 1633 or as required to translate it into languages other than English. 1635 The limited permissions granted above are perpetual and will not be 1636 revoked by the Internet Society or its successors or assigns. 1638 This document and the information contained herein is provided on an 1639 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1640 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT 1641 NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN 1642 WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1643 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1645 14. Authors' Addresses 1647 Glenn W. Parsons 1648 Northern Telecom 1649 P.O. Box 3511, Station C 1650 Ottawa, ON K1Y 4H7 1651 Canada 1652 Phone: +1-613-763-7582 1653 Fax: +1-613-763-4461 1654 Glenn.Parsons@Nortel.ca 1656 Gregory M. Vaudreuil 1657 Lucent Technologies, 1658 Octel Messaging Division 1659 17080 Dallas Parkway 1660 Dallas, TX 75248-1905 1661 United States 1662 Phone/Fax: +1-972-733-2722 1663 GregV@Lucent.Com 1665 15. Appendix A - VPIM Requirements Summary 1667 The following table summarizes the profile of VPIM version 2 detailed 1668 in this document. Since in many cases it is not possible to simplify 1669 the qualifications for supporting each feature this appendix is 1670 informative. The reader is recommended to read the complete 1671 explanation of each feature in the referenced section. The text in 1672 the previous sections shall be deemed authoritative if any item in 1673 this table is ambiguous. 1675 The conformance table is separated into various columns: 1677 Feature - name of protocol feature (note that the indenting 1678 indicates a hierarchy of conformance, i.e. the 1679 conformance of a lower feature is only relevant if there 1680 is conformance to the higher feature) 1682 Section - reference section in main text of this document 1684 Area - conformance area to which each feature applies: 1685 C - content 1686 T - transport 1688 Status - whether the feature is mandatory, optional, or prohibited. 1689 The key words used in this table are to be interpreted as described 1690 in [REQ], though the following list gives a quick overview of the 1691 different degrees of feature conformance: 1692 Must - mandatory 1693 Should - encouraged optional 1694 May - optional 1695 Should not - discouraged optional 1696 Must not - prohibited 1698 Footnote - special comment about conformance for a particular 1699 feature 1700 VPIM version 2 Conformance 1701 | | | | |S| | 1702 | | | | | |H| |F 1703 | | | | | |O|M|o 1704 | | | |S| |U|U|o 1705 | | | |H| |L|S|t 1706 | |A|M|O| |D|T|n 1707 | |R|U|U|M| | |o 1708 | |E|S|L|A|N|N|t 1709 | |A|T|D|Y|O|O|t 1710 FEATURE |SECTION | | | | |T|T|e 1711 -------------------------------------------|----------|-|-|-|-|-|-|- 1712 | | | | | | | | 1713 Message Addressing Formats: | | | | | | | | 1714 Use DNS host names |4.1 |C|x| | | | | 1715 Use only numbers in mailbox IDs |4.1.1 |C| |x| | | | 1716 Use alpha-numeric mailbox IDs |4.1.1 |C| | |x| | | 1717 Support of postmaster@domain |4.1.2 |C|x| | | | | 1718 Support of non-mail-user@domain |4.1.2 |C| |x| | | | 1719 Support of distribution lists |4.1.3 |C| |x| | | | 1720 | | | | | | | | 1721 Message Header Fields: | | | | | | | | 1722 Encoding outbound messages | | | | | | | | 1723 From |4.2.1 |C|x| | | | | 1724 Addition of text name |4.2.1 |C| |x| | | | 1725 To |4.2.2 |C|x| | | | |1 1726 cc |4.2.3 |C| |x| | | |1 1727 Date |4.2.4 |C|x| | | | | 1728 Sender |4.2.5 |C| | |x| | | 1729 Return-Path |4.2.6 |C| | |x| | | 1730 Message-id |4.2.7 |C|x| | | | | 1731 Reply-To |4.2.8 |C| | | |x| | 1732 Received |4.2.9 |C|x| | | | | 1733 MIME Version: 1.0 (Voice 2.0) |4.2.10 |C| |x| | | | 1734 Content-Type |4.2.11 |C|x| | | | | 1735 Content-Transfer-Encoding |4.2.12 |C|x| | | | | 1736 Sensitivity |4.2.13 |C| | |x| | | 1737 Importance |4.2.14 |C| | |x| | | 1738 Subject |4.2.15 |C| |x| | | | 1739 Disposition-notification-to |4.2.16 |C| | |x| | | 1740 Disposition-notification-options |4.2.17 |C| | |x| | | 1741 Other Headers |4.2 |C| | |x| | | 1742 | | | | | | | | 1743 | | | | |S| | 1744 | | | | | |H| |F 1745 | | | | | |O|M|o 1746 | | | |S| |U|U|o 1747 | | | |H| |L|S|t 1748 | |A|M|O| |D|T|n 1749 | |R|U|U|M| | |o 1750 | |E|S|L|A|N|N|t 1751 | |A|T|D|Y|O|O|t 1752 FEATURE |SECTION | | | | |T|T|e 1753 -------------------------------------------|----------|-|-|-|-|-|-|- 1754 Detection & Decoding inbound messages | | | | | | | | 1755 From |4.2.1 |C|x| | | | | 1756 Present text personal name |4.2.1 |C| | |x| | | 1757 To |4.2.2 |C|x| | | | | 1758 cc |4.2.3 |C| | |x| | | 1759 Date |4.2.4 |C|x| | | | | 1760 Conversion of Date to local time |4.2.4 |C| |x| | | | 1761 Sender |4.2.5 |C| | |x| | | 1762 Return-Path |4.2.6 |C| | |x| | | 1763 Message ID |4.2.7 |C|x| | | | | 1764 Reply-To |4.2.8 |C| |x| | | | 1765 Received |4.2.9 |C| | |x| | | 1766 MIME Version: 1.0 (Voice 2.0) |4.2.10 |C| |x| | | | 1767 Content Type |4.2.11 |C|x| | | | | 1768 Content-Transfer-Encoding |4.2.12 |C|x| | | | | 1769 Sensitivity |4.2.13 |C|x| | | | |2 1770 Importance |4.2.14 |C| | |x| | | 1771 Subject |4.2.15 |C| | |x| | | 1772 Disposition-notification-to |4.2.16 |C| | |x| | | 1773 Disposition-notification-options |4.2.17 |C| | |x| | | 1774 Other Headers |4.2 |C|x| | | | |3 1775 | | | | | | | | 1776 Message Content Encoding: | | | | | | | | 1777 Encoding outbound audio/fax contents | | | | | | | | 1778 7BIT |4.3 |C| | | | |x| 1779 8BIT |4.3 |C| | | | |x| 1780 Quoted Printable |4.3 |C| | | | |x| 1781 Base64 |4.3 |C|x| | | | |4 1782 Binary |4.3 |C| |x| | | |5 1783 Detection & decoding inbound messages | | | | | | | | 1784 7BIT |4.3 |C|x| | | | | 1785 8BIT |4.3 |C|x| | | | | 1786 Quoted Printable |4.3 |C|x| | | | | 1787 Base64 |4.3 |C|x| | | | | 1788 Binary |4.3 |C|x| | | | |5 1789 | | | | | | | | 1790 | | | | |S| | 1791 | | | | | |H| |F 1792 | | | | | |O|M|o 1793 | | | |S| |U|U|o 1794 | | | |H| |L|S|t 1795 | |A|M|O| |D|T|n 1796 | |R|U|U|M| | |o 1797 | |E|S|L|A|N|N|t 1798 | |A|T|D|Y|O|O|t 1799 FEATURE |SECTION | | | | |T|T|e 1800 -------------------------------------------|----------|-|-|-|-|-|-|- 1801 Message Content Types: | | | | | | | | 1802 Inclusion in outbound messages | | | | | | | | 1803 Multipart/Voice-Message |4.3.1 |C|x| | | | | 1804 Message/RFC822 |4.3.2 |C| | |x| | | 1805 Text/Directory |4.3.3 |C| |x| | | | 1806 include TEL, EMAIL, VERSION |4.3.3 |C|x| | | | | 1807 include ROLE, SOUND, N, REV |4.3.3 |C| |x| | | | 1808 only one voice type per level |4.3.3 |C|x| | | | | 1809 Audio/32KADPCM |4.3.4 |C|x| | | | | 1810 Content-Description |4.3.4.1 |C| | |x| | | 1811 Content-Disposition |4.3.4.2 |C|x| | | | | 1812 Content-Duration |4.3.4.3 |C| | |x| | | 1813 Content-Langauge |4.3.4.4 |C| | |x| | | 1814 Image/tiff; application=faxbw |4.3.5 |C| | |x| | | 1815 Audio/* or Image/* (other encodings) |4.3.6 |C| | |x| | | 1816 Multipart/Mixed |4.4.1 |C| | |x| | | 1817 Text/plain |4.4.2 |C| | | |x| | 1818 Multipart/Report |4.4.3 |C|x| | | | | 1819 human-readable part is voice |4.4.3 |C| |x| | | | 1820 human-readable part is text |4.4.3 |C| | |x| | | 1821 Message/delivery-status |4.4.4 |C|x| | | | | 1822 Message/disposition-notification |4.4.5 |C| |x| | | | 1823 Other contents |4.4 |C| | | |x| |6 1824 | | | | | | | | 1825 Detection & decoding in inbound messages | | | | | | | | 1826 Multipart/Voice-Message |4.3.1 |C|x| | | | | 1827 Message/RFC822 |4.3.2 |C|x| | | | | 1828 Text/Directory |4.3.3 |C| |x| | | | 1829 recognize TEL, EMAIL, VERSION |4.3.3 |C|x| | | | | 1830 recognize ROLE, SOUND, N, REV |4.3.3 |C| |x| | | | 1831 Audio/32KADPCM |4.3.4 |C|x| | | | | 1832 Content-Description |4.3.4.1 |C| | |x| | | 1833 Content-Disposition |4.3.4.2 |C| |x| | | | 1834 Content-Duration |4.3.4.3 |C| | |x| | | 1835 Content-Langauge |4.3.4.4 |C| | |x| | | 1836 Image/tiff; application=faxbw |4.3.5 |C| |x| | | | 1837 send NDN if unable to render |4.3.5 |C|x| | | | |7 1838 Audio/* or Image/* (other encodings) |4.3.6 |C| | |x| | | 1839 Multipart/Mixed |4.4.1 |C|x| | | | | 1840 Text/plain |4.4.2 |C|x| | | | | 1841 send NDN if unable to render |4.4.2 |C|x| | | | | 1842 | | | | | |S| | 1843 | | | | | |H| |F 1844 | | | | | |O|M|o 1845 | | | |S| |U|U|o 1846 | | | |H| |L|S|t 1847 | |A|M|O| |D|T|n 1848 | |R|U|U|M| | |o 1849 | |E|S|L|A|N|N|t 1850 | |A|T|D|Y|O|O|t 1851 FEATURE |SECTION | | | | |T|T|e 1852 ------------------------------------------|-----------|-|-|-|-|-|-|- 1853 | | | | | | | | 1854 Multipart/Report |4.4.3 |C|x| | | | | 1855 human-readable part is voice |4.4.3 |C| |x| | | | 1856 human-readable part is text |4.4.3 |C|x| | | | | 1857 Message/delivery-status |4.4.4 |C|x| | | | | 1858 Message/disposition-notification |4.4.5 |C| |x| | | | 1859 Other contents |4.4 |C| | | |x| |6 1860 send NDN if unable to render |4.4 |C| |x| | | | 1861 | | | | | | | | 1862 Forwarded Messages | | | | | | | | 1863 use Message/RFC822 construct |4.5 |C| |x| | | | 1864 simulate headers if none available |4.5 |C| |x| | | | 1865 | | | | | | | | 1866 Reply Messages | | | | | | | | 1867 send to Reply-to, else From address |4.6 |C|x| | | | | 1868 do not send to non-mail-user |4.6 |C|x| | | | | 1869 | | | | | | | | 1870 Notifications | | | | | | | | 1871 use multipart/report format |4.7 |C|x| | | | | 1872 always send error on non-delivery |4.7 |C| |x| | | | 1873 | | | | | | | | 1874 Message Transport Protocol: | | | | | | | | 1875 ESMTP Commands | | | | | | | | 1876 HELO |5.1.1 |T|x| | | | | 1877 MAIL FROM |5.1.2 |T|x| | | | | 1878 support null address |5.1.2 |T|x| | | | | 1879 RCPT TO |5.1.3 |T|x| | | | | 1880 DATA |5.1.4 |T|x| | | | | 1881 TURN |5.1.5 |T| | | | |x| 1882 QUIT |5.1.6 |T|x| | | | | 1883 RSET |5.1.7 |T|x| | | | | 1884 VRFY |5.1.8 |T| | |x| | | 1885 EHLO |5.1.9 |T|x| | | | | 1886 BDAT |5.1.10 |T| |x| | | |5 1887 | | | | |S| | 1888 | | | | | |H| |F 1889 | | | | | |O|M|o 1890 | | | |S| |U|U|o 1891 | | | |H| |L|S|t 1892 | |A|M|O| |D|T|n 1893 | |R|U|U|M| | |o 1894 | |E|S|L|A|N|N|t 1895 | |A|T|D|Y|O|O|t 1896 FEATURE |SECTION | | | | |T|T|e 1897 -------------------------------------------|----------|-|-|-|-|-|-|- 1898 | | | | | | | | 1899 ESMTP Keywords & Parameters | | | | | | | | 1900 PIPELINING |5.2.1 |T| |x| | | | 1901 SIZE |5.2.2 |T|x| | | | | 1902 CHUNKING |5.2.3 |T| |x| | | | 1903 BINARYMIME |5.2.4,5.3.1|T| |x| | | | 1904 DSN |5.2.5 |T|x| | | | | 1905 ENHANCEDSTATUSCODES |5.2.6 |T| |x| | | | 1906 RET |5.3.2 |T| |x| | | | 1907 ENVID |5.3.3 |T| | |x| | | 1908 NOTIFY |5.4.1 |T|x| | | | | 1909 ORCPT |5.4.2 |T| | |x| | | 1910 | | | | | | | | 1911 ESMTP-SMTP Downgrading | | | | | | | | 1912 send delivery report upon downgrade |5.5 |T|x| | | | | 1913 | | | | | | | | 1914 Directory Address Resolution | | | | | | | | 1915 provide facility to resolve addresses |6 |C| |x| | | | 1916 use vCards to populate local directory |6 |C| |x| | | |8 1917 use headers to populate local directory |6 |C| | | |x| | 1918 | | | | | | | | 1919 Management Protocols: | | | | | | | | 1920 Network management |8.1 |T| |x| | | | 1921 -------------------------------------------|----------|-|-|-|-|-|-|- 1923 Footnotes: 1925 1. MUST NOT include if all recipients are not known or resolvable. 1926 2. If a sensitive message is received by a system that does not 1927 support sensitivity, then it MUST be returned to the originator 1928 with an appropriate error notification. Also, a received 1929 sensitive message MUST NOT be forwarded to anyone. 1930 3. If the addtional headers are not understood they MAY be ignored 1931 4. When binary transport is not available 1932 5. When binary transport is available 1933 6. Other un-profiled contents must only be sent by bilateral 1934 agreement. 1935 7. If the content cannot be presented in some form, the entire 1936 message MUST be non-delivered. 1937 8. When the vCard is present in a message 1939 16. Appendix B - Example Voice Messages 1941 The following message is a full-featured message addressed to two 1942 recipients. The message includes the sender's spoken name and a short 1943 speech segment. The message is marked as important and private. 1945 To: +19725551212@vm1.mycompany.com 1946 To: +16135551234@VM1.mycompany.com 1947 From: "Parsons, Glenn" <12145551234@VM2.mycompany.com> 1948 Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT) 1949 MIME-Version: 1.0 (Voice 2.0) 1950 Content-type: Multipart/Voice-Message; Version=2.0; 1951 Boundary="MessageBoundary" 1952 Content-Transfer-Encoding: 7bit 1953 Message-ID: 123456789@VM2.mycompany.com 1954 Sensitivity: Private 1955 Importance: High 1957 --MessageBoundary 1958 Content-type: Audio/32KADPCM 1959 Content-Transfer-Encoding: Base64 1960 Content-Disposition: inline; voice=Originator-Spoken-Name 1961 Content-Language: EN-US 1962 Content-ID: part1@VM2-4321 1964 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1965 (This is a sample of the base-64 Spoken Name data) 1966 fgdhgddlkgpokpeowrit09== 1968 --MessageBoundary 1969 Content-type: Audio/32KADPCM 1970 Content-Transfer-Encoding: Base64 1971 Content-Description: Brand X Voice Message 1972 Content-Disposition: inline; voice=Voice-Message; filename=msg1.726 1973 Content-Duration: 25 1975 iIiIiIjMzN3czdze3s7d7fwfHhcvESJVe/4yEhLz8/FOQjVFRERCESL/zqrq 1976 (This is a sample of the base64 message data) zb8tFdLTQt1PXj 1977 u7wjOyRhws+krdns7Rju0t4tLF7cE0K0MxOTOnRW/Pn30c8uHi9== 1979 --MessageBoundary 1980 Content-type: text/directory; charset=us-ascii; profile=vCard 1981 Content-Transfer-Encoding: 7bit 1983 BEGIN:VCARD 1984 N:Parsons;Glenn;;Mr.; 1985 EMAIL;TYPE=INTERNET:+12145551234@VM2.mycompany.com 1986 TEL:+1-217-555-1234 1987 SOUND;TYPE=32KADPCM;ENCODING=URI: CID: 1988 REV:19951031T222710Z 1989 VERSION: 3.0 1990 END:VCARD 1992 --MessageBoundary_ 1993 The following message is a forwarded single segment voice. Both the 1994 forwarded message and the forwarding message contain VCARDs with 1995 spoken names. 1997 To: +12145551212@vm1.mycompany.com 1998 From: "Vaudreuil, Greg" <+19725552345@VM2.mycompany.com> 1999 Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT) 2000 MIME-Version: 1.0 (Voice 2.0) 2001 Content-type: Multipart/Voice-Message; Version=2.0; 2002 Boundary="MessageBoundary" 2003 Content-Transfer-Encoding: 7bit 2004 Message-ID: ABCD-123456789@VM2.mycompany.com 2006 --MessageBoundary 2007 Content-type: Audio/32KADPCM 2008 Content-Transfer-Encoding: Base64 2009 Content-Disposition: inline; voice=Originator-Spoken-Name 2010 Content-Language: EN-US 2011 Content-ID: part3@VM2-4321 2013 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 2014 (This is a sample of the base-64 Spoken Name data) 2015 fgdhgd dlkgpokpeowrit09== 2017 --MessageBoundary 2018 Content-type: Audio/32KADPCM 2019 Content-Description: Forwarded Message Annotation 2020 Content-Disposition: inline; voice=Voice-Message 2021 Content-Transfer-Encoding: Base64 2023 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 2024 (This is the voiced introductory remarks encoded in base64) 2025 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW 2026 dlkgpokpeowrit09== 2028 --MessageBoundary 2029 Content-type: Message/RFC822 2030 Content-Transfer-Encoding: 7bit 2032 To: +19725552345@VM2.mycompany.com 2033 From: "Parsons, Glenn, W." <+16135551234@VM1.mycompany.com> 2034 Date: Mon, 26 Aug 93 8:23:10 -0500 (EST) 2035 Content-type: Multipart/Voice-Message; Version=2.0; 2036 Boundary="MessageBoundary2" 2037 Content-Transfer-Encoding: 7bit 2038 MIME-Version: 1.0 (Voice 2.0) 2039 --MessageBoundary2 2040 Content-type: Audio/32KADPCM 2041 Content-Transfer-Encoding: Base64 2042 Content-Disposition: inline; voice=Originator-Spoken-Name 2043 Content-Language: EN-US 2044 Content-ID: part6@VM2-4321 2046 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 2047 (This is a sample of the base-64 Spoken Name data) fgdhgd 2048 dlkgpokpeowrit09== 2050 --MessageBoundary2 2051 Content-type: Audio/32KADPCM 2052 Content-Disposition: inline; voice=Voice-Message 2053 Content-Transfer-Encoding: Base64 2055 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 2056 (This is the original message audio data) fgwersdfmniwrjj 2057 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW 2058 dlkgpokpeowrit09== 2060 --MessageBoundary2 2061 Content-type: text/directory; charset=us-ascii 2062 Content-Transfer-Encoding: 7bit 2064 BEGIN:VCARD 2065 N:Parsons;Glenn;W;Mr.; 2066 EMAIL;TYPE=INTERNET:+16135551234@VM2.mycompany.com 2067 TEL:+1-613-555-1234 2068 SOUND;TYPE=32KADPCM;ENCODING=URI: CID: 2069 REV:19951031T222710Z 2070 END:VCARD 2072 --MessageBoundary2-- 2074 --MessageBoundary 2075 Content-type: text/directory; charset=us-ascii 2076 Content-Transfer-Encoding: 7bit 2078 BEGIN:VCARD 2079 N:Vaudreuil;Greg;;Mr.; 2080 SOUND;TYPE=32KADPCM;ENCODING=URI: CID: 2081 EMAIL;TYPE=INTERNET,VPIM:+19725552345@VM2.mycompany.com 2082 TEL:+1-972-555-2345 2083 REV:19951031T222710Z 2084 VERSION: 3.0 2085 END:VCARD 2087 --MessageBoundary-- 2088 The following example is for a message returned to the sender by a 2089 VPIM gateway at VM1.company.com for a mailbox which does not exist. 2091 Date: Thu, 7 Jul 1994 17:16:05 -0400 2092 From: Mail Delivery Subsystem 2093 Message-Id: <199407072116.RAA14128@vm1.company.com> 2094 Subject: Returned voice message 2095 To: 2175552345@VM2.mycompany.com 2096 MIME-Version: 1.0 (Voice 2.0) 2097 Content-Type: multipart/report; report-type=delivery-status; 2098 boundary="RAA14128.773615765/VM1.COMPANY.COM" 2100 --RAA14128.773615765/VM1.COMPANY.COM 2101 Content-type: Audio/32KADPCM 2102 Content-Description: Spoken Delivery Status Notification 2103 Content-Disposition: inline; voice= Voice-Message-Notification 2104 Content-Transfer-Encoding: Base64 2106 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd 2107 (This is a voiced description of the error in base64) 2108 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW 2109 dlkgpokpeowrit09== 2111 --RAA14128.773615765/VM1.COMPANY.COM 2112 Content-type: message/delivery-status 2114 Reporting-MTA: dns; vm1.company.com 2115 Original-Recipient: rfc822; 2145551234@VM1.mycompany.com 2116 Final-Recipient: rfc822; 2145551234@VM1.mycompany.com 2117 Action: failed 2118 Status: 5.1.1 (User does not exist) 2119 Diagnostic-Code: smtp; 550 Mailbox not found 2120 Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400 2122 --RAA14128.773615765/VM1.COMPANY.COM 2123 content-type: message/rfc822 2125 [original VPIM message goes here] 2127 --RAA14128.773615765/VM1.COMPANY.COM-- 2128 The following example is for a read receipt sent to the original 2129 sender for a message which has been played. This delivered VPIM 2130 message was received by a corporate gateway and relayed to a 2131 unified mailbox. 2133 Date: Thu, 7 Jul 1994 17:16:05 -0400 2134 From: "Greg Vaudreuil" <22722@vm.company.com> 2135 Message-Id: <199407072116.RAA14128@exchange.company.com> 2136 Subject: Voice message played 2137 To: 2175552345@VM2.mycompany.com 2138 MIME-Version: 1.0 (Voice 2.0) 2139 Content-Type: multipart/report; 2140 Report-type=disposition-notification; 2141 Boundary="RAA14128.773615765/EXCHANGE.COMPANY.COM" 2143 --RAA14128.773615765/EXCHANGE.COMPANY.COM 2144 Content-type: Audio/32KADPCM 2145 Content-Description: Spoken Disposition Notification 2146 Content-Disposition: inline; voice= Voice-Message-Notification 2147 Content-Transfer-Encoding: Base64 2149 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd 2150 (Voiced description of the disposition action in base64) 2151 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW 2152 dlkgpokpeowrit09== 2154 --RAA14128.773615765/EXCHANGE.COMPANY.COM 2155 Content-type: message/disposition-notification 2157 Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0) 2158 Original-Recipient: rfc822;22722@vm.company.com 2159 Final-Recipient: rfc822;Greg.Vaudreuil@foomail.company.com 2160 Original-Message-ID: <199509192301.12345@vm2.mycompany.com > 2161 Disposition: manual-action/MDN-sent-automatically; displayed 2163 --RAA14128.773615765/EXCHANGE.COMPANY.COM 2164 Content-type: message/rfc822 2166 [original VPIM message goes here] 2168 --RAA14128.773615765/EXCHANGE.COMPANY.COM-- 2170 17. Appendix C - Example Error Voice Processing Error Codes 2172 The following common voice processing errors and their corresponding 2173 status codes are given as examples. Text after the error codes are 2174 intended only for reference to describe the error code. 2175 Implementations should provide implementation specific informative 2176 comments after the error code rather than the text below. 2178 Error condition RFC 1893 Error codes 2179 ----------------------------- -------------------------------- 2181 Analog delivery failed 4.4.0 Persistent connection error 2182 because remote system is busy - other 2184 Analog delivery failed 4.4.1 Persistent protocol error 2185 because remote system is - no answer from host 2186 ring-no-answer 2188 Remote system did not answer 5.5.5 Permanent protocol error 2189 AMIS-Analog handshake ("D" in - wrong version 2190 response to "C" at connect 2191 time) 2193 Mailbox does not exist 5.1.1 Permanent mailbox error 2194 - does not exist 2196 Mailbox full or over quota 4.2.2 Persistent mailbox error 2197 - full 2199 Disk full 4.3.1 Persistent system error 2200 - full 2202 Command out of sequence 5.5.1 Permanent protocol error 2203 - invalid command 2205 Frame Error 5.5.2 Permanent protocol error 2206 - syntax error 2208 Mailbox does not support FAX 5.6.1 Permanent media error 2209 - not supported 2211 Mailbox does not support TEXT 5.6.1 Permanent media error 2212 - not supported 2214 Sender is not authorized 5.7.1 Permanent security error 2215 - sender not authorized 2217 Message marked private, but 5.3.3 Permanent system error 2218 system is not private capable - not feature capable 2220 18. Appendix D - Example Voice Processing Disposition Types 2222 The following common voice processing disposition conditions and their 2223 corresponding MDN Disposition (which contains the disposition mode, 2224 type and modifier, if applicable) are given as examples. Implementors 2225 should refer to [MDN] for a full description of the format of message 2226 disposition notifications. 2228 Notification event MDN Disposition mode, type & modifier 2229 ------------------------------ ------------------------------------- 2231 Message played by recipient, manual-action/MDN-sent-automatically; 2232 receipt automatically returned displayed 2234 Message deleted from mailbox manual-action/MDN-sent-automatically; 2235 by user without listening deleted 2237 Message cleared when mailbox manual-action/MDN-sent-automatically; 2238 deleted by admin deleted/mailbox-terminated 2240 Message automatically deleted automatic-action/ 2241 when older than administrator MDN-sent-automatically; deleted/ 2242 set threshold expired 2244 Message processed, however manual-action/MDN-sent-automatically; 2245 audio encoding unknown - processed/error 2246 unable to play to user Error: unknown audio encoding 2248 19. Appendix E - IANA Registrations 2250 19.1 vCard EMAIL Type Definition for VPIM 2252 To: ietf-mime-directory@imc.org 2254 Subject: Registration of new parameter for text/directory MIME type 2255 EMAIL 2257 Type name: EMAIL 2259 Type purpose: To specify the electronic mail address for 2260 communication with the object the vCard represents (defined in 2261 [VCARD]). 2263 Type encoding: 8bit 2265 Type value: A single text value. 2267 Type special notes: The type may include the type parameter "TYPE" to 2268 specify the format or preference of the electronic mail address. The 2269 TYPE parameter values previously defined include: "internet" to 2270 indicate an Internet addressing type, "x400" to indicate a X.400 2271 addressing type and "pref" to indicate a preferred-use email address 2272 when more than one is specified. The value of "vpim" is defined to 2273 indicate that the address specified supports VPIM messages. Other 2274 IANA registered address type may also be specified. The default email 2275 type is "internet". A non-standard value may also be specified. 2277 Type example: 2278 EMAIL;TYPE=internet,vpim:jqpublic@xyz.dom1.com 2280 19.2 Voice Content-Disposition Parameter Definition 2282 To: IANA@IANA.ORG 2284 Subject: Registration of new Content-Disposition parameter 2286 Content-Disposition parameter name: voice 2288 Allowable values for this parameter: 2290 Voice-Message - the primary voice message, 2291 Voice-Message-Notification - a spoken delivery notification 2292 or spoken disposition notification, 2293 Originator-Spoken-Name - the spoken name of the originator, 2294 Recipient-Spoken-Name - the spoken name of the recipient if 2295 available to the originator and present if there is ONLY one 2296 recipient, 2297 Spoken-Subject- the spoken subject of the message, typically 2298 spoken by the originator 2300 Description: 2302 In order to distinguish between the various types of audio contents in 2303 a VPIM voice message a new disposition parameter "voice" is defined 2304 with the preceding values to be used as appropriate. Note that there 2305 SHOULD only be one instance of each of these types of audio contents 2306 per message level. Additional instances of a given type (i.e., 2307 parameter value) may occur within an attached forwarded voice message. 2309 20. Appendix F - Change History: RFC 1911 to this Document 2311 The updated profile in this document is based on the experience of a 2312 proof of concept demonstration of VPIM at EMA'96 in April 1996 and a 2313 subsequent demonstration of products at EMA'97 in April 1997. This 2314 version of the profile is significantly different from the previous 2315 described in [VPIM1]. The changes are categorized as general, 2316 content, transport and conformance. They are detailed below: 2318 1. General 2320 - All definitions are now contained in separate documents that are 2321 referenced by this profile. The new documents include: 2323 - a refined multipart/voice-message definition 2325 - a refined (i.e., added nibble order) audio/32KADPCM definition 2327 - the definitions of TIFF-F and image/tiff for fax images 2329 - the Content-Duration definition 2331 - Changed the Voice version to 2.0 2333 - Added Table of Contents and more examples 2335 - Various editorial updates to improve readability 2337 - Added more security considerations 2339 2. Content 2341 - Modified multipart/voice-message content type by dropping the 2342 positional dependence of contents while restricting its contents to 2343 voice message specific content types 2345 - Explicitly indicated other contents that may be present ina 2346 multipart/mixed content type 2348 - Explicitly defined the forwarding model using message/RFC822 2350 - Explained the use of reply-to and from headers for addressing 2351 message replies 2353 - Deprecated the special "loopback" address because of security 2354 concerns and its use only for testing 2356 - Defined the non-mail-user reserved address to support the case in 2357 which replies to the originator are not possible 2359 - Eliminated the text name in the "To" and "CC" headers. 2360 Deprecated ordering of text names in the "From" header. 2362 - Added support for facsimile using TIFF-F in an image/tiff; 2363 application=faxbw content type 2365 - Profiled vCard in the text/directory body part for transport of 2366 directory information about the originator 2368 - Loosened text restriction 2370 - Added additional details on delivery and receipt notifications 2372 - Added support for message disposition notifications, also known 2373 as read receipts. 2375 - Added suggested addressing formats 2377 - Described handling of private messages 2379 - Described the handling of non-profiled contents in VPIM messages 2381 - Described the use of Content-Disposition to semantically identify 2382 audio contents 2384 3. Transport 2386 - Moved binary support to optional 2388 - Added optional ESMTP keywords for return of content, enhanced 2389 status codes, original recipient, and envelope ID 2391 - Described use of null MAIL FROM address 2393 4. Compliance 2395 - Added an explicit section on conformance specifying conformance 2396 to content or transport 2398 - Improved conformance table in Appendix A