idnits 2.17.1 draft-ema-vpim-05.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 42 longer pages, the longest (page 2) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 464 instances of too long lines in the document, the longest one being 3 characters in excess of 72. == There are 4 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 306: '...x named "postmaster" MUST exist on all...' RFC 2119 keyword, line 321: '... this special address MUST send a non-...' RFC 2119 keyword, line 347: '...As a result, recipient information MAY...' RFC 2119 keyword, line 349: '...nsion) then the recipient headers MUST...' RFC 2119 keyword, line 363: '...m. VPIM systems MUST be able to accep...' (135 more instances...) -- The abstract seems to indicate that this document obsoletes RFC1911, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The From address may be used for replies (see 4.6). However, if the From address contains , the user SHOULD not be offered the option to reply, nor should notifications be sent to this address. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: In some cases, a reply message is not possible, such as with a message created by telephone answering (i.e. classic voice mail). In this case, the From field MUST contain the special address non-mail-user@domain (see 4.1.2). The use of a null ESMTP MAIL FROM address SHOULD also be used in this case (see 5.1.2). A receiving VPIM system SHOULD not offer the user the option to reply to this kind of message. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 26, 1996) is 10257 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'MIME' is mentioned on line 227, but not defined == Missing Reference: 'X400' is mentioned on line 575, but not defined == Unused Reference: '8BIT' is defined on line 1301, but no explicit reference was found in the text == Unused Reference: 'AMIS-A' is defined on line 1311, but no explicit reference was found in the text == Unused Reference: 'AMIS-D' is defined on line 1314, but no explicit reference was found in the text == Unused Reference: 'DNS1' is defined on line 1330, but no explicit reference was found in the text == Unused Reference: 'DNS2' is defined on line 1333, but no explicit reference was found in the text == Unused Reference: 'E164' is defined on line 1345, but no explicit reference was found in the text == Unused Reference: 'G726' is defined on line 1354, but no explicit reference was found in the text == Unused Reference: 'MIME3' is defined on line 1378, but no explicit reference was found in the text == Unused Reference: 'MIME5' is defined on line 1386, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1426 (ref. '8BIT') (Obsoleted by RFC 1652) -- Possible downref: Non-RFC (?) normative reference: ref. 'ADPCM' -- Possible downref: Non-RFC (?) normative reference: ref. 'AMIS-A' -- Possible downref: Non-RFC (?) normative reference: ref. 'AMIS-D' ** Obsolete normative reference: RFC 1830 (ref. 'BINARY') (Obsoleted by RFC 3030) ** Obsolete normative reference: RFC 1893 (ref. 'CODES') (Obsoleted by RFC 3463) -- Possible downref: Non-RFC (?) normative reference: ref. 'DIRECTORY' ** Obsolete normative reference: RFC 1806 (ref. 'DISP') (Obsoleted by RFC 2183) ** Obsolete normative reference: RFC 1891 (ref. 'DRPT') (Obsoleted by RFC 3461) ** Obsolete normative reference: RFC 1894 (ref. 'DSN') (Obsoleted by RFC 3464) -- Possible downref: Non-RFC (?) normative reference: ref. 'DUR' -- Possible downref: Non-RFC (?) normative reference: ref. 'E164' ** Obsolete normative reference: RFC 1869 (ref. 'ESMTP') (Obsoleted by RFC 2821) -- Possible downref: Non-RFC (?) normative reference: ref. 'G726' ** Obsolete normative reference: RFC 1766 (ref. 'LANG') (Obsoleted by RFC 3066, RFC 3282) -- Possible downref: Non-RFC (?) normative reference: ref. 'MDN' ** Obsolete normative reference: RFC 1158 (ref. 'MIB II') (Obsoleted by RFC 1213) ** Obsolete normative reference: RFC 2048 (ref. 'MIME4') (Obsoleted by RFC 4288, RFC 4289) ** Obsolete normative reference: RFC 1854 (ref. 'PIPE') (Obsoleted by RFC 2197) ** Obsolete normative reference: RFC 1892 (ref. 'REPORT') (Obsoleted by RFC 3462) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 821 (ref. 'SMTP') (Obsoleted by RFC 2821) -- Possible downref: Non-RFC (?) normative reference: ref. 'TIFF-F' -- Possible downref: Non-RFC (?) normative reference: ref. 'V-MSG' -- Possible downref: Non-RFC (?) normative reference: ref. 'VCARD' ** Obsolete normative reference: RFC 1911 (ref. 'VPIM1') (Obsoleted by RFC 2421, RFC 2422, RFC 2423) Summary: 26 errors (**), 0 flaws (~~), 16 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Greg Vaudreuil 2 Internet Draft Octel Communications 3 Expires in six months Glenn Parsons 4 Obsoletes: RFC 1911 Nortel Technology 5 March 26, 1996 7 Voice Profile for Internet Mail - version 2 9 11 Status of this Memo 13 This document is an Internet Draft. Internet Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its Areas, 15 and its Working Groups. Note that other groups may also distribute 16 working documents as Internet Drafts. 18 Internet Drafts are valid for a maximum of six months and may be 19 updated, replaced, or obsoleted by other documents at any time. It is 20 inappropriate to use Internet Drafts as reference material or to cite 21 them other than as a "work in progress". 23 To learn the current status of any Internet-Draft, please check the 24 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 25 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 26 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 27 ftp.isi.edu (US West Coast). 29 Overview 31 This document profiles Internet mail for voice messaging. It 32 obsoletes RFC 1911 which describes version 1 of the profile. A list 33 of changes from that document are noted in Appendix D. As well, 34 Appendix A summarizes the protocol profiles of this version of VPIM. 36 Please send comments on this document to the EMA VPIM Work Group 37 mailing list: 39 Working Group Summary 41 This profile was not reviewed by an active IETF working group. 42 However, it has been reviewed by the VPIM Work Group of the Electronic 43 Messaging Association (EMA). This work group, which has 44 representatives from most major voice mail vendors, has held an 45 interoperability demonstration between voice messaging vendors and 46 received comments from traditional messaging vendors. 48 Table of Contents 50 1. ABSTRACT ............................................................3 51 2. SCOPE ...............................................................4 52 2.1 Voice Messaging System Limitations ...............................4 53 2.2 Design Goals .....................................................5 54 3. PROTOCOL RESTRICTIONS ...............................................6 55 4. VOICE MESSAGE INTERCHANGE FORMAT ....................................7 56 4.1 Message Addressing Formats .......................................7 57 4.2 Message Header Fields ............................................9 58 4.3 Voice Message Content Types .....................................14 59 4.4 Other Message Content Types .....................................19 60 4.5 Forwarded Messages ..............................................20 61 4.6 Reply Messages ..................................................21 62 5. MESSAGE TRANSPORT PROTOCOL .........................................22 63 5.1 ESMTP Commands ..................................................22 64 5.2 ESMTP Keywords ..................................................24 65 5.3 ESMTP Parameters - MAIL FROM ....................................25 66 5.4 ESMTP Parameters - RCPT TO ......................................25 67 5.5 ESMTP - SMTP Downgrading ........................................26 68 6. DIRECTORY ADDRESS RESOLUTION .......................................26 69 7. IMAP ...............................................................27 70 8. MANAGEMENT PROTOCOLS ...............................................27 71 8.1 Network Management ..............................................27 72 9. CONFORMANCE REQUIREMENTS ...........................................27 73 10. REFERENCES ........................................................28 74 11. SECURITY CONSIDERATION ............................................31 75 12. ACKNOWLEDGMENTS ...................................................31 76 13. AUTHORS' ADDRESSES ................................................31 77 14. APPENDIX A - VPIM REQUIREMENTS SUMMARY ............................32 78 15. APPENDIX B - EXAMPLE VOICE MESSAGES ...............................38 79 16. APPENDIX C _ EXAMPLE ERROR VOICE PROCESSING ERROR CODES ...........42 80 17. APPENDIX D - CHANGE HISTORY: RFC 1911 TO THIS DOCUMENT ............43 81 1. Abstract 83 A class of special-purpose computers has evolved to provide voice 84 messaging services. These machines generally interface to a telephone 85 switch and provide call answering and voice messaging services. 86 Traditionally, messages sent to a non-local machine are transported 87 using analog networking protocols based on DTMF signaling and analog 88 voice playback. As the demand for networking increases, there is a 89 need for a standard high-quality digital protocol to connect these 90 machines. The following document is a profile of the Internet 91 standard MIME and ESMTP protocols for use as a digital voice messaging 92 networking protocol. The profile is referred to as VPIM (Voice Profile 93 for Internet Mail) in this document. 95 This profile is based on earlier work in the Audio Message Interchange 96 Specification (AMIS) group that defined a voice messaging protocol 97 based on X.400 technology. This profile is intended to satisfy the 98 user requirements statement from that earlier work with the industry 99 standard ESMTP/MIME mail protocol infrastructures already used within 100 corporate intranets. This second version of VPIM is based on 101 implementation experience and obsoletes RFC 1911 which describes 102 version 1 of the profile. 104 2. Scope 106 MIME is the Internet multipurpose, multimedia messaging standard. 107 This document explicitly recognizes its capabilities and provides a 108 mechanism for the exchange of various messaging technologies, 109 primarily voice and facsimile. 111 This document specifies a restricted profile of the Internet 112 multimedia messaging protocols for use between voice processing 113 platforms. These platforms have historically been special-purpose 114 computers and often do not have the same facilities normally 115 associated with a traditional Internet Email-capable computer. As a 116 result, VPIM also specifies additional functionality as it is needed. 117 This profile is intended to specify the minimum common set of features 118 to allow interworking between compliant systems. 120 2.1 Voice Messaging System Limitations 122 The following are typical limitations of voice messaging platform 123 which were considered in creating this baseline profile. 125 1) Text messages are not normally received and often cannot be 126 displayed or viewed. They can often be processed only via text-to- 127 speech or text-to-fax features not currently present in many of 128 these machines. 130 2) Voice mail machines usually act as an integrated Message 131 Transfer Agent, Message Store and User Agent. There is no relaying 132 of messages, and RFC 822 header fields may have limited use in the 133 context of the limited messaging features currently deployed. 135 3) VM message stores are generally not capable of preserving the 136 full semantics of an Internet message. As such, use of a voice 137 mail machine for gatewaying is not supported. In particular, 138 storage of recipient lists, "Received" lines, and "Message-ID" may 139 be limited. 141 4) Internet-style distribution/exploder mailing lists are not 142 typically supported. Voice mail machines often implement only 143 local alias lists, with error-to-sender and reply-to-sender 144 behavior. Reply-all capabilities using a CC list is not generally 145 available. 147 5) Error reports must be machine-parsable so that helpful responses 148 can be voiced to users whose only access mechanism is a telephone. 150 6) The voice mail systems generally limit address entry to 16 or 151 fewer numeric characters, and normally do not support alphanumeric 152 mailbox names. Alpha characters are not generally used for mailbox 153 identification as they cannot be easily entered from a telephone 154 terminal. 156 2.2 Design Goals 158 It is a goal of this profile to make as few restrictions and additions 159 to the existing Internet mail protocols as possible while satisfying 160 the requirements for interoperability with current generation voice 161 messaging systems. This goal is motivated by the desire to increase 162 the accessibility to digital messaging by enabling the use of proven 163 existing networking software for rapid development. 165 This specification is intended for use on a TCP/IP network, however, 166 it is possible to use the SMTP protocol suite over other transport 167 protocols. The necessary protocol parameters for such use is outside 168 the scope of this document. 170 This profile is intended to be robust enough to be used in an 171 environment, such as the global Internet with installed-base gateways 172 which do not understand MIME, though typical use is expected to be 173 within corporate intranets. Full functionality, such as reliable 174 error messages and binary transport, will require careful selection of 175 gateways (e.g., via MX records) to be used as VPIM forwarding agents. 176 Nothing in this document precludes use of a general purpose MIME email 177 packages to read and compose VPIM messages. While no special 178 configuration is required to receive VPIM compliant messages, some may 179 be required to originate compliant structures. 181 It is expected that a VPIM messaging system will be managed by a 182 system administrator who can perform TCP/IP network configuration. 183 When using facsimile or multiple voice encodings, it is suggested that 184 the system administrator maintain a list of the capabilities of the 185 networked mail machines to reduce the sending of undeliverable 186 messages due to lack of feature support. Configuration, 187 implementation and management of this directory listing capabilities 188 is a local matter. 190 3. Protocol Restrictions 192 This protocol does not limit the number of recipients per message. 193 Where possible, implementations should not restrict the number of 194 recipients in a single message. It is recognized that no 195 implementation supports unlimited recipients, and that the number of 196 supported recipients may be quite low. However, ESMTP currently does 197 not provide a mechanism for indicating the number of supported 198 recipients. 200 This protocol does not limit the maximum message length. Implementors 201 should understand that some machines will be unable to accept 202 excessively long messages. A mechanism is defined in the RFC 1425 203 SMTP service extensions to declare the maximum message size supported. 205 The message size indicated in the ESMTP SIZE command is in bytes, not 206 minutes or seconds. The number of bytes varies by voice encoding 207 format and must include the MIME wrapper overhead. If the length must 208 be known before sending, an approximate translation into minutes or 209 seconds can be performed if the voice encoding is known. 211 The following sections describe the restrictions and additions to 212 Internet mail protocols that are required to be compliant with this 213 VPIM v2 profile. Though various SMTP, ESMTP and MIME features are 214 described here, the implementor is referred to the relevant RFCs for 215 complete details. It is also advisable to check for IETF drafts of 216 various Internet Mail specifications that are later than the most 217 recent RFCs since, for example, MIME has yet to be published as a full 218 IETF Standard. The table in Appendix A summarizes the protocol details 219 of this profile. 221 4. Voice Message Interchange Format 223 The voice message interchange format is a profile of the Internet Mail 224 Protocol Suite. As such, this document assumes an understanding of 225 these specifications. Specifically, VPIM references components from 226 the message format standard for Internet messages [RFC822], the 227 Multipurpose Internet Message Extensions [MIME], the X.400 gateway 228 specification [X.400], delivery status notification 229 [DSN][DRPT][STATUS], and the electronic business card 230 [DIRECTORY][VCARD]. 232 4.1 Message Addressing Formats 234 RFC 822 addresses are based on the domain name system. This naming 235 system has two components: the local part, used for username or 236 mailbox identification; and the host part, used for global machine 237 identification. 239 4.1.1 VPIM Addresses 241 The local part of the address shall be a US-ASCII string uniquely 242 identifying a mailbox on a destination system. For voice messaging, 243 the local part is a printable string containing the mailbox ID of the 244 originator or recipient. While alpha characters and long mailbox 245 identifiers are permitted, most voice mail networks rely on numeric 246 mailbox identifiers to retain compatibility with the limited 10 digit 247 telephone keypad. As a result, some voice messaging systems may only 248 be able to handle a numeric local part. The reception of alphanumeric 249 local parts on these systems may result in the address being mapped to 250 some locally unique (but confusing to the recipient) number or, in the 251 worst case the address could be deleted making the message un- 252 replyable. Additionally, it may be difficult to create messages on 253 these systems with an alphanumeric local part without complex key 254 sequences or some form of directory lookup (see 6). 256 The use of the domain naming system should be transparent to the user. 257 It is the responsibility of the voice mail machine to lookup the 258 fully-qualified domain name (FQDN) based on the address entered by the 259 user (see 6). 261 In the absence of a global directory, specification of the local part 262 is expected to conform to international or private telephone numbering 263 plans. It is likely that private numbering plans will prevail and 264 these are left for local definition. However, it is recommended that 265 public telephone numbers be noted according to the international 266 numbering plan described in [E.164]. The indication that the local 267 part is a public telephone number is given by a preceding `+' (the `+' 268 would not be entered from a telephone keypad, it is added by the 269 system as a flag). Since the primary information in the numeric 270 scheme is contained by the digits, other character separators (e.g. `- 271 ') may be ignored (i.e. to allow parsing of the numeric local mailbox) 272 or may be used to recognize distinct portions of the telephone number 273 (e.g. country code). The specification of the local part of a VPIM 274 address can be split into the four groups described below: 276 1) mailbox number 277 - for use as a private numbering plan (any number of digits) 278 - e.g. 2722@octel.com 280 2) mailbox number+extension 281 - for use as a private numbering plan with extensions 282 any number of digits, use of `+' as separator 283 - e.g. 2722+111@octel.com 285 3) +international number 286 - for international telephone numbers conforming to E.164 287 maximum of 15 digits 288 - e.g. +16137637582@vm.nortel.ca 290 4) +international number+extension 291 - for international telephone numbers conforming to E.164 292 maximum of 15 digits, with an extension (e.g. behind a 293 PBX) that has a maximum of 15 digits. 294 - e.g. +17035245550+230@ema.org 296 4.1.2 Special Addresses 298 Special addresses are provided for compatibility with the conventions 299 of Internet mail. These addresses do not use numeric local addresses, 300 both to conform to current Internet practice and to avoid conflict 301 with existing numeric addressing plans. Two special addresses are 302 RESERVED for use as follows: 304 postmaster@domain 306 By convention, a special mailbox named "postmaster" MUST exist on all 307 systems. This address is used for diagnostics and should be checked 308 regularly by the system manager. This mailbox is particularly likely 309 to receive text messages, which is not normal on a voice processing 310 platform. The specific handling of these messages is an individual 311 implementation choice. 313 non-mail-user@domain 315 If a reply to a message is not possible, such as a telephone answering 316 message, then the special address _non-mail-user_ must be used as the 317 originator's address. Any text name such as "Telephone Answering," or 318 the telephone number if it is available, is permitted. This special 319 address is used as a token to indicate an unreachable originator. For 320 compatibility with the installed base of mail user agents, 321 implementations that generate this special address MUST send a non- 322 delivery notification for reply messages sent to the undeliverable 323 address. The status code for such NDN's is 5.1.1 "Mailbox does not 324 exist". 326 Example: 328 From: Telephone Answering 330 4.1.3 Distribution Lists 332 There are many ways to handle distribution list (DL) expansions and 333 none are 'standard'. Simple alias is a behavior closest to what most 334 voice mail systems do today and what is to be used with VPIM messages. 335 That is: 337 Reply to the originator - (Address in the RFC822 Reply-to or From 338 field) 339 Errors to the submitter - (Address in the MAIL FROM: field of the 340 ESMTP exchange and the Return-Path: 341 RFC 822 field) 343 Some proprietary voice messaging protocols include only the recipient 344 of the particular copy in the envelope and include no "headers" except 345 date and per-message features. Most voice messaging systems do not 346 provide for "Header Information" in their messaging queues and only 347 include delivery information. As a result, recipient information MAY 348 be in either the To or CC headers. If all recipients cannot be 349 presented (e.g. unknown DL expansion) then the recipient headers MUST 350 be omitted to indicate that an accurate list of recipients (e.g. for 351 use with a reply-all capability) is not known. 353 4.2 Message Header Fields 355 Internet messages contain a header information block. This header 356 block contains information required to identify the sender, the list 357 of recipients, the message send time, and other information intended 358 for user presentation. Except for specialized gateway and mailing 359 list cases, headers do not indicate delivery options for the transport 360 of messages. 362 Exploder lists are noted for modifying or adding to the headers of 363 messages that pass through them. VPIM systems MUST be able to accept 364 and ignore headers that are not defined here. 366 The following header lines are permitted for use with VPIM voice 367 messages: 369 4.2.1 From 371 The originator's fully-qualified domain address (a mailbox address 372 followed by the fully-qualified domain name). The user listed in this 373 field should be presented in the voice message envelope as the 374 originator of the message. 376 Systems compliant with this profile SHOULD provide the text personal 377 name of the voice message originator in a quoted phrase, if the name 378 is available. Text names of corporate or positional mailboxes MAY be 379 provided as a simple string. From [RFC822] 381 Example: 383 From: "Joe S. User" <12145551212@mycompany.com> 384 From: Technical Support <611@serviceprovider.com> 386 The From address may be used for replies (see 4.6). However, if the 387 From address contains , the user SHOULD not be 388 offered the option to reply, nor should notifications be sent to this 389 address. 391 4.2.2 To 393 The To header contains the recipient's fully-qualified domain address. 394 There may be one or more To: fields in any message. 396 Example: 398 To: +12145551213@mycompany.com 400 Systems compliant to this profile SHOULD provide a list of recipients 401 only if all recipients are provided. The To header MUST NOT be 402 included in the message if the sending message transport agent (MTA) 403 cannot resolve all the addresses in it, e.g. if an address is a DL 404 alias for which the expansion is unknown (see 4.1.3). If present, the 405 addresses in the To header MAY be used for a reply message to all 406 recipients. 408 Systems compliant to this profile MAY also discard the To addresses of 409 incoming messages because of the inability to store the information. 410 This would, of course, make a reply-to-all capability impossible. 412 4.2.3 Cc 414 The cc header contains additional recipients' fully-qualified domain 415 addresses. Many voice mail systems maintain only sufficient envelope 416 information for message delivery and are not capable of storing or 417 providing a complete list of recipients. 419 Systems compliant to this profile SHOULD provide a list of recipients 420 only if all disclosed recipients can be provided. The list of 421 disclosed recipients does not include those sent via a blind copy. If 422 not, systems SHOULD omit the To and Cc headers to indicate that the 423 full list of recipients is unknown. 425 Example: 427 Cc: +12145551213@mycompany.com 429 Systems compliant to this profile MAY discard the Cc addresses of 430 incoming messages as necessary. If a list of Cc or to addresses is 431 present, these addresses MAY be used for a reply message to all 432 recipients. 434 4.2.4 Date 436 The Date header contains the date, time, and time zone in which the 437 message was sent by the originator. The time zone SHOULD be 438 represented in a four-digit time zone offset, such as -0500 for North 439 American Eastern Standard Time. This may be supplemented by a time 440 zone name in parentheses, e.g., "-0900 (PDT)". Compliant 441 implementations SHOULD be able to convert RFC 822 date and time stamps 442 into local time. 444 Example: 446 Date: Wed, 28 Jul 96 10:08:49 -0800 (PST) 448 The sending system MUST report the time the message was sent. If the 449 VPIM sender is relaying a message from a system which does not provide 450 a timestamp, the time of arrival at the VPIM system SHOULD be used as 451 the date. From [RFC822] 453 4.2.5 Sender 455 The Sender header contains the actual address of the originator if the 456 message is sent by an agent on behalf of the author indicated in the 457 From: field and MAY be present in a VPIM message. 459 While it may not be possible to save this information in some voice 460 mail machines, discarding this information or the ESMTP MAIL FROM (see 461 4.2.6) address will make it difficult to send an error message to the 462 proper destination. From [RFC822] 464 4.2.6 Return Path 466 The Return-path header is added by the final delivering SMTP server. 467 If present, it contains the address from the MAIL FROM parameter of 468 the ESMTP exchange (see 5.1.2) to which error messages MUST be sent to 469 this address (see [DRPT] for additional details). Note that if the 470 Return-path is null ("<>"), e.g. no path, loop prevention or 471 confidential, a notification MUST NOT be sent. If the Return path 472 address is not available (either from this header or the MAIL FROM 473 parameter) the Sender or From addresses may be used to deliver 474 notifications. 476 4.2.7 Message-id 478 The Message-id header contains a unique per-message identifier. A 479 unique message-id MUST be generated for each message sent from a 480 compliant implementation. 482 The message-id is not required to be stored on the receiving system. 483 This identifier MAY be used for tracking, auditing, and returning 484 read-receipt reports. From [RFC822] 486 Example: 488 Message-id: <12345678@mycompany.com> 490 4.2.8 Reply-To 492 If present, the reply-to header provides a preferred address to which 493 reply messages should be sent (see 4.6). If a reply-to header is 494 present, a reply-to sender message MUST be sent to the address 495 specified. From [RFC822] This preferred address of the originator 496 must also be provided in the originator's vCard EMAIL attribute, if 497 present (see 4.3.3). 499 4.2.9 Received 501 The Received header contains trace information added to the beginning 502 of a RFC 822 message by MTAs. This is the only header permitted to be 503 added by an MTA. Information in this header is useful for debugging 504 when using an US-ASCII message reader or a header parsing tool. 506 A compliant system MUST add Received headers when acting as a gateway 507 and MUST NOT remove any. These headers MAY be ignored or deleted when 508 the message is received at the final destination. From [RFC822] 510 4.2.10 MIME Version 512 The MIME-Version header indicates that the message conforms to the 513 MIME message format specification. Systems compliant with this 514 specification SHOULD include a comment with the words "(Voice 2.0)". 515 RFC 1911 defines an earlier version of this profile and uses the token 516 (Voice 1.0). From [MIME1][VPIM1] 518 Example: 520 MIME-Version: 1.0 (Voice 2.0) 522 A MIME message that contains this header is referred to in this 523 document as a VPIM Message. However, this identifier is intended for 524 information only and SHOULD NOT be used to semantically identify the 525 message as being a VPIM message. Instead, the presence of the content 526 defined in [V-MSG] SHOULD be used if identification is necessary. 528 4.2.11 Content-Type 530 The content-type header declares the type of content enclosed in the 531 message. The typical top level content in a VPIM Message SHOULD be 532 multipart/voice-message, a mechanism for bundling several components 533 into a single identifiable voice message. The allowable contents are 534 detailed in section 4.3 of this document. From [MIME2] 536 4.2.12 Content-Transfer-Encoding 538 Because Internet mail was initially specified to carry only 7-bit US- 539 ASCII text, it may be necessary to encode voice and fax data into a 540 representation suitable for that environment. The content-transfer- 541 encoding header describes this transformation if it is needed. 542 Compliant implementations MUST recognize and decode the standard 543 encodings, "Binary", "7bit, "8bit", "Base64" and "Quoted-Printable". 544 The allowable content-transfer-encodings are specified in section 4.3. 545 From [MIME1] 547 4.2.13 Sensitivity 549 The sensitivity header, if present, indicates the requested privacy 550 level. The case-insensitive values "Personal" and "Private" are 551 specified. If no privacy is requested, this field is omitted. 553 If a sensitivity header is present in the message, a compliant system 554 MUST prohibit the recipient from forwarding this message to any other 555 user. A compliant system, however, SHOULD allow the user to reply to 556 a sensitive message, but SHOULD NOT include the original message 557 content. The sensitivity of the reply message MAY be set by the user. 559 If the receiving system does not support privacy and the sensitivity 560 is one of "Personal" or "Private", the message MUST be returned to the 561 sender with an appropriate error code indicating that privacy could 562 not be assured and that the message was not delivered. A non-delivery 563 notification to a private message need not be tagged private since it 564 will be sent to the originator. From: [X.400] 566 4.2.14 Importance 568 Indicates the requested priority to be given by the receiving system. 569 The case-insensitive values "low", "normal" and "high" are specified. 570 If no special importance is requested, this header may be omitted and 571 the value assumed to be "normal". 573 Compliant implementations MAY use this header to indicate the 574 importance of a message and may order messages in a recipient's 575 mailbox. From: [X400] 577 4.2.15 Subject 579 The subject field is often provided by email systems but is not widely 580 supported on Voice Mail platforms. For compatibility with text based 581 mailbox interfaces, a text subject field SHOULD be generated by a 582 compliant implementation but MAY be discarded if present by a 583 receiving system. From [RFC822] 585 It is recommended that voice messaging systems that do not support any 586 text user interfaces (e.g. access only by a telephone) insert a 587 generic subject header of "VPIM Message" for the benefit of text 588 enabled recipients. 590 4.2.16 Disposition-Notification-To 592 This header MAY be present to indicate that the sender is requesting a 593 receipt notification from the receiving user agent. This message 594 disposition notification (MDN) is typically sent by the user agent 595 after the user has listened to the message and consented to an MDN 596 being sent 598 Example: 600 Disposition-notification-to: +12145551213@mycompany.com 602 The presence of a Disposition-notification-to header in a message is 603 merely a request for an MDN described in 4.4.5. The recipients' user 604 agents are always free to silently ignore such a request so this 605 header does not burden any system that does not support it. From 606 [MDN]. 608 4.3 Voice Message Content Types 610 MIME, introduced in [MIME1], is a general-purpose message body format 611 that is extensible to carry a wide range of body parts. It provides 612 for encoding binary data so that it can be transported over the 7-bit 613 text-oriented SMTP protocol. This transport encoding is in addition 614 to the audio encoding required to generate a binary object. 616 MIME defines two transport encoding mechanisms to transform binary 617 data into a 7 bit representation, one designed for text-like data 618 ("Quoted-Printable"), and one for arbitrary binary data ("Base64"). 619 While Base64 is dramatically more efficient for audio data, both will 620 work. Where binary transport is available, no transport encoding is 621 needed, and the data can be labeled as "Binary". 623 An implementation in compliance with this profile SHOULD send audio 624 and/or facsimile data in binary form when binary message transport is 625 available. When binary transport is not available, implementations 626 MUST encode the audio and/or facsimile data as Base64. The detection 627 and decoding of "Quoted-Printable", "7bit", and "8bit" MUST be 628 supported in order to meet MIME requirements and to preserve 629 interoperability with the fullest range of possible devices. However, 630 if a content is received that cannot be rendered to the user, an 631 appropriate non-delivery notification MUST be sent. 633 The content types described in this section are identified for use 634 within the multipart/voice-message content. This content, which is 635 the fundamental part of a VPIM message, is referred to as a VPIM voice 636 message in this document. 638 Each of the contents profiled subsequently can be sent within a VPIM 639 voice message construct to form a simple or a more complex structure 640 (several examples are given in Appendix B). When multiple contents 641 are present within the multipart/voice-message, they SHOULD be 642 presented to the user in the order that they appear in the message. 644 4.3.1 Multipart/Voice-Message 646 This MIME multipart structure provides a mechanism for packaging a 647 voice message into one container that is tagged as VPIM v2 compliant. 648 The semantic of multipart/Voice-Message (defined in [V-MSG]) is 649 identical to multipart/mixed and may be interpreted as that by systems 650 that do not recognize this content-type. 652 The Multipart/Voice-Message content-type MUST only contain the 653 profiled media and content types specified in this section (i.e. 654 audio/*, image/*, message/rfc822 and application/directory). The most 655 common will be: spoken name, spoken subject, the message itself, 656 attached fax and directory info. Forwarded messages are created by 657 simply using the message/rfc822 construct. 659 Conformant implementations MUST send the Multipart/Voice-Message in a 660 VPIM message. In most cases, this Multipart/Voice-Message content 661 will be the top level (i.e. in the Content-Type header). Conformant 662 implementations MUST recognize the Multipart/Voice-Message content 663 (whether it is a top level content or below a mulitpart/mixed) and be 664 able to separate the contents (e.g. spoken name or spoken subject). 666 4.3.2 Message/RFC822 668 MIME requires support of the Message/RFC822 message encapsulation body 669 part. This body part is used within a multipart/voice-message to 670 forward complete messages (see 4.5) or to reply with original content 671 (see 4.6). From [MIME2] 673 4.3.3 Application/Directory 675 This content allows for the inclusion of a Versit vCard [VCARD] 676 electronic business card within a VPIM message. The format is 677 suitable as an interchange format between applications or systems, and 678 is defined independent of the method used to transport it. It 679 provides a useful mechanism to transport information about the 680 originator that can be used by the receiving VPIM system (see 6) or 681 other local applications. 683 Each VPIM message SHOULD be created with an Application/Directory 684 content type [DIRECTORY] that MUST contain the preferred address and 685 telephone number of the message originator and SHOULD contain the 686 spoken name and the spelled name of the originator. The intent is 687 that the vCard be used as the source of information to contact the 688 originator (e.g. reply, call). 690 If included in a VPIM message, the vCard profile [VCARD] MUST be used 691 and MUST specify at least the following attributes: 693 TEL - Public switched telephone number in international (E.164) 694 format (various types, typically VOICE) 695 EMAIL - email address (various types, typically INTERNET; the type 696 VPIM is optionally used to denote the address that supports 697 VPIM messages) 699 The following attributes SHOULD be specified: 701 N - Family Name, Given Name, Additional Names, Honorific 702 Prefixes, and Suffixes (all present components in the From 703 text name MUST match) 704 ROLE - the role of the person identified in `N', but may be used 705 as an alternative to the `N' attribute when the sender is a 706 corporate or positional mailbox 707 SOUND - spoken name sound data (various types, typically 32KADPCM) 708 REV - Revision of vCard in ISO 8601 date format 710 The vCard MAY use other attributes (e.g. capabilities) as defined in 711 [VCARD]. 713 If present, the spoken name attribute MUST be denoted by a content ID 714 pointing to an audio/* content elsewhere in the VPIM message. 716 A typical VPIM message (i.e. no forwarded parts), MUST only contain 717 one vCard -- more than one is an error condition. A VPIM message that 718 contains forwarded messages, though, may contain multiple vCards. 719 However, these vCards MUST be associated with the originator(s) of the 720 forwarded message(s) and the originator of the forwarding message. As 721 a result, all forwarded vCards will be contained in message/rfc822 722 contents -- only the vCard of forwarding originator will be at the 723 top-level. 725 Example: 727 BEGIN:VCARD 728 N:Parsons;Glenn 729 ORG:Nortel Technology 730 TEL;TYPE=VOICE;MSG;WORK:+1-613-763-7582 731 EMAIL;TYPE=INTERNET:glenn.parsons@nortel.ca 732 EMAIL;TYPE=INTERNET;VPIM:6137637582@vm.nortel.ca 733 SOUND;TYPE=32KADPCM;ENCODING=BASE64;VALUE=CID: 734 REV:19960831T103310Z 735 END:VCARD 737 4.3.4 Audio/32KADPCM 739 An implementation compliant to this profile MUST use Audio/32KADPCM by 740 default for voice [ADPCM]. Typically this body contains several 741 minutes of message content, however if used for spoken name or subject 742 the content should be considerably shorter (i.e. about 10 and 20 743 seconds respectively). 745 If an implementation can only handle one voice body, then multiple 746 voice bodies (if present) SHOULD be concatenated, and SHOULD NOT be 747 discarded. It is recommended that this be done in the same order as 748 they were sent. Note that if an Originator Spoken Name audio body and 749 a vCard are both present in a VPIM message, the vCard SOUND attribute 750 MUST point to this audio body (see 4.3.3). 752 While any valid MIME body header MAY be used, several headers have the 753 following semantics when included with this body part: 755 4.3.4.1 Content-Description: 757 This field MAY be present to facilitate the text identification of 758 these body parts in simple email readers. Any values may be used, 759 though it may be useful to use values similar to those for Content- 760 Disposition. 762 Example: 764 Content-Description: Big Telco Voice Message 766 4.3.4.2 Content-Disposition: 768 This field MUST be present to allow the parsable identification of 769 these body parts. This is especially useful if, as is typical, 770 more than one Audio/32KADPCM body occurs within a single level 771 (e.g. multipart/voice-message). Since a VPIM voice message is 772 intended to be automatically played upon display of the message, in 773 the order in which the audio contents occur, the audio contents are 774 always of type inline. From [DISP] 776 In order to distinguish between the various kinds of audio contents 777 in a VPIM voice message a new disposition parameter "voice" is 778 defined with the following values to be used as appropriate: 780 Voice-Message - the primary voice message, 781 Voice-Message-Notification - a spoken delivery notification, 782 Originator-Spoken-Name - the spoken name of the originator, 783 Recipient-Spoken-Name - the spoken name of the recipient if 784 available to the originator and present if there is ONLY one 785 recipient, 786 Spoken-Subject- the spoken subject of the message, typically 787 spoken by the originator 789 Implementations that do not understand the "voice" parameter (or 790 the Content-Disposition header) can safely ignore it, and will 791 present the audio bodyparts in order (but will not be able to 792 distinguish between them). 794 Example: 796 Content-Disposition: inline; voice=spoken-subject 798 4.3.4.3 Content-Duration: 800 This field MAY be present to allow the specification of the length 801 of the audio bodypart in seconds. The use of this field on 802 reception is a local implementation issue. From [DUR] 804 Example: 806 Content-Duration: 33 808 4.3.4.4 Content-Language: 810 This field MAY be present to allow the specification of the spoken 811 language of the audio bodypart. The encoding is defined in [LANG]. 812 The use of this field on reception is a local implementation issue. 814 Example for UK English: 816 Content-Language: EN-UK 818 4.3.5 Image/TIFF 820 A common image encoding for facsimile is a class of the Tag Image File 821 Format (TIFF) and is defined in [TIFF-F]. While there are several 822 variations of TIFF, only class F (denoted by the parameter class=F) is 823 profiled for use in a VPIM voice message. 825 All VPIM implementations that support facsimile MUST generate and read 826 TIFF-F compatible facsimile contents in the image/TIFF; Class=F sub- 827 type encoding by default. An implementation MAY send this fax content 828 in VPIM voice messages and MUST be able to recognize it in received 829 messages. If a fax message is received that cannot be rendered to the 830 user (e.g. the receiving VPIM system does not support fax), then the 831 system MUST non-deliver the entire message with a media not supported 832 error. 834 4.3.6 Proprietary Voice or Fax Formats 836 Proprietary voice or fax encoding formats or other standard formats 837 may be supported under this profile provided a unique identifier is 838 registered with the IANA prior to use (see [MIME4]). The voice 839 encodings should be registered as sub-types of Audio and the fax 840 encodings should be registered as sub-types of Image 842 Use of any other encoding except Audio/32KADPCM or Image/TIFF; class=F 843 reduces interoperability in the absence of explicit manual system 844 configuration. A compliant implementation MAY use any other encoding 845 with explicit per-destination configuration. 847 4.4 Other Message Content Types 849 An implementation compliant with this profile MAY send additional 850 contents in a VPIM message, but ONLY outside of the multipart/voice- 851 message. The content types described in this section are identified 852 for use with this profile. Contents not defined here MUST NOT be used 853 without prior explicit per-destination configuration. If an 854 implementation receives a VPIM message (i.e. MIME-Version: 1.0 (Voice 855 2.0)) that contains content types not specified in this profile, their 856 handling is a local implementation issue (e.g. the unknown contents 857 MAY be discarded if they cannot be presented to the recipient). 858 Conversely, if an implementation receives a non-VPIM message with any 859 of the contents defined in 4.3 & 4.4, it SHOULD deliver those 860 contents, but the full message handling is a local issue (e.g. the 861 unknown contents _or_ the entire message MAY be discarded). It is 862 recommended that implementations issue notifications to the originator 863 when any form of non-delivery to the recipient occurs. 865 Each of the contents defined below can be sent individually in a VPIM 866 message or wrapped in a multipart/mixed to form a more complex 867 structure (several examples are given in Appendix B). When multiple 868 contents are present, they SHOULD be presented to the user in the 869 order that they appear in the message. 871 4.4.1 Multipart/Mixed 873 MIME provides the facilities for enclosing several body parts in a 874 single message. Multipart/Mixed SHOULD only be used for sending 875 complex voice or multimedia messages. That is, as the top level 876 Content-Type when sending one of the following contents (in addition 877 to the VPIM voice message) in a VPIM message. Compliant systems MUST 878 accept multipart/mixed body parts. From [MIME2] 880 4.4.2 Text/Plain 882 MIME requires support of the basic Text/Plain content type. This 883 content type has limited applicability within the voice messaging 884 environment. Compliant implementations SHOULD NOT send the Text/Plain 885 content-type, but SHOULD only send this content if the recipient 886 system is known to support it. Compliant implementations MUST accept 887 Text/Plain messages, however, specific handling is left as an 888 implementation decision. From [MIME2] 890 There are several mechanisms that can be used to support text on voice 891 messaging systems including text-to-speech and text-to-fax 892 conversions. If no rendering of the text is possible (i.e. it is not 893 possible for the recipient to determine if the text is a critical part 894 of the message), the entire message MUST be non-delivered and returned 895 to the sender with a media-unsupported error code. 897 4.4.3 Multipart/report 899 The Multipart/Report is used for enclosing human-readable and machine 900 parsable notification (e.g. Message/delivery-status) body parts and 901 any returned message content. Compliant implementations MUST use the 902 Multipart/Report construct when returning messages, sending warnings, 903 or issuing read receipts. Compliant implementations MUST recognize 904 and decode the Multipart/Report content type. From [REPORT] 906 Multipart/Report messages that are VPIM messages (i.e. MIME-Version: 907 1.0 (Voice 2.0)) MUST include the human-readable description of the 908 error as a spoken audio/* content. Note that VPIM implementations 909 MUST be able to handle (and MAY generate) Multipart/Report messages 910 that encode the human-readable description of the error as text. 912 4.4.4 Message/delivery-status 914 This MIME body part is used for sending machine-parsable delivery 915 status notifications. Compliant implementations must use the 916 Message/delivery-status construct when returning messages or sending 917 warnings. Compliant implementations must recognize and decode the 918 Message/delivery-status content type and present the reason for 919 failure to the user. From [DSN] 921 4.4.5 Message/Disposition-notification 923 This MIME body part is used for sending machine-parsable read-receipt 924 and extended-absence message disposition notifications. Conforming 925 implementations should use the Message/Disposition-notification 926 construct when sending post-delivery message status notifications. 927 Conforming implementations should recognize and decode the 928 Message/Disposition-notification content type and present the 929 notification to the user. From [MDN] 931 4.5 Forwarded Messages 933 VPIM version 2 explicitly supports the forwarding of voice and fax 934 content with voice or fax annotation. However, only the two constructs 935 described below are acceptable in a VPIM message. Since only the 936 first (i.e. message/rfc822) can be recognized as a forwarded message 937 (or even mulitple forwarded messages), it is recommended that this 938 construct be used whenever possible. 940 Forwarded VPIM messages SHOULD be sent as a multipart/voice-message 941 with the entire original message enclosed in a message/rfc822 content 942 type and the annotation as a separate Audio/* or image/* body part. 943 If the RFC822 headers are not available for the forwarded content, 944 simulated headers with available information SHOULD be constructed to 945 indicate the original sending timestamp, and the original sender as 946 indicated in the "From" line. However, note that at least one of 947 "From", "Subject", or "Date" MUST be present. As well, the 948 message/rfc822 content MUST include at least the "MIME-Version", 949 "Content-Type" headers, and MAY include the "Content-Transfer- 950 Encoding" header. From [MIME2] 951 In the event that forwarding information is lost through concatenation 952 of the original message and the forwarding annotation, such as must be 953 done in a gateway between VPIM and the AMIS voice messaging protocol, 954 the entire content MAY be sent as a single Audio/* segment without 955 including any forwarding semantics. 957 4.6 Reply Messages 959 Replies to VPIM messages (and Internet mail messages) are addressed to 960 the address noted in the reply-to header (see 4.2.8) if it is present, 961 else the From address (see 4.2.1) is used. The vCard EMAIL attribute, 962 if present, SHOULD be the same as the reply-to address and may be the 963 same as the From address. While the vCard is the senders preferred 964 address it SHOULD NOT be used to generate a reply. Also, the Return- 965 path address should not be used for replies. 967 Support of multiple originator headers is often not possible on voice 968 messaging systems, so it may be necessary to choose only one. 969 However, implementors should note that this may make it impossible to 970 send error messages and replies to the proper destination. 972 In some cases, a reply message is not possible, such as with a message 973 created by telephone answering (i.e. classic voice mail). In this 974 case, the From field MUST contain the special address non-mail- 975 user@domain (see 4.1.2). The use of a null ESMTP MAIL FROM address 976 SHOULD also be used in this case (see 5.1.2). A receiving VPIM system 977 SHOULD not offer the user the option to reply to this kind of message. 979 4.7 Notification Messages 981 VPIM Delivery Notification messages (4.4.4) must be sent to the 982 originator of the message when any form of non-delivery of the subject 983 message or its components occurs. These error messages must be sent 984 to the return path (4.2.6) if present, else the sender (4.2.5) or From 985 (4.2.1) address may be used (in that order). 987 VPIM Receipt Notification messages (4.4.5) should be sent to the 988 sender specified in the MDN header (4.2.16), if the header is present, 989 and typically after the user has initiated the notification by some 990 action (like listening to the message). 992 VPIM Notification messages may be positive or negative, and can 993 indicate delivery at the server or receipt by the client. However, 994 the notification MUST be contained in a multipart/report container 995 (4.4.3) and SHOULD contain a spoken error message. It is recommended 996 that VPIM systems that do not support the notification format SHOULD 997 still send some form of error message when non-delivery occurs. 999 5. Message Transport Protocol 1001 Messages are transported between voice mail machines using the 1002 Internet Extended Simple Mail Transfer Protocol (ESMTP). All 1003 information required for proper delivery of the message is included in 1004 the ESMTP dialog. This information, including the sender and 1005 recipient addresses, is commonly referred to as the message 1006 "envelope". This information is equivalent to the message control 1007 block in many analog voice networking protocols. 1009 ESMTP is a general-purpose messaging protocol, designed both to send 1010 mail and to allow terminal console messaging. Simple Mail Transport 1011 Protocol (SMTP) was originally created for the exchange of US-ASCII 7- 1012 bit text messages. Binary and 8-bit text messages have traditionally 1013 been transported by encoding the messages into a 7-bit text-like form. 1014 [ESMTP] formalized an extension mechanism for SMTP, and subsequent 1015 RFCs have defined 8-bit text networking, command streaming, binary 1016 networking, and extensions to permit the declaration of message size 1017 for the efficient transmission of large messages such as multi-minute 1018 voice mail. 1020 The following sections list ESMTP commands, keywords, and parameters 1021 that are required and those that are optional for conformance to this 1022 profile. 1024 5.1 ESMTP Commands 1026 5.1.1 HELO 1028 Base SMTP greeting and identification of sender. This command is not 1029 to be sent by compliant systems unless the more-capable EHLO command 1030 is not accepted. It is included for compatibility with general SMTP 1031 implementations. Compliant implementations MUST implement the HELO 1032 command for backward compatibility but SHOULD NOT send it unless EHLO 1033 is not supported. From [SMTP] 1035 5.1.2 MAIL FROM (REQUIRED) 1037 Originating mailbox. This address contains the mailbox to which 1038 errors should be sent. This address may not be the same as the 1039 message sender listed in the message header fields if the message was 1040 received from a gateway or sent to an Internet-style mailing list. 1041 Compliant implementations MUST implement the extended MAIL FROM 1042 command. From [SMTP, ESMTP] 1044 The MAIL FROM address MAY be passed as a local system parameter or 1045 placed in a Return-Path: line inserted at the beginning of a VPIM 1046 message. From [HOSTREQ] 1048 Since error messages MUST be sent to the MAIL FROM address, the use of 1049 the null address ("<>") is often used to prevent looping of error 1050 notifications. This null address MAY also be used to note that a 1051 particular message has no return path (e.g. a telephone answer 1052 message). From [SMTP] 1054 5.1.3 RCPT TO 1056 Recipient's mailbox. This field contains only the addresses to which 1057 the message should be delivered for this transaction. In the event 1058 that multiple transport connections to multiple destination machines 1059 are required for the same message, this list may not match the list of 1060 recipients in the message header. Compliant implementations MUST 1061 implement the extended RCPT TO command. From [SMTP, ESMTP] 1063 5.1.4 DATA 1065 Initiates the transfer of message data. Support for this command is 1066 required in the event the binary mode command BDAT is not supported by 1067 the remote system. Compliant implementations MUST implement the SMTP 1068 DATA command for backwards compatibility. From [SMTP] 1070 5.1.5 TURN 1072 Requests a change-of-roles, that is, the client that opened the 1073 connection offers to assume the role of server for any mail the remote 1074 machine may wish to send. Because SMTP is not an authenticated 1075 protocol, the TURN command presents an opportunity to improperly fetch 1076 mail queued for another destination. Compliant implementations SHOULD 1077 NOT implement the TURN command. From [SMTP] 1079 5.1.6 QUIT 1081 Requests that the connection be closed. If accepted, the remote 1082 machine will reset and close the connection. Compliant 1083 implementations MUST implement the QUIT command. From [SMTP] 1085 5.1.7 RSET 1087 Resets the connection to its initial state. Compliant implementations 1088 MUST implement the RSET command. From [SMTP] 1090 5.1.8 VRFY 1092 Requests verification that this node can reach the listed recipient. 1093 While this functionality is also included in the RCPT TO command, VRFY 1094 allows the query without beginning a mail transfer transaction. This 1095 command is useful for debugging and tracing problems. Compliant 1096 implementations MAY implement the VRFY command. From [SMTP] 1098 (Note that the implementation of VRFY may simplify the guessing of a 1099 recipient's mailbox or automated sweeps for valid mailbox addresses, 1100 resulting in a possible reduction in privacy. Various implementation 1101 techniques may be used to reduce the threat, such as limiting the 1102 number of queries per session.) From [SMTP] 1104 5.1.9 EHLO 1106 The enhanced mail greeting that enables a server to announce support 1107 for extended messaging options. The extended messaging modes are 1108 discussed in subsequent sections of this document. Compliant 1109 implementations MUST implement the ESMTP command and return the 1110 capabilities indicated later in this memo. From [ESMTP] 1112 5.1.10 BDAT 1114 The BDAT command provides a higher efficiency alternative to the 1115 earlier DATA command, especially for voice. The BDAT command provides 1116 for native binary transport of messages. Compliant implementations 1117 SHOULD support binary transport using the BDAT command.[BINARY] 1119 5.2 ESMTP Keywords 1121 The following ESMTP keywords indicate extended features useful for 1122 voice messaging. 1124 5.2.1 PIPELINING 1126 The "PIPELINING" keyword indicates ability of the receiving server to 1127 accept new commands before issuing a response to the previous command. 1128 Pipelining commands dramatically improves performance by reducing the 1129 number of round-trip packet exchanges and makes it possible to 1130 validate all recipient addresses in one operation. Compliant 1131 implementations SHOULD support the command pipelining indicated by 1132 this parameter. From [PIPE] 1134 5.2.2 SIZE 1136 The "SIZE" keyword provides a mechanism by which the SMTP server can 1137 indicate the maximum size message supported. Compliant 1138 implementations MUST provide the size capability and SHOULD honor any 1139 size limitations when sending. From [SIZE] 1141 5.2.3 CHUNKING 1143 The "CHUNKING" keyword indicates that the receiver will support the 1144 high-performance binary transport mode. Note that CHUNKING can be 1145 used with any message format and does not imply support for binary 1146 encoded messages. Compliant implementations SHOULD support binary 1147 transport indicated by this capability. From [BINARY] 1149 5.2.4 BINARYMIME 1151 The "BINARYMIME" keyword indicates that the SMTP server can accept 1152 binary encoded MIME messages. Compliant implementations SHOULD support 1153 binary transport indicated by this capability. Note that support for 1154 this feature requires support of CHUNKING. From [BINARY] 1156 5.2.5 DSN 1158 The "DSN" keyword indicates that the SMTP server will accept explicit 1159 delivery status notification requests. Compliant implementations MUST 1160 support the delivery notification extensions in [DRPT]. 1162 5.2.6 ENHANCEDSTATUSCODES 1164 The "ENHANCEDSTATUSCODES" keyword indicates that an SMTP server 1165 augments its responses with the enhanced mail system status codes 1166 [CODES]. These codes can then be used to provide more informative 1167 explanations of error conditions, especially in the context of the 1168 delivery status notifications format defined in [DSN]. Compliant 1169 implementations SHOULD support this capability. From [STATUS] 1171 5.3 ESMTP Parameters - MAIL FROM 1173 5.3.1 BINARYMIME 1175 The current message is a binary encoded MIME messages. Compliant 1176 implementations SHOULD support binary transport indicated by this 1177 parameter. From [BINARY] 1179 5.3.2 RET 1181 The RET parameter indicates whether the content of the message should 1182 be returned. Compliant systems SHOULD honor a request for returned 1183 content. From [DRPT] 1185 5.3.3 ENVID 1187 The ENVID keyword of the SMTP MAIL command is used to specify an 1188 "envelope identifier" to be transmitted along with the message and 1189 included in any DSNs issued for any of the recipients named in this 1190 SMTP transaction. The purpose of the envelope identifier is to allow 1191 the sender of a message to identify the transaction for which the DSN 1192 was issued. Compliant implementations MAY use this parameter. From 1193 [DRPT] 1195 5.4 ESMTP Parameters - RCPT TO 1197 5.4.1 NOTIFY 1199 The NOTIFY parameter indicates the conditions under which a delivery 1200 report should be sent. Compliant implementations MUST honor this 1201 request. From [DRPT] 1203 5.4.2 ORCPT 1205 The ORCPT keyword of the RCPT command is used to specify an "original" 1206 recipient address that corresponds to the actual recipient to which 1207 the message is to be delivered. If the ORCPT esmtp-keyword is used, 1208 it MUST have an associated esmtp-value, which consists of the original 1209 recipient address, encoded according to the rules below. Compliant 1210 implementations MAY use this parameter. From [DRPT] 1212 5.5 ESMTP - SMTP Downgrading 1214 To ensure a consistent level of service across an intranet or the 1215 global Internet, it is essential that VPIM compliant ESMTP be 1216 supported at all hops between a VPIM originating system and the 1217 recipient system. Unfortunately, in the situation where a `downgrade' 1218 is unavoidable the expected result is not defined. A downgrade is 1219 defined as the loss of VPIM transport features at some hop due to the 1220 lack of support. For example, a relay hop may be forced (by the next 1221 hop) to forward a VPIM using SMTP instead of ESMTP, or using DATA 1222 instead of BDAT. It is recommended that the downgrading system should 1223 continue to attempt to deliver the message, but MUST send an 1224 appropriate delivery notification to the originator, e.g. the message 1225 left an ESMTP host and was sent (unreliably) via SMTP. 1227 6. Directory Address Resolution 1229 It is the responsibility of a VPIM system to lookup the fully- 1230 qualified domain name (FQDN) based on the address entered by the user 1231 (if the entered address is not already a FQDN). This would typically 1232 be an issue on systems that offered only a telephone user interface. 1233 The mapping of the dialed target number to a routable FQDN address 1234 allowing delivery to the destination system can be accomplished 1235 through implementation-specific means. 1237 To facilitate a local dial-by-name cache, an implementation may wish 1238 to populate local directories with the first and last names, as well 1239 as the address information extracted from received messages. It is 1240 mandated that only address information from vCard attachments to VPIM 1241 messages be used to populate such a directory when the vCard is 1242 available. Addresses or names parsed from the headers of VPIM messages 1243 SHOULD NOT be used to populate directories as it only provides partial 1244 data. Alternatively, bilateral agreements could be made to allow the 1245 bulk transfer of vCards between systems. 1247 7. IMAP 1249 The use of client/server desktop mailbox protocols like IMAP or POP to 1250 retrieve VPIM messages from a IMAP or POP message store is possible 1251 without any special modifications to this VPIM specification. Email 1252 clients (and web browsers) typically have a table for mapping from 1253 MIME type to displaying application. The audio/*, image/tiff and 1254 application/directory contents can be configured so that they invoke 1255 the correct player/recorder for rendering. In addition with IMAP 1256 clients, the first multipart/mixed content (if present) will not 1257 appear since it is a generic part. The user instead will be presented 1258 with a message that has (for example) audio and image contents. 1260 8. Management Protocols 1262 The Internet protocols provide a mechanism for the management of 1263 messaging systems, from the management of the physical network through 1264 the management of the message queues. SNMP should be supported on a 1265 compliant message machine. 1267 8.1 Network Management 1269 The digital interface to the VM and the TCP/IP protocols SHOULD be 1270 managed. MIB II SHOULD be implemented to provide basic statistics and 1271 reporting of TCP and IP protocol performance. [MIB II] 1273 9. Conformance Requirements 1275 In order to claim conformance to this document and be called `VPIM 1276 compliant', a voice messaging system must implement all mandatory 1277 features of this profile in each of three areas: Content, Transport, 1278 and Notifications. In addition, systems which conform to this profile 1279 must not send messages with features beyond this profile unless 1280 explicit per-destination configuration of these enhanced features is 1281 provided. Such configuration information could be stored in a 1282 directory, though the implementation of this is currently a local 1283 matter. 1285 It is also possible, though not encouraged, to claim conformance to 1286 only specific areas (e.g. VPIM content compliant) of this profile. 1287 The delineation of these areas is as follows: 1289 Content - Section 4, except REPORT & NOTIFY and Section 6 1291 Transport - Section 5 except NOTIFY & RET, and Section 8 1293 Notifications - REPORT & NOTIFY from Section 4, NOTIFY, RET & 1294 ENHANCEDSTATUSCODES from Section 5, and all 1295 notification requirements. 1297 A summary of compliance requirements is contained in Appendix A. 1299 10. References 1301 [8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E., D. Crocker, 1302 "SMTP Service Extension for 8bit-MIMEtransport" RFC 1426, United 1303 Nations University, Innosoft International, Inc., Dover Beach 1304 Consulting, Inc., Network Management Associates, Inc., The Branch 1305 Office, February 1993. 1307 [ADPCM] G. Vaudreuil and G. Parsons, "Toll Quality Voice - 32 kbit/s 1308 ADPCM: MIME Sub-type Registration", , January 1997. 1311 [AMIS-A] Audio Messaging Interchange Specifications (AMIS) - Analog 1312 Protocol Version 1, Issue 2, February 1992 1314 [AMIS-D] Audio Messaging Interchange Specifications (AMIS) - Digital 1315 Protocol Version 1, Issue 3 August 1993 1317 [BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of 1318 Large and Binary MIME Messages", RFC 1830, October 1995. 1320 [CODES] Vaudreuil, G. "Enhanced Mail System Status Codes", RFC 1893, 1321 01/15/1996. 1323 [DIRECTORY] Howes, Tim, Smith, Mark, "A MIME Content-Type for Directory 1324 Information" 1326 [DISP] R. Troost and S. Dorner, Communicating Presentation Information 1327 in Internet Messages: The Content-Disposition Header, RFC 1806, June 1328 1995 1330 [DNS1] Mockapetris, P., "Domain names - implementation and 1331 specification", RFC1035, Nov 1987. 1333 [DNS2] Mockapetris, P., "Domain names - concepts and facilities", RFC 1334 1034, Nov 1987. 1336 [DRPT] Moore, K. "SMTP Service Extensions for Delivery Status 1337 Notifications", RFC 1891, 01/15/1996 1339 [DSN] Moore, K., Vaudreuil, G., "An Extensible Message Format for 1340 Delivery Status Notifications", RFC 1894, 01/15/1996. 1342 [DUR] G. Parsons and G. Vaudreuil, "Content Duration MIME Header 1343 Definition", , January 1997. 1345 [E164] CCITT Recommendation E.164 (1991), Telephone Network and ISDN 1346 Operation, Numbering, Routing and Mobile Service - Numbering Plan 1347 for the ISDN Era. 1349 [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, 1350 "SMTP Service Extensions" RFC 1869, United Nations University, 1351 Innosoft International, Inc., Dover Beach Consulting, Inc., Network 1352 Management Associates, Inc., The Branch Office, November 1995. 1354 [G726] CCITT Recommendation G.726 (1990), General Aspects of Digital 1355 Transmission Systems, Terminal Equipment - 40, 32, 24,16 kbit/s 1356 Adaptive Differential Pulse Code Modulation (ADPCM). 1358 [HOSTREQ] Braden, R., "Requirements for Internet Hosts -- Application 1359 and Support", STD 3, RFC 1123, October 1989. 1361 [LANG] Alvestrand,H., "Tags for the Identification of Languages", RFC 1362 1766, Mar 1995 1364 [MDN] Fajman, Roger, "An Extensible Message Format for Message 1365 Disposition Notifications" 1367 [MIB II] M. Rose, "Management Information Base for Network Management of 1368 TCP/IP-based internets: MIB-II", RFC 1158, May 1990. 1370 [MIME1] N. Freed and N. Borenstein, "Multipurpose Internet Mail 1371 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 1372 2045, Innosoft, First Virtual, Nov 1996. 1374 [MIME2] N. Freed and N. Borenstein, "Multipurpose Internet Mail 1375 Extensions (MIME) Part Two: Media Types ", RFC 2046, Innosoft, First 1376 Virtual, Nov 1996. 1378 [MIME3] K. Moore, "Multipurpose Internet Mail Extensions (MIME) Part 1379 Three: Message Header Extensions for Non-ASCII Text ", RFC 2047, 1380 University of Tennessee, Nov 1996. 1382 [MIME4] N. Freed, J. Klensin and J. Postel, "Multipurpose Internet Mail 1383 Extensions (MIME) Part Four: Registration Procedures", RFC 2048, 1384 Innosoft, MCI, ISI, Nov 1996. 1386 [MIME5] N. Freed and N. Borenstein, "Multipurpose Internet Mail 1387 Extensions (MIME) Part Five: Conformance Criteria and Examples ", RFC 1388 2049, Innosoft, First Virtual, Nov 1996. 1390 [PIPE] Freed, N., Cargille, A., "SMTP Service Extension for Command 1391 Pipelining" RFC 1854, October 1995. 1393 [REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the 1394 Reporting of Mail System Administrative Messages", RFC 1892, 1395 01/15/1996. 1397 [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text 1398 Messages", STD 11, RFC 822, UDEL, August 1982. 1400 [SIZE] Klensin, J, Freed, N., Moore, K, "SMTP Service Extensions for 1401 Message Size Declaration" RFC 1870, United Nations University, 1402 Innosoft International, Inc., November 1995. 1404 [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 1405 USC/Information Sciences Institute, August 1982. 1407 [STATUS] Freed, N. "SMTP Service Extension for Returning Enhanced Error 1408 Codes", RFC 2034, 10/30/1996. 1410 [TIFF-F] G. Parsons and J. Rafferty, "Tag Image File Format: Class F", 1411 , March 1997. 1413 [V-MSG] G. Vaudreuil and G. Parsons, "VPIM Voice Message: MIME Sub- 1414 type Registration", , January 1997. 1416 [VCARD] Dawson, Frank, Howes, Tim, "An Application/Directory MIME 1417 Content-Type Electronic Business Card Profile" 1420 [VPIM1] Vaudreuil, Greg, "Voice Profile for Internet Mail", RFC 1911, 1421 Feb 1996. 1423 [X.400] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021 1424 and RFC 822", RFC 1327, May 1992. 1426 11. Security Consideration 1428 This document is a profile of existing Internet mail protocols. As 1429 such, it does not create any security issues not already existing in 1430 the profiled Internet mail protocols themselves. 1432 Further, the profile specified in this document does not in any way 1433 preclude the use of any Internet mail security protocol to encrypt, 1434 authenticate, or non-repudiate the messages. 1436 12. Acknowledgments 1438 The authors would like to offer a special thanks to the Electronic 1439 Messaging Association, especially the members of the Voice Messaging 1440 Committee, for their support of the VPIM specification and the efforts 1441 they have made to ensure its success. 1443 13. Authors' Addresses 1445 Glenn W. Parsons 1446 Nortel Technology 1447 P.O. Box 3511, Station C 1448 Ottawa, ON K1Y 4H7 1449 Canada 1450 Phone: +1-613-763-7582 1451 Fax: +1-613-763-8385 1452 Glenn.Parsons@Nortel.ca 1454 Gregory M. Vaudreuil 1455 Octel Communications 1456 17080 Dallas Parkway 1457 Dallas, TX 75248-1905 1458 United States 1459 Phone/Fax: +1-972-733-2722 1460 Greg.Vaudreuil@Octel.Com 1462 14. Appendix A - VPIM Requirements Summary 1464 The following table summarizes the profile of VPIM version 2 detailed 1465 in this document. For complete explanations of each feature it is 1466 recommended to read the accompanying text. The conformance table is 1467 separated into various columns: 1469 Feature - name of protocol feature (note that the indenting 1470 indicates a hierarchy of conformance, i.e. the 1471 conformance of a lower feature is only relevant if there 1472 is comformance to the higher feature) 1474 Section - reference section in main text of this document 1476 Area - conformance area to which each feature applies: 1477 C - content 1478 T - transport 1479 N - notifications 1481 Status - whether the feature is mandatory, optional, or prohibited. 1482 There are three different degrees of optional used in this table: 1483 Must - mandatory 1484 Should - encouraged optional 1485 May - optional 1486 Should not - discouraged optional 1487 Must not - prohibited 1489 Footnote - special comment about conformance for a particular 1490 feature 1491 VPIM version 2 Conformance 1492 | | | | |S| | 1493 | | | | | |H| |F 1494 | | | | | |O|M|o 1495 | | | |S| |U|U|o 1496 | | | |H| |L|S|t 1497 | |A|M|O| |D|T|n 1498 | |R|U|U|M| | |o 1499 | |E|S|L|A|N|N|t 1500 | |A|T|D|Y|O|O|t 1501 FEATURE |SECTION | | | | |T|T|e 1502 -------------------------------------------|----------|-|-|-|-|-|-|- 1503 | | | | | | | | 1504 Message Addressing Formats: | | | | | | | | 1505 Use DNS host names |4.1 |C|x| | | | | 1506 Use only numbers in mailbox IDs |4.1.1 |C| |x| | | | 1507 Use alpha-numeric mailbox IDs |4.1.1 |C| | |x| | | 1508 Support of postmaster@domain |4.1.2 |C|x| | | | | 1509 Support of non-mail-user@domain |4.1.2 |C| |x| | | | 1510 Support of distribution lists |4.1.3 |C| |x| | | | 1511 | | | | | | | | 1512 Message Header Fields: | | | | | | | | 1513 Encoding outbound messages | | | | | | | | 1514 From |4.2.1 |C|x| | | | | 1515 Addition of text name |4.2.1 |C| |x| | | | 1516 To |4.2.2 |C|x| | | | |1 1517 cc |4.2.3 |C| |x| | | |1 1518 Date |4.2.4 |C|x| | | | | 1519 Sender |4.2.5 |C| | |x| | | 1520 Return-Path |4.2.6 |C| | |x| | | 1521 Message-id |4.2.7 |C|x| | | | | 1522 Reply-To |4.2.8 |C| | |x| | | 1523 Received |4.2.9 |C|x| | | | | 1524 MIME Version: 1.0 (Voice 2.0) |4.2.10 |C| |x| | | | 1525 Content-Type |4.2.11 |C|x| | | | | 1526 Content-Transfer-Encoding |4.2.12 |C|x| | | | | 1527 Sensitivity |4.2.13 |C| | |x| | | 1528 Importance |4.2.14 |C| | |x| | | 1529 Subject |4.2.15 |C| |x| | | | 1530 Disposition-notification-to |4.2.16 |N| | |x| | | 1531 Other Headers |4.2 |C| | |x| | | 1532 | | | | | | | | 1533 | | | | |S| | 1534 | | | | | |H| |F 1535 | | | | | |O|M|o 1536 | | | |S| |U|U|o 1537 | | | |H| |L|S|t 1538 | |A|M|O| |D|T|n 1539 | |R|U|U|M| | |o 1540 | |E|S|L|A|N|N|t 1541 | |A|T|D|Y|O|O|t 1542 FEATURE |SECTION | | | | |T|T|e 1543 -------------------------------------------|----------|-|-|-|-|-|-|- 1544 Detection & Decoding inbound messages | | | | | | | | 1545 From |4.2.1 |C|x| | | | | 1546 Present text personal name |4.2.1 |C| | |x| | | 1547 To |4.2.2 |C|x| | | | | 1548 cc |4.2.3 |C| | |x| | | 1549 Date |4.2.4 |C|x| | | | | 1550 Conversion of Date to local time |4.2.4 |C| |x| | | | 1551 Sender |4.2.5 |C| | |x| | | 1552 Return-Path |4.2.6 |C| | |x| | | 1553 Message ID |4.2.7 |C|x| | | | | 1554 Reply-To |4.2.8 |C|x| | | | | 1555 Received |4.2.9 |C| | |x| | | 1556 MIME Version: 1.0 (Voice 2.0) |4.2.10 |C| |x| | | | 1557 Content Type |4.2.11 |C|x| | | | | 1558 Content-Transfer-Encoding |4.2.12 |C|x| | | | | 1559 Sensitivity |4.2.13 |C|x| | | | |2 1560 Importance |4.2.14 |C| | |x| | | 1561 Subject |4.2.15 |C| | |x| | | 1562 Disposition-notification-to |4.2.16 |N| | |x| | | 1563 Other Headers |4.2 |C|x| | | | |3 1564 | | | | | | | | 1565 Message Content Encoding: | | | | | | | | 1566 Encoding outbound audio/fax contents | | | | | | | | 1567 7BITMIME |4.3 |C| | | | |x| 1568 8BITMIME |4.3 |C| | | | |x| 1569 Quoted Printable |4.3 |C| | | | |x| 1570 Base64 |4.3 |C|x| | | | |4 1571 Binary |4.3 |C| |x| | | |5 1572 Detection & decoding inbound messages | | | | | | | | 1573 7BITMIME |4.3 |C|x| | | | | 1574 8BITMIME |4.3 |C|x| | | | | 1575 Quoted Printable |4.3 |C|x| | | | | 1576 Base64 |4.3 |C|x| | | | | 1577 Binary |4.3 |C|x| | | | |5 1578 | | | | | | | | 1579 | | | | |S| | 1580 | | | | | |H| |F 1581 | | | | | |O|M|o 1582 | | | |S| |U|U|o 1583 | | | |H| |L|S|t 1584 | |A|M|O| |D|T|n 1585 | |R|U|U|M| | |o 1586 | |E|S|L|A|N|N|t 1587 | |A|T|D|Y|O|O|t 1588 FEATURE |SECTION | | | | |T|T|e 1589 -------------------------------------------|----------|-|-|-|-|-|-|- 1590 Message Content Types: | | | | | | | | 1591 Inclusion in outbound messages | | | | | | | | 1592 Multipart/Voice-Message |4.3.1 |C|x| | | | | 1593 Message/RFC822 |4.3.2 |C| | |x| | | 1594 Application/Directory |4.3.3 |C| |x| | | | 1595 include TEL, EMAIL |4.3.3 |C|x| | | | | 1596 include N, ROLE, SOUND, REV |4.3.3 |C| |x| | | | 1597 only one per level |4.3.3 |C|x| | | | | 1598 Audio/32KADPCM |4.3.4 |C|x| | | | | 1599 Content-Description |4.3.4.1 |C| | |x| | | 1600 Content-Disposition |4.3.4.2 |C|x| | | | | 1601 Content-Duration |4.3.4.3 |C| | |x| | | 1602 Content-Langauge |4.3.4.4 |C| | |x| | | 1603 Image/TIFF; class=F |4.3.5 |C| | |x| | | 1604 Audio/* or Image/* (other encodings) |4.3.6 |C| | |x| | | 1605 Multipart/Mixed |4.4.1 |C| | |x| | | 1606 Text/plain |4.4.2 |C| | | |x| | 1607 Multipart/Report |4.4.3 |N|x| | | | | 1608 human-readable part is voice |4.4.3 |N|x| | | | |8 1609 Message/delivery-status |4.4.4 |N|x| | | | | 1610 Message/disposition-notification |4.4.5 |N| |x| | | | 1611 Other contents |4.4 |C| | | |x| |6 1612 | | | | | | | | 1613 Detection & decoding in inbound messages | | | | | | | | 1614 Multipart/Voice-Message |4.3.1 |C|x| | | | | 1615 Message/RFC822 |4.3.2 |C|x| | | | | 1616 Application/Directory |4.3.3 |C| |x| | | | 1617 recognize TEL, EMAIL |4.3.3 |C|x| | | | | 1618 recognize N, ROLE, SOUND, REV |4.3.3 |C| |x| | | | 1619 Audio/32KADPCM |4.3.4 |C|x| | | | | 1620 Content-Description |4.3.4.1 |C| | |x| | | 1621 Content-Disposition |4.3.4.2 |C| |x| | | | 1622 Content-Duration |4.3.4.3 |C| | |x| | | 1623 Content-Langauge |4.3.4.4 |C| | |x| | | 1624 Image/TIFF; class=F |4.3.5 |C| |x| | | | 1625 send NDN if unable to render |4.3.5 |C|x| | | | |7 1626 Audio/* or Image/* (other encodings) |4.3.6 |C| | |x| | | 1627 Multipart/Mixed |4.4.1 |C|x| | | | | 1628 Text/plain |4.4.2 |C|x| | | | | 1629 send NDN if unable to render |4.4.2 |N|x| | | | | 1630 Multipart/Report |4.4.3 |N|x| | | | | 1631 human-readable part is voice |4.4.3 |N|x| | | | |8 1632 | | | | | | | | 1634 | | | | | |S| | 1635 | | | | | |H| |F 1636 | | | | | |O|M|o 1637 | | | |S| |U|U|o 1638 | | | |H| |L|S|t 1639 | |A|M|O| |D|T|n 1640 | |R|U|U|M| | |o 1641 | |E|S|L|A|N|N|t 1642 | |A|T|D|Y|O|O|t 1643 FEATURE |SECTION | | | | |T|T|e 1644 ------------------------------------------|-----------|-|-|-|-|-|-|- 1645 | | | | | | | | 1646 Message/delivery-status |4.4.4 |N|x| | | | | 1647 Message/disposition-notification |4.4.5 |N| |x| | | | 1648 Other contents |4.4 |C| | | |x| |6 1649 send NDN if unable to render |4.4 |N| |x| | | | 1650 | | | | | | | | 1651 Forwarded Messages | | | | | | | | 1652 use Message/RFC822 construct |4.5 |C| |x| | | | 1653 simulate headers if none available |4.5 |C| |x| | | | 1654 | | | | | | | | 1655 Reply Messages | | | | | | | | 1656 send to Reply-to, else From address |4.6 |C|x| | | | | 1657 do not send to non-mail-user |4.6 |C|x| | | | | 1658 | | | | | | | | 1659 Notifications | | | | | | | | 1660 use mulitpart/report format |4.7 |N|x| | | | | 1661 always send error on non-delivery |4.7 |C| |x| | | | 1662 | | | | | | | | 1663 Message Transport Protocol: | | | | | | | | 1664 ESMTP Commands | | | | | | | | 1665 HELO |5.1.1 |T|x| | | | | 1666 MAIL FROM |5.1.2 |T|x| | | | | 1667 support null address |5.1.2 |T|x| | | | | 1668 RCPT TO |5.1.3 |T|x| | | | | 1669 DATA |5.1.4 |T|x| | | | | 1670 TURN |5.1.5 |T| | | | |x| 1671 QUIT |5.1.6 |T|x| | | | | 1672 RSET |5.1.7 |T|x| | | | | 1673 VRFY |5.1.8 |T| | |x| | | 1674 EHLO |5.1.9 |T|x| | | | | 1675 BDAT |5.1.10 |T| |x| | | |5 1676 ESMTP Keywords & Parameters | | | | | | | | 1677 PIPELINING |5.2.1 |T| |x| | | | 1678 SIZE |5.2.2 |T|x| | | | | 1679 CHUNKING |5.2.3 |T| |x| | | | 1680 BINARYMIME |5.2.4,5.3.1|T| |x| | | | 1681 DSN |5.2.5 |N|x| | | | | 1682 ENHANCEDSTATUSCODES |5.2.6 |N| |x| | | | 1683 RET |5.3.2 |N| |x| | | | 1684 ENVID |5.3.3 |N| | |x| | | 1685 NOTIFY |5.4.1 |N|x| | | | | 1686 ORCPT |5.4.2 |N| | |x| | | 1687 | | | | | | | | 1688 | | | | |S| | 1689 | | | | | |H| |F 1690 | | | | | |O|M|o 1691 | | | |S| |U|U|o 1692 | | | |H| |L|S|t 1693 | |A|M|O| |D|T|n 1694 | |R|U|U|M| | |o 1695 | |E|S|L|A|N|N|t 1696 | |A|T|D|Y|O|O|t 1697 FEATURE |SECTION | | | | |T|T|e 1698 -------------------------------------------|----------|-|-|-|-|-|-|- 1699 | | | | | | | | 1700 ESMTP-SMTP Downgrading | | | | | | | | 1701 send delivery report upon downgrade | 1702 | | | | | | | | 1703 Directory Address Resolution | | | | | | | | 1704 provide facility to resolve addresses |6 |C| |x| | | | 1705 use Vcards to populate local directory |6 |C|x| | | | |9 1706 use headers to populate local directory |6 |C| | | |x| | 1707 | | | | | | | | 1708 Management Protocols: | | | | | | | | 1709 Network management |8.1 |T| |x| | | | 1710 -------------------------------------------|----------|-|-|-|-|-|-|- 1712 Footnotes: 1714 1. MUST NOT include if all recipients are not known or resolvable. 1715 2. If a sensitive message is received by a system that does not 1716 support sensitivity, then it MUST be returned to the originator 1717 with an appropriate error notification. Also, a received 1718 sensitive message MUST NOT be forwarded to anyone. 1719 3. If the addtional headers are not understood they MAY be ignored 1720 4. When binary transport is not available 1721 5. When binary transport is available 1722 6. Other un-profiled contents must only be sent by bilateral 1723 agreement. 1724 7. If the content cannot be presented in some form, the entire 1725 message MUST be non-delivered. 1726 8. If the message is a "VPIM Message", else it MAY be text 1727 9. When the vCard is present in a message 1729 15. Appendix B - Example Voice Messages 1731 The following message is a full-featured message addressed to two 1732 recipients. The message includes the sender's spoken name and a short 1733 speech segment. The message is marked as important and private. 1735 To: +19725551212@vm1.mycompany.com 1736 To: +16135551234@VM1.mycompany.com 1737 From: "Parsons, Glenn" <12145551234@VM2.mycompany.com> 1738 Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT) 1739 MIME-Version: 1.0 (Voice 2.0) 1740 Content-type: Multipart/Voice-Message; Version=2.0; 1741 Boundary="MessageBoundary" 1742 Content-Transfer-Encoding: 7bit 1743 Message-ID: VM2.mycompany.com-123456789 1744 Sensitivity: Private 1745 Importance: High 1747 --MessageBoundary 1748 Content-type: Audio/32KADPCM 1749 Content-Transfer-Encoding: Base64 1750 Content-Disposition: inline; voice=Originator-Spoken-Name 1751 Content-Language: EN-US 1752 Content-ID: part1@VM2-4321 1754 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1755 (This is a sample of the base-64 Spoken Name data) fgdhgd 1756 dlkgpokpeowrit09== 1758 --MessageBoundary 1759 Content-type: Audio/32KADPCM 1760 Content-Transfer-Encoding: Base64 1761 Content-Description: Brand X Voice Message 1762 Content-Disposition: inline; voice= Voice-Message 1763 Content-Duration: 25 1765 iIiIiIjMzN3czdze3s7d7fwfHhcvESJVe/4yEhLz8/FOQjVFRERCESL/zqrq 1766 (This is a sample of the base64 message data) zb8tFdLTQt1PXj 1767 u7wjOyRhws+krdns7Rju0t4tLF7cE0K0MxOTOnRW/Pn30c8uHi9== 1769 --MessageBoundary 1770 Content-type: Application/Directory 1771 Content-Transfer-Encoding: 7bit 1773 BEGIN:VCARD 1774 N:Parsons;Glenn;;Mr.; 1775 EMAIL;TYPE=INTERNET:+12145551234@VM2.mycompany.com 1776 TEL:+1-217-555-1234 1777 SOUND;TYPE=32KADPCM;ENCODING=BASE64;VALUE=CID: 1778 REV:19951031T222710Z 1779 END:VCARD 1781 --MessageBoundary-- 1782 The following message is a forwarded single segment voice. Both the 1783 forwarded message and the forwarding message contain VCARDs with 1784 spoken names. 1786 To: +12145551212@vm1.mycompany.com 1787 From: "Vaudreuil, Greg" <+19725552345@VM2.mycompany.com> 1788 Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT) 1789 MIME-Version: 1.0 (Voice 2.0) 1790 Content-type: Multipart/Voice-Message; Version=2.0; 1791 Boundary="MessageBoundary" 1792 Content-Transfer-Encoding: 7bit 1793 Message-ID: VM2.mycompany.com-123456789 1795 --MessageBoundary 1796 Content-type: Audio/32KADPCM 1797 Content-Transfer-Encoding: Base64 1798 Content-Disposition: inline; voice=Originator-Spoken-Name 1799 Content-Language: EN-US 1800 Content-ID: part3@VM2-4321 1802 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1803 (This is a sample of the base-64 Spoken Name data) fgdhgd 1804 dlkgpokpeowrit09== 1806 --MessageBoundary 1807 Content-type: Audio/32KADPCM 1808 Content-Description: Forwarded Message Annotation 1809 Content-Disposition: inline; voice=Voice-Message 1810 Content-Transfer-Encoding: Base64 1812 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1813 (This is the voiced introductory remarks encoded in base64) 1814 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW 1815 dlkgpokpeowrit09== 1817 --MessageBoundary 1818 Content-type: Message/RFC822 1819 Content-Transfer-Encoding: 7bit 1821 To: +19725552345@VM2.mycompany.com 1822 From: "Parsons, Glenn, W." <+16135551234@VM1.mycompany.com> 1823 Date: Mon, 26 Aug 93 8:23:10 -0500 (EST) 1824 Content-type: Multipart/Voice-Message; Version=2.0; 1825 Boundary="MessageBoundary2" 1826 Content-Transfer-Encoding: 7bit 1827 MIME-Version: 1.0 (Voice 2.0) 1828 --MessageBoundary2 1829 Content-type: Audio/32KADPCM 1830 Content-Transfer-Encoding: Base64 1831 Content-Disposition: inline; voice=Originator-Spoken-Name 1832 Content-Language: EN-US 1833 Content-ID: part6@VM2-4321 1835 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1836 (This is a sample of the base-64 Spoken Name data) fgdhgd 1837 dlkgpokpeowrit09== 1839 --MessageBoundary2 1840 Content-type: Audio/32KADPCM 1841 Content-Disposition: inline; voice=Voice-Message 1842 Content-Transfer-Encoding: Base64 1844 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1845 (This is the original message audio data) fgwersdfmniwrjj 1846 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW 1847 dlkgpokpeowrit09== 1849 --MessageBoundary2 1850 Content-type: Application/Directory 1851 Content-Transfer-Encoding: 7bit 1853 BEGIN:VCARD 1854 N:Parsons;Glenn;W;Mr.; 1855 EMAIL;TYPE=INTERNET:+16135551234@VM2.mycompany.com 1856 TEL:+1-613-555-1234 1857 SOUND;TYPE=32KADPCM;ENCODING=BASE64;VALUE=CID: 1858 REV:19951031T222710Z 1859 END:VCARD 1861 --MessageBoundary2-- 1863 --MessageBoundary 1864 Content-type: Application/Directory 1865 Content-Transfer-Encoding: 7bit 1867 BEGIN:VCARD 1868 N:Vaudreuil;Greg;;Mr.; 1869 SOUND;TYPE=32KBADPCM;ENCODING=BASE64;VALUE=CID: 1870 EMAIL;TYPE=INTERNET;VPIM:+19725552345@VM2.mycompany.com 1871 TEL:+1-972-555-2345 1872 REV:19951031T222710Z 1873 END:VCARD 1875 --MessageBoundary-- 1876 The following example is for a message returned to the sender by a 1877 VPIM gateway at VM1.company.com for a mailbox which does not exist. 1879 Date: Thu, 7 Jul 1994 17:16:05 -0400 1880 From: Mail Delivery Subsystem 1881 Message-Id: <199407072116.RAA14128@vm1.company.com> 1882 Subject: Returned voice message 1883 To: 2175552345@VM2.mycompany.com 1884 MIME-Version: 1.0 (Voice 2.0) 1885 Content-Type: multipart/report; report-type=delivery-status; 1886 boundary="RAA14128.773615765/VM1.COMPANY.COM" 1888 --RAA14128.773615765/VM1.COMPANY.COM 1889 Content-type: Audio/32KADPCM 1890 Content-Description: Spoken Delivery Status Notification 1891 Content-Disposition: inline; voice= Voice-Message-Notification 1892 Content-Transfer-Encoding: Base64 1894 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd 1895 (This is a voiced description of the error in base64) 1896 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW 1897 dlkgpokpeowrit09== 1899 --RAA14128.773615765/VM1.COMPANY.COM 1900 content-type: message/delivery-status 1902 Reporting-MTA: dns; vm1.company.com 1904 Original-Recipient: rfc822; 2145551234@VM1.mycompany.com 1905 Final-Recipient: rfc822; 2145551234@VM1.mycompany.com 1906 Action: failed 1907 Status: 5.1.1 (User does not exist) 1908 Diagnostic-Code: smtp; 550 Mailbox not found 1909 Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400 1911 --RAA14128.773615765/VM1.COMPANY.COM 1912 content-type: message/rfc822 1914 [original VPIM message goes here] 1916 --RAA14128.773615765/VM1.COMPANY.COM-- 1918 16. Appendix C - Example Error Voice Processing Error Codes 1920 The following common voice processing errors and their corresponding 1921 status codes are given as examples. Text after the error codes are 1922 intended only for reference to describe the error code. 1923 Implementations should provide implementation specific informative 1924 comments after the error code rather than the text below. 1926 Error condition RFC 1893 Error codes 1927 ----------------------------- ---------------------------------- 1929 Analog delivery failed 4.4.0 Persistent connection error 1930 because remote system is busy - other 1932 Analog delivery failed 4.4.1 Persistent protocol error 1933 because remote system is - no answer from host 1934 ring-no-answer 1936 Remote system did not answer 5.5.5 Permanent protocol error 1937 AMIS-Analog handshake ("D" in - wrong version 1938 response to "C" at connect 1939 time) 1941 Mailbox does not exist 5.1.1 Permanent mailbox error 1942 - does not exist 1944 Mailbox full or over quota 4.2.2 Persistent mailbox error 1945 - full 1947 Disk full 4.3.1 Persistent system error 1948 - full 1950 Command out of sequence 5.5.1 Permanent protocol error 1951 - invalid command 1953 Frame Error 5.5.2 Permanent protocol error 1954 - syntax error 1956 Mailbox does not support FAX 5.6.1 Permanent media error 1957 - not supported 1959 Mailbox does not support TEXT 5.6.1 Permanent media error 1960 - not supported 1962 Sender is not authorized 5.7.1 Permanent security error 1963 - sender not authorized 1965 Message marked private, but 5.3.3 Permanent system error 1966 system is not private capable - not feature capable 1968 17. Appendix D - Change History: RFC 1911 to this Document 1970 The updated profile in this document is based on the experience of a 1971 proof of concept demonstration of VPIM at EMA'96 in April 1996. This 1972 version of the profile is significantly different from the previous 1973 described in [VPIM1]. The changes are categorized as general, 1974 content, transport and conformance. They are detailed below: 1976 1. General 1978 - All definitions are now contained in separate documents that are 1979 referenced by this profile. The new documents include: 1981 - a refined multipart/voice-message definition 1983 - a refined (i.e. added nibble order) audio/32KADPCM definition 1985 - the refined definition for image/TIFF for fax images (includes 1986 tag defaults for Class F) 1988 - the Content-Duration definition 1990 - Changed the Voice version to 2.0 1992 - Added Table of Contents and more examples 1994 - Various editorial updates to improve readability 1996 2. Content 1998 - Modified multipart/voice-message content by dropping the 1999 positional dependence of contents 2001 - Explicitly defined the forwarding model using message/RFC822 2003 - Explained the use of reply-to and from headers for addressing 2004 message replies 2006 - Deprecated the special `loopback' address because of security 2007 concerns and its use only for testing 2009 - Defined the non-mail-user reserved address to support the case in 2010 which replies to the originator are not possible 2012 - Eliminated the text name in the "To" and "CC" headers. 2013 Deprecated ordering of text names in the "From" header. 2015 - Added support for facsimile using the refined image/TIFF; class=F 2016 content 2018 - Profiled the vCard in the application/directory body part for 2019 transport of directory information about the originator 2021 - Loosened text restriction 2022 - Added additional details on delivery and receipt notifications 2024 - Added suggested addressing formats 2026 - Described handling of private messages 2028 - Described the handling of non-profiled contents in VPIM messages 2030 - Described the use of Content-Disposition to semantically identify 2031 audio contents 2033 3. Transport 2035 - Moved binary support to optional 2037 - Added optional ESMTP keywords for return of content, enhanced 2038 status codes, original recipient, and envelope ID 2040 - Described use of null MAIL FROM address 2042 4. Compliance 2044 - Added an explicit section on conformance allowing conformance to 2045 all or any of three conformance areas 2047 - Improved conformance table