idnits 2.17.1 draft-ema-vpim-04.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 442 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 307: '...x named "postmaster" MUST exist on all...' RFC 2119 keyword, line 322: '... this special address MUST send a non-...' RFC 2119 keyword, line 347: '...a result, recipient information MAY be...' RFC 2119 keyword, line 349: '... the recipient headers MUST be omitted...' RFC 2119 keyword, line 363: '...m. VPIM systems MUST be able to accep...' (129 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 (January 22, 1997) is 9949 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 228, but not defined == Missing Reference: 'X400' is mentioned on line 573, but not defined == Unused Reference: '8BIT' is defined on line 1242, but no explicit reference was found in the text == Unused Reference: 'AMIS-A' is defined on line 1251, but no explicit reference was found in the text == Unused Reference: 'AMIS-D' is defined on line 1254, but no explicit reference was found in the text == Unused Reference: 'DNS1' is defined on line 1270, but no explicit reference was found in the text == Unused Reference: 'DNS2' is defined on line 1273, but no explicit reference was found in the text == Unused Reference: 'E164' is defined on line 1285, but no explicit reference was found in the text == Unused Reference: 'G726' is defined on line 1294, but no explicit reference was found in the text == Unused Reference: 'MIME5' is defined on line 1319, 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) ** Obsolete normative reference: RFC 1158 (ref. 'MIB II') (Obsoleted by RFC 1213) -- Duplicate reference: RFC2046, mentioned in 'MIME4', was also mentioned in 'MIME2'. -- Duplicate reference: RFC2046, mentioned in 'MIME5', was also mentioned in 'MIME4'. ** 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: 25 errors (**), 0 flaws (~~), 15 warnings (==), 16 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Greg Vaudreuil 3 Internet Draft Octel Communications 4 Expires in six months Glenn Parsons 5 Obsoletes: RFC 1911 Nortel Technology 6 January 22, 1997 8 Voice Profile for Internet Mail - version 2 10 12 Status of this Memo 14 This document is an Internet Draft. Internet Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its Areas, 16 and its Working Groups. Note that other groups may also distribute 17 working documents as Internet Drafts. 19 Internet Drafts are valid for a maximum of six months and may be 20 updated, replaced, or obsoleted by other documents at any time. It is 21 inappropriate to use Internet Drafts as reference material or to cite 22 them other than as a "work in progress". 24 To learn the current status of any Internet-Draft, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 27 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 28 ftp.isi.edu (US West Coast). 30 Overview 32 This document profiles Internet mail for voice messaging. It 33 obsoletes RFC 1911 which describes version 1 of the profile. A list 34 of changes from that document are noted in Appendix D. As well, 35 Appendix A summarizes the protocol profiles of this version of VPIM. 37 Please send comments on this document to the EMA VPIM Work Group 38 mailing list: 40 Working Group Summary 42 This profile was not reviewed by an active IETF working group. 43 However, it has been reviewed by the VPIM Work Group of the Electronic 44 Messaging Association (EMA). This work group, which has 45 representatives from most major voice mail vendors, has held an 46 interoperability demonstration between voice messaging vendors and 47 received comments from traditional messaging vendors. 49 Table of Contents 51 1. ABSTRACT ............................................................3 52 2. SCOPE ...............................................................4 53 2.1 Voice Messaging System Limitations ...............................4 54 2.2 Design Goals .....................................................5 55 3. PROTOCOL RESTRICTIONS ...............................................6 56 4. VOICE MESSAGE INTERCHANGE FORMAT ....................................7 57 4.1 Message Addressing Formats .......................................7 58 4.2 Message Header Fields ............................................9 59 4.3 Voice Message Content Types .....................................14 60 4.4 Other Message Content Types .....................................18 61 4.5 Forwarded Messages ..............................................20 62 4.6 Reply Messages ..................................................20 63 5. MESSAGE TRANSPORT PROTOCOL .........................................21 64 5.1 ESMTP Commands ..................................................21 65 5.2 ESMTP Keywords ..................................................23 66 5.3 ESMTP Parameters - MAIL FROM ....................................24 67 5.4 ESMTP Parameters - RCPT TO ......................................24 68 5.5 ESMTP - SMTP Downgrading ........................................25 69 6. DIRECTORY ADDRESS RESOLUTION .......................................25 70 7. IMAP ...............................................................26 71 8. MANAGEMENT PROTOCOLS ...............................................26 72 8.1 Network Management ..............................................26 73 9. CONFORMANCE REQUIREMENTS ...........................................26 74 10. REFERENCES ........................................................27 75 11. SECURITY CONSIDERATION ............................................30 76 12. ACKNOWLEDGMENTS ...................................................30 77 13. AUTHORS' ADDRESSES ................................................30 78 14. APPENDIX A - VPIM REQUIREMENTS SUMMARY ............................31 79 15. APPENDIX B - EXAMPLE VOICE MESSAGES ...............................38 80 16. APPENDIX C _ EXAMPLE ERROR VOICE PROCESSING ERROR CODES ...........42 81 17. APPENDIX D - CHANGE HISTORY: RFC 1911 TO THIS DOCUMENT ............43 82 1. Abstract 84 A class of special-purpose computers has evolved to provide voice 85 messaging services. These machines generally interface to a telephone 86 switch and provide call answering and voice messaging services. 87 Traditionally, messages sent to a non-local machine are transported 88 using analog networking protocols based on DTMF signaling and analog 89 voice playback. As the demand for networking increases, there is a 90 need for a standard high-quality digital protocol to connect these 91 machines. The following document is a profile of the Internet 92 standard MIME and ESMTP protocols for use as a digital voice messaging 93 networking protocol. The profile is referred to as VPIM (Voice Profile 94 for Internet Mail) in this document. 96 This profile is based on earlier work in the Audio Message Interchange 97 Specification (AMIS) group that defined a voice messaging protocol 98 based on X.400 technology. This profile is intended to satisfy the 99 user requirements statement from that earlier work with the industry 100 standard ESMTP/MIME mail protocol infrastructures already used within 101 corporate intranets. This second version of VPIM is based on 102 implementation experience and obsoletes RFC 1911 which describes 103 version 1 of the profile. 105 2. Scope 107 MIME is the Internet multipurpose, multimedia messaging standard. 108 This document explicitly recognizes its capabilities and provides a 109 mechanism for the exchange of various messaging technologies, 110 primarily voice and facsimile. 112 This document specifies a restricted profile of the Internet 113 multimedia messaging protocols for use between voice processing 114 platforms. These platforms have historically been special-purpose 115 computers and often do not have the same facilities normally 116 associated with a traditional Internet Email-capable computer. As a 117 result, VPIM also specifies additional functionality as it is needed. 118 This profile is intended to specify the minimum common set of features 119 to allow interworking between compliant systems. 121 2.1 Voice Messaging System Limitations 123 The following are typical limitations of voice messaging platform 124 which were considered in creating this baseline profile. 126 1) Text messages are not normally received and often cannot be 127 displayed or viewed. They can often be processed only via text-to- 128 speech or text-to-fax features not currently present in many of 129 these machines. 131 2) Voice mail machines usually act as an integrated Message 132 Transfer Agent, Message Store and User Agent. There is limited 133 relaying of messages, and RFC 822 header fields may have limited 134 use in the context of the limited messaging features currently 135 deployed. 137 3) VM message stores are generally not capable of preserving the 138 full semantics of an Internet message. As such, use of a voice 139 mail machine for gatewaying is not supported. In particular, 140 storage of recipient lists, "Received" lines, and "Message-ID" may 141 be limited. 143 4) Internet-style distribution/mailing lists are not typically 144 supported. Voice mail machines often implement only local alias 145 lists, with error-to-sender and reply-to-sender behavior. Reply- 146 all capabilities using a CC list is not generally available. 148 5) Error reports must be machine-parsable so that helpful responses 149 can be voiced to users whose only access mechanism is a telephone. 151 6) The voice mail systems generally limit address entry to 16 or 152 fewer numeric characters, and normally do not support alphanumeric 153 mailbox names. Alpha characters are not generally used for mailbox 154 identification as they cannot be easily entered from a telephone 155 terminal. 157 2.2 Design Goals 159 It is a goal of this profile to make as few restrictions and additions 160 to the existing Internet mail protocols as possible while satisfying 161 the requirements for interoperability with current generation voice 162 messaging systems. This goal is motivated by the desire to increase 163 the accessibility to digital messaging by enabling the use of proven 164 existing networking software for rapid development. 166 This specification is intended for use on a TCP/IP network, however, 167 it is possible to use the SMTP protocol suite over other transport 168 protocols. The necessary protocol parameters for such use is outside 169 the scope of this document. 171 This profile is intended to be robust enough to be used in an 172 environment, such as the global Internet with installed-base gateways 173 which do not understand MIME, though typical use is expected to be 174 within corporate intranets. Full functionality, such as reliable 175 error messages and binary transport, will require careful selection of 176 gateways (e.g., via MX records) to be used as VPIM forwarding agents. 177 Nothing in this document precludes use of a general purpose MIME email 178 packages to read and compose VPIM messages. While no special 179 configuration is required to receive VPIM compliant messages, some may 180 be required to originate compliant structures. 182 It is expected that a VPIM messaging system will be managed by a 183 system administrator who can perform TCP/IP network configuration. 184 When using facsimile or multiple voice encodings, it is suggested that 185 the system administrator maintain a list of the capabilities of the 186 networked mail machines to reduce the sending of undeliverable 187 messages due to lack of feature support. Configuration, 188 implementation and management of this directory listing capabilities 189 is a local matter. 191 3. Protocol Restrictions 193 This protocol does not limit the number of recipients per message. 194 Where possible, implementations should not restrict the number of 195 recipients in a single message. It is recognized that no 196 implementation supports unlimited recipients, and that the number of 197 supported recipients may be quite low. However, ESMTP currently does 198 not provide a mechanism for indicating the number of supported 199 recipients. 201 This protocol does not limit the maximum message length. Implementors 202 should understand that some machines will be unable to accept 203 excessively long messages. A mechanism is defined in the RFC 1425 204 SMTP service extensions to declare the maximum message size supported. 206 The message size indicated in the ESMTP SIZE command is in bytes, not 207 minutes or seconds. The number of bytes varies by voice encoding 208 format and must include the MIME wrapper overhead. If the length must 209 be known before sending, an approximate translation into minutes or 210 seconds can be performed if the voice encoding is known. 212 The following sections describe the restrictions and additions to 213 Internet mail protocols that are required to be compliant with this 214 VPIM v2 profile. Though various SMTP, ESMTP and MIME features are 215 described here, the implementor is referred to the relevant RFCs for 216 complete details. It is also advisable to check for IETF drafts of 217 various Internet Mail specifications that are later than the most 218 recent RFCs since, for example, MIME has yet to be published as a full 219 IETF Standard. The table in Appendix A summarizes the protocol details 220 of this profile. 222 4. Voice Message Interchange Format 224 The voice message interchange format is a profile of the Internet Mail 225 Protocol Suite. As such, this document assumes an understanding of 226 these specifications. Specifically, VPIM references components from 227 the message format standard for Internet messages [RFC822], the 228 Multipurpose Internet Message Extensions [MIME], the X.400 gateway 229 specification [X.400], delivery status notification 230 [DSN][DRPT][STATUS], and the electronic business card 231 [DIRECTORY][VCARD]. 233 4.1 Message Addressing Formats 235 RFC 822 addresses are based on the domain name system. This naming 236 system has two components: the local part, used for username or 237 mailbox identification; and the host part, used for global machine 238 identification. 240 4.1.1 VPIM Addresses 242 The local part of the address shall be a US-ASCII string uniquely 243 identifying a mailbox on a destination system. For voice messaging, 244 the local part is a printable string containing the mailbox ID of the 245 originator or recipient. While alpha characters and long mailbox 246 identifiers are permitted, most voice mail networks rely on numeric 247 mailbox identifiers to retain compatibility with the limited 10 digit 248 telephone keypad. As a result, some voice messaging systems may only 249 be able to handle a numeric local part. The reception of alphanumeric 250 local parts on these systems may result in the address being mapped to 251 some locally unique (but confusing to the recipient) number or, in the 252 worst case the address could be deleted making the message un- 253 replyable. Additionally, it may be difficult to create messages on 254 these systems with an alphanumeric local part without complex key 255 sequences or some form of directory lookup (see 6). 257 The use of the domain naming system should be transparent to the user 258 of a telephone interface. It is the responsibility of the voice mail 259 machine to lookup the fully-qualified domain name (FQDN) based on the 260 numeric address entered by the user (see 6). 262 In the absence of a global directory, specification of the local part 263 is expected to conform to international or private telephone numbering 264 plans. It is likely that private numbering plans will prevail and 265 these are left for local definition. However, it is recommended that 266 public telephone numbers be noted according to the international 267 numbering plan described in [E.164]. The indication that the local 268 part is a public telephone number is given by a preceding `+' (the `+' 269 would not be entered from a telephone keypad, it is added by the 270 system as a flag). Since the primary information in the numeric 271 scheme is contained by the digits, other character separators (e.g. `- 272 ') may be ignored (i.e. to allow parsing of the numeric local mailbox) 273 or may be used to recognize distinct portions of the telephone number 274 (e.g. country code). The specification of the local part of a VPIM 275 address can be split into the four groups described below: 277 1) mailbox number 278 - for use as a private numbering plan (any number of digits) 279 - e.g. 2722@octel.com 281 2) mailbox number+extension 282 - for use as a private numbering plan with extensions 283 any number of digits, use of `+' as separator 284 - e.g. 2722+111@octel.com 286 3) +international number 287 - for international telephone numbers conforming to E.164 288 maximum of 15 digits 289 - e.g. +16137637582@vm.nortel.ca 291 4) +international number+extension 292 - for international telephone numbers conforming to E.164 293 maximum of 15 digits, with an extension (e.g. behind a 294 PBX) that has a maximum of 15 digits. 295 - e.g. +17035245550+230@ema.org 297 4.1.2 Special Addresses 299 Special addresses are provided for compatibility with the conventions 300 of Internet mail. These addresses do not use numeric local addresses, 301 both to conform to current Internet practice and to avoid conflict 302 with existing numeric addressing plans. Two special addresses are 303 RESERVED for use as follows: 305 postmaster@domain 307 By convention, a special mailbox named "postmaster" MUST exist on all 308 systems. This address is used for diagnostics and should be checked 309 regularly by the system manager. This mailbox is particularly likely 310 to receive text messages, which is not normal on a voice processing 311 platform. The specific handling of these messages is an individual 312 implementation choice. 314 non-mail-user@domain 316 If a reply to a message is not possible, such as a telephone answering 317 message, then the special address _non-mail-user_ must be used as the 318 originator's address. Any text name such as "Telephone Answering," or 319 the telephone number if it is available, is permitted. This special 320 address is used as a token to indicate an unreachable originator. For 321 compatibility with the installed base of mail user agents, 322 implementations that generate this special address MUST send a non- 323 delivery notification for reply messages sent to the undeliverable 324 address. The status code for such NDN's is 5.1.1 "Mailbox does not 325 exist". 327 Example: 329 From: Telephone Answering 331 4.1.3 Distribution Lists 333 There are many ways to handle distribution list (DL) expansions and 334 none are 'standard'. Simple alias is a behavior closest to what most 335 voice mail systems do today and what is to be used with VPIM messages. 336 That is: 338 Reply to the originator - (Address in the RFC822 Reply-to or From 339 field) 340 Errors to the submitter - (Address in the MAIL FROM: field of the 341 ESMTP exchange and the Return-Path: 342 RFC 822 field) 344 Most voice messaging systems provide only limited support for "Header 345 Information" in their messaging queues. Typical systems include 346 delivery envelope information and a few header attributes such as date 347 and per-message features. As a result, recipient information MAY be 348 in either the To or CC headers. If all recipients cannot be presented 349 (e.g. unknown DL expansion) then the recipient headers MUST be omitted 350 to indicate that an accurate list of recipients (e.g. for use with a 351 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 disclosed recipients are identified. The To header MUST 402 NOT be included in the message if the sending message transport agent 403 (MTA) cannot resolve all the addresses in it, e.g. if an address is a 404 DL alias for which the expansion is unknown (see 4.1.3). If present, 405 the addresses in the To and CC header MAY be used for a reply message 406 to all 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 are identified. If not, systems 421 SHOULD omit the To and Cc headers to indicate that the full list of 422 recipients is unknown. The list of disclosed recipients does not 423 include those sent via a blind copy. 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 -0600 for North 439 American Eastern Standard Time. This may be supplemented by a time 440 zone name in parentheses, e.g., "-0800 (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 -0900 (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 relay system SHOULD be 451 used as 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, if present, contains the address of the last 467 submitter of the message from the MAIL FROM parameter of the ESMTP 468 exchange (see 5.1.2). Error messages MUST be sent to this address 469 (see [DRPT] for additional details). Note that if the Return-path is 470 null ("<>"), e.g. no path, loop prevention or confidential, a 471 notification MUST NOT be sent. If the Return path address is not 472 available (either from this header or the MAIL FROM parameter) the 473 Sender or From addresses may be used to deliver notifications. 475 4.2.7 Message-id 477 The Message-id header contains a unique per-message identifier. A 478 unique message-id MUST be generated for each message sent from a 479 compliant implementation. 481 The message-id is not required to be stored on the receiving system. 482 This identifier MAY be used for tracking, auditing, and returning 483 read-receipt reports. From [RFC822] 485 Example: 487 Message-id: <12345678@mycompany.com> 489 4.2.8 Reply-To 491 If present, the reply-to header provides a preferred address to which 492 reply messages should be sent (see 4.6). If a reply-to header is 493 present, a reply-to sender message MUST be sent to the address 494 specified. From [RFC822] This preferred address of the originator 495 must also be provided in the originator's vCard EMAIL attribute, if 496 present (see 4.3.3). 498 4.2.9 Received 500 The Received header contains trace information added to the beginning 501 of a RFC 822 message by MTAs. This is the only header permitted to be 502 added by an MTA. Information in this header is useful for debugging 503 when using an US-ASCII message reader or a header parsing tool. 505 A compliant system MUST add Received headers when acting as a relay 506 and MUST NOT remove any. These headers MAY be ignored or deleted when 507 the message is received at the final destination. From [RFC822] 509 4.2.10 MIME Version 511 The MIME-Version header indicates that the message conforms to the 512 MIME message format specification. Systems compliant with this 513 specification SHOULD include a comment with the words "(Voice 2.0)". 514 RFC 1911 defines an earlier version of this profile and uses the token 515 (Voice 1.0). From [MIME1][VPIM1] 517 Example: 519 MIME-Version: 1.0 (Voice 2.0) 521 This identifier is intended for information only and SHOULD NOT be 522 used to semantically identify the message as being a VPIM message. 523 Instead, the presence of the content defined in [V-MSG] SHOULD be used 524 if identification is necessary. 526 4.2.11 Content-Type 528 The content-type header declares the type of content enclosed in the 529 message. The typical top level content in a VPIM Message SHOULD be 530 multipart/voice-message, a mechanism for bundling several components 531 into a single identifiable voice message. The allowable contents are 532 detailed in section 4.3 of this document. From [MIME2] 534 4.2.12 Content-Transfer-Encoding 536 Because Internet mail was initially specified to carry only 7-bit US- 537 ASCII text, it may be necessary to encode voice and fax data into a 538 representation suitable for that transport environment. The content- 539 transfer-encoding header describes this transformation if it is 540 needed. Compliant implementations MUST recognize and decode the 541 standard encodings, "Binary", "7bit, "8bit", "Base64" and "Quoted- 542 Printable". The allowable content-transfer-encodings are specified in 543 section 4.3. From [MIME1] 545 4.2.13 Sensitivity 547 The sensitivity header, if present, indicates the requested privacy 548 level. The case-insensitive values "Personal" and "Private" are 549 specified. If no privacy is requested, this field is omitted. 551 If a sensitivity header is present in the message, a compliant system 552 MUST prohibit the recipient from forwarding this message to any other 553 user. A compliant system, however, SHOULD allow the user to reply to 554 a sensitive message, but SHOULD NOT include the original message 555 content. The sensitivity of the reply message MAY be set by the user. 557 If the receiving system does not support privacy and the sensitivity 558 is one of "Personal" or "Private", the message MUST be returned to the 559 sender with an appropriate error code indicating that privacy could 560 not be assured and that the message was not delivered. A non-delivery 561 notification to a private message need not be tagged private since it 562 will be sent to the originator. From: [X.400] 564 4.2.14 Importance 566 Indicates the requested priority to be given by the receiving system. 567 The case-insensitive values "low", "normal" and "high" are specified. 568 If no special importance is requested, this header may be omitted and 569 the value assumed to be "normal". 571 Compliant implementations MAY use this header to indicate the 572 importance of a message and may order messages in a recipient's 573 mailbox. From: [X400] 575 4.2.15 Subject 577 The subject field is often provided by email systems but is not widely 578 supported on Voice Mail platforms. For compatibility with text based 579 mailbox interfaces, a text subject field SHOULD be generated by a 580 compliant implementation but MAY be discarded if present by a 581 receiving system. From [RFC822] 583 It is recommended that voice messaging systems that do not support any 584 text user interfaces (e.g. access only by a telephone) insert a 585 generic subject header of "VPIM Message" for the benefit of text 586 enabled recipients. 588 4.3 Voice Message Content Types 590 MIME, introduced in [MIME1], is a general-purpose message body format 591 that is extensible to carry a wide range of body parts. It provides 592 for encoding binary data so that it can be transported over the 7-bit 593 text-oriented SMTP protocol. This transport encoding is in addition 594 to the audio encoding required to generate a binary object. 596 MIME defines two transport encoding mechanisms to transform binary 597 data into a 7 bit representation, one designed for text-like data 598 ("Quoted-Printable"), and one for arbitrary binary data ("Base64"). 599 While Base64 is dramatically more efficient for audio data, both will 600 work. Where binary transport is available, no transport encoding is 601 needed, and the data can be labeled as "Binary". 603 An implementation in compliance with this profile SHOULD send audio 604 and/or facsimile data in binary form when binary message transport is 605 available. When binary transport is not available, implementations 606 MUST encode the audio and/or facsimile data as Base64. The detection 607 and decoding of "Quoted-Printable", "7bit", and "8bit" MUST be 608 supported in order to meet MIME requirements and to preserve 609 interoperability with the fullest range of possible devices. However, 610 if a content is received that cannot be rendered to the user, an 611 appropriate non-delivery notification MUST be sent. 613 The content types described in this section are identified for use 614 within the multipart/voice-message content. This content, which is 615 the fundamental part of a VPIM message, is referred to as a VPIM voice 616 message in this document. 618 Each of the contents profiled subsequently can be sent within a VPIM 619 voice message construct to form a simple or a more complex structure 620 (several examples are given in Appendix B). When multiple contents 621 are present within the multipart/voice-message, they SHOULD be 622 presented to the user in the order that they appear in the message. 624 4.3.1 Multipart/Voice-Message 626 This MIME multipart structure provides a mechanism for packaging a 627 voice message into one container that is tagged as VPIM v2 compliant. 628 The semantic of multipart/Voice-Message (defined in [V-MSG]) is 629 identical to multipart/mixed and may be interpreted as that by systems 630 that do not recognize this content-type. 632 The Multipart/Voice-Message content-type MUST only contain the 633 profiled media and content types specified in this section (i.e. 634 audio/*, image/*, message/rfc822 and application/directory). The most 635 common will be: spoken name, spoken subject, the message itself, 636 attached fax and directory info. Forwarded messages are created by 637 simply using the message/rfc822 construct. 639 Conformant implementations MUST send the Multipart/Voice-Message in a 640 VPIM message. In most cases, this Multipart/Voice-Message content 641 will be the top level (i.e. in the Content-Type header). Conformant 642 implementations MUST recognize the Multipart/Voice-Message content 643 (whether it is a top level content or below a mulitpart/mixed) and be 644 able to separate the contents (e.g. spoken name or spoken subject). 646 4.3.2 Message/RFC822 648 MIME requires support of the Message/RFC822 message encapsulation body 649 part. This body part is used within a multipart/voice-message to 650 forward complete messages (see 4.5) or to reply with original content 651 (see 4.6). From [MIME2] 653 4.3.3 Application/Directory 655 This content allows for the inclusion of a Versit vCard [VCARD] 656 electronic business card within a VPIM message. The format is 657 suitable as an interchange format between applications or systems, and 658 is defined independent of the method used to transport it. It 659 provides a useful mechanism to transport information about the 660 originator that can be used by the receiving VPIM system (see 6) or 661 other local applications. 663 Each VPIM message SHOULD be created with an Application/Directory 664 content type [DIRECTORY] that MUST contain the preferred address and 665 telephone number of the message originator and SHOULD contain the 666 spoken name and the spelled name of the originator. The intent is 667 that the vCard be used as the source of information to contact the 668 originator (e.g. reply, call). 670 If included in a VPIM message, the vCard profile [VCARD] MUST be used 671 and MUST specify at least the following attributes: 673 TEL - Public switched telephone number in international (E.164) 674 format (various types, typically VOICE) 675 EMAIL - email address (various types, typically INTERNET; the type 676 VPIM is optionally used to denote the address that supports 677 VPIM messages) 679 The following attributes SHOULD be specified: 681 N - Family Name, Given Name, Additional Names, Honorific 682 Prefixes, and Suffixes (all present components in the From 683 text name MUST match) 684 ROLE - the role of the person identified in `N', but may be used 685 as an alternative to the `N' attribute when the sender is a 686 corporate or positional mailbox 687 SOUND - spoken name sound data (various types, typically 32KADPCM) 688 REV - Revision of vCard in ISO 8601 date format 690 The vCard MAY use other attributes (e.g. capabilities) as defined in 691 [VCARD]. 693 If present, the spoken name attribute MUST be denoted by a content ID 694 pointing to an audio/* content elsewhere in the VPIM message. 696 A typical VPIM message (i.e. no forwarded parts), MUST only contain 697 one vCard -- more than one is an error condition. A VPIM message that 698 contains forwarded messages, though, may contain multiple vCards. 699 However, these vCards MUST be associated with the originator(s) of the 700 forwarded message(s) and the originator of the forwarding message. As 701 a result, all forwarded vCards will be contained in message/rfc822 702 contents -- only the vCard of forwarding originator will be at the 703 top-level. 705 Example: 707 BEGIN:VCARD 708 N:Parsons;Glenn 709 ORG:Nortel Technology 710 TEL;TYPE=VOICE,MSG,WORK:+1-613-763-7582 711 EMAIL;TYPE=INTERNET:glenn.parsons@nortel.ca 712 EMAIL;TYPE=INTERNET,VPIM:6137637582@vm.nortel.ca 713 SOUND;TYPE=32KADPCM;ENCODE=BASE64;VALUE=CID: 714 REV:19960831T103310Z 715 END:VCARD 717 4.3.4 Audio/32KADPCM 719 An implementation compliant to this profile MUST use Audio/32KADPCM by 720 default for voice [ADPCM]. Typically this body contains several 721 minutes of message content, however if used for spoken name or subject 722 the content should be considerably shorter (i.e. about 10 and 20 723 seconds respectively). 725 If an implementation can only handle one voice body, then multiple 726 voice bodies (if present) SHOULD be concatenated, and SHOULD NOT be 727 discarded. It is recommended that this be done in the same order as 728 they were sent. Note that if an Originator Spoken Name audio body and 729 a vCard are both present in a VPIM message, the vCard SOUND attribute 730 MUST point to this audio body (see 4.3.3). 732 While any valid MIME body header MAY be used, several headers have the 733 following semantics when included with this body part: 735 4.3.4.1 Content-Description: 737 This field MAY be present to facilitate the text identification of 738 these body parts in simple email readers. Any values may be used, 739 though it may be useful to use values similar to those for Content- 740 Disposition. 742 Example: 744 Content-Description: Big Telco Voice Message 746 4.3.4.2 Content-Disposition: 748 This field SHOULD be present to allow the parsable identification 749 of these body parts. If more than one Audio/32KADPCM body occurs 750 within a single level (e.g. multipart/voice-message), then this 751 header MUST be present to allow differentiation. Since a VPIM 752 voice message is intended to be automatically played upon display 753 of the message, in the order in which the audio contents occur, the 754 audio contents are always of type inline. From [DISP] 756 In order to distinguish between the various kinds of audio contents 757 in a VPIM voice message a new disposition parameter "voice" is 758 defined with the following values to be used as appropriate: 760 Voice-Message - the primary voice message, 761 Voice-Message-Notification - a spoken delivery notification, 762 Originator-Spoken-Name - the spoken name of the originator, 763 Recipient-Spoken-Name - the spoken name of the recipient if 764 available to the originator and present if there is ONLY one 765 recipient, 766 Spoken-Subject.- the spoken subject of the message, typically 767 spoken by the originator 769 Implementations that do not understand the "voice" parameter can 770 safely ignore it, and will present the audio bodyparts in order 771 (but will not be able to distinguish between them). 773 Example: 775 Content-Disposition: inline; voice=spoken-subject 777 4.3.4.3 Content-Duration: 779 This field MAY be present to allow the specification of the length 780 of the audio bodypart in seconds. The use of this field on 781 reception is a local implementation issue. From [DUR] 783 Example: 785 Content-Duration: 33 787 4.3.4.4 Content-Language: 789 This field MAY be present to allow the specification of the spoken 790 language of the audio bodypart. The encoding is defined in [LANG]. 791 The use of this field on reception is a local implementation issue. 793 Example for UK English: 795 Content-Language: EN-UK 797 4.3.5 Image/TIFF 799 A common image encoding for facsimile is a class of the Tag Image File 800 Format (TIFF) and is defined in [TIFF-F]. While there are several 801 variations of TIFF, only class F (denoted by the parameter class=F) is 802 profiled for use in a VPIM voice message. 804 All VPIM implementations that support facsimile MUST generate and read 805 TIFF-F compatible facsimile contents in the image/TIFF; Class=F sub- 806 type encoding by default. An implementation MAY send this fax content 807 in VPIM voice messages and MUST be able to recognize it in received 808 messages. If a fax message is received that cannot be rendered to the 809 user (e.g. the receiving VPIM system does not support fax), then the 810 system MUST non-deliver the entire message with a media not supported 811 error. 813 4.3.6 Proprietary Voice or Fax Formats 815 Proprietary voice or fax encoding formats or other standard formats 816 may be supported under this profile provided a unique identifier is 817 registered with the IANA prior to use (see [MIME4]). The voice 818 encodings should be registered as sub-types of Audio and the fax 819 encodings should be registered as sub-types of Image 821 Use of any other encoding except Audio/32KADPCM or Image/TIFF; class=F 822 reduces interoperability in the absence of explicit manual system 823 configuration. A compliant implementation MAY use any other encoding 824 with explicit per-destination configuration. 826 4.4 Other Message Content Types 828 An implementation compliant with this profile MAY send additional 829 contents in a VPIM message, but ONLY outside of the multipart/voice- 830 message. The content types described in this section are identified 831 for use with this profile. Contents not defined here MUST NOT be used 832 without prior explicit per-destination configuration. If an 833 implementation receives a VPIM message (i.e. MIME-Version: 1.0 (Voice 834 2.0)) that contains content types not specified in this profile, their 835 handling is a local implementation issue (e.g. the unknown contents 836 MAY be discarded if they cannot be presented to the recipient). 837 Conversely, if an implementation receives a non-VPIM message with any 838 of the contents defined in 4.3 & 4.4, it SHOULD deliver those 839 contents, but the full message handling is a local issue (e.g. the 840 unknown contents _or_ the entire message MAY be discarded). It is 841 recommended that implementations issue notifications to the originator 842 when any form of non-delivery to the recipient occurs. 844 Each of the contents defined below can be sent individually in a VPIM 845 message or wrapped in a multipart/mixed to form a more complex 846 structure (several examples are given in Appendix B). When multiple 847 contents are present, they SHOULD be presented to the user in the 848 order that they appear in the message. 850 4.4.1 Multipart/Mixed 852 MIME provides the facilities for enclosing several body parts in a 853 single message. Multipart/Mixed SHOULD only be used for sending 854 complex voice or multimedia messages. That is, as the top level 855 Content-Type when sending one of the following contents (in addition 856 to the VPIM voice message) in a VPIM message. Compliant systems MUST 857 accept multipart/mixed body parts. From [MIME2] 859 4.4.2 Text/Plain 861 MIME requires support of the basic Text/Plain content type. This 862 content type has limited applicability within the voice messaging 863 environment. Compliant implementations SHOULD NOT send the Text/Plain 864 content-type, but SHOULD only send this content if the recipient 865 system is known to support it. Compliant implementations MUST accept 866 Text/Plain messages, however, specific handling is left as an 867 implementation decision. From [MIME2] 869 There are several mechanisms that can be used to support text on voice 870 messaging systems including text-to-speech and text-to-fax 871 conversions. If no rendering of the text is possible (i.e. it is not 872 possible for the recipient to determine if the text is a critical part 873 of the message), the entire message MUST be non-delivered and returned 874 to the sender with a media-unsupported error code. 876 4.4.3 Multipart/report 878 The Multipart/Report is used for enclosing human-readable and machine 879 parsable notification (e.g. Message/delivery-status) body parts and 880 any returned message content. Compliant implementations MUST use the 881 Multipart/Report construct when returning messages, sending warnings, 882 or issuing read receipts. Compliant implementations MUST recognize 883 and decode the Multipart/Report content type. From [REPORT] 885 Multipart/Report messages that are VPIM messages (i.e. MIME-Version: 886 1.0 (Voice 2.0)) MUST include the human-readable description of the 887 error as a spoken audio/* content. Note that VPIM implementations 888 MUST be able to handle (and MAY generate) Multipart/Report messages 889 that encode the human-readable description of the error text. 891 4.4.4 Message/delivery-status 893 This MIME body part is used for sending machine-parsable delivery 894 status notifications. Compliant implementations must use the 895 Message/delivery-status construct when returning messages or sending 896 warnings. Compliant implementations must recognize and decode the 897 Message/delivery-status content type and present the reason for 898 failure to the user. From [DSN] 900 4.5 Forwarded Messages 902 VPIM version 2 explicitly supports the forwarding of voice and fax 903 content with voice or fax annotation. Forwarded VPIM messages SHOULD 904 be sent as a multipart/voice-message with the entire original message 905 enclosed in a message/rfc822 content type and the annotation as a 906 separate Audio/* or image/TIFF body part. 908 In the event that the RFC822 headers are not available for the 909 forwarded content, simulated headers with information as available 910 SHOULD be constructed to indicate the original sending timestamp, and 911 the original sender as indicated in the "From" line. The 912 message/rfc822 content MUST include at least the MIME-Version: 1.0 913 (Voice 2.0), the MIME content type and MIME content-encoding header as 914 necessary. From [MIME2] 916 In the event that forwarding information is lost through concatenation 917 of the original message and the forwarding annotation, such as must be 918 done in agateway between VPIM and the AMIS voice messaging protocol, 919 the entire content MAY be sent as a single Audio/* segment without 920 including any forwarding semantics. 922 4.6 Reply Messages 924 Replies to VPIM messages (and Internet mail messages) are addressed to 925 the address noted in the reply-to header (see 4.2.8) if it is present, 926 else the From address (see 4.2.1) is used. Support of multiple 927 originator headers is often not possible on voice messaging systems, 928 so it may be necessary to choose only one. However, implementors 929 should note that this may make it impossible to send error messages 930 and replies to the proper destination. 932 In some cases, a reply message is not possible, such as with a message 933 created by telephone answering (i.e. classic voice mail). In this 934 case, the From field MUST contain the special address non-mail- 935 user@domain (see 4.1.2). The use of a null ESMTP MAIL FROM address 936 SHOULD also be used in this case (see 5.1.2). A receiving VPIM system 937 SHOULD not offer the user the option to reply to this kind of message. 939 5. Message Transport Protocol 941 Messages are transported between voice mail machines using the 942 Internet Extended Simple Mail Transfer Protocol (ESMTP). All 943 information required for proper delivery of the message is included in 944 the ESMTP dialog. This information, including the sender and 945 recipient addresses, is commonly referred to as the message 946 "envelope". This information is equivalent to the message control 947 block in many analog voice networking protocols. 949 ESMTP is a general-purpose messaging protocol, designed both to send 950 mail and to allow terminal console messaging. Simple Mail Transport 951 Protocol (SMTP) was originally created for the exchange of US-ASCII 7- 952 bit text messages. Binary and 8-bit text messages have traditionally 953 been transported by encoding the messages into a 7-bit text-like form. 954 [ESMTP] formalized an extension mechanism for SMTP, and subsequent 955 RFCs have defined 8-bit text networking, command streaming, binary 956 networking, and extensions to permit the declaration of message size 957 for the efficient transmission of large messages such as multi-minute 958 voice mail. 960 The following sections list ESMTP commands, keywords, and parameters 961 that are required and those that are optional for conformance to this 962 profile. 964 5.1 ESMTP Commands 966 5.1.1 HELO 968 Base SMTP greeting and identification of sender. This command is not 969 to be sent by compliant systems unless the more-capable EHLO command 970 is not accepted. It is included for compatibility with general SMTP 971 implementations. Compliant implementations MUST implement the HELO 972 command for backward compatibility but SHOULD NOT send it unless EHLO 973 is not supported. From [SMTP] 975 5.1.2 MAIL FROM (REQUIRED) 977 Originating mailbox. This address contains the mailbox to which 978 errors should be sent. This address may not be the same as the 979 message sender listed in the message header fields if the message was 980 received from a gateway or sent to an Internet-style mailing list. 981 Compliant implementations MUST implement the extended MAIL FROM 982 command. From [SMTP, ESMTP] 984 The MAIL FROM address MAY be passed as a local system parameter or 985 placed in a Return-Path: line inserted at the beginning of a VPIM 986 message. From [HOSTREQ] 988 Since error messages MUST be sent to the MAIL FROM address, the use of 989 the null address ("<>") is often used to prevent looping of error 990 notifications. This null address MAY also be used to note that a 991 particular message has no return path (e.g. a telephone answer 992 message). From [SMTP] 994 5.1.3 RCPT TO 996 Recipient's mailbox. This field contains only the addresses to which 997 the message should be delivered for this transaction. In the event 998 that multiple transport connections to multiple destination machines 999 are required for the same message, this list may not match the list of 1000 recipients in the message header. Compliant implementations MUST 1001 implement the extended RCPT TO command. From [SMTP, ESMTP] 1003 5.1.4 DATA 1005 Initiates the transfer of message data. Support for this command is 1006 required in the event the binary mode command BDAT is not supported by 1007 the remote system. Compliant implementations MUST implement the SMTP 1008 DATA command for backwards compatibility. From [SMTP] 1010 5.1.5 TURN 1012 Requests a change-of-roles, that is, the client that opened the 1013 connection offers to assume the role of server for any mail the remote 1014 machine may wish to send. Because SMTP is not an authenticated 1015 protocol, the TURN command presents an opportunity to improperly fetch 1016 mail queued for another destination. Compliant implementations SHOULD 1017 NOT implement the TURN command. From [SMTP] 1019 5.1.6 QUIT 1021 Requests that the connection be closed. If accepted, the remote 1022 machine will reset and close the connection. Compliant 1023 implementations MUST implement the QUIT command. From [SMTP] 1025 5.1.7 RSET 1027 Resets the connection to its initial state. Compliant implementations 1028 MUST implement the RSET command. From [SMTP] 1030 5.1.8 VRFY 1032 Requests verification that this node can reach the listed recipient. 1033 While this functionality is also included in the RCPT TO command, VRFY 1034 allows the query without beginning a mail transfer transaction. This 1035 command is useful for debugging and tracing problems. Compliant 1036 implementations MAY implement the VRFY command. From [SMTP] 1038 (Note that the implementation of VRFY may simplify the guessing of a 1039 recipient's mailbox or automated sweeps for valid mailbox addresses, 1040 resulting in a possible reduction in privacy. Various implementation 1041 techniques may be used to reduce the threat, such as limiting the 1042 number of queries per session.) From [SMTP] 1044 5.1.9 EHLO 1046 The enhanced mail greeting that enables a server to announce support 1047 for extended messaging options. The extended messaging modes are 1048 discussed in subsequent sections of this document. Compliant 1049 implementations MUST implement the ESMTP command and return the 1050 capabilities indicated later in this memo. From [ESMTP] 1052 5.1.10 BDAT 1054 The BDAT command provides a higher efficiency alternative to the 1055 earlier DATA command, especially for voice. The BDAT command provides 1056 for native binary transport of messages. Compliant implementations 1057 SHOULD support binary transport using the BDAT command.[BINARY] 1059 5.2 ESMTP Keywords 1061 The following ESMTP keywords indicate extended features useful for 1062 voice messaging. 1064 5.2.1 PIPELINING 1066 The "PIPELINING" keyword indicates ability of the receiving server to 1067 accept new commands before issuing a response to the previous command. 1068 Pipelining commands dramatically improves performance by reducing the 1069 number of round-trip packet exchanges and makes it possible to 1070 validate all recipient addresses in one operation. Compliant 1071 implementations SHOULD support the command pipelining indicated by 1072 this parameter. From [PIPE] 1074 5.2.2 SIZE 1076 The "SIZE" keyword provides a mechanism by which the SMTP server can 1077 indicate the maximum size message supported. Compliant 1078 implementations MUST provide the size capability and SHOULD honor any 1079 size limitations when sending. From [SIZE] 1081 5.2.3 CHUNKING 1083 The "CHUNKING" keyword indicates that the receiver will support the 1084 high-performance binary transport mode. Note that CHUNKING can be 1085 used with any message format and does not imply support for binary 1086 encoded messages. Compliant implementations SHOULD support binary 1087 transport indicated by this capability. From [BINARY] 1089 5.2.4 BINARYMIME 1091 The "BINARYMIME" keyword indicates that the SMTP server can accept 1092 binary encoded MIME messages. Compliant implementations SHOULD support 1093 binary transport indicated by this capability. Note that support for 1094 this feature requires support of CHUNKING. From [BINARY] 1096 5.2.5 NOTIFY 1098 The "NOTIFY" keyword indicates that the SMTP server will accept 1099 explicit delivery status notification requests. Compliant 1100 implementations MUST support the delivery notification extensions in 1101 [DRPT]. 1103 5.2.6 ENHANCEDSTATUSCODES 1105 The "ENHANCEDSTATUSCODES" keyword indicates that an SMTP server 1106 augments its responses with the enhanced mail system status codes 1107 [CODES]. These codes can then be used to provide more informative 1108 explanations of error conditions, especially in the context of the 1109 delivery status notifications format defined in [DSN]. Compliant 1110 implementations SHOULD support this capability. From [STATUS] 1112 5.3 ESMTP Parameters - MAIL FROM 1114 5.3.1 BINARYMIME 1116 The current message is a binary encoded MIME messages. Compliant 1117 implementations SHOULD support binary transport indicated by this 1118 parameter. From [BINARY] 1120 5.3.2 RET 1122 The RET parameter indicates whether the content of the message should 1123 be returned. Compliant systems SHOULD honor a request for returned 1124 content. From [DRPT] 1126 5.3.3 ENVID 1128 The ENVID keyword of the SMTP MAIL command is used to specify an 1129 "envelope identifier" to be transmitted along with the message and 1130 included in any DSNs issued for any of the recipients named in this 1131 SMTP transaction. The purpose of the envelope identifier is to allow 1132 the sender of a message to identify the transaction for which the DSN 1133 was issued. Compliant implementations MAY use this parameter. From 1134 [DRPT] 1136 5.4 ESMTP Parameters - RCPT TO 1138 5.4.1 NOTIFY 1140 The NOTIFY parameter indicates the conditions under which a delivery 1141 report should be sent. Compliant implementations MUST honor this 1142 request. From [DRPT] 1144 5.4.2 ORCPT 1146 The ORCPT keyword of the RCPT command is used to specify an "original" 1147 recipient address that corresponds to the actual recipient to which 1148 the message is to be delivered. If the ORCPT esmtp-keyword is used, 1149 it MUST have an associated esmtp-value, which consists of the original 1150 recipient address, encoded according to the rules below. Compliant 1151 implementations MAY use this parameter. From [DRPT] 1153 5.5 ESMTP - SMTP Downgrading 1155 To ensure a consistent level of service across an intranet or the 1156 global Internet, it is essential that VPIM compliant ESMTP be 1157 supported at all hops between a VPIM originating system and the 1158 recipient system. Unfortunately, in the situation where a `downgrade' 1159 is unavoidable the expected result is not defined. A downgrade is 1160 defined as the loss of VPIM transport features at some hop due to the 1161 lack of support. For example, a relay hop may be forced (by the next 1162 hop) to forward a VPIM using SMTP instead of ESMTP, or using DATA 1163 instead of BDAT. It is recommended that the downgrading system should 1164 continue to attempt to deliver the message, but MUST send an 1165 appropriate delivery notification to the originator, e.g. the message 1166 left an ESMTP host and was sent (unreliably) via SMTP. 1168 6. Directory Address Resolution 1170 It is the responsibility of a VPIM system to lookup the fully- 1171 qualified domain name (FQDN) based on the address entered by the user 1172 (if the entered address is not already a FQDN). This would typically 1173 be an issue on systems that offered only a telephone user interface. 1174 The mapping of the dialed target number to a routable FQDN address 1175 allowing delivery to the destination system can be accomplished 1176 through implementation-specific means. 1178 To facilitate a local dial-by-name cache, an implementation may wish 1179 to populate local directories with the first and last names, as well 1180 as the address information extracted from received messages. It is 1181 mandated that only address information from vCard attachments to VPIM 1182 messages be used to populate such a directory when the vCard is 1183 available. Addresses or names parsed from the headers of VPIM messages 1184 SHOULD NOT be used to populate directories as it only provides partial 1185 data. Alternatively, bilateral agreements could be made to allow the 1186 bulk transfer of vCards between systems. 1188 7. IMAP 1190 The use of client/server desktop mailbox protocols like IMAP or POP to 1191 retrieve VPIM messages from a IMAP or POP message store is possible 1192 without any special modifications to this VPIM specification. Email 1193 clients (and web browsers) typically have a table for mapping from 1194 MIME type to displaying application. The audio/*, image/tiff and 1195 application/directory contents can be configured so that they invoke 1196 the correct player/recorder for rendering. In addition with IMAP 1197 clients, the first multipart/mixed content (if present) will not 1198 appear since it is a generic part. The user instead will be presented 1199 with a message that has (for example) audio and image contents. 1201 8. Management Protocols 1203 The Internet protocols provide a mechanism for the management of 1204 messaging systems, from the management of the physical network through 1205 the management of the message queues. SNMP should be supported on a 1206 compliant message machine. 1208 8.1 Network Management 1210 The digital interface to the VM and the TCP/IP protocols SHOULD be 1211 managed. MIB II SHOULD be implemented to provide basic statistics and 1212 reporting of TCP and IP protocol performance. [MIB II] 1214 9. Conformance Requirements 1216 In order to claim conformance to this document and be called `VPIM 1217 compliant', a voice messaging system must implement all mandatory 1218 features of this profile in each of three areas: Content, Transport, 1219 and Notifications. In addition, systems which conform to this profile 1220 must not send messages with features beyond this profile unless 1221 explicit per-destination configuration of these enhanced features is 1222 provided. Such configuration information could be stored in a 1223 directory, though the implementation of this is currently a local 1224 matter. 1226 It is also possible, though not encouraged, to claim conformance to 1227 only specific areas (e.g. VPIM content compliant) of this profile. 1228 The delineation of these areas is as follows: 1230 Content - Section 4, except REPORT & NOTIFY and Section 6 1232 Transport - Section 5 except NOTIFY & RET, and Section 8 1234 Notifications - REPORT & NOTIFY from Section 4, NOTIFY, RET & 1235 ENHANCEDSTATUSCODES from Section 5, and all 1236 notification requirements. 1238 A summary of compliance requirements is contained in Appendix A. 1240 10. References 1242 [8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E., D. Crocker, 1243 "SMTP Service Extension for 8bit-MIMEtransport" RFC 1426, United 1244 Nations University, Innosoft International, Inc., Dover Beach 1245 Consulting, Inc., Network Management Associates, Inc., The Branch 1246 Office, February 1993. 1248 [ADPCM] Toll Quality Voice MIME Content: G.726, Work in Progress, 1249 January 1997. 1251 [AMIS-A] Audio Messaging Interchange Specifications (AMIS) - Analog 1252 Protocol Version 1, Issue 2, February 1992 1254 [AMIS-D] Audio Messaging Interchange Specifications (AMIS) - Digital 1255 Protocol Version 1, Issue 3 August 1993 1257 [BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of 1258 Large and Binary MIME Messages", RFC 1830, October 1995. 1260 [CODES] Vaudreuil, G. "Enhanced Mail System Status Codes", RFC 1893, 1261 01/15/1996. 1263 [DIRECTORY] Howes, Tim, Smith, Mark, "A MIME Content-Type for Directory 1264 Information" 1266 [DISP] R. Troost and S. Dorner, Communicating Presentation Information 1267 in Internet Messages: The Content-Disposition Header, RFC 1806, June 1268 1995 1270 [DNS1] Mockapetris, P., "Domain names - implementation and 1271 specification", RFC1035, Nov 1987. 1273 [DNS2] Mockapetris, P., "Domain names - concepts and facilities", RFC 1274 1034, Nov 1987. 1276 [DRPT] Moore, K. "SMTP Service Extensions for Delivery Status 1277 Notifications", RFC 1891, 01/15/1996 1279 [DSN] Moore, K., Vaudreuil, G., "An Extensible Message Format for 1280 Delivery Status Notifications", RFC 1894, 01/15/1996. 1282 [DUR] Content Duration for Audio and Video Contents, Work in Progress, 1283 January 1997. 1285 [E164] CCITT Recommendation E.164 (1991), Telephone Network and ISDN 1286 Operation, Numbering, Routing and Mobile Service - Numbering Plan 1287 for the ISDN Era. 1289 [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, 1290 "SMTP Service Extensions" RFC 1869, United Nations University, 1291 Innosoft International, Inc., Dover Beach Consulting, Inc., Network 1292 Management Associates, Inc., The Branch Office, November 1995. 1294 [G726] CCITT Recommendation G.726 (1990), General Aspects of Digital 1295 Transmission Systems, Terminal Equipment - 40, 32, 24,16 kbit/s 1296 Adaptive Differential Pulse Code Modulation (ADPCM). 1298 [HOSTREQ] Braden, R., "Requirements for Internet Hosts -- Application 1299 and Support", STD 3, RFC 1123, October 1989. 1301 [LANG] Alvestrand,H., "Tags for the Identification of Languages", RFC 1302 1766, Mar 1995 1304 [MIB II] M. Rose, "Management Information Base for Network Management of 1305 TCP/IP-based internets: MIB-II", RFC 1158, May 1990. 1307 [MIME1] N. Freed and N. Borenstein, "Multipurpose Internet Mail 1308 Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 1309 2045, Innosoft, First Virtual, Nov 1996. 1311 [MIME2] N. Freed and N. Borenstein, "Multipurpose Internet Mail 1312 Extensions (MIME) Part Two: Media Types ", RFC 2046, Innosoft, First 1313 Virtual, Nov 1996. 1315 [MIME4] N. Freed and N. Borenstein, "Multipurpose Internet Mail 1316 Extensions (MIME) Part Four: Registration Procedures", RFC 2046, 1317 Innosoft, First Virtual, Nov 1996. 1319 [MIME5] N. Freed and N. Borenstein, "Multipurpose Internet Mail 1320 Extensions (MIME) Part Five: Conformance Criteria and Examples ", RFC 1321 2046, Innosoft, First Virtual, Nov 1996. 1323 [PIPE] Freed, N., Cargille, A., "SMTP Service Extension for Command 1324 Pipelining" RFC 1854, October 1995. 1326 [REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the 1327 Reporting of Mail System Administrative Messages", RFC 1892, 1328 01/15/1996. 1330 [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text 1331 Messages", STD 11, RFC 822, UDEL, August 1982. 1333 [SIZE] Klensin, J, Freed, N., Moore, K, "SMTP Service Extensions for 1334 Message Size Declaration" RFC 1870, United Nations University, 1335 Innosoft International, Inc., November 1995. 1337 [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 1338 USC/Information Sciences Institute, August 1982. 1340 [STATUS] Freed, N. "SMTP Service Extension for Returning Enhanced Error 1341 Codes", RFC 2034, 10/30/1996. 1343 [TIFF-F] Tag Image File Format: Class F, Work in Progress, January 1344 1997. 1346 [V-MSG] VPIM Voice Message Content, Work in Progress, January 1997. 1348 [VCARD] Dawson, Frank, Howes, Tim, "An Application/Directory MIME 1349 Content-Type Electronic Business Card Profile" 1352 [VPIM1] Vaudreuil, Greg, "Voice Profile for Internet Mail", RFC 1911, 1353 Feb 1996. 1355 [X.400] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021 1356 and RFC 822", RFC 1327, May 1992. 1358 11. Security Consideration 1360 This document is a profile of existing Internet mail protocols. As 1361 such, it does not create any security issues not already existing in 1362 the profiled Internet mail protocols themselves. 1364 Further, the profile specified in this document does not in any way 1365 preclude the use of any Internet mail security protocol to encrypt, 1366 authenticate, or non-repudiate the messages. 1368 12. Acknowledgments 1370 The authors would like to offer a special thanks to the Electronic 1371 Messaging Association, especially the members of the Voice Messaging 1372 Committee, for their support of the VPIM specification and the efforts 1373 they have made to ensure its success. 1375 13. Authors' Addresses 1377 Glenn W. Parsons 1378 Nortel Technology 1379 P.O. Box 3511, Station C 1380 Ottawa, ON K1Y 4H7 1381 Canada 1382 Phone: +1-613-763-7582 1383 Fax: +1-613-763-8385 1384 Glenn.Parsons@Nortel.ca 1386 Gregory M. Vaudreuil 1387 Octel Communications 1388 17080 Dallas Parkway 1389 Dallas, TX 75248-1905 1390 United States 1391 Phone/Fax: +1-972-733-2722 1392 Greg.Vaudreuil@Octel.Com 1394 14. Appendix A - VPIM Requirements Summary 1396 The following table summarizes the profile of VPIM version 2 detailed 1397 in this document. For complete explanations of each feature it is 1398 recommended to read the accompanying text. The conformance table is 1399 separated into various columns: 1401 Feature - name of protocol feature (note that the indenting 1402 indicates 1403 a hierarchy of conformance, i.e. the conformance of a 1404 lower 1405 feature is only relevant if there is comformance to the 1406 higher feature) 1408 Section - reference section in main text of this document 1410 Area - conformance area to which each feature applies: 1411 C - content 1412 T - transport 1413 N - notifications 1415 Status - whether the feature is mandatory, optional, or prohibited. 1416 There are three different degrees of optional used in this table: 1417 Must - mandatory 1418 Should - encouraged optional 1419 May - optional 1420 Should not - discouraged optional 1421 Must not - prohibited 1423 Footnote - special comment about conformance for a particular 1424 feature 1425 VPIM version 2 Conformance 1426 | | | | |S| | 1427 | | | | | |H| |F 1428 | | | | | |O|M|o 1429 | | | |S| |U|U|o 1430 | | | |H| |L|S|t 1431 | |A|M|O| |D|T|n 1432 | |R|U|U|M| | |o 1433 | |E|S|L|A|N|N|t 1434 | |A|T|D|Y|O|O|t 1435 FEATURE |SECTION | | | | |T|T|e 1436 -------------------------------------------|----------|-|-|-|-|-|-|- 1437 | | | | | | | | 1438 Message Addressing Formats: | | | | | | | | 1439 Use DNS host names |4.1 |C|x| | | | | 1440 Use only numbers in mailbox IDs |4.1.1 |C| |x| | | | 1441 Use alpha-numeric mailbox IDs |4.1.1 |C| | |x| | | 1442 Support of postmaster@domain |4.1.2 |C|x| | | | | 1443 Support of non-mail-user@domain |4.1.2 |C| |x| | | | 1444 Support of distribution lists |4.1.3 |C| |x| | | | 1445 | | | | | | | | 1446 Message Header Fields: | | | | | | | | 1447 Encoding outbound messages | | | | | | | | 1448 From |4.2.1 |C|x| | | | | 1449 Addition of text name |4.2.1 |C| |x| | | | 1450 To |4.2.2 |C|x| | | | |1 1451 cc |4.2.3 |C| |x| | | |1 1452 Date |4.2.4 |C|x| | | | | 1453 Sender |4.2.5 |C| | |x| | | 1454 Return-Path |4.2.6 |C| | |x| | | 1455 Message-id |4.2.7 |C|x| | | | | 1456 Reply-To |4.2.8 |C| | |x| | | 1457 Received |4.2.9 |C|x| | | | | 1458 MIME Version: 1.0 (Voice 2.0) |4.2.10 |C| |x| | | | 1459 Content-Type |4.2.11 |C|x| | | | | 1460 Content-Transfer-Encoding |4.2.12 |C|x| | | | | 1461 Sensitivity |4.2.13 |C| | |x| | | 1462 Importance |4.2.14 |C| | |x| | | 1463 Subject |4.2.15 |C| |x| | | | 1464 Other Headers |4.2 |C| | |x| | | 1465 | | | | | | | | 1466 | | | | |S| | 1467 | | | | | |H| |F 1468 | | | | | |O|M|o 1469 | | | |S| |U|U|o 1470 | | | |H| |L|S|t 1471 | |A|M|O| |D|T|n 1472 | |R|U|U|M| | |o 1473 | |E|S|L|A|N|N|t 1474 | |A|T|D|Y|O|O|t 1475 FEATURE |SECTION | | | | |T|T|e 1476 -------------------------------------------|----------|-|-|-|-|-|-|- 1477 Detection & Decoding inbound messages | | | | | | | | 1478 From |4.2.1 |C|x| | | | | 1479 Present text personal name |4.2.1 |C| | |x| | | 1480 To |4.2.2 |C|x| | | | | 1481 cc |4.2.3 |C| | |x| | | 1482 Date |4.2.4 |C|x| | | | | 1483 Conversion of Date to local time |4.2.4 |C| |x| | | | 1484 Sender |4.2.5 |C| | |x| | | 1485 Return-Path |4.2.6 |C| | |x| | | 1486 Message ID |4.2.7 |C|x| | | | | 1487 Reply-To |4.2.8 |C|x| | | | | 1488 Received |4.2.9 |C| | |x| | | 1489 MIME Version: 1.0 (Voice 2.0) |4.2.10 |C| |x| | | | 1490 Content Type |4.2.11 |C|x| | | | | 1491 Content-Transfer-Encoding |4.2.12 |C|x| | | | | 1492 Sensitivity |4.2.13 |C|x| | | | |2 1493 Importance |4.2.14 |C| | |x| | | 1494 Subject |4.2.15 |C| | |x| | | 1495 Other Headers |4.2 |C|x| | | | |3 1496 | | | | | | | | 1497 Message Content Encoding: | | | | | | | | 1498 Encoding outbound audio/fax contents | | | | | | | | 1499 7BITMIME |4.3 |C| | | | |x| 1500 8BITMIME |4.3 |C| | | | |x| 1501 Quoted Printable |4.3 |C| | | | |x| 1502 Base64 |4.3 |C|x| | | | |4 1503 Binary |4.3 |C| |x| | | |5 1504 Detection & decoding inbound messages | | | | | | | | 1505 7BITMIME |4.3 |C|x| | | | | 1506 8BITMIME |4.3 |C|x| | | | | 1507 Quoted Printable |4.3 |C|x| | | | | 1508 Base64 |4.3 |C|x| | | | | 1509 Binary |4.3 |C|x| | | | |5 1510 | | | | | | | | 1511 | | | | |S| | 1512 | | | | | |H| |F 1513 | | | | | |O|M|o 1514 | | | |S| |U|U|o 1515 | | | |H| |L|S|t 1516 | |A|M|O| |D|T|n 1517 | |R|U|U|M| | |o 1518 | |E|S|L|A|N|N|t 1519 | |A|T|D|Y|O|O|t 1520 FEATURE |SECTION | | | | |T|T|e 1521 -------------------------------------------|----------|-|-|-|-|-|-|- 1522 Message Content Types: | | | | | | | | 1523 Inclusion in outbound messages | | | | | | | | 1524 Multipart/Voice-Message |4.3.1 |C|x| | | | | 1525 Message/RFC822 |4.3.2 |C| | |x| | | 1526 Application/Directory |4.3.3 |C| |x| | | | 1527 include TEL, EMAIL |4.3.3 |C|x| | | | | 1528 include N, ROLE, SOUND, REV |4.3.3 |C| |x| | | | 1529 only one per level |4.3.3 |C|x| | | | | 1530 Audio/32KADPCM |4.3.4 |C|x| | | | | 1531 Content-Description |4.3.4.1 |C| | |x| | | 1532 Content-Disposition |4.3.4.2 |C| |x| | | |6 1533 Content-Duration |4.3.4.3 |C| | |x| | | 1534 Content-Langauge |4.3.4.4 |C| | |x| | | 1535 Image/TIFF; class=F |4.3.5 |C| | |x| | | 1536 Audio/* or Image/* (other encodings) |4.3.6 |C| | |x| | | 1537 Multipart/Mixed |4.4.1 |C| | |x| | | 1538 Text/plain |4.4.2 |C| | | |x| | 1539 Multipart/Report |4.4.3 |N|x| | | | | 1540 human-readable part is voice |4.4.3 |N|x| | | | | 1541 Message/delivery-status |4.4.4 |N|x| | | | | 1542 Other contents |4.4 |C| | | |x| |7 1543 | | | | | | | | 1544 Detection & decoding in inbound messages | | | | | | | | 1545 Multipart/Voice-Message |4.3.1 |C|x| | | | | 1546 Message/RFC822 |4.3.2 |C|x| | | | | 1547 Application/Directory |4.3.3 |C| |x| | | | 1548 recognize TEL, EMAIL |4.3.3 |C|x| | | | | 1549 recognize N, ROLE, SOUND, REV |4.3.3 |C| |x| | | | 1550 Audio/32KADPCM |4.3.4 |C|x| | | | | 1551 Content-Description |4.3.4.1 |C| | |x| | | 1552 Content-Disposition |4.3.4.2 |C| |x| | | |6 1553 Content-Duration |4.3.4.3 |C| | |x| | | 1554 Content-Langauge |4.3.4.4 |C| | |x| | | 1555 Image/TIFF; class=F |4.3.5 |C| |x| | | | 1556 send NDN if unable to render |4.3.5 |C|x| | | | |8 1557 Audio/* or Image/* (other encodings) |4.3.6 |C| | |x| | | 1558 Multipart/Mixed |4.4.1 |C|x| | | | | 1559 Text/plain |4.4.2 |C|x| | | | | 1560 send NDN if unable to render |4.4.2 |N|x| | | | | 1561 Multipart/Report |4.4.3 |N|x| | | | | 1562 human-readable part is voice |4.4.3 |N|x| | | | |9 1563 Message/delivery-status |4.4.4 |N|x| | | | | 1564 Other contents |4.4 |C| | | |x| |7 1565 send NDN if unable to render |4.4 |N| |x| | | | 1566 | | | | | |S| | 1567 | | | | | |H| |F 1568 | | | | | |O|M|o 1569 | | | |S| |U|U|o 1570 | | | |H| |L|S|t 1571 | |A|M|O| |D|T|n 1572 | |R|U|U|M| | |o 1573 | |E|S|L|A|N|N|t 1574 | |A|T|D|Y|O|O|t 1575 FEATURE |SECTION | | | | |T|T|e 1576 ------------------------------------------|-----------|-|-|-|-|-|-|- 1577 | | | | | | | | 1578 Forwarded Messages | | | | | | | | 1579 use Message/RFC822 construct |4.5 |C| |x| | | | 1580 simulate headers if none available |4.5 |C| |x| | | | 1581 | | | | | | | | 1582 Reply Messages | | | | | | | | 1583 send to Reply-to, else From address |4.6 |C|x| | | | | 1584 do not send to non-mail-user |4.6 |C|x| | | | | 1585 | | | | | | | | 1586 Message Transport Protocol: | | | | | | | | 1587 ESMTP Commands | | | | | | | | 1588 HELO |5.1.1 |T|x| | | | | 1589 MAIL FROM |5.1.2 |T|x| | | | | 1590 support null address |5.1.2 |T|x| | | | | 1591 RCPT TO |5.1.3 |T|x| | | | | 1592 DATA |5.1.4 |T|x| | | | | 1593 TURN |5.1.5 |T| | | | |x| 1594 QUIT |5.1.6 |T|x| | | | | 1595 RSET |5.1.7 |T|x| | | | | 1596 VRFY |5.1.8 |T| | |x| | | 1597 EHLO |5.1.9 |T|x| | | | | 1598 BDAT |5.1.10 |T| |x| | | |5 1599 ESMTP Keywords & Parameters | | | | | | | | 1600 PIPELINING |5.2.1 |T| |x| | | | 1601 SIZE |5.2.2 |T|x| | | | | 1602 CHUNKING |5.2.3 |T| |x| | | | 1603 BINARYMIME |5.2.4,5.3.1|T| |x| | | | 1604 NOTIFY |5.2.5,5.4.1|N|x| | | | | 1605 ENHANCEDSTATUSCODES |5.2.6 |N| |x| | | | 1606 RET |5.3.2 |N| |x| | | | 1607 ENVID |5.3.3 |N| | |x| | | 1608 ORCPT |5.4.2 |N| | |x| | | 1609 | | | | | | | | 1610 ESMTP-SMTP Downgrading | | | | | | | | 1611 send delivery report upon downgrade |5.5 |N|x| | | | | 1612 | | | | | | | | 1613 | | | | |S| | 1614 | | | | | |H| |F 1615 | | | | | |O|M|o 1616 | | | |S| |U|U|o 1617 | | | |H| |L|S|t 1618 | |A|M|O| |D|T|n 1619 | |R|U|U|M| | |o 1620 | |E|S|L|A|N|N|t 1621 | |A|T|D|Y|O|O|t 1622 FEATURE |SECTION | | | | |T|T|e 1623 -------------------------------------------|----------|-|-|-|-|-|-|- 1624 Directory Address Resolution | | | | | | | | 1625 provide facility to resolve addresses |6 |C| |x| | | | 1626 use Vcards to populate local directory |6 |C|x| | | | |10 1627 use headers to populate local directory |6 |C| | | |x| | 1628 | | | | | | | | 1629 Management Protocols: | | | | | | | | 1630 Network management |8.1 |T| |x| | | | 1631 -------------------------------------------|----------|-|-|-|-|-|-|- 1633 Footnotes: 1635 1. MUST NOT include if all recipients are not known or resolvable. 1636 2. If a sensitive message is received by a system that does not 1637 support sensitivity, then it MUST be returned to the originator 1638 with an appropriate error notification. Also, a received 1639 sensitive message MUST NOT be forwarded to anyone. 1640 3. If the addtional headers are not understood they MAY be ignored 1641 4. When binary transport is not available 1642 5. When binary transport is available 1643 6. If multiple audio contents are present in a message, this header 1644 MUST be present 1645 7. Other un-profiled contents must only be sent by bilateral 1646 agreement. 1647 8. If the content cannot be presented in some form, the entire 1648 message MUST be non-delivered. 1649 9. If the message is a VPIM Message, else it MAY be text 1650 10. When the vCard is present in a message 1652 15. Appendix B - Example Voice Messages 1654 The following message is a full-featured message addressed to two 1655 recipients. The message includes the sender's spoken name and a short 1656 speech segment. The message is marked as important and private. 1658 To: +19725551212@vm1.mycompany.com 1659 To: +16135551234@VM1.mycompany.com 1660 From: "Parsons, Glenn" <12145551234@VM2.mycompany.com> 1661 Date: Mon, 26 Aug 93 10:20:20 -0700 (CST) 1662 MIME-Version: 1.0 (Voice 2.0) 1663 Content-type: Multipart/Voice-Message; Version=2.0; 1664 Boundary="MessageBoundary" 1665 Content-Transfer-Encoding: 7bit 1666 Message-ID: VM2.mycompany.com-123456789 1667 Sensitivity: Private 1668 Importance: High 1670 --MessageBoundary 1671 Content-type: Audio/32KADPCM 1672 Content-Transfer-Encoding: Base64 1673 Content-Disposition: inline; voice=Originator-Spoken-Name 1674 Content-Language: EN-US 1675 Content-ID: part1@VM2-4321 1677 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1678 (This is a sample of the base-64 Spoken Name data) fgdhgd 1679 dlkgpokpeowrit09== 1681 --MessageBoundary 1682 Content-type: Audio/32KADPCM 1683 Content-Transfer-Encoding: Base64 1684 Content-Description: Brand X Voice Message 1685 Content-Disposition: inline; voice= Voice-Message 1686 Content-Duration: 25 1688 iIiIiIjMzN3czdze3s7d7fwfHhcvESJVe/4yEhLz8/FOQjVFRERCESL/zqrq 1689 (This is a sample of the base64 message data) zb8tFdLTQt1PXj 1690 u7wjOyRhws+krdns7Rju0t4tLF7cE0K0MxOTOnRW/Pn30c8uHi9== 1692 --MessageBoundary 1693 Content-type: Application/Directory 1694 Content-Transfer-Encoding: 7bit 1696 BEGIN:VCARD 1697 N:Parsons;Glenn;;Mr.; 1698 EMAIL;TYPE=INTERNET:+12145551234@VM2.mycompany.com 1699 TEL:+1-217-555-1234 1700 SOUND;TYPE=32KADPCM;ENCODE=BASE64;VALUE=CID: 1701 REV:19951031T222710Z 1702 END:VCARD 1704 --MessageBoundary-- 1705 The following message is a forwarded single segment voice. Both the 1706 forwarded message and the forwarding message contain VCARDs with 1707 spoken names. 1709 To: +12145551212@vm1.mycompany.com 1710 From: "Vaudreuil, Greg" <+19725552345@VM2.mycompany.com> 1711 Date: Mon, 26 Aug 93 10:20:20 -0700 (CST) 1712 MIME-Version: 1.0 (Voice 2.0) 1713 Content-type: Multipart/Voice-Message; Version=2.0; 1714 Boundary="MessageBoundary" 1715 Content-Transfer-Encoding: 7bit 1716 Message-ID: VM2.mycompany.com-123456789 1718 --MessageBoundary 1719 Content-type: Audio/32KADPCM 1720 Content-Transfer-Encoding: Base64 1721 Content-Disposition: inline; voice=Originator-Spoken-Name 1722 Content-Language: EN-US 1723 Content-ID: part3@VM2-4321 1725 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1726 (This is a sample of the base-64 Spoken Name data) fgdhgd 1727 dlkgpokpeowrit09== 1729 --MessageBoundary 1730 Content-type: Audio/32KADPCM 1731 Content-Description: Forwarded Message Annotation 1732 Content-Disposition: inline; voice=Voice-Message 1733 Content-Transfer-Encoding: Base64 1735 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1736 (This is the voiced introductory remarks encoded in base64) 1737 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW 1738 dlkgpokpeowrit09== 1740 --MessageBoundary 1741 Content-type: Message/RFC822 1742 Content-Transfer-Encoding: 7bit 1744 To: +19725552345@VM2.mycompany.com 1745 From: "Parsons, Glenn, W." <+16135551234@VM1.mycompany.com> 1746 From: Date: Mon, 26 Aug 93 8:23:10 -0600 (EST) 1747 Content-type: Multipart/Voice-Message; Version=2.0; 1748 Boundary="MessageBoundary2" 1749 Content-Transfer-Encoding: 7bit 1750 MIME-Version: 1.0 (Voice 2.0) 1751 --MessageBoundary2 1752 Content-type: Audio/32KADPCM 1753 Content-Transfer-Encoding: Base64 1754 Content-Disposition: inline; voice=Originator-Spoken-Name 1755 Content-Language: EN-US 1756 Content-ID: part6@VM2-4321 1758 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1759 (This is a sample of the base-64 Spoken Name data) fgdhgd 1760 dlkgpokpeowrit09== 1762 --MessageBoundary2 1763 Content-type: Audio/32KADPCM 1764 Content-Disposition: inline; voice=Voice-Message 1765 Content-Transfer-Encoding: Base64 1767 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1768 (This is the original message audio data) fgwersdfmniwrjj 1769 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW 1770 dlkgpokpeowrit09== 1772 --MessageBoundary2 1773 Content-type: Application/Directory 1774 Content-Transfer-Encoding: 7bit 1776 BEGIN:VCARD 1777 N:Parsons;Glenn;W;Mr.; 1778 EMAIL;TYPE=INTERNET:+16135551234@VM2.mycompany.com 1779 TEL:+1-613-555-1234 1780 SOUND;TYPE=32KADPCM;ENCODE=BASE64;VALUE=CID: 1781 REV:19951031T222710Z 1782 END:VCARD 1784 --MessageBoundary2-- 1785 --MessageBoundary 1786 Content-type: Application/Directory 1787 Content-Transfer-Encoding: 7bit 1789 BEGIN:VCARD 1790 N:Vaudreuil;Greg;;Mr.; 1791 SOUND;TYPE=32kbADPCM;ENCODE=BASE64;VALUE=CID: 1792 EMAIL;TYPE=INTERNET,VPIM:+19725552345@VM2.mycompany.com 1793 TEL:+1-972-555-2345 1794 REV:19951031T222710Z 1795 END:VCARD 1797 --MessageBoundary-- 1798 The following example is for a message returned to the sender by a 1799 VPIM gateway at VM1.company.com for a mailbox which does not exist. 1801 Date: Thu, 7 Jul 1994 17:16:05 -0400 1802 From: Mail Delivery Subsystem 1803 Message-Id: <199407072116.RAA14128@vm1.company.com> 1804 Subject: Returned voice message 1805 To: 2175552345@VM2.mycompany.com 1806 MIME-Version: 1.0 (Voice 2.0) 1807 Content-Type: multipart/report; report-type=delivery-status; 1808 boundary="RAA14128.773615765/VM1.COMPANY.COM" 1810 --RAA14128.773615765/VM1.COMPANY.COM 1811 Content-type: Audio/32KADPCM 1812 Content-Description: Spoken Delivery Status Notification 1813 Content-Disposition: inline; voice= Voice-Message-Notification 1814 Content-Transfer-Encoding: Base64 1816 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd 1817 (This is a voiced description of the error in base64) 1818 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW 1819 dlkgpokpeowrit09== 1821 --RAA14128.773615765/VM1.COMPANY.COM 1822 content-type: message/delivery-status 1824 Reporting-MTA: dns; vm1.company.com 1826 Original-Recipient: rfc822; 2145551234@VM1.mycompany.com 1827 Final-Recipient: rfc822; 2145551234@VM1.mycompany.com 1828 Action: failed 1829 Status: 5.1.1 (User does not exist) 1830 Diagnostic-Code: smtp; 550 Mailbox not found 1831 Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400 1833 --RAA14128.773615765/VM1.COMPANY.COM 1834 content-type: message/rfc822 1836 [original VPIM message goes here] 1838 --RAA14128.773615765/VM1.COMPANY.COM-- 1840 16. Appendix C - Example Error Voice Processing Error Codes 1842 The following common voice processing errors and their corresponding 1843 status codes are given as examples. Text after the error codes are 1844 intended only for reference to describe the error code. 1845 Implementations should provide implementation specific informative 1846 comments after the error code rather than the text below. 1848 Error condition RFC 1893 Error codes 1849 ----------------------------- ---------------------------------- 1851 Analog delivery failed 4.4.0 Persistent connection error 1852 because remote system is busy - other 1854 Analog delivery failed 4.4.1 Persistent protocol error 1855 because remote system is - no answer from host 1856 ring-no-answer 1858 Remote system did not answer 5.5.5 Permanent protocol error 1859 AMIS-Analog handshake ("D" in - wrong version 1860 response to "C" at connect 1861 time) 1863 Mailbox does not exist 5.1.1 Permanent mailbox error 1864 - does not exist 1866 Mailbox full or over quota 4.2.2 Persistent mailbox error 1867 - full 1869 Disk full 4.3.1 Persistent system error 1870 - full 1872 Command out of sequence 5.5.1 Permanent protocol error 1873 - invalid command 1875 Frame Error 5.5.2 Permanent protocol error 1876 - syntax error 1878 Mailbox does not support FAX 5.6.1 Permanent media error 1879 - not supported 1881 Mailbox does not support TEXT 5.6.1 Permanent media error 1882 - not supported 1884 Sender is not authorized 5.7.1 Permanent security error 1885 - sender not authorized 1887 Message marked private, but 5.3.3 Permanent system error 1888 system is not private capable - not feature capable 1890 17. Appendix D - Change History: RFC 1911 to this Document 1892 The updated profile in this document is based on the experience of a 1893 proof of concept demonstration of VPIM at EMA'96 in April 1996. This 1894 version of the profile is significantly different from the previous 1895 described in [VPIM1]. The changes are categorized as general, 1896 content, transport and conformance. They are detailed below: 1898 1. General 1900 - All definitions are now contained in separate documents that are 1901 referenced by this profile. The new documents include: 1903 - a refined multipart/voice-message definition 1905 - a refined (i.e. added nibble order) audio/32KADPCM definition 1907 - the refined definition for image/TIFF for fax images (includes 1908 tag defaults for Class F) 1910 - the Content-Duration definition 1912 - Changed the Voice version to 2.0 1914 - Added Table of Contents and more examples 1916 - Various editorial updates to improve readability 1918 2. Content 1920 - Modified multipart/voice-message content by dropping the 1921 positional dependence of contents 1923 - Explicitly defined the forwarding model using message/RFC822 1925 - Explained the use of reply-to and from headers for addressing 1926 message replies 1928 - Deprecated the special `loopback' address because of security 1929 concerns and its use only for testing 1931 - Defined the non-mail-user reserved address to support the case in 1932 which replies to the originator are not possible 1934 - Eliminated the text name in the "To" and "CC" headers. 1935 Deprecated ordering of text names in the "From" header. 1937 - Added support for facsimile using the refined image/TIFF; class=F 1938 content 1940 - Profiled the vCard in the application/directory body part for 1941 transport of directory information about the originator 1943 - Loosened text restriction 1944 - Added additional details on delivery notifications 1946 - Added suggested addressing formats 1948 - Described handling of private messages 1950 - Described the handling of non-profiled contents in VPIM messages 1952 - Described the use of Content-Disposition to semantically identify 1953 audio contents 1955 3. Transport 1957 - Moved binary support to optional 1959 - Added optional ESMTP keywords for return of content, enhanced 1960 status codes, original recipient, and envelope ID 1962 - Described use of null MAIL FROM address 1964 4. Compliance 1966 - Added an explicit section on conformance allowing conformance to 1967 all or any of three conformance areas 1969 - Improved conformance table