idnits 2.17.1 draft-ema-vpim-vpimv2r2-02.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 2) being 102 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 62 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. -- The abstract seems to indicate that this document obsoletes RFC2421, 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 883 has weird spacing: '...message syste...' == Line 1130 has weird spacing: '...message that ...' == Line 1385 has weird spacing: '...ssaging proto...' == Line 1926 has weird spacing: '...for the purpo...' == Line 2539 has weird spacing: '...eturned displ...' == (3 more instances...) == 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 'MUST not' in this paragraph: SEND RULES Conforming implementations MAY send "Cc:" lists if all recipients are known at the time or origination . The list of disclosed recipients MUST not include undisclosed recipients (ie., those sent via a blind copy). If not, systems SHOULD omit the "Cc:" fields to indicate that the full list of recipients is unknown or otherwise unavailable. == 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 'MUST not' in this paragraph: The originator system MUST not add this header. == 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: This command SHOULD not be sent by compliant systems unless the more-capable EHLO command is not accepted. It is included for compatibility with general SMTP implementations. -- 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 (October 28, 1999) is 8946 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: 'RFC 2421' is mentioned on line 57, but not defined ** Obsolete undefined reference: RFC 2421 (Obsoleted by RFC 3801) == Missing Reference: 'MIME' is mentioned on line 645, but not defined == Unused Reference: '8BIT' is defined on line 1772, but no explicit reference was found in the text == Unused Reference: 'AMIS-A' is defined on line 1781, but no explicit reference was found in the text == Unused Reference: 'AMIS-D' is defined on line 1784, but no explicit reference was found in the text == Unused Reference: 'DNS1' is defined on line 1800, but no explicit reference was found in the text == Unused Reference: 'DNS2' is defined on line 1803, but no explicit reference was found in the text == Unused Reference: 'E164' is defined on line 1815, but no explicit reference was found in the text == Unused Reference: 'G726' is defined on line 1824, but no explicit reference was found in the text == Unused Reference: 'MIME3' is defined on line 1848, but no explicit reference was found in the text == Unused Reference: 'MIME5' is defined on line 1856, but no explicit reference was found in the text == Unused Reference: 'VPIM2' is defined on line 1898, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1426 (ref. '8BIT') (Obsoleted by RFC 1652) ** Obsolete normative reference: RFC 2422 (ref. 'ADPCM') (Obsoleted by RFC 3802) -- 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) ** Obsolete normative reference: RFC 2425 (ref. 'MIMEDIR') (Obsoleted by RFC 6350) ** Obsolete normative reference: RFC 1891 (ref. 'DRPT') (Obsoleted by RFC 3461) ** Obsolete normative reference: RFC 1894 (ref. 'DSN') (Obsoleted by RFC 3464) ** Obsolete normative reference: RFC 2424 (ref. 'DUR') (Obsoleted by RFC 3803) -- 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) ** Obsolete normative reference: RFC 2298 (ref. 'MDN') (Obsoleted by RFC 3798) ** 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) ** Downref: Normative reference to an Informational RFC: RFC 2306 (ref. 'TIFF-F') ** Obsolete normative reference: RFC 2302 (ref. 'TIFFREG') (Obsoleted by RFC 3302) ** Obsolete normative reference: RFC 2426 (ref. 'VCARD') (Obsoleted by RFC 6350) ** Obsolete normative reference: RFC 1911 (ref. 'VPIM1') (Obsoleted by RFC 2421, RFC 2422, RFC 2423) ** Obsolete normative reference: RFC 2421 (ref. 'VPIM2') (Obsoleted by RFC 3801) Summary: 30 errors (**), 0 flaws (~~), 25 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Greg Vaudreuil 3 Internet Draft Lucent Technologies 4 Expires in six months Glenn Parsons 5 Obsoletes: RFC 2421 Nortel Networks 6 October 28, 1999 8 Voice Profile for Internet Mail - version 2 10 12 Status of this Memo 14 This document is an Internet-Draft and is in full conformance with 15 all provisions of Section 10 of RFC2026. 17 This document is an Internet Draft. Internet Drafts are working 18 documents of the Internet Engineering Task Force (IETF), its Areas, 19 and its Working Groups. Note that other groups may also distribute 20 working documents as Internet Drafts. 22 Internet Drafts are valid for a maximum of six months and may be 23 updated, replaced, or obsoleted by other documents at any time. It 24 is inappropriate to use Internet Drafts as reference material or to 25 cite them other than as a "work in progress". 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 To learn the current status of any Internet-Draft, please check the 34 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 35 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 36 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 37 ftp.isi.edu (US West Coast). 39 Copyright Notice 41 Copyright (C) The Internet Society (1999). All Rights Reserved. 43 Overview 45 This document profiles Internet mail for voice messaging. It 46 obsoletes RFC 2421 which describes version 2 of the profile with less 47 precision. A list of changes from that document are noted in 48 Appendix F. As well, Appendix A summarizes the protocol profiles of 49 this version of VPIM. 51 Please send comments on this document to the IETF VPIM mailing list: 52 54 Working Group Summary 56 This document is a deliverable of the draft charter of the IETF VPIM 57 BOF. This document is intended as a revision of VPIM v2 [RFC 2421] 58 for the purposes of elevating its maturity status. No protocol 59 changes should be made from RFC 2421 but this document is hoped to be 60 a more precise profile. 62 Table of Contents 64 1. ABSTRACT..........................................................4 65 2. SCOPE.............................................................5 66 2.1 Voice Messaging System Limitations ..............................5 67 2.2 Design Goals ....................................................6 68 3. PROTOCOL RESTRICTIONS.............................................7 69 4. VOICE MESSAGE INTERCHANGE FORMAT..................................8 70 4.1 Message Addressing Formats ......................................8 71 4.2 Message Header Fields ..........................................11 72 4.3 MIME Audio Content Descriptions ................................19 73 4.4 Voice Message Content Types ....................................20 74 4.5 Other MIME Content Types .......................................25 75 4.6 Return and Notification Messages ...............................27 76 4.7 Forwarded Messages .............................................29 77 4.8 Reply Messages .................................................29 78 4.9 Notification Messages ..........................................30 79 5. MESSAGE TRANSPORT PROTOCOL.......................................31 80 5.1 ESMTP Commands .................................................31 81 5.2 ESMTP Keywords .................................................33 82 5.3 ESMTP Parameters - MAIL FROM ...................................34 83 5.4 ESMTP Parameters - RCPT TO .....................................35 84 5.5 ESMTP - SMTP Downgrading .......................................35 85 6. DIRECTORY ADDRESS RESOLUTION.....................................36 86 7. MANAGEMENT PROTOCOLS.............................................36 87 7.1 Network Management .............................................36 88 8. CONFORMANCE REQUIREMENTS.........................................37 89 9. SECURITY CONSIDERATIONS..........................................38 90 9.1 General Directive ..............................................38 91 9.2 Threats and Problems ...........................................38 92 9.3 Security Techniques ............................................39 93 10. REFERENCES.......................................................39 94 11. ACKNOWLEDGMENTS..................................................42 95 12. COPYRIGHT NOTICE.................................................42 96 13. AUTHORS' ADDRESSES...............................................43 97 14. APPENDIX A - VPIM REQUIREMENTS SUMMARY...........................44 98 15. APPENDIX B - EXAMPLE VOICE MESSAGES..............................52 99 16. APPENDIX C - EXAMPLE ERROR VOICE PROCESSING ERROR CODES..........57 100 17. APPENDIX D - EXAMPLE VOICE PROCESSING DISPOSITION TYPES..........58 101 18. APPENDIX E - IANA REGISTRATIONS..................................59 102 18.1 vCard EMAIL Type Definition for VPIM .........................59 103 18.2 Voice Content-Disposition Parameter Definition ...............59 104 19. APPENDIX F - CHANGE HISTORY: RFC 2421 (VPIM V2) TO THIS DOCUMENT.61 105 1. Abstract 107 Voice messaging evolved as telephone answering service into a full 108 send, receive, and forward messaging paradigm with unique message 109 features, semantics and usage patterns. Voice messaging was 110 introduced on special purpose computers that interface to a telephone 111 switch and provide call answering and voice messaging services. 112 Traditionally, messages sent from one voice messaging system to 113 another were transported using analog networking protocols based on 114 DTMF signaling and analog voice playback. As the demand for 115 networking increases, there was a need for a standard high-quality 116 digital protocol to connect these machines. VPIM has successfully 117 demonstrated its usefulness as this new standard. VPIM is widely 118 implemented and is seeing deployment in early adopter customer 119 networks. This document clarifies ambiguities found in the earlier 120 specification and is consistent with implementation practice. The 121 profile is referred to as VPIM (Voice Profile for Internet Mail) in 122 this document. 124 This second revision of the version 2 of obsoletes RFC 2421 which 125 less precisely describes version 2 of the profile. 127 2. Scope 129 MIME is the Internet multipurpose, multimedia messaging standard. 130 This document explicitly recognizes its capabilities and provides a 131 mechanism for the exchange of various messaging technologies, 132 primarily voice and facsimile. 134 This document specifies a restricted profile of the Internet 135 multimedia messaging protocols for use between voice processing 136 server platforms. These platforms have historically been special- 137 purpose computers and often do not have the same facilities normally 138 associated with a traditional Internet Email-capable computer. As a 139 result, VPIM also specifies additional functionality as it is needed. 140 This profile is intended to specify the minimum common set of 141 features to allow interworking between compliant systems. 143 2.1 Voice Messaging System Limitations 145 The following are typical limitations of voice messaging platform 146 which were considered in creating this baseline profile. 148 1) Text messages are not normally received and often cannot be 149 easily displayed or viewed. They can often be processed only via 150 text-to-speech or text-to-fax features not currently present in 151 many of these machines. 153 2) Voice mail machines usually act as an integrated Message 154 Transfer Agent, Message Store and User Agent. There is typically 155 no relaying of messages, and RFC 822 header fields may have limited 156 use in the context of the limited messaging features currently 157 deployed. 159 3) Voice mail message stores are generally not capable of 160 preserving the full semantics of an Internet message. As such, use 161 of a voice mail machine for gatewaying is not supported. In 162 particular, storage of recipient lists, "Received" lines, and 163 "Message-ID" may be limited. 165 4) Internet-style distribution/exploder mailing lists are not 166 typically supported. Voice mail machines often implement only 167 local alias lists, with error-to-sender and reply-to-sender 168 behavior. Reply-all capabilities using a CC list are not generally 169 available. 171 5) Error reports must be machine-parsable so that helpful responses 172 can be voiced to users whose only access mechanism is a telephone. 174 6) The voice mail systems generally limit address entry to 16 or 175 fewer numeric characters, and normally do not support alphanumeric 176 mailbox names. Alpha characters are not generally used for mailbox 177 identification as they cannot be easily entered from a telephone 178 terminal. 180 It should be noted that newer systems are based natively on SMTP/MIME 181 and do not suffer these limitations. In particular, some systems may 182 support media other than voice and fax. 184 2.2 Design Goals 186 It is a goal of this profile to make as few restrictions and 187 additions to the existing Internet mail protocols as possible while 188 satisfying the requirements for interoperability with current 189 generation voice messaging systems. This goal is motivated by the 190 desire to increase the accessibility to digital messaging by enabling 191 the use of proven existing networking software for rapid development. 193 This specification is intended for use on a TCP/IP network; however, 194 it is possible to use the SMTP protocol suite over other transport 195 protocols. The necessary protocol parameters for such use is outside 196 the scope of this document. 198 This profile is intended to be robust enough to be used in an 199 environment, such as the global Internet with installed-base gateways 200 which do not understand MIME. Full functionality, such as reliable 201 error messages and binary transport, will require careful selection 202 of gateways (e.g., via MX records) to be used as VPIM forwarding 203 agents. Nothing in this document precludes use of general purpose 204 MIME email packages to read and compose VPIM messages. While no 205 special configuration is required to receive VPIM compliant messages, 206 some may be required to originate compliant structures. 208 It is expected that a VPIM messaging system will be managed by a 209 system administrator who can perform TCP/IP network configuration. 210 When using facsimile or multiple voice encodings, it is suggested 211 that the system administrator maintain a list of the capabilities of 212 the networked mail machines to reduce the sending of undeliverable 213 messages due to lack of feature support. Configuration, 214 implementation and management of these directory listing capabilities 215 are local matters. 217 3. Protocol Restrictions 219 This protocol does not limit the number of recipients per message. 220 Where possible, server implementations should not restrict the number 221 of recipients in a single message. It is recognized that no 222 implementation supports unlimited recipients, and that the number of 223 supported recipients may be quite low. 225 This protocol does not limit the maximum message length. 226 Implementers should understand that some machines will be unable to 227 accept excessively long messages. A mechanism is defined in the RFC 228 1425 SMTP service extensions to declare the maximum message size 229 supported. 231 The message size indicated in the ESMTP SIZE parameter is in bytes, 232 not minutes or seconds. The number of bytes varies by voice encoding 233 format and includes the MIME wrapper overhead. If the length must be 234 known before sending, an approximate translation into minutes or 235 seconds can be performed if the voice encoding is known. 237 The following sections describe the restrictions and additions to 238 Internet mail protocols that are required to be compliant with this 239 VPIM v2 profile. Though various SMTP, ESMTP and MIME features are 240 described here, the implementer is referred to the relevant RFCs for 241 complete details. The table in Appendix A summarizes the protocol 242 details of this profile. 244 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 245 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 246 document are to be interpreted as described in [REQ]. 248 4. Voice Message Interchange Format 250 The voice message interchange format is a profile of the Internet 251 Mail Protocol Suite. Any Internet Mail message containing the format 252 defined in this section is referred to as a VPIM Message in this 253 document. As a result, this document assumes an understanding of the 254 Internet Mail specifications. Specifically, VPIM references 255 components from the message format standard for Internet messages 256 [RFC822], the Multipurpose Internet Message Extensions [MIME], the 257 X.400 gateway specification [X.400], delivery status and message 258 disposition notifications [REPORT][DSN][DRPT][STATUS][MDN], and the 259 electronic business card [MIMEDIR][VCARD]. 261 MIME, introduced in [MIME1], is a general-purpose message body format 262 that is extensible to carry a wide range of body parts. It provides 263 for encoding binary data so that it can be transported over the 7-bit 264 text-oriented SMTP protocol. This transport encoding (denoted by the 265 Content-Transfer-Encoding header field) is in addition to the audio 266 encoding required to generate a binary object. 268 MIME defines two transport encoding mechanisms to transform binary 269 data into a 7 bit representation, one designed for text-like data 270 ("Quoted-Printable"), and one for arbitrary binary data ("Base64"). 271 While Base64 is dramatically more efficient for audio data, either 272 will work. Where binary transport is available, no transport 273 encoding is needed, and the data can be labeled as "Binary". 275 An implementation in compliance with this profile SHOULD send audio 276 and/or facsimile data in binary form when binary message transport is 277 available (see section 5). When binary transport is not available, 278 implementations MUST encode the audio and/or facsimile data as 279 Base64. The detection and decoding of "Quoted-Printable", "7bit", 280 and "8bit" MUST be supported in order to meet MIME requirements and 281 to preserve interoperability with the fullest range of possible 282 devices. However, if a content is received in a transfer encoding 283 that cannot be rendered to the user, an appropriate negative delivery 284 status notification MUST be sent. 286 4.1 Message Addressing Formats 288 RFC 822 addresses are based on the domain name system. This naming 289 system has two components: the local part, used for username or 290 mailbox identification; and the host part, used for global machine 291 identification. 293 4.1.1 VPIM Addresses 295 The local part of the address shall be a US-ASCII string uniquely 296 identifying a mailbox on a destination system. For voice messaging, 297 the local part is a printable string containing the mailbox ID of the 298 originator or recipient. While alpha characters and long mailbox 299 identifiers are permitted, most voice mail networks rely on numeric 300 mailbox identifiers to retain compatibility with the limited 10 digit 301 telephone keypad. As a result, some voice messaging systems may only 302 be able to handle a numeric local part. The reception of 303 alphanumeric local parts on these systems may result in the address 304 being mapped to some locally unique (but confusing to the recipient) 305 number or, in the worst case the address could be deleted making the 306 message un-replyable. Additionally, it may be difficult to create 307 messages on these systems with an alphanumeric local part without 308 complex key sequences or some form of directory lookup (see 6). 310 The use of the domain naming system should be transparent to the 311 user. It is the responsibility of the voice mail machine to lookup 312 the fully-qualified domain name (FQDN) based on the address entered 313 by the user (see 6). 315 In the absence of a global directory, specification of the local part 316 is expected to conform to international or private telephone 317 numbering plans. It is likely that private numbering plans will 318 prevail and these are left for local definition. However, it is 319 RECOMMENDED that public telephone numbers be noted according to the 320 international numbering plan described in [E.164]. The indication 321 that the local part is a public telephone number is given by a 322 preceding `+' (the `+' would not be entered from a telephone keypad, 323 it is added by the system as a flag). Since the primary information 324 in the numeric scheme is contained by the digits, other character 325 separators (e.g. `-') may be ignored (i.e. to allow parsing of the 326 numeric local mailbox) or may be used to recognize distinct portions 327 of the telephone number (e.g. country code). The specification of 328 the local part of a VPIM address can be split into the four groups 329 described below: 331 1) mailbox number 332 - for use as a private numbering plan (any number of digits) 333 - e.g. 2722@lucent.com 335 2) mailbox number+extension 336 - for use as a private numbering plan with extensions 337 any number of digits, use of `+' as separator 338 - e.g. 2722+111@Lucent.com 340 3) +international number 341 - for international telephone numbers conforming to E.164 342 maximum of 15 digits 343 - e.g. +16137637582@vm.nortel.ca 345 4) +international number+extension 347 - for international telephone numbers conforming to E.164 348 maximum of 15 digits, with an extension (e.g. behind a 349 PBX) that has a maximum of 15 digits. 350 - e.g. +17035245550+230@ema.org 352 Note that this address format is designed to be compatible with 353 current usage within the voice messaging industry. It is not 354 compatible with the addressing formats of RFC s 2303-2304. It is 355 expected that as telephony services become more widespread on the 356 Internet, these addressing formats will converge. 358 4.1.2 Special Addresses 360 Special addresses are provided for compatibility with the conventions 361 of Internet mail. These addresses do not use numeric local 362 addresses, both to conform to current Internet practice and to avoid 363 conflict with existing numeric addressing plans. Two special 364 addresses are RESERVED for use as follows: 366 postmaster@domain 368 By convention, a special mailbox named "postmaster" MUST exist on all 369 systems. This address is used for diagnostics and should be checked 370 regularly by the system manager. This mailbox is particularly likely 371 to receive text messages, which is not normal on a voice processing 372 platform. The specific handling of these messages is an individual 373 implementation choice. 375 non-mail-user@domain 377 If a reply to a message is not possible, such as a telephone 378 answering message, then the special address "non-mail-user" SHOULD be 379 used as the originator's address. Any text name such as "Telephone 380 Answering", or the telephone number if it is available, is permitted. 381 This special address is used as a token to indicate an unreachable 382 originator. For compatibility with the installed base of mail user 383 agents, implementations that generate this special address MUST send 384 a negative delivery status notification (DSN) for reply messages sent 385 to the undeliverable address. The status code for such NDN's is 386 5.1.1 "Mailbox does not exist". 388 Example: 390 From: Telephone Answering 392 4.1.3 Distribution Lists 394 There are many ways to handle distribution list (DL) expansions and 395 none are 'standard'. Simple alias is a behavior closest to what most 396 voice mail systems do today and what is to be used with VPIM 397 messages. That is: 399 Reply to the originator - (Address in the RFC822 Reply-to or From 400 field) 401 Errors to the submitter - (Address in the MAIL FROM: field of the 402 ESMTP exchange and the Return-Path: 403 RFC 822 field) 405 Some proprietary voice messaging protocols include only the recipient 406 of the particular copy in the envelope and include no "header fields" 407 except date and per-message features. Most voice messaging systems 408 do not provide for "Header Information" in their messaging queues and 409 only include delivery information. As a result, recipient 410 information MAY be in either the To or CC header fields. If all 411 recipients cannot be presented then the recipient header fields 412 SHOULD be omitted to indicate that an accurate list of recipients 413 (e.g. for use with a reply-all capability) is not known. 415 4.2 Message Header Fields 417 Internet messages contain a header information block. This header 418 block contains information required to identify the sender, the list 419 of recipients, the message send time, and other information intended 420 for user presentation. Except for specialized gateway and mailing 421 list cases, header fields do not indicate delivery options for the 422 transport of messages. 424 Distribution list processors are noted for modifying or adding to the 425 header fields of messages that pass through them. VPIM systems MUST 426 be able to accept and ignore header fields that are not defined here. 428 The following header lines are permitted for use with VPIM voice 429 messages: 431 4.2.1 From 433 SEND RULES 435 The originator's fully-qualified domain address (a mailbox address 436 followed by the fully-qualified domain name) MUST be present. Systems 437 compliant with this profile SHOULD provide the text personal name of 438 the voice message originator in a quoted phrase, if the name is 439 available. Text names of corporate or positional mailboxes MAY be 440 provided as a simple string. From [RFC822] 442 Example: 444 From: "Joe S. User" <12145551212@mycompany.com> 446 From: Technical Support <611@serviceprovider.com> 448 From: Non-mail-user@myserver.mycompany.com 450 Voice mail machines may not be able to support separate attributes 451 for the "From:" and "Reply-To:" header fields, the SMTP MAIL FROM and 452 the vCard email attribute, VPIM-conforming systems SHOULD set these 453 values to the same address. Use of addresses different than those 454 present in the "From:" header field address may result in 455 unanticipated behavior. 457 RECEPTION RULES 459 The user listed in this field should be presented in the voice 460 message envelope of the voice messaging system as the originator of 461 the message. The "From:" address SHOULD be used for replies (see 462 4.8). However, if the "From:" address contains , the user SHOULD NOT be offered the option to reply, nor 464 should notifications be sent to this address. 466 4.2.2 To 468 The "To:" field contains the recipient's fully-qualified domain 469 address. Example: 471 To: +12145551213@mycompany.com 473 SEND RULES 475 There MAY be one or more "To:" fields in any message. Systems SHOULD 476 provide a list of recipients only if all recipients are available. 478 Systems such as gateways from protocols which do not indicate the 479 complete list of recipients SHOULD provide a "To:" line. Because 480 these systems cannot accurately enumerate all recipients in the "To:" 481 headers, no recipients should be enumerated. 483 RECEPTION RULES 485 Systems compliant to this profile MAY discard the addresses in the 486 "To:" fields if they are unable to store the information. This 487 would, of course, make a reply-to-all capability impossible. If 488 present, the addresses in the "To:" field MAY be used for a reply 489 message to all recipients. 491 4.2.3 Cc 493 The "Cc:" field contains additional recipients' fully-qualified 494 domain addresses. Many voice mail systems maintain only sufficient 495 envelope information for message delivery and are not capable of 496 storing or providing a complete list of additional recipients. 498 SEND RULES 499 Conforming implementations MAY send "Cc:" lists if all recipients are 500 known at the time or origination . The list of disclosed recipients 501 MUST not include undisclosed recipients (ie., those sent via a blind 502 copy). If not, systems SHOULD omit the "Cc:" fields to indicate that 503 the full list of recipients is unknown or otherwise unavailable. 505 Example: 507 Cc: +12145551213@mycompany.com 509 RECEPTION RULES 511 Systems compliant to this profile MAY add all the addresses in the 512 "Cc:" field to the "To:" field, others MAY discard the addresses in 513 the "Cc:" fields. If a list of "Cc:" addresses is present, these 514 addresses MAY be used for a reply message to all recipients. 516 4.2.4 Date 518 The "Date:" field MUST be present and contains the date, time, and 519 time zone in which the message was sent by the originator. 521 SEND RULES 523 The time zone MUST be present and SHOULD be represented in a four- 524 digit time zone offset, such as -0500 for North American Eastern 525 Standard Time. This MAY be supplemented by a time zone name in 526 parentheses, e.g., "-0900 (PDT)". Compliant implementations SHOULD 527 be able to convert [RFC822] date and time stamps into local time. 529 If the VPIM sender is relaying a message from a system which does not 530 provide a time stamp, the time of arrival at the gateway system 531 SHOULD be used as the date. 533 Example: 535 Date: Wed, 28 Jul 96 10:08:49 -0800 (PST) 537 RECEPTION RULES 539 The sending system MUST report the time the message was sent. From 540 [RFC822] 542 4.2.5 Sender 544 SEND RULES 546 The "Sender:" field contains the actual address of the originator if 547 the message is sent by an agent on behalf of the author indicated in 548 the "From:" field. This header field MAY be sent by VPIM-conforming 549 systems. 551 RECEPTION RULES 553 If the address in the "Sender:" field cannot be preserved in the 554 recipient's message queues or in the next-hop protocol from a 555 gateway, the field MAY be silently discarded. 557 4.2.6 Return-Path 559 The "Return-path:" field is added by the final delivering SMTP 560 server. If present, it contains the address from the MAIL FROM 561 parameter of the ESMTP exchange (see 5.1.2). Any error messages 562 resulting from the delivery failure MUST be sent to this address. 563 Note that if the "Return-path:" is null ("<>"), e.g. no path, loop 564 prevention or confidential, delivery status and message disposition 565 notifications MUST NOT be sent. 567 SEND RULES 569 The originator system MUST not add this header. 571 RECEPTION RULES 573 If the receiving system is incapable of storing the return path to be 574 used for subsequent delivery errors, the receiving system must 575 otherwise ensure that further delivery errors don't happen. Systems 576 that do not support the return path MUST ensure that at the time the 577 message is acknowledged, the message is delivered to the recipient's 578 ultimate mailbox. Non-Delivery notifications should not be sent 579 after that final delivery. 581 4.2.7 Message-id 583 The "Message-Id:" field contains a unique per-message identifier. 585 SEND RULES 587 A unique message-id MUST be generated for each message sent from a 588 VPIM-compliant implementation. 590 Example: 592 Message-Id: <12345678@mycompany.com> 594 RECEPTION RULES 596 The message id is not required to be stored on the receiving system. 597 This identifier MAY be used for tracking, auditing, and returning 598 receipt notification reports. From [RFC822] 600 4.2.8 Reply-To 602 If present, the "Reply-to:" header provides a preferred address to 603 which reply messages should be sent (see 4.8). Typically, voice mail 604 systems can only support one originator of a message so it is likely 605 that this field will be ignored by the receiving system. From 606 [RFC822] 608 SEND RULES 610 A compliant system SHOULD NOT send a Reply-To header. 612 RECEPTION RULES 614 If a "reply-to:" field is present, a reply-to sender message MAY be 615 sent to the address specified (that is, in lieu of the address in the 616 "From:" field). If only one address of the originator is supported in 617 the message store or in the next-hop protocol from a multi-protocol 618 gateway, the address in the "From:" field MUST be used and the 619 "Reply-To:" field MAY be silently discarded. 621 4.2.9 Received 623 The "Received:" field contains trace information added to the 624 beginning of a RFC 822 message by MTAs. This is the only field 625 permitted to be added by an MTA. Information in this header is 626 useful for debugging when using an US-ASCII message reader or a 627 header-parsing tool. From [RFC822] 629 SEND RULES 631 A VPIM-compliant system MUST add a "Received:" field. When acting as 632 a gateway, information about the system translated from SHOULD be 633 included. 635 RECEPTION RULES 637 A VPIM-compliant system SHOULD NOT remove any "Received:" fields when 638 relaying messages to other MTAs or gateways. These header fields 639 MAY be ignored or deleted when the message is received at the final 640 destination. 642 4.2.10 MIME Version 644 The "MIME-Version:" field indicates that the message conforms to 645 [MIME]. Systems compliant with this specification SHOULD include a 646 comment with the words "(Voice 2.0)". [VPIM1] defines an earlier 647 version of this profile and uses the token (Voice 1.0). Example: 649 MIME-Version: 1.0 (Voice 2.0) 651 This identifier is intended for information only and SHOULD NOT be 652 used to semantically identify the message as being a VPIM message. 653 Instead, the presence of the content defined in [V-MSG] SHOULD be 654 used if identification is necessary. 656 4.2.11 Content-Type 658 The content-type header declares the type of content enclosed in the 659 message. The typical top level content in a VPIM Message SHOULD be 660 multipart/voice-message. The allowable contents are detailed 661 starting in section 4.4 of this document. From [MIME2] 663 4.2.12 Content-Transfer-Encoding 665 Because Internet mail was initially specified to carry only 7-bit US- 666 ASCII text, it may be necessary to encode voice and fax data into a 667 representation suitable for that environment. The content-transfer- 668 encoding header describes this transformation if it is needed. 669 Compliant implementations MUST recognize and decode the standard 670 encodings, "Binary", "7bit, "8bit", "Base64" and "Quoted- 671 Printable".From [MIME1]. 673 4.2.13 Sensitivity 675 The "Sensitivity:" field, if present, indicates the requested privacy 676 level. The case-insensitive values "Personal", "Private", and 677 "Normal" are specified. If no privacy is requested, this field is 678 omitted. 680 SEND RULES 682 A VPIM-compliant implementations MAY include this header to indicate 683 the sensitivity of a message. If the message is of "Normal" 684 sensitivity, this field SHOULD be omitted. From: [X.400] 686 RECEPTION RULES 688 If a "Sensitivity:" field with a value of "Personal" or "Private" is 689 present in the message, a compliant system MUST prohibit the 690 recipient from forwarding this message to any other user. A 691 compliant system, however, SHOULD allow the responder to reply to a 692 sensitive message, but SHOULD NOT include the original message 693 content. The sensitivity of the reply message MAY be set by the 694 responder. 696 If the receiving system does not support privacy and the sensitivity 697 is one of "Personal" or "Private", a negative delivery status 698 notification MUST be sent to the originator with the appropriate 699 status code (X.Y.Z) indicating that privacy could not be assured. The 700 message contents SHOULD be returned to the sender to allow for a 701 voice context with the notification. A non-delivery notification to a 702 private message SHOULD NOT be tagged private since it will be sent to 703 the originator. From: [X.400] 705 A message with no privacy explicitly noted (ie., no header) or with 706 _ Normal_ sensitivity has no special treatment. 708 4.2.14 Importance 710 Indicates the requested importance to be given by the receiving 711 system. The case-insensitive values "low", "normal" and "high" are 712 specified. If no special importance is requested, this header may be 713 omitted and the value of the absent header assumed to be "normal". 714 From: [X.400] 716 SEND RULES 718 Compliant implementations MAY include this header to indicate the 719 importance of a message 721 RECEPTION RULES 723 If the receiving system does not support importance, the attribute 724 may be silently dropped. If the attribute is supported, it can be 725 used for various user interface purposes including the ordering 726 messages within a mailbox or trigging notification devices such as 727 pagers. 729 4.2.15 Subject 731 The subject field is often provided by email systems but is not 732 widely supported on Voice Mail platforms. From [RFC822] 734 SEND RULES 736 For compatibility with text based mailbox interfaces, a text subject 737 field SHOULD be generated by a compliant implementation. It is 738 recommended that voice-messaging systems that do not support any text 739 user interfaces (e.g. access only by a telephone) insert a generic 740 subject header of "VPIM Message" or _ Voice Message_ for the benefit 741 of GUI enabled recipients. 743 RECEPTION RULES 745 It is anticipated that many voice-only systems will be incapable of 746 storing the subject line. The subject MAY be discarded if present by 747 a receiving system. 749 4.2.16 Disposition-Notification-To 751 This header MAY be present to indicate that the sender is requesting 752 a receipt notification from the receiving user agent. This message 753 disposition notification (MDN) is typically sent by the user agent 754 after the user has listened to the message and consented to an MDN 755 being sent 757 Example: 759 Disposition-notification-to: +12145551213@mycompany.com 761 SEND RULES 763 VPIM-compliant implementations MAY include this header to request a 764 disposition indication such as a listen confirmation. 766 RECEPTION RULES 768 The presence of a "Disposition-notification-to:" header in a message 769 is merely a request for an MDN described in 4.6.3. The recipients' 770 system is always free to silently ignore such a request so this 771 header does not burden any system that does not support it. From 772 [MDN]. 774 4.2.17 Disposition-Notification-Options 776 This header MAY be present to define future extensions parameters for 777 an MDN requested by the presence of the header in the previous 778 section. 780 SEND RULES 782 No "Disposition-notification-options:" are defined that are useful 783 for voice messaging. Sending systems SHOULD NOT request disposition 784 notification options by sending a disposition-notification-options 785 header. 787 RECEPTION RULES 789 Currently no parameters are defined by this document or by [MDN]. 790 However for forward compatibility with future extensions, this header 791 MUST be processed if present, if MDNs are supported. If it contains 792 a extension parameter that is required for proper MDN generation 793 (noted with "=required"), then an MDN MUST NOT be sent if the 794 parameter is not understood. See [MDN] for complete details. 796 Example: 798 Disposition-notification-options: 799 whizzbang=required,foo 801 4.3 MIME Audio Content Descriptions 803 4.3.1 Content-Description: 805 This field MAY be present to facilitate the text identification of 806 these body parts in simple email readers. Any values may be used, 807 though it may be useful to use values similar to those for Content- 808 Disposition. 810 Example: 812 Content-Description: Big Telco Voice Message 814 4.3.2 Content-Disposition: 816 This field MUST be present to allow the parsable identification of 817 body parts within a VPIM voice message. This is especially useful 818 if, as is typical, more than one Audio/* body occurs within a 819 single level (e.g. multipart/voice-message). Since a VPIM voice 820 message is intended to be automatically played upon display of the 821 message, in the order in which the audio contents occur, the audio 822 contents must always be of type inline. However, it is still 823 useful to include a filename value, so this should be present if 824 this information is available. From [DISP] 826 In order to distinguish between the various types of audio contents 827 in a VPIM voice message a new disposition parameter "voice" is 828 defined with the parameter values below to be used as appropriate 829 (see 18.2): 831 Voice-Message - the primary voice message, 832 Voice-Message-Notification - a spoken delivery notification 833 or spoken disposition notification, 834 Originator-Spoken-Name - the spoken name of the originator, 835 Recipient-Spoken-Name - the spoken name of the recipient(s) if 836 available to the originator 837 Spoken-Subject- the spoken subject of the message, typically 838 spoken by the originator 840 Note that there SHOULD only be one instance of each of these types 841 of audio contents per message level. Additional instances of a 842 given type (i.e., parameter value) may occur within an attached 843 forwarded voice message. 845 Implementations that do not understand the "voice" parameter (or 846 the Content-Disposition header) can safely ignore it, and will 847 present the audio bodyparts in order (but will not be able to 848 distinguish between them). 850 4.3.3 Content-Duration: 852 This field MAY be present to allow the specification of the length 853 of the audio bodypart in seconds. The use of this field on 854 reception is a local implementation issue. From [DUR] 856 Example: 858 Content-Duration: 33 860 4.3.4 Content-Language: 862 This field MAY be present to allow the specification of the spoken 863 language of the audio bodypart. The encoding is defined in [LANG]. 864 The use of this field on reception is a local implementation issue. 866 Example for UK English: 868 Content-Language: en-UK 870 4.4 Voice Message Content Types 872 The content types described in this section are identified for use 873 within the multipart/voice-message content. This content is referred 874 to as a `VPIM voice message' in this document and is the fundamental 875 part of a `VPIM message'. 877 Only the contents profiled subsequently (and occasionally those in 878 4.5) can be sent within a VPIM voice message construct (i.e., the 879 mulitpart/voice-message content type) to form a simple or a more 880 complex structure (several examples are given in Appendix B). The 881 presence of other contents (see 4.5) within a VPIM voice message is 882 not permitted If present, it MAY be tolerated, but most voice 883 message systems have no means to tolerate other contents. In this 884 case, the unsupported content MAY be deleted and the remaining 885 message delivered, however most systems SHOULD reject the entire 886 message with a negative delivery status notification. In case of 887 partial delivery, the recipient must be notified of the deletion. 888 When multiple contents are present within the multipart/voice- 889 message, they SHOULD be presented to the user in the order that they 890 appear in the message. 892 4.4.1 Multipart/Voice-Message 894 This MIME multipart structure provides a mechanism for packaging a 895 voice message into one container that is tagged as VPIM v2 compliant. 897 SEND RULES 899 The Multipart/Voice-Message content-type MUST only contain the 900 profiled media and content types specified in this section (i.e. 901 audio/*, image/*, message/rfc822 and text/directory). The most 902 common will be: spoken name, spoken subject, the message itself, 903 attached fax and directory info. Forwarded messages are created by 904 simply using the message/rfc822 construct. 906 Conformant implementations MUST send the multipart/voice-message in a 907 VPIM message. In most cases, this Multipart/Voice-Message content 908 will be the top level (i.e. in the Content-Type header). 910 RECEPTION RULES 912 Conformant implementations MUST recognize the Multipart/Voice-Message 913 content (whether it is a top level content or below a 914 multipart/mixed) and be able to separate the contents (e.g. spoken 915 name or spoken subject). 917 The semantic of multipart/Voice-Message (defined in [V-MSG]) is 918 identical to multipart/mixed and may be interpreted as that by 919 systems that do not recognize this content-type. 921 4.4.2 Message/RFC822 923 SEND RULES 925 MIME requires support of the Message/RFC822 message encapsulation 926 body part. This body part SHOULD be used within a multipart/voice- 927 message to forward complete messages (see 4.7) or to reply with 928 original content (see4.8). From [MIME2] 930 RECEPTION RULES 932 The receiving system SHOULD treat this attachment as a forwarded 933 message. The receiving system may flatten the forwarding structure 934 (ie., remove this construct to leave multiple voice contents or even 935 concatenate the voice contents to fit in a recipient's mailbox) if 936 necessary. If flattening and vCards are supported, the recipient 937 system MUST discard other vCards of forwarded parts such that only 938 the outermost vCard is retained. 940 4.4.3 Text/Directory 942 This content allows for the inclusion of a Versit vCard [VCARD] 943 electronic business card within a VPIM message. The format is 944 suitable as an interchange format between applications or systems, 945 and is defined independent of the method used to transport it. 947 SEND RULES 949 Each vCard MUST be contained within a Text/Directory content type 950 [MIMEDIR] within a VPIM message. [MIMEDIR] requires that the 951 character set MUST be defined as a parameter value (typically us- 952 ascii for VPIM) and that the profile SHOULD be defined (the value 953 MUST be vCard within VPIM messages). 955 Each VPIM message SHOULD be created with a Text/Directory (vCard 956 profile) content type that MUST contain the preferred email address, 957 telephone number, and text name of the message originator as well as 958 the vCard version. The vCard SHOULD contain the spoken name and role 959 of the originator, as well as the revision date. Any other vCard 960 attribute MAY also be present. The intent is that the vCard be used 961 as the source of information to contact the originator (e.g., reply, 962 call). 964 The vCard profile [VCARD] MUST specify at least the following 965 attributes: 967 TEL - Public switched telephone number in international (E.164) 968 format (various types, typically VOICE) 970 EMAIL - email address (various types, typically INTERNET; the 971 type VPIM is optionally used to denote an address that 972 supports VPIM messages. This address MAY be used for 973 reply-to-sender functionality when the RFC822 FROM: 974 header 975 field is not accessible to the voice mail helper 976 application. 978 Version - Indicates the version of the vCard profile. Version 3.0 979 [VCARD] MUST be used. 981 The following attributes SHOULD be specified: 983 N - Family Name, Given Name, Additional Names, Honorific 984 Prefixes, and Suffixes. Because it is expected that 985 recipients using a telephone user interface will use the 986 information in the vCard to identify the originator, and 987 the GUI will see the information presented in the FROM 988 line, all present components in the text name of the FROM 989 header field MUST match the values provided by the Vcard. 991 SOUND - spoken name sound data (various types, typically 32KADPCM) 993 REV - Revision of vCard in ISO 8601 date format 995 The vCard MAY use other attributes as defined in [VCARD] or 996 extensions attributes not yet defined (e.g. recipient media 997 capabilities). 999 If present, the spoken name attribute MUST be denoted by a content ID 1000 pointing to an audio/* content elsewhere in the VPIM message. 1002 Each multipart/voice-message content MUST only contain one vCard -- 1003 more than one is an error condition. A VPIM message may contain 1004 forwarded messages. VCards that are part of the forwarded messages 1005 are permitted. However, these vCards MUST be associated with the 1006 originator(s) of the forwarded message(s) and the originator of the 1007 forwarding message. As a result, all forwarded vCards will be 1008 contained in message/rfc822 contents -- only the vCard of forwarding 1009 originator will be at the top-level. 1011 RECEPTION RULES 1013 The vCard MAY be used by the receiving system. It provides a useful 1014 mechanism to transport information about the originator that can be 1015 used by the receiving VPIM system or other local applications. It may 1016 also be used to create a reply VPIM message (see 4.8). 1018 Example: 1020 Content-Type: text/directory; charset=us-ascii; profile=vCard 1021 Content-Transfer-Encoding: 7bit 1023 BEGIN:VCARD 1024 N:Parsons;Glenn 1025 ORG:Northern Telecom 1026 TEL;TYPE=VOICE;MSG;WORK:+1-613-763-7582 1027 EMAIL;TYPE=INTERNET;glenn.parsons@nortel.ca 1028 EMAIL;TYPE=INTERNET;VPIM:6137637582@vm.nortel.ca 1029 SOUND;TYPE=32KADPCM;ENCODING=URI: CID: 1030 REV:19960831T103310Z 1031 Version: 3.0 1032 END:VCARD 1034 4.4.4 Audio/32KADPCM 1036 SEND RULES 1038 An implementation compliant to this profile MUST send Audio/32KADPCM 1039 by default for voice [ADPCM]. This encoding is a moderately 1040 compressed encoding with a data rate of 32 kbits/second using 1041 moderate processing resources. Typically this body contains several 1042 minutes of message content, however if used for spoken name or 1043 subject the content should be considerably shorter (i.e. about 10 and 1044 20 seconds respectively). 1046 Note that if an Originator Spoken Name audio body and a vCard are 1047 both present in a VPIM message, the vCard SOUND attribute MUST point 1048 to this audio body (see 4.4.3). 1050 RECEPTION RULES 1051 Receivers MUST be able to accept and decode Audio/32KADPCM. If an 1052 implementation can only handle one voice body, then multiple voice 1053 bodies (if present) SHOULD be concatenated, and SHOULD NOT be 1054 discarded. It is RECOMMENDED that this be done in the same order as 1055 they were sent. 1057 4.4.5 Image/Tiff 1059 A common image encoding for facsimile, known as TIFF-F, is a 1060 derivative of the Tag Image File Format (TIFF) and is described in 1061 several documents. For the purposes of VPIM, the F Profile of TIFF 1062 for Facsimile (TIFF-F) is defined in [TIFF-F] and the image/tiff MIME 1063 content type is defined in [TIFFREG]. While there are several 1064 formats of TIFF, only TIFF-F is profiled for use within a VPIM voice 1065 message. Further, since the TIFF-F file format is used in a store- 1066 and-forward mode with VPIM, the image MUST be encoded so that there 1067 is only one image strip per facsimile page. 1069 SEND RULES 1071 All VPIM implementations that support facsimile MUST generate TIFF-F 1072 compatible facsimile contents in the image/tiff; application=faxbw 1073 sub-type encoding by default. An implementation SHOULD send this fax 1074 content in multipart/voice-message but may send it outside to be more 1075 compatible with fax only (RFC 2305) implementations. 1077 While any valid MIME body header MAY be used (e.g., Content- 1078 Disposition to indicate the filename), none are specified to have 1079 special semantics for VPIM and MAY be ignored. Note that the content 1080 type parameter application=faxbw MUST be included in outbound 1081 messages. 1083 Inbound messages in the multipart/voice-message with or without the 1084 application parameter MUST be rendered to the user. If the rendering 1085 software encounters an error in the file format, some form of 1086 negative delivery status notification SHOULD be sent to the 1087 originator). 1089 RECEPTION RULES 1091 Not all VPIM systems support fax. Those that do MUST support it 1092 without the multipart/voice-message and MAY outside of the 1093 multipart/voice-message. A receiving system MAY accept the voice 1094 content of a VPIM message and discard the fax content. The recipient 1095 MUST be notified of the dropped content. Though discouraged, a 1096 recipient system MAY reject (with appropriate NDN) the entire message 1097 if it cannot handle fax attachments within the multipart/voice- 1098 message. 1100 4.4.6 Proprietary Voice or Fax Formats 1102 Use of any other encoding except the required codecs reduces 1103 interoperability in the absence of explicit knowledge about the 1104 capabilities of the recipient. A compliant implementation MAY use any 1105 other encoding provided a unique identifier is registered with the 1106 IANA prior to use (see [MIME4]). The voice encodings should be 1107 registered as sub-types of Audio. The fax encodings should be 1108 registered as sub-types of Image. 1110 SEND RULES 1112 Proprietary voice encoding formats or other standard formats MAY be 1113 sent under this profile only if the sender has a reasonable 1114 expectation that the recipient will accept the encoding. In 1115 practice, this requires explicit per-destination configuration 1116 information maintained either in a directory, personal address book, 1117 or gateway configuration tables. 1119 RECEPTION RULES 1121 Systems MAY accept other audio/* or image/* content types if they can 1122 decode them. Systems which receive audio/* or image/* content types 1123 which they are unable to decode MUST return the message to the 1124 originator with an NDN indicating media not supported. 1126 4.5 Other MIME Content Types 1128 An implementation compliant with this profile MAY send additional 1129 contents in a VPIM message, but only outside the multipart/voice- 1130 message. If an implementation receives a VPIM message that contains 1131 content types not specified in 4.4 or 4.5, their handling is a local 1132 implementation issue (e.g., the unknown contents MAY be discarded if 1133 they cannot be presented to the recipient). Conversely, if an 1134 implementation receives a non-VPIM message (i.e., without a 1135 multipart/voice-message content type) with any of the contents 1136 defined in 4.4, it SHOULD deliver those contents, but the full 1137 message handling is a local issue (e.g. the unknown contents or the 1138 entire message MAY be discarded). Implementations MUST issue negative 1139 delivery status notifications to the originator when any form of non- 1140 delivery to the recipient occurs. 1142 Only the contents specified in 4.4 are required to be supported 1143 within a multipart/voice message by a receiving system. Other 1144 contents MUST NOT be sent within the multipart/voice-message. The 1145 multipart contents defined below MAY be sent within a multipart/voice 1146 message as the recipient system will likely reject the message. 1147 Several examples are given in Appendix B. 1149 4.5.1 Multipart/Mixed 1151 Multipart/mixed provides the facilities for enclosing several body 1152 parts in a single message. 1154 SEND RULES 1156 When used in a VPIM message, multipart/mixed is the top level content 1157 type and multipart/voice-message is typically the first second level 1158 content type. Other attachments follow as additional second level 1159 content types. Multipart/mixed may also be used within a 1160 multipart/voice-message but caution is advised. Note that the 1161 semantics of using complex hierarchy within a voice message is 1162 undefined and the use of such a structure is discouraged. 1164 Multipart/mixed contents MAY be sent as the top level of a VPIM 1165 message. Typically, this would only be used when attaching non-voice 1166 or fax content to a VPIM message. These other contents SHOULD be 1167 placed after the multipart/voice-message. 1169 RECEPTION RULES 1171 Compliant systems MUST accept multipart/mixed content types at the 1172 top level and SHOULD within a multipart/voice-messages. Systems may 1173 collapse the contents of the multipart/mixed structure into the 1174 multipart/voice message itself. If necessary, systems SHOULD discard 1175 the other contents to deliver the voice content but they MAY reject 1176 the entire message if this is not possible. From [MIME2] 1178 4.5.2 Text/Plain 1180 MIME requires support of the basic Text/Plain content type. This 1181 content type has limited applicability within the voice messaging 1182 environment. However, because VPIM is a MIME profile, MIME 1183 requirements should be met. 1185 SEND RULES 1187 Compliant VPIM implementations SHOULD NOT send the Text/Plain 1188 content-type. It should be understood that the textual information is 1189 not considered a primary media within multipart/voice-message and may 1190 be discarded (or rejected) by a receiving system. 1192 RECEPTION RULES 1193 Within a multipart/voice message, the text/plain content type MAY be 1194 dropped from the message. The recipient SHOULD NOT reject the 1195 entire message (if an implementation does reject the entire message a 1196 suitable DSN MUST be used). However, if no rendering of the text is 1197 possible and no indication of its presence can be given to the 1198 recipient, the entire message SHOULD be returned to the sender with a 1199 negative delivery status notification and a media-unsupported status 1200 code. 1202 Outside a Multipart/Voice-message, compliant implementations MUST 1203 accept Text/Plain messages, however, specific handling is left as an 1204 implementation decision. From [MIME2] 1206 There are several mechanisms that can be used to support text (once 1207 accepted) on voice messaging systems including text-to-speech and 1208 text-to-fax conversions. 1210 4.6 Return and Notification Messages 1212 VPIM delivery status notification messages (4.6.2) MUST be sent to 1213 the originator of the message when any form of non-delivery of the 1214 subject message or its components occurs. These error messages MUST 1215 be sent to the address in the Mail From (5.1.2) if available (same as 1216 the return path (4.2.6) if present), otherwise, the From (4.2.1) 1217 address may be used. 1219 VPIM Receipt Notification messages (4.6.3) SHOULD be sent to the 1220 sender specified in the Disposition-Notification-To header field 1221 (4.2.16). The MDN SHOULD be sent after the message has been 1222 presented to the recipient or if the message has somehow been 1223 disposed of without being presented to the recipient (e.g. if it were 1224 deleted before playing it). 1226 VPIM Notification messages may be positive or negative, and can 1227 indicate delivery at the server or receipt by the client. However, 1228 the notification MUST be contained in a multipart/report container 1229 (4.6.1) and SHOULD contain a spoken error message. 1231 4.6.1 Multipart/Report 1233 The Multipart/Report is used for enclosing human-readable and machine 1234 parsable notification (e.g. Message/delivery-status) body parts and 1235 any returned message content. The multipart/report content-type is 1236 used to deliver both delivery status reports indicating transport 1237 success or failure and message disposition notifications to indicate 1238 post-delivery events such as receipt notification. 1240 SEND RULES 1242 Compliant implementations MUST use the Multipart/Report construct. 1243 From [REPORT] 1244 Multipart/Report messages from VPIM implementations MAY include the 1245 human-readable description of the error as a spoken audio/* content 1246 (this speech MAY be made available to the notification recipient). 1247 As well, VPIM implementations MAY generate Multipart/Report messages 1248 that encode the human-readable description of the error as text. 1249 Note that per [DSN] the human-readable part MUST always be present. 1251 RECEPTION RULES 1253 Compliant implementations MUST recognize and decode the 1254 Multipart/Report content type and its components in order to present 1255 the report to the user. 1257 As well, implementers MUST be able to handle the human readable 1258 description of the error as text or audio. 1260 4.6.2 Message/Delivery-status 1262 This MIME body part is used for sending machine-parsable delivery 1263 status notifications. 1265 SEND RULES 1267 Compliant implementations MUST use the Message/delivery-status 1268 construct when returning messages or sending warnings. 1270 RECEPTION RULES 1272 Compliant implementations MUST recognize and decode the 1273 Message/delivery-status content type and present the reason for 1274 failure to the sender of the message. From [DSN] 1276 4.6.3 Message/Disposition-notification 1278 This MIME body part is used for sending machine-parsable read-receipt 1279 message disposition notifications. 1281 SEND RULES 1283 Conforming implementations SHOULD use the Message/Disposition- 1284 notification construct when sending post-delivery message status 1285 notifications. These MDNs, however, MUST only be sent in response to 1286 the presence of the Disposition-notification-to header described in 1287 4.2.16. 1289 RECEPTION RULES 1291 Conforming implementations should recognize and decode the 1292 Message/Disposition-notification content type and present the 1293 notification to the user. From [MDN] 1295 4.7 Forwarded Messages 1297 VPIM version 2 explicitly supports the forwarding of voice and fax 1298 content with voice or fax annotation. However, only the two 1299 constructs described below are acceptable in a VPIM message. Since 1300 only the first (i.e. message/rfc822) can be recognized as a forwarded 1301 message (or even multiple forwarded messages), it is RECOMMENDED that 1302 this construct be used whenever possible. 1304 Forwarded VPIM messages SHOULD be sent as a multipart/voice-message 1305 with the entire original message enclosed in a message/rfc822 content 1306 type and the annotation as a separate Audio/* or image/* body part. 1307 If the RFC822 header fields are not available for the forwarded 1308 content, simulated header fields with available information SHOULD be 1309 constructed to indicate the original sending timestamp, and the 1310 original sender as indicated in the "From" line. However, note that 1311 at least one of "From", "Subject", or "Date" MUST be present. As 1312 well, the message/rfc822 content MUST include at least the "MIME- 1313 Version", and "Content-Type" header fields. From [MIME2] 1315 In the event that forwarding information is lost through 1316 concatenation of the original message and the forwarding annotation, 1317 such as must be done in a gateway between VPIM and the AMIS voice 1318 messaging protocol, the entire audio content MAY be sent as a single 1319 Audio/* segment without including any forwarding semantics. 1321 4.8 Reply Messages 1323 Replies to VPIM messages (and Internet mail messages) are addressed 1324 to the address noted in the reply-to header (see 4.2.8) if it is 1325 present, else the From address (see 4.2.1) is used. The vCard EMAIL 1326 attribute, if present, SHOULD be the same as the reply-to address and 1327 may be the same as the From address. It is expected that within 1328 legacy email implementations, the voice message viewer application 1329 may need to create a reply message without the benefit of the RFC822 1330 headers. In such a case, the vCard MAY be used to generate a reply 1331 to the sender. 1333 RECEPTION RULES 1335 Support of multiple originator header fields is often not possible on 1336 voice messaging systems, so it may be necessary to choose only one 1337 when gatewaying a VPIM message to another voice message system. 1338 However, implementers should note that this may make it impossible to 1339 send error messages and replies to their proper destinations. 1341 In some cases, a reply message is not possible, such as with a 1342 message created by telephone answering (i.e. classic voice mail). In 1343 this case, the From field MUST contain the special address non-mail- 1344 user@domain (see 4.1.2). A null ESMTP MAIL FROM address SHOULD also 1345 be used in this case (see 5.1.2). A receiving VPIM system SHOULD NOT 1346 offer the user the option to reply to this kind of message. 1348 4.9 Notification Messages 1350 VPIM delivery status notification messages (4.6.2) MUST be sent to 1351 the originator of the message when any form of non-delivery of the 1352 subject message or its components occurs. These error messages must 1353 be sent to the Mail From (5.1.2) if available (same as the return 1354 path (4.2.6) if present), otherwise, the From (4.2.1) address may be 1355 used. 1357 VPIM Receipt Notification messages (4.6.3) should be sent to the 1358 sender specified in the Disposition-Notification-To header field 1359 (4.2.16), only after the message has been presented to the recipient 1360 or if the message has somehow been disposed of without being 1361 presented to the recipient (e.g. if it were deleted before playing 1362 it). 1364 VPIM Notification messages may be positive or negative, and can 1365 indicate delivery at the server or receipt by the client. However, 1366 the notification MUST be contained in a multipart/report container 1367 (4.6.1) and SHOULD contain a spoken error message. 1369 If a VPIM system receives a message with contents that are not 1370 understood (see 4.4 & 4.5), its handling is a local matter. A 1371 delivery status notification SHOULD be generated if the message could 1372 not be delivered because of unknown contents (e.g., on traditional 1373 voice processing systems). In some cases, the message may be 1374 delivered (with a positive DSN sent) to a mailbox before the 1375 determination of rendering can be made. 1377 5. Message Transport Protocol 1379 Messages are transported between voice mail machines using the 1380 Internet Extended Simple Mail Transfer Protocol (ESMTP). All 1381 information required for proper delivery of the message is included 1382 in the ESMTP dialog. This information, including the sender and 1383 recipient addresses, is commonly referred to as the message 1384 "envelope". This information is equivalent to the message control 1385 block in many analog voice messaging protocols. 1387 ESMTP is a general-purpose messaging protocol, designed both to send 1388 mail and to allow terminal console messaging. Simple Mail Transport 1389 Protocol (SMTP) was originally created for the exchange of US-ASCII 1390 7-bit text messages. Binary and 8-bit text messages have 1391 traditionally been transported by encoding the messages into a 7-bit 1392 text-like form. [ESMTP] formalized an extension mechanism for SMTP, 1393 and subsequent RFCs have defined 8-bit text networking, command 1394 streaming, binary networking, and extensions to permit the 1395 declaration of message size for the efficient transmission of large 1396 messages such as multi-minute voice mail. 1398 The following sections list ESMTP commands, keywords, and parameters 1399 that are required and those that are optional for conformance to this 1400 profile. 1402 5.1 ESMTP Commands 1404 5.1.1 HELO 1406 Base SMTP greeting and identification of sender. 1408 SEND RULES 1410 This command SHOULD not be sent by compliant systems unless the more- 1411 capable EHLO command is not accepted. It is included for 1412 compatibility with general SMTP implementations. 1414 RECEPTION RULES 1416 Compliant servers MUST implement the HELO command for backward 1417 compatibility. From [SMTP] 1419 5.1.2 MAIL FROM 1421 Originating mailbox. This address contains the mailbox to which 1422 errors should be sent. 1424 SEND RULES 1425 VPIM implementations SHOULD use the same address in the MAIL FROM 1426 command as is used in the From header field. This address is not 1427 necessarily the same as the message Sender listed in the message 1428 header fields if the message was received from a gateway or sent to 1429 an Internet-style mailing list. From [SMTP, ESMTP] 1431 RECEPTION RULES 1433 The MAIL FROM address SHOULD be stored in the local message store for 1434 the purposes of generating a delivery status notification to the 1435 originator. The address indicated in the MAIL FROM command SHOULD be 1436 passed as a local system parameter or placed in a Return-Path: line 1437 inserted at the beginning of a VPIM message. From [HOSTREQ] 1439 Since delivery status notifications MUST be sent to the MAIL FROM 1440 address, the use of the null address ("<>") is often used to prevent 1441 looping of messages. This null address MAY be used to note that a 1442 particular message has no return path (e.g. a telephone answer 1443 message). From [SMTP] 1445 5.1.3 RCPT TO 1447 Recipient's mailbox. The parameter to this command contains only the 1448 address to which the message should be delivered for this 1449 transaction. It is the set of addresses in one or more RCPT TO 1450 commands that are used for mail routing. From [SMTP, ESMTP] 1452 Note: In the event that multiple transport connections to multiple 1453 destination machines are required for the same message, the set of 1454 addresses in a given transport connection may not match the list of 1455 recipients in the message header fields. 1457 5.1.4 DATA 1459 Initiates the transfer of message data. Support for this command is 1460 required. Compliant implementations MUST implement the SMTP DATA 1461 command for backwards compatibility. From [SMTP] 1463 5.1.5 TURN 1465 Requests a change-of-roles, that is, the client that opened the 1466 connection offers to assume the role of server for any mail the 1467 remote machine may wish to send. Because SMTP is not an 1468 authenticated protocol, the TURN command presents an opportunity to 1469 improperly fetch mail queued for another destination. Compliant 1470 implementations SHOULD NOT implement the TURN command. From [SMTP] 1472 5.1.6 QUIT 1474 Requests that the connection be closed. If accepted, the remote 1475 machine will reset and close the connection. Compliant 1476 implementations MUST implement the QUIT command. From [SMTP] 1478 5.1.7 RSET 1480 Resets the connection to its initial state. Compliant 1481 implementations MUST implement the RSET command. From [SMTP] 1483 5.1.8 VRFY 1485 Requests verification that this node can reach the listed recipient. 1486 While this functionality is also included in the RCPT TO command, 1487 VRFY allows the query without beginning a mail transfer transaction. 1488 This command is useful for debugging and tracing problems. Compliant 1489 implementations MAY implement the VRFY command. From [SMTP] 1491 (Note that the implementation of VRFY may simplify the guessing of a 1492 recipient's mailbox or automated sweeps for valid mailbox addresses, 1493 resulting in a possible reduction in privacy. Various implementation 1494 techniques may be used to reduce the threat, such as limiting the 1495 number of queries per session.) From [SMTP] 1497 5.1.9 EHLO 1499 The enhanced mail greeting that enables a server to announce support 1500 for extended messaging options. The extended messaging modes are 1501 discussed in subsequent sections of this document. Compliant 1502 implementations MUST implement the ESMTP command and return the 1503 capabilities indicated later section 5. From [ESMTP] 1505 5.1.10 BDAT 1507 The BDAT command provides a higher efficiency alternative to the 1508 earlier DATA command, especially for voice. The BDAT command provides 1509 for native binary transport of messages. Compliant implementations 1510 SHOULD support binary transport using the BDAT command.[BINARY] 1512 5.2 ESMTP Keywords 1514 The following ESMTP keywords indicate extended features useful for 1515 voice messaging. 1517 5.2.1 PIPELINING 1519 The "PIPELINING" keyword indicates ability of the receiving server to 1520 accept new commands before issuing a response to the previous 1521 command. Pipelining commands dramatically improves performance by 1522 reducing the number of round-trip packet exchanges and makes it 1523 possible to validate all recipient addresses in one operation. 1524 Compliant implementations SHOULD support the command pipelining 1525 indicated by this keyword. From [PIPE] 1527 5.2.2 SIZE 1529 The "SIZE" keyword provides a mechanism by which the SMTP server can 1530 indicate the maximum size message supported. Compliant servers MUST 1531 provide size extension to indicate the maximum size message that can 1532 be accepted. Clients SHOULD NOT send messages larger than the size 1533 indicated by the server. Clients SHOULD advertise SIZE= when sending 1534 messages to servers that indicate support for the SIZE extension. 1535 From [SIZE] 1537 5.2.3 CHUNKING 1539 The "CHUNKING" keyword indicates that the receiver will support the 1540 high-performance binary transport mode. Note that CHUNKING can be 1541 used with any message format and does not imply support for binary 1542 encoded messages. Compliant implementations MAY support binary 1543 transport indicated by this capability. From [BINARY] 1545 5.2.4 BINARYMIME 1547 The "BINARYMIME" keyword indicates that the SMTP server can accept 1548 binary encoded MIME messages. Compliant implementations MAY support 1549 binary transport indicated by this capability. Note that support for 1550 this feature requires support of CHUNKING. From [BINARY] 1552 5.2.5 DSN 1554 The "DSN" keyword indicates that the SMTP server will accept explicit 1555 delivery status notification requests. Compliant implementations 1556 MUST support the delivery notification extensions in [DRPT]. 1558 5.2.6 ENHANCEDSTATUSCODES 1560 The "ENHANCEDSTATUSCODES" keyword indicates that an SMTP server 1561 augments its responses with the enhanced mail system status codes 1562 [CODES]. These codes can then be used to provide more informative 1563 explanations of error conditions, especially in the context of the 1564 delivery status notification format defined in [DSN]. Compliant 1565 implementations SHOULD support this capability. From [STATUS] 1567 5.3 ESMTP Parameters - MAIL FROM 1569 5.3.1 BINARYMIME 1571 The current message is a binary encoded MIME messages. Compliant 1572 implementations SHOULD support binary transport indicated by this 1573 parameter. From [BINARY] 1575 5.3.2 RET 1577 The RET parameter indicates whether the content of the message should 1578 be returned. Compliant systems SHOULD honor a request for returned 1579 content. From [DRPT] 1581 5.3.3 ENVID 1583 The ENVID keyword of the SMTP MAIL command is used to specify an 1584 "envelope identifier" to be transmitted along with the message and 1585 included in any DSNs issued for any of the recipients named in this 1586 SMTP transaction. The purpose of the envelope identifier is to allow 1587 the sender of a message to identify the transaction for which the DSN 1588 was issued. Compliant implementations MAY use this parameter. From 1589 [DRPT] 1591 5.4 ESMTP Parameters - RCPT TO 1593 5.4.1 NOTIFY 1595 The NOTIFY parameter indicates the conditions under which a delivery 1596 report should be sent. Compliant implementations MUST honor this 1597 request. From [DRPT] 1599 5.4.2 ORCPT 1601 The ORCPT keyword of the RCPT command is used to specify an 1602 "original" recipient address that corresponds to the actual recipient 1603 to which the message is to be delivered. If the ORCPT esmtp-keyword 1604 is used, it MUST have an associated esmtp-value, which consists of 1605 the original recipient address. Compliant implementations MAY use 1606 this parameter. From [DRPT] 1608 5.5 ESMTP - SMTP Downgrading 1610 The ESMTP extensions suggested or required for conformance to VPIM 1611 fall into two categories. The first category includes features which 1612 increase the efficiency of the transport system such as SIZE, 1613 BINARYMIME, and PIPELINING. In the event of a downgrade to a less 1614 functional transport system, these features can be dropped with no 1615 functional change to the sender or recipient. 1617 The second category of features is transport extensions in support of 1618 new functions. DSN and EnhancedStatusCodes provide essential 1619 improvements in the handling of delivery status notifications to 1620 bring email to the level of reliability expected of Voice Mail. To 1621 ensure a consistent level of service across an intranet or the global 1622 Internet, it is essential that VPIM compliant ESMTP support the ESMTP 1623 DSN extension at all hops between a VPIM originating system and the 1624 recipient system. In the situation where a `downgrade' is unavoidable 1625 a relay hop may be forced (by the next hop) to forward a VPIM message 1626 without the ESMTP request for positive delivery status notification. 1627 It is RECOMMENDED that the downgrading system should continue to 1628 attempt to deliver the message, but MUST send an appropriate delivery 1629 notification to the originator, e.g. the message left an ESMTP host 1630 and was sent (unreliably) via SMTP. 1632 6. Directory Address Resolution 1634 It is the responsibility of a VPIM system to provide the fully- 1635 qualified domain name (FQDN) of the recipient based on the address 1636 entered by the user (if the entered address is not already a FQDN). 1637 This would typically be an issue on systems that offered only a 1638 telephone user interface. The mapping of the dialed target number to 1639 a routable FQDN address allowing delivery to the destination system 1640 can be accomplished through implementation-specific means. 1642 To facilitate a local dial-by-name cache, an implementation may wish 1643 to populate local directories with the first and last names, as well 1644 as the address information extracted from received messages. It is 1645 mandated that only address information from vCard attachments to VPIM 1646 messages be used to populate such a directory when the vCard is 1647 available. Addresses or names parsed from the header fields of VPIM 1648 messages SHOULD NOT be used to populate directories as it only 1649 provides partial data. Alternatively, bilateral agreements could be 1650 made to allow the bulk transfer of vCards between systems. 1652 7. Management Protocols 1654 The Internet protocols provide a mechanism for the management of 1655 messaging systems, from the management of the physical network 1656 through the management of the message queues. SNMP should be 1657 supported on a compliant message machine. 1659 7.1 Network Management 1661 The digital interface to the VM and the TCP/IP protocols MAY be 1662 managed. MIB II MAY be implemented to provide basic statistics and 1663 reporting of TCP and IP protocol performance. [MIB II] 1665 8. Conformance Requirements 1667 VPIM is a messaging application which must be supported in several 1668 environments and be supported on differing devices. These 1669 environments include traditional voice processing systems, desktop 1670 voice messaging systems, store and forward relays, and protocol 1671 translation gateways. 1673 In order to accommodate all environments, this document defines two 1674 areas of conformance: transport and content. 1676 Transport conformant systems will pass VPIM messages in a store and 1677 forward manner with assured delivery notifications and without the 1678 loss of information. It is expected that most store and forward 1679 Internet mail based messaging systems will be VPIM transport 1680 compliant. 1682 Content conformant systems will generate and interpret VPIM messages. 1683 Conformance in the generation of VPIM messages indicates that the 1684 restrictions of this profile are honored. Only contents specified in 1685 this profile or extensions agreed to by bilateral agreement may be 1686 sent. Conformance in the interpretation of VPIM messages indicates 1687 that all VPIM content types and constructs can be received; that all 1688 mandatory VPIM content types can be decoded and presented to the 1689 recipient in an appropriate manner; and that any unrenderable 1690 contents result in the appropriate notification. 1692 A summary of the compliance requirements is contained in Appendix A. 1694 VPIM end systems are expected to be both transport and content 1695 conformant. They should generate conforming content, reliably send 1696 it to the next hop system, receive a message, decode the message and 1697 present it to the user. Voice messaging systems and protocol 1698 conversion gateways are considered end systems. 1700 Relay systems are expected to be transport compliant in order to 1701 receive and send conforming messages. However, they must also create 1702 VPIM conforming delivery status notifications in the event of 1703 delivery problems. 1705 Desktop Email clients that support VPIM and are expected to be 1706 content conformant. Desktop email clients use various protocols and 1707 API's for exchanging messages with the local message store and 1708 message transport system. While these clients may benefit from VPIM 1709 transport capabilities, specific client-server requirements are out- 1710 of-scope for this document. 1712 9. Security Considerations 1714 9.1 General Directive 1716 This document is a profile of existing Internet mail protocols. To 1717 maintain interoperability with Internet mail, any security to be 1718 provided should be part of the Internet security infrastructure, 1719 rather than a new mechanism or some other mechanism outside of the 1720 Internet infrastructure. 1722 9.2 Threats and Problems 1724 Both Internet mail and voice messaging have their own set of threats 1725 and countermeasures. As such, this specification does not create any 1726 security issues not already existing in the profiled Internet mail 1727 and voice mail protocols themselves. This section attends only to 1728 the set of additional threats that ensue from integrating the two 1729 services. 1731 9.2.1 Spoofed sender 1733 The actual sender of the voice message might not be the same as that 1734 specified in the Sender or From header fields of the message content 1735 header fields or the MAIL FROM address from the SMTP envelope. In a 1736 tightly constrained environment, sufficient physical and software 1737 controls may be able to ensure prevention of this problem. In 1738 addition, the recognition of the sender's voice may provide 1739 confidence of the sender's identity irrespective of that specified in 1740 Sender or From. It should be recognized that SMTP implementations do 1741 not provide inherent authentication of the senders of messages, nor 1742 are sites under obligation to provide such authentication. 1744 9.2.2 Unsolicited voice mail 1746 Assigning an Internet mail address to a voice mailbox opens the 1747 possibility of receiving unsolicited messages (either text or voice 1748 mail). Traditionally voice mail systems operated in closed 1749 environments and were not susceptible to unknown senders. Voice mail 1750 users have a higher expectation of mailbox privacy and may consider 1751 such messages as a security breach. Many Internet mail systems are 1752 choosing to block all messages from unknown sources in an attempt to 1753 curb this problem. 1755 9.2.3 Message disclosure 1757 Users of voice messaging systems have an expectation of a level of 1758 message privacy that is higher than the level provided by Internet 1759 mail without security enhancements. This expectation of privacy by 1760 users SHOULD be preserved as much as possible. 1762 9.3 Security Techniques 1764 Sufficient physical and software control may be acceptable in 1765 constrained environments. Further, the profile specified in this 1766 document does not in any way preclude the use of any Internet object 1767 or channel security protocol to encrypt, authenticate, or non- 1768 repudiate the messages. 1770 10. References 1772 [8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E., D. Crocker, 1773 "SMTP Service Extension for 8bit-MIMEtransport" RFC 1426, United 1774 Nations University, Innosoft International, Inc., Dover Beach 1775 Consulting, Inc., Network Management Associates, Inc., The Branch 1776 Office, February 1993. 1778 [ADPCM] G. Vaudreuil and G. Parsons, "Toll Quality Voice - 32 kbit/s 1779 ADPCM: MIME Sub-type Registration", RFC 2422, September 1998. 1781 [AMIS-A] Audio Messaging Interchange Specifications (AMIS) - Analog 1782 Protocol Version 1, Issue 2, February 1992. 1784 [AMIS-D] Audio Messaging Interchange Specifications (AMIS) - Digital 1785 Protocol Version 1, Issue 3 August 1993. 1787 [BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of 1788 Large and Binary MIME Messages", RFC 1830, October 1995. 1790 [CODES] Vaudreuil, G. "Enhanced Mail System Status Codes", RFC 1893, 1791 01/15/1996. 1793 [MIMEDIR] F. Dawson, T. Howes, & M. Smith, "A MIME Content-Type for 1794 Directory Information", RFC 2425 September 1998 1796 [DISP] R. Troost and S. Dorner, Communicating Presentation Information 1797 in Internet Messages: The Content-Disposition Header, RFC 2183, 1798 August 1997 1800 [DNS1] Mockapetris, P., "Domain names - implementation and 1801 specification", RFC1035, Nov 1987. 1803 [DNS2] Mockapetris, P., "Domain names - concepts and facilities", RFC 1804 1034, Nov 1987. 1806 [DRPT] Moore, K. "SMTP Service Extensions for Delivery Status 1807 Notifications", RFC 1891, 01/15/1996 1809 [DSN] Moore, K., Vaudreuil, G., "An Extensible Message Format for 1810 Delivery Status Notifications", RFC 1894, 01/15/1996. 1812 [DUR] G. Parsons and G. Vaudreuil, "Content Duration MIME Header 1813 Definition", RFC 2424, September 1998. 1815 [E164] CCITT Recommendation E.164 (1991), Telephone Network and ISDN 1816 Operation, Numbering, Routing and Mobile Service - Numbering Plan 1817 for the ISDN Era. 1819 [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, 1820 "SMTP Service Extensions" RFC 1869, United Nations University, 1821 Innosoft International, Inc., Dover Beach Consulting, Inc., Network 1822 Management Associates, Inc., The Branch Office, November 1995. 1824 [G726] CCITT Recommendation G.726 (1990), General Aspects of Digital 1825 Transmission Systems, Terminal Equipment - 40, 32, 24,16 kbit/s 1826 Adaptive Differential Pulse Code Modulation (ADPCM). 1828 [HOSTREQ] Braden, R., "Requirements for Internet Hosts -- Application 1829 and Support", STD 3, RFC 1123, October 1989. 1831 [LANG] Alvestrand,H., "Tags for the Identification of Languages", RFC 1832 1766, Mar 1995 1834 [MDN] Fajman, Roger, "An Extensible Message Format for Message 1835 Disposition Notifications" RFC 2298, March 1998 1837 [MIB II] M. Rose, "Management Information Base for Network Management of 1838 TCP/IP-based internets: MIB-II", RFC 1158, May 1990. 1840 [MIME1] N. Freed and N. Borenstein, "Multipurpose Internet Mail 1841 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 1842 2045, Innosoft, First Virtual, Nov 1996. 1844 [MIME2] N. Freed and N. Borenstein, "Multipurpose Internet Mail 1845 Extensions (MIME) Part Two: Media Types ", RFC 2046, Innosoft, First 1846 Virtual, Nov 1996. 1848 [MIME3] K. Moore, "Multipurpose Internet Mail Extensions (MIME) Part 1849 Three: Message Header Extensions for Non-ASCII Text ", RFC 2047, 1850 University of Tennessee, Nov 1996. 1852 [MIME4] N. Freed, J. Klensin and J. Postel, "Multipurpose Internet Mail 1853 Extensions (MIME) Part Four: Registration Procedures", RFC 2048, 1854 Innosoft, MCI, ISI, Nov 1996. 1856 [MIME5] N. Freed and N. Borenstein, "Multipurpose Internet Mail 1857 Extensions (MIME) Part Five: Conformance Criteria and Examples ", 1858 RFC 2049, Innosoft, First Virtual, Nov 1996. 1860 [PIPE] Freed, N., Cargille, A., "SMTP Service Extension for Command 1861 Pipelining" RFC 1854, October 1995. 1863 [REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the 1864 Reporting of Mail System Administrative Messages", RFC 1892, 1865 01/15/1996. 1867 [REQ] S. Bradner, "Key words for use in RFCs to Indicate Requirement 1868 Levels", RFC 2119, March 1997. 1870 [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text 1871 Messages", STD 11, RFC 822, UDEL, August 1982. 1873 [SIZE] Klensin, J, Freed, N., Moore, K, "SMTP Service Extensions for 1874 Message Size Declaration" RFC 1870, United Nations University, 1875 Innosoft International, Inc., November 1995. 1877 [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 1878 USC/Information Sciences Institute, August 1982. 1880 [STATUS] Freed, N. "SMTP Service Extension for Returning Enhanced Error 1881 Codes", RFC 2034, 10/30/1996. 1883 [TIFF-F] G. Parsons and J. Rafferty, "Tag Image File Format: 1884 Application F", RFC 2306 , March 1998. 1886 [TIFFREG] G. Parsons, J. Rafferty & S. Zilles, "Tag Image File Format: 1887 image/tiff - MIME sub-type registraion", RFC 2302, March 1998. 1889 [V-MSG] G. Vaudreuil and G. Parsons, "VPIM Voice Message: MIME Sub-type 1890 Registration", RFC 2022, September 1998. 1892 [VCARD] Dawson, Frank, Howes, Tim, "vCard MIME Directory Profile" RFC 1893 2426, September 1998. 1895 [VPIM1] Vaudreuil, Greg, "Voice Profile for Internet Mail", RFC 1911, 1896 Feb 1996. 1898 [VPIM2] Vaudreuil, Greg, Parsons, Glen, "Voice Profile for Internet 1899 Mail, Version 2", RFC 2421, September 1998. 1901 [X.400] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021 1902 and RFC 822", RFC 1327, May 1992. 1904 11. Acknowledgments 1906 The authors would like to offer a special thanks to the Electronic 1907 Messaging Association (EMA), especially the members of the Voice 1908 Messaging Committee and the VPIM Work Group, for their support of the 1909 VPIM specification and the efforts they have made to ensure its 1910 success. 1912 The EMA hosts the VPIM web page at http://www.ema.org/vpim. 1914 12. Copyright Notice 1916 "Copyright (C) The Internet Society (1999). All Rights Reserved. 1918 This document and translations of it may be copied and furnished to 1919 others, and derivative works that comment on or otherwise explain it 1920 or assist in its implementation may be prepared, copied, published 1921 and distributed, in whole or in part, without restriction of any 1922 kind, provided that the above copyright notice and this paragraph are 1923 included on all such copies and derivative works. However, this 1924 document itself may not be modified in any way, such as by removing 1925 the copyright notice or references to the Internet Society or other 1926 Internet organizations, except as needed for the purpose of 1927 developing Internet standards in which case the procedures for 1928 copyrights defined in the Internet Standards process must be 1929 followed, or as required to translate it into languages other than 1930 English. 1932 The limited permissions granted above are perpetual and will not be 1933 revoked by the Internet Society or its successors or assigns. 1935 This document and the information contained herein is provided on an 1936 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1937 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1938 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1939 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1940 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 1942 13. Authors' Addresses 1944 Glenn W. Parsons 1945 Nortel Networks 1946 P.O. Box 3511, Station C 1947 Ottawa, ON K1Y 4H7 1948 Canada 1949 Phone: +1-613-763-7582 1950 Fax: +1-613-763-4461 1951 Glenn.Parsons@NortelNetworks.com 1953 Gregory M. Vaudreuil 1954 Lucent Technologies 1955 7291 Williamson Rd 1956 Dallas, TX 75214 1957 United States 1958 Phone/Fax: +1-972-733-2722 1959 GregV@Lucent.Com 1961 14. Appendix A - VPIM Requirements Summary 1963 The following table summarizes the profile of VPIM version 2 detailed 1964 in this document. Since in many cases it is not possible to simplify 1965 the qualifications for supporting each feature this appendix is 1966 informative. The reader is recommended to read the complete 1967 explanation of each feature in the referenced section. The text in 1968 the previous sections shall be deemed authoritative if any item in 1969 this table is ambiguous. 1971 The conformance table is separated into various columns: 1973 Feature - name of protocol feature (note that the indenting 1974 indicates a hierarchy of conformance, i.e. the 1975 conformance of a lower feature is only relevant if there 1976 is conformance to the higher feature) 1978 Section - reference section in main text of this document 1980 Area - conformance area to which each feature applies: 1981 C - content 1982 T - transport 1984 Status - whether the feature is mandatory, optional, or prohibited. 1985 The key words used in this table are to be interpreted as described 1986 in [REQ], though the following list gives a quick overview of the 1987 different degrees of feature conformance: 1988 Must - mandatory 1989 Should - required in the absence of a compelling 1990 need to omit. 1991 May - optional 1992 Should not - prohibited in the absence of a compelling 1993 need. 1994 Must not - prohibited 1996 Footnote - special comment about conformance for a particular 1997 feature 1998 VPIM version 2 Conformance 1999 | | | | |S| | 2000 | | | | | |H| |F 2001 | | | | | |O|M|o 2002 | | | |S| |U|U|o 2003 | | | |H| |L|S|t 2004 | |A|M|O| |D|T|n 2005 | |R|U|U|M| | |o 2006 | |E|S|L|A|N|N|t 2007 | |A|T|D|Y|O|O|t 2008 FEATURE |SECTION | | | | |T|T|e 2009 -------------------------------------------|----------|-|-|-|-|-|-|- 2010 | | | | | | | | 2011 Message Addressing Formats: | | | | | | | | 2012 Use DNS host names |4.1 |C|x| | | | | 2013 Use only numbers in mailbox IDs |4.1.1 |C| |x| | | | 2014 Use alpha-numeric mailbox IDs |4.1.1 |C| | |x| | | 2015 Support of postmaster@domain |4.1.2 |C|x| | | | | 2016 Support of non-mail-user@domain |4.1.2 |C| |x| | | | 2017 Support of distribution lists |4.1.3 |C| |x| | | | 2018 | | | | | | | | 2019 Message Header Fields: | | | | | | | | 2020 Encoding outbound messages | | | | | | | | 2021 From |4.2.1 |C|x| | | | | 2022 Addition of text name |4.2.1 |C| |x| | | | 2023 To |4.2.2 |C| |x| | | |1 2024 cc |4.2.3 |C| |x| | | |1 2025 Date |4.2.4 |C|x| | | | | 2026 Sender |4.2.5 |C| | |x| | | 2027 Return-Path |4.2.6 |C| | | |x| | 2028 Message-id |4.2.7 |C|x| | | | | 2029 Reply-To |4.2.8 |C| | | |x| | 2030 Received |4.2.9|C|x| | | | | 2031 MIME Version: 1.0 (Voice 2.0) |4.2.10 |C| |x| | | | 2032 Content-Type |4.2.11 |C|x| | | | | 2033 Content-Transfer-Encoding |4.2.12 |C|x| | | | | 2034 Sensitivity |4.2.13 |C| | |x| | | 2035 Importance |4.2.14 |C| | |x| | | 2036 Subject |4.2.15|C| |x| | | | 2037 Disposition-notification-to |4.2.16|C| | |x| | | 2038 Disposition-notification-options |4.2.17 |C| | |x| | | 2039 Other Headers |4.2 |C| | |x| | | 2040 | | | | | | | | 2041 | | | | |S| | 2042 | | | | | |H| |F 2043 | | | | | |O|M|o 2044 | | | |S| |U|U|o 2045 | | | |H| |L|S|t 2046 | |A|M|O| |D|T|n 2047 | |R|U|U|M| | |o 2048 | |E|S|L|A|N|N|t 2049 | |A|T|D|Y|O|O|t 2050 FEATURE |SECTION | | | | |T|T|e 2051 -------------------------------------------|----------|-|-|-|-|-|-|- 2052 Detection & Decoding inbound messages | | | | | | | | 2053 From |4.2.1 |C|x| | | | | 2054 Present text personal name |4.2.1 |C| | |x| | | 2055 To |4.2.2 |C|x| | | | | 2056 cc |4.2.3 |C| | |x| | | 2057 Date |4.2.4 |C|x| | | | | 2058 Conversion of Date to local time |4.2.4 |C| |x| | | | 2059 Sender |4.2.5 |C| | |x| | | 2060 Return-Path |4.2.6 |C| |x| | | | 2061 Message ID |4.2.7 |C|x| | | | | 2062 Reply-To |4.2.8 |C| | |x| | | 2063 Received |4.2.9 |C| | |x| | | 2064 MIME Version: 1.0 (Voice 2.0) |4.2.10 |C| |x| | | | 2065 Content Type |4.2.11 |C|x| | | | | 2066 Content-Transfer-Encoding |4.2.12 |C|x| | | | | 2067 Sensitivity |4.2.13 |C|x| | | | |2 2068 Importance |4.2.14 |C| | |x| | | 2069 Subject |4.2.15|C| | |x| | | 2070 Disposition-notification-to |4.2.16|C| | |x| | | 2071 Disposition-notification-options |4.2.17 |C| | | |x| | 2072 Other Headers |4.2 |C|x| | | | |3 2073 | | | | | | | | 2074 Message Content Encoding: | | | | | | | | 2075 Encoding outbound audio/fax contents | | | | | | | | 2076 7BIT |4|C| | | | |x| 2077 8BIT |4|C| | | | |x| 2078 Quoted Printable |4|C| | | | |x| 2079 Base64 |4|C|x| | | | |4 2080 Binary |4|C| |x| | | |5 2081 Detection & decoding inbound messages | | | | | | | | 2082 7BIT |4|C|x| | | | | 2083 8BIT |4|C|x| | | | | 2084 Quoted Printable |4|C|x| | | | | 2085 Base64 |4|C|x| | | | | 2086 Binary |4|C|x| | | | |5 2087 | | | | | | | | 2088 | | | | |S| | 2089 | | | | | |H| |F 2090 | | | | | |O|M|o 2091 | | | |S| |U|U|o 2092 | | | |H| |L|S|t 2093 | |A|M|O| |D|T|n 2094 | |R|U|U|M| | |o 2095 | |E|S|L|A|N|N|t 2096 | |A|T|D|Y|O|O|t 2097 FEATURE |SECTION | | | | |T|T|e 2098 -------------------------------------------|----------|-|-|-|-|-|-|- 2099 Message Content Types: | | | | | | | | 2100 Inclusion in outbound messages | | | | | | | | 2101 Multipart/Voice-Message |4.4.1 |C|x| | | | | 2102 Message/RFC822 |4.4.2 |C| | |x| | | 2103 Text/Directory |4.4.3 |C| |x| | | | 2104 include TEL, EMAIL, VERSION |4.4.3 |C|x| | | | | 2105 include SOUND, N, REV |4.4.3 |C| |x| | | | 2106 only one voice type per level |4.4.3 |C|x| | | | | 2107 Audio/32KADPCM |4.4.4 |C|x| | | | | 2108 Content-Description |4.3.1 |C| | |x| | | 2109 Content-Disposition |4.3.2 |C|x| | | | | 2110 Content-Duration |4.3.3 |C| | |x| | | 2111 Content-Language |4.3.4 |C| | |x| | | 2112 Image/tiff; application=faxbw |4.4.5|C| | |x| | | 2113 Audio/* or Image/* (other encodings) |4.4.6|C| | |x| | | 2114 Other contents |4.5 |C| | | | |x| 2115 Multipart/Mixed |4.5.1 |C| | |x| | | 2116 Text/plain |4.5.2 |C| | | |x| | 2117 Multipart/Report |4.6.1 |C|x| | | | | 2118 human-readable part is voice |4.6.1 |C| |x| | | | 2119 human-readable part is text |4.6.1 |C| | |x| | | 2120 Message/delivery-status |4.6.2 |C|x| | | | | 2121 Message/disposition-notification |4.6.3 |C| |x| | | | 2122 Other contents |4.5 |C| | |x| | |6 2123 | | | | | | | | 2124 Detection & decoding in inbound messages | | | | | | | | 2125 Multipart/Voice-Message |4.4.1 |C|x| | | | | 2126 Message/RFC822 |4.4.2 |C|x| | | | | 2127 Text/Directory |4.4.3 |C| |x| | | | 2128 recognize TEL, EMAIL, VERSION |4.4.3 |C|x| | | | | 2129 recognize SOUND, N, REV |4.4.3 |C| |x| | | | 2130 Audio/32KADPCM |4.4.4 |C|x| | | | | 2131 Content-Description |4.3.1 |C| | |x| | | 2132 Content-Disposition |4.3.2 |C| |x| | | | 2133 Content-Duration |4.3.3 |C| | |x| | | 2134 Content-Langauge |4.3.4 |C| | |x| | | 2135 Image/tiff; application=faxbw |4.4.5|C| |x| | | | 2136 send NDN if unable to render |4.4.5|C|| |x | | |7 2137 Audio/* or Image/* (other encodings) |4.4.6|C| | |x| | | 2138 Other contents |4.5 |C| | | |x| | 2139 Multipart/Mixed |4.5.1 |C|x| | | | | 2140 Text/plain |4.5.2 |C|x| | | | | 2141 send NDN if unable to render |4.5.2 |C|x| | | | | 2142 | | | | | |S| | 2143 | | | | | |H| |F 2144 | | | | | |O|M|o 2145 | | | |S| |U|U|o 2146 | | | |H| |L|S|t 2147 | |A|M|O| |D|T|n 2148 | |R|U|U|M| | |o 2149 | |E|S|L|A|N|N|t 2150 | |A|T|D|Y|O|O|t 2151 FEATURE |SECTION | | | | |T|T|e 2152 ------------------------------------------|-----------|-|-|-|-|-|-|- 2153 | | | | | | | | 2154 Multipart/Report |4.6.1 |C|x| | | | | 2155 human-readable part is voice |4.6.1 |C| |x| | | | 2156 human-readable part is text |4.6.1 |C|x| | | | | 2157 Message/delivery-status |4.6.2 |C|x| | | | | 2158 Message/disposition-notification |4.6.3 |C| |x| | | | 2159 Other contents |4.5 |C| | |x| | |6 2160 send NDN if unable to render |4.5 |C| |x| | | | 2161 | | | | | | | | 2162 Forwarded Messages | | | | | | | | 2163 use Message/RFC822 construct |4.7 |C| |x| | | | 2164 simulate headers if none available |4.7 |C| |x| | | | 2165 | | | | | | | | 2166 Reply Messages | | | | | | | | 2167 send to Reply-to, else From address |4.8 |C|x| | | | | 2168 send to non-mail-user |4.8 |C| | | |x| | 2169 | | | | | | | | 2170 Notifications | | | | | | | | 2171 use multipart/report format |4.9 |C|x| | | | | 2172 always send error on non-delivery |4.9 |C| |x| | | | 2173 | | | | | | | | 2174 Message Transport Protocol: | | | | | | | | 2175 ESMTP Commands | | | | | | | | 2176 HELO |5.1.1 |T|x| | | | | 2177 MAIL FROM |5.1.2 |T|x| | | | | 2178 support null address |5.1.2 |T|x| | | | | 2179 RCPT TO |5.1.3 |T|x| | | | | 2180 DATA |5.1.4 |T|x| | | | | 2181 TURN |5.1.5 |T| | | | |x| 2182 QUIT |5.1.6 |T|x| | | | | 2183 RSET |5.1.7 |T|x| | | | | 2184 VRFY |5.1.8 |T| | |x| | | 2185 EHLO |5.1.9 |T|x| | | | | 2186 BDAT |5.1.10 |T| | |x| | |5 2187 | | | | |S| | 2188 | | | | | |H| |F 2189 | | | | | |O|M|o 2190 | | | |S| |U|U|o 2191 | | | |H| |L|S|t 2192 | |A|M|O| |D|T|n 2193 | |R|U|U|M| | |o 2194 | |E|S|L|A|N|N|t 2195 | |A|T|D|Y|O|O|t 2196 FEATURE |SECTION | | | | |T|T|e 2197 -------------------------------------------|----------|-|-|-|-|-|-|- 2198 | | | | | | | | 2199 ESMTP Keywords & Parameters | | | | | | | | 2200 PIPELINING |5.2.1 |T| |x| | | | 2201 SIZE |5.2.2 |T|x| | | | | 2202 CHUNKING |5.2.3 |T| | |x| | | 2203 BINARYMIME |5.2.4,5.3.1|T| | |x| | | 2204 DSN |5.2.5 |T|x| | | | | 2205 ENHANCEDSTATUSCODES |5.2.6 |T| |x| | | | 2206 RET |5.3.2 |T| |x| | | | 2207 ENVID |5.3.3 |T| | |x| | | 2208 NOTIFY |5.4.1 |T|x| | | | | 2209 ORCPT |5.4.2 |T| | |x| | | 2210 | | | | | | | | 2211 ESMTP-SMTP Downgrading | | | | | | | | 2212 send delivery report upon downgrade |5.5 |T|x| | | | | 2213 | | | | | | | | 2214 Directory Address Resolution | | | | | | | | 2215 provide facility to resolve addresses |6 |C| |x| | | | 2216 use vCards to populate local directory |6 |C| |x| | | |8 2217 use headers to populate local directory |6 |C| | | |x| | 2218 | | | | | | | | 2219 Management Protocols: | | | | | | | | 2220 Network management |7.1 |T| | |x| | | 2221 -------------------------------------------|----------|-|-|-|-|-|-|- 2223 Footnotes: 2225 1. SHOULD leave blank if all recipients are not known or resolvable. 2226 2. If a sensitive message is received by a system that does not 2227 support sensitivity, then it MUST be returned to the originator 2228 with an appropriate error notification. Also, a received 2229 sensitive message MUST NOT be forwarded to anyone. 2230 3. If the additional header fields are not understood they MAY be 2231 ignored 2232 4. When binary transport is not available 2233 5. When binary transport is available 2234 6. Other un-profiled contents must only be sent by bilateral 2235 agreement. 2237 7. If the content cannot be presented or acknowledged in some form, 2238 the entire message MUST be returned with a negative delivery 2239 status notification. 2240 8. When the vCard is present in a message 2242 15. Appendix B - Example Voice Messages 2244 The following message is a full-featured message addressed to two 2245 recipients. The message includes the sender's spoken name and a short 2246 speech segment. The message is marked as important and private. 2248 To: +19725551212@vm1.mycompany.com 2249 To: +16135551234@VM1.mycompany.com 2250 From: "Parsons, Glenn" <12145551234@VM2.mycompany.com> 2251 Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT) 2252 MIME-Version: 1.0 (Voice 2.0) 2253 Content-type: Multipart/Voice-Message; Version=2.0; 2254 Boundary="MessageBoundary" 2255 Content-Transfer-Encoding: 7bit 2256 Message-ID: 123456789@VM2.mycompany.com 2257 Sensitivity: Private 2258 Importance: High 2260 --MessageBoundary 2261 Content-type: Audio/32KADPCM 2262 Content-Transfer-Encoding: Base64 2263 Content-Disposition: inline; voice=Originator-Spoken-Name 2264 Content-Language: en-US 2265 Content-ID: part1@VM2-4321 2267 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 2268 (This is a sample of the base-64 Spoken Name data) 2269 fgdhgddlkgpokpeowrit09== 2271 --MessageBoundary 2272 Content-type: Audio/32KADPCM 2273 Content-Transfer-Encoding: Base64 2274 Content-Description: Brand X Voice Message 2275 Content-Disposition: inline; voice=Voice-Message; filename=msg1.726 2276 Content-Duration: 25 2278 iIiIiIjMzN3czdze3s7d7fwfHhcvESJVe/4yEhLz8/FOQjVFRERCESL/zqrq 2279 (This is a sample of the base64 message data) zb8tFdLTQt1PXj 2280 u7wjOyRhws+krdns7Rju0t4tLF7cE0K0MxOTOnRW/Pn30c8uHi9== 2282 --MessageBoundary 2283 Content-type: text/directory; charset=us-ascii; profile=vCard 2284 Content-Transfer-Encoding: 7bit 2286 BEGIN:VCARD 2287 N:Parsons;Glenn;;Mr.; 2288 EMAIL;TYPE=INTERNET:+12145551234@VM2.mycompany.com 2289 TEL:+1-217-555-1234 2290 SOUND;TYPE=32KADPCM;ENCODING=URI: CID: 2291 REV:19951031T222710Z 2292 VERSION: 3.0 2293 END:VCARD 2294 --MessageBoundary_ 2296 The following message is a forwarded single segment voice. Both the 2297 forwarded message and the forwarding message contain VCARDs with 2298 spoken names. 2300 To: +12145551212@vm1.mycompany.com 2301 From: "Vaudreuil, Greg" <+19725552345@VM2.mycompany.com> 2302 Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT) 2303 MIME-Version: 1.0 (Voice 2.0) 2304 Content-type: Multipart/Voice-Message; Version=2.0; 2305 Boundary="MessageBoundary" 2306 Content-Transfer-Encoding: 7bit 2307 Message-ID: ABCD-123456789@VM2.mycompany.com 2309 --MessageBoundary 2310 Content-type: Audio/32KADPCM 2311 Content-Transfer-Encoding: Base64 2312 Content-Disposition: inline; voice=Originator-Spoken-Name 2313 Content-Language: en-US 2314 Content-ID: part3@VM2-4321 2316 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 2317 (This is a sample of the base-64 Spoken Name data) 2318 fgdhgd dlkgpokpeowrit09== 2320 --MessageBoundary 2321 Content-type: Audio/32KADPCM 2322 Content-Description: Forwarded Message Annotation 2323 Content-Disposition: inline; voice=Voice-Message 2324 Content-Transfer-Encoding: Base64 2326 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 2327 (This is the voiced introductory remarks encoded in base64) 2328 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW 2329 dlkgpokpeowrit09== 2331 --MessageBoundary 2332 Content-type: Message/RFC822 2333 Content-Transfer-Encoding: 7bit 2335 To: +19725552345@VM2.mycompany.com 2336 From: "Parsons, Glenn, W." <+16135551234@VM1.mycompany.com> 2337 Date: Mon, 26 Aug 93 8:23:10 -0500 (EST) 2338 Content-type: Multipart/Voice-Message; Version=2.0; 2339 Boundary="MessageBoundary2" 2340 Content-Transfer-Encoding: 7bit 2341 MIME-Version: 1.0 (Voice 2.0) 2342 --MessageBoundary2 2343 Content-type: Audio/32KADPCM 2344 Content-Transfer-Encoding: Base64 2345 Content-Disposition: inline; voice=Originator-Spoken-Name 2346 Content-Language: en-US 2347 Content-ID: part6@VM2-4321 2349 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 2350 (This is a sample of the base-64 Spoken Name data) fgdhgd 2351 dlkgpokpeowrit09== 2353 --MessageBoundary2 2354 Content-type: Audio/32KADPCM 2355 Content-Disposition: inline; voice=Voice-Message 2356 Content-Transfer-Encoding: Base64 2358 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 2359 (This is the original message audio data) fgwersdfmniwrjj 2360 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW 2361 dlkgpokpeowrit09== 2363 --MessageBoundary2 2364 Content-type: text/directory; charset=us-ascii 2365 Content-Transfer-Encoding: 7bit 2367 BEGIN:VCARD 2368 N:Parsons;Glenn;W;Mr.; 2369 EMAIL;TYPE=INTERNET:+16135551234@VM2.mycompany.com 2370 TEL:+1-613-555-1234 2371 SOUND;TYPE=32KADPCM;ENCODING=URI: CID: 2372 REV:19951031T222710Z 2373 END:VCARD 2375 --MessageBoundary2-- 2377 --MessageBoundary 2378 Content-type: text/directory; charset=us-ascii 2379 Content-Transfer-Encoding: 7bit 2381 BEGIN:VCARD 2382 N:Vaudreuil;Greg;;Mr.; 2383 SOUND;TYPE=32KADPCM;ENCODING=URI: CID: 2384 EMAIL;TYPE=INTERNET,VPIM:+19725552345@VM2.mycompany.com 2385 TEL:+1-972-555-2345 2386 REV:19951031T222710Z 2387 VERSION: 3.0 2388 END:VCARD 2390 --MessageBoundary-- 2391 The following example is for a message returned to the sender by a 2392 VPIM gateway at VM1.company.com for a mailbox which does not exist. 2394 Date: Thu, 7 Jul 1994 17:16:05 -0400 2395 From: Mail Delivery Subsystem 2396 Message-Id: <199407072116.RAA14128@vm1.company.com> 2397 Subject: Returned voice message 2398 To: 2175552345@VM2.mycompany.com 2399 MIME-Version: 1.0 (Voice 2.0) 2400 Content-Type: multipart/report; report-type=delivery-status; 2401 boundary="RAA14128.773615765/VM1.COMPANY.COM" 2403 --RAA14128.773615765/VM1.COMPANY.COM 2404 Content-type: Audio/32KADPCM 2405 Content-Description: Spoken Delivery Status Notification 2406 Content-Disposition: inline; voice= Voice-Message-Notification 2407 Content-Transfer-Encoding: Base64 2409 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd 2410 (This is a voiced description of the error in base64) 2411 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW 2412 dlkgpokpeowrit09== 2414 --RAA14128.773615765/VM1.COMPANY.COM 2415 Content-type: message/delivery-status 2417 Reporting-MTA: dns; vm1.company.com 2419 Original-Recipient: rfc822; 2145551234@VM1.mycompany.com 2420 Final-Recipient: rfc822; 2145551234@VM1.mycompany.com 2421 Action: failed 2422 Status: 5.1.1 (User does not exist) 2423 Diagnostic-Code: smtp; 550 Mailbox not found 2424 Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400 2426 --RAA14128.773615765/VM1.COMPANY.COM 2427 content-type: message/rfc822 2429 [original VPIM message goes here] 2431 --RAA14128.773615765/VM1.COMPANY.COM-- 2432 The following example is for a receipt notification sent to the 2433 original sender for a message which has been played. This 2434 delivered VPIM message was received by a corporate gateway and 2435 relayed to a unified mailbox. 2437 Date: Thu, 7 Jul 1994 17:16:05 -0400 2438 From: "Greg Vaudreuil" <22722@vm.company.com> 2439 Message-Id: <199407072116.RAA14128@exchange.company.com> 2440 Subject: Voice message played 2441 To: 2175552345@VM2.mycompany.com 2442 MIME-Version: 1.0 (Voice 2.0) 2443 Content-Type: multipart/report; 2444 Report-type=disposition-notification; 2445 Boundary="RAA14128.773615765/EXCHANGE.COMPANY.COM" 2447 --RAA14128.773615765/EXCHANGE.COMPANY.COM 2448 Content-type: Audio/32KADPCM 2449 Content-Description: Spoken Disposition Notification 2450 Content-Disposition: inline; voice= Voice-Message-Notification 2451 Content-Transfer-Encoding: Base64 2453 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd 2454 (Voiced description of the disposition action in base64) 2455 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW 2456 dlkgpokpeowrit09== 2458 --RAA14128.773615765/EXCHANGE.COMPANY.COM 2459 Content-type: message/disposition-notification 2461 Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0) 2463 Original-Recipient: rfc822;22722@vm.company.com 2464 Final-Recipient: rfc822;Greg.Vaudreuil@foomail.company.com 2465 Original-Message-ID: <199509192301.12345@vm2.mycompany.com > 2466 Disposition: manual-action/MDN-sent-automatically; displayed 2468 --RAA14128.773615765/EXCHANGE.COMPANY.COM 2469 Content-type: message/rfc822 2471 [original VPIM message goes here] 2473 --RAA14128.773615765/EXCHANGE.COMPANY.COM-- 2475 16. Appendix C - Example Error Voice Processing Error Codes 2477 The following common voice processing errors and their corresponding 2478 status codes are given as examples. Text after the error codes are 2479 intended only for reference to describe the error code. 2480 Implementations should provide implementation specific informative 2481 comments after the error code rather than the text below. 2483 Error condition RFC 1893 Error codes 2484 ----------------------------- -------------------------------- 2486 Analog delivery failed 4.4.0 Persistent connection error 2487 because remote system is busy - other 2489 Analog delivery failed 4.4.1 Persistent protocol error 2490 because remote system is - no answer from host 2491 ring-no-answer 2493 Remote system did not answer 5.5.5 Permanent protocol error 2494 AMIS-Analog handshake ("D" in - wrong version 2495 response to "C" at connect 2496 time) 2498 Mailbox does not exist 5.1.1 Permanent mailbox error 2499 - does not exist 2501 Mailbox full or over quota 4.2.2 Persistent mailbox error 2502 - full 2504 Disk full 4.3.1 Persistent system error 2505 - full 2507 Command out of sequence 5.5.1 Permanent protocol error 2508 - invalid command 2510 Frame Error 5.5.2 Permanent protocol error 2511 - syntax error 2513 Mailbox does not support FAX 5.6.1 Permanent media error 2514 - not supported 2516 Mailbox does not support TEXT 5.6.1 Permanent media error 2517 - not supported 2519 Sender is not authorized 5.7.1 Permanent security error 2520 - sender not authorized 2522 Message marked private, but 5.3.3 Permanent system error 2523 system is not private capable - not feature capable 2525 17. Appendix D - Example Voice Processing Disposition Types 2527 The following common voice processing disposition conditions and 2528 their corresponding MDN Disposition (which contains the disposition 2529 mode, type and modifier, if applicable) are given as examples. 2530 Implementers should refer to [MDN] for a full description of the 2531 format of message disposition notifications. 2533 Notification event MDN Disposition mode, type & 2534 modifier 2535 ------------------------------ ------------------------------------ 2536 - 2538 Message played by recipient, manual-action/MDN-sent-automatically; 2539 receipt automatically returned displayed 2541 Message deleted from mailbox manual-action/MDN-sent-automatically; 2542 by user without listening deleted 2544 Message cleared when mailbox manual-action/MDN-sent-automatically; 2545 deleted by admin deleted/mailbox-terminated 2547 Message automatically deleted automatic-action/ 2548 when older than administrator MDN-sent-automatically; deleted/ 2549 set threshold expired 2551 Message processed, however manual-action/MDN-sent-automatically; 2552 audio encoding unknown - processed/error 2553 unable to play to user Error: unknown audio encoding 2555 18. Appendix E - IANA Registrations 2557 18.1 vCard EMAIL Type Definition for VPIM 2559 To: ietf-mime-directory@imc.org 2561 Subject: Registration of new parameter for text/directory MIME type 2562 EMAIL 2564 Type name: EMAIL 2566 Type purpose: To specify the electronic mail address for 2567 communication with the object the vCard represents (defined in 2568 [VCARD]). 2570 Type encoding: 8bit 2572 Type value: A single text value. 2574 Type special notes: The type may include the type parameter "TYPE" to 2575 specify the format or preference of the electronic mail address. The 2576 TYPE parameter values previously defined include: "internet" to 2577 indicate an Internet addressing type, "x400" to indicate a X.400 2578 addressing type and "pref" to indicate a preferred-use email address 2579 when more than one is specified. The value of "vpim" is defined to 2580 indicate that the address specified supports VPIM messages. Other 2581 IANA registered address type may also be specified. The default email 2582 type is "internet". A non-standard value may also be specified. 2584 Type example: 2585 EMAIL;TYPE=internet,vpim:jqpublic@xyz.dom1.com 2587 18.2 Voice Content-Disposition Parameter Definition 2589 To: IANA@IANA.ORG 2591 Subject: Registration of new Content-Disposition parameter 2593 Content-Disposition parameter name: voice 2595 Allowable values for this parameter: 2597 Voice-Message - the primary voice message, 2598 Voice-Message-Notification - a spoken delivery notification 2599 or spoken disposition notification, 2600 Originator-Spoken-Name - the spoken name of the originator, 2601 Recipient-Spoken-Name - the spoken name of the recipient if 2602 available to the originator and present if there is ONLY one 2603 recipient, 2604 Spoken-Subject- the spoken subject of the message, typically 2605 spoken by the originator 2607 Description: 2609 In order to distinguish between the various types of audio contents 2610 in a VPIM voice message a new disposition parameter "voice" is 2611 defined with the preceding values to be used as appropriate. Note 2612 that there SHOULD only be one instance of each of these types of 2613 audio contents per message level. Additional instances of a given 2614 type (i.e., parameter value) may occur within an attached forwarded 2615 voice message. 2617 19. Appendix F - Change History: RFC 2421 (VPIM V2) to this Document 2619 The updated profile in this document is based on the implementation 2620 and operational deployment experience of several vendors. The 2621 changes are categorized as general, content, transport and 2622 compliance. They are summarized below: 2624 1. General 2626 - Various editorial updates to improve readability. 2628 - Separated send rules from reception rules. 2630 Clarified the behavior upon reception of unrecognized content types 2631 (eg. originator and recipient should be notified) expected with the 2632 interworking between voice and unified messaging systems. 2634 - added _ Normal_ sensitivity for consistency 2636 - should not use MDN Content-Disp options 2638 - reorganized the content type descriptions 2640 2. Content 2642 - Changed handling of received lines by a gateway to SHOULD 2643 NOT delete in a gateway. In gateways to systems such as AMIS, 2644 it is not possible to preserve this information. It is intended 2645 that such systems be able to claim conformance. 2647 - Removed "ROLE" as a recommended vCard field 2649 - Proposed change of the encoding of spoken name in vCards 2650 from "by-reference" to "inline" will aid "helper application" 2651 based implementations create replies when access to RFC822 2652 headers is not possible. 2654 3. Transport 2656 - None 2658 4. Compliance 2660 - Aligned the table of Appendix A to the requirements in the text. 2662 Outstanding Issues 2664 Should functionality be dropped to progress to Draft Standard since 2665 some features are only Proposed Standard 2666 - v-Card 2668 - DSN 2670 - MDN