idnits 2.17.1 draft-ema-vpim-03.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-27) 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 43 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 441 instances of too long lines in the document, the longest one being 4 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 301: '...x named "postmaster" MUST exist on all...' RFC 2119 keyword, line 316: '... this special address MUST send a non-...' RFC 2119 keyword, line 342: '...As a result, recipient information MAY...' RFC 2119 keyword, line 344: '...nsion) then the recipient headers MUST...' RFC 2119 keyword, line 358: '...m. VPIM systems MUST be able to accep...' (125 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: ---------------------------------------------------------------------------- == Line 523 has weird spacing: '...ocument as a ...' == Line 1918 has weird spacing: '...ntation must ...' == 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.5). However, if the From: address contains , the user SHOULD not be offered the option to reply, nor should notifications be sent to this address. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: In some cases, a reply message is not possible, such as with a message created by telephone answering (i.e. classic voice mail). In this case, the From field MUST contain the special address non-mail-user@domain (see 4.1.2). The use of a null ESMTP MAIL FROM address SHOULD also be used in this case (see 5.1.2). A receiving VPIM system SHOULD not offer the user the option to reply to this kind of message. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 11, 1996) is 10029 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: 'X400' is mentioned on line 572, but not defined == Unused Reference: 'AMIS-A' is defined on line 1201, but no explicit reference was found in the text == Unused Reference: 'AMIS-D' is defined on line 1204, but no explicit reference was found in the text == Unused Reference: '8BIT' is defined on line 1228, but no explicit reference was found in the text == Unused Reference: 'DNS1' is defined on line 1234, but no explicit reference was found in the text == Unused Reference: 'DNS2' is defined on line 1237, but no explicit reference was found in the text == Unused Reference: 'RELATED' is defined on line 1269, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'AMIS-A' -- Possible downref: Non-RFC (?) normative reference: ref. 'AMIS-D' ** Obsolete normative reference: RFC 1521 (ref. 'MIME') (Obsoleted by RFC 2045, RFC 2046, RFC 2047, RFC 2048, RFC 2049) ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) ** Obsolete normative reference: RFC 1854 (ref. 'PIPE') (Obsoleted by RFC 2197) ** Obsolete normative reference: RFC 1869 (ref. 'ESMTP') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 1426 (ref. '8BIT') (Obsoleted by RFC 1652) ** Obsolete normative reference: RFC 821 (ref. 'SMTP') (Obsoleted by RFC 2821) ** Obsolete normative reference: RFC 1830 (ref. 'BINARY') (Obsoleted by RFC 3030) ** Obsolete normative reference: RFC 1894 (ref. 'DSN') (Obsoleted by RFC 3464) ** Obsolete normative reference: RFC 1892 (ref. 'REPORT') (Obsoleted by RFC 3462) ** Obsolete normative reference: RFC 1891 (ref. 'DRPT') (Obsoleted by RFC 3461) ** Obsolete normative reference: RFC 1893 (ref. 'CODES') (Obsoleted by RFC 3463) -- Possible downref: Non-RFC (?) normative reference: ref. 'G726' ** Obsolete normative reference: RFC 1158 (ref. 'MIB II') (Obsoleted by RFC 1213) ** Obsolete normative reference: RFC 1872 (ref. 'RELATED') (Obsoleted by RFC 2112) -- Possible downref: Non-RFC (?) normative reference: ref. 'DIRECTORY' -- Possible downref: Non-RFC (?) normative reference: ref. 'VCARD' ** Obsolete normative reference: RFC 1766 (ref. 'LANG') (Obsoleted by RFC 3066, RFC 3282) ** Obsolete normative reference: RFC 1911 (ref. 'VPIM1') (Obsoleted by RFC 2421, RFC 2422, RFC 2423) -- Possible downref: Non-RFC (?) normative reference: ref. 'TIFF' -- Possible downref: Non-RFC (?) normative reference: ref. 'S100' Summary: 26 errors (**), 0 flaws (~~), 14 warnings (==), 11 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 November 11, 1996 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 Appedix F. 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 Message Content Types ...........................................13 60 4.4 Forwarded Messages ..............................................19 61 4.5 Reply Messages ..................................................19 62 5. Message Transport Protocol .........................................20 63 5.1 ESMTP Commands ..................................................20 64 5.2 ESMTP Keywords ..................................................22 65 5.3 ESMTP Parameters - MAIL FROM ....................................23 66 5.4 ESMTP Parameters - RCPT TO ......................................23 67 5.5 ESMTP - SMTP Downgrading ........................................24 68 6. Directory Address Resolution .......................................24 69 7. IMAP ...............................................................25 70 8. Management Protocols ...............................................25 71 8.1 Network Management ..............................................25 72 9. Conformance Requirements ...........................................25 73 10. References ........................................................26 74 11. Security Consideration ............................................28 75 12. Acknowledgments ...................................................28 76 13. Authors' Addresses ................................................28 77 14. Appendix A - VPIM Requirements Summary ............................29 78 15. Appendix B - Example Voice Messages ...............................35 79 16. Appendix C _ Example Error Voice Processing Error Codes ...........39 80 17. Appendix D - audio/32KADPCM Content Type ..........................40 81 18. Appendix E - image/TIFF Content Type ..............................41 82 18.1 References .....................................................41 83 18.2 TIFF Class F ...................................................41 84 19. Appendix F - Change History: RFC 1911 to this Document ............43 85 1. Abstract 87 A class of special-purpose computers has evolved to provide voice 88 messaging services. These machines generally interface to a telephone 89 switch and provide call answering and voice messaging services. 90 Traditionally, messages sent to a non-local machine are transported 91 using analog networking protocols based on DTMF signaling and analog 92 voice playback. As the demand for networking increases, there is a 93 need for a standard high-quality digital protocol to connect these 94 machines. The following document is a profile of the Internet 95 standard MIME and ESMTP protocols for use as a digital voice messaging 96 networking protocol. The profile is referred to as VPIM (Voice Profile 97 for Internet Mail) in this document. 99 This profile is based on earlier work in the Audio Message Interchange 100 Specification (AMIS) group that defined a voice messaging protocol 101 based on X.400 technology. This profile is intended to satisfy the 102 user requirements statement from that earlier work with the industry 103 standard ESMTP/MIME mail protocol infrastructures already used within 104 corporate intranets. This second version of VPIM is based on 105 implementation experience and obsoletes RFC 1911 which describes 106 version 1 of the profile. 108 2. Scope 110 MIME is the Internet multipurpose, multimedia messaging standard. 111 This document explicitly recognizes its capabilities and provides a 112 mechanism for the exchange of various messaging technologies, 113 primarily voice and facsimile. 115 This document specifies a restricted profile of the Internet 116 multimedia messaging protocols for use between voice processing 117 platforms. These platforms have historically been special-purpose 118 computers and often do not have the same facilities normally 119 associated with a traditional Internet Email-capable computer. As a 120 result, VPIM also specifies additional functionality as it is needed. 121 This profile is intended to specify the minimum common set of features 122 to allow interworking between compliant systems. 124 2.1 Voice Messaging System Limitations 126 The following are typical limitations of voice messaging platform 127 which were considered in creating this baseline profile. 129 1) Text messages are not normally received and often cannot be 130 displayed or viewed. They can often be processed only via text-to- 131 speech or text-to-fax features not currently present in many of 132 these machines. 134 2) Voice mail machines usually act as an integrated Message 135 Transfer Agent, Message Store and User Agent. There is no relaying 136 of messages, and RFC 822 header fields may have limited use in the 137 context of the limited messaging features currently deployed. 139 3) VM message stores are generally not capable of preserving the 140 full semantics of an Internet message. As such, use of a voice 141 mail machine for gatewaying is not supported. In particular, 142 storage of "CC" lists, "Received" lines, and "Message-ID" may be 143 limited. 145 4) Internet-style distribution/exploder mailing lists are not 146 typically supported. Voice mail machines often implement only 147 local alias lists, with error-to-sender and reply-to-sender 148 behavior. Reply-all capabilities using a CC list is not generally 149 available. 151 5) Error reports must be machine-parsable so that helpful responses 152 can be voiced to users whose only access mechanism is a telephone. 154 6) The voice mail systems generally limit address entry to 16 or 155 fewer numeric characters, and normally do not support alphanumeric 156 mailbox names. Alpha characters are not generally used for mailbox 157 identification as they cannot be easily entered from a telephone 158 terminal. 160 2.2 Design Goals 162 It is a goal of this profile to make as few restrictions and additions 163 to the existing Internet mail protocols as possible while satisfying 164 the requirements for interoperability with current generation voice 165 messaging systems. This goal is motivated by the desire to increase 166 the accessibility to digital messaging by enabling the use of proven 167 existing networking software for rapid development. 169 This specification is intended for use on a TCP/IP network, however, 170 it is possible to use the SMTP protocol suite over other transport 171 protocols. The necessary protocol parameters for such use is outside 172 the scope of this document. 174 This profile is intended to be robust enough to be used in an 175 environment, such as the global Internet with installed-base gateways 176 which do not understand MIME, though typical use is expected to be 177 within corporate intranets. Full functionality, such as reliable 178 error messages and binary transport, will require careful selection of 179 gateways (e.g., via MX records) to be used as VPIM forwarding agents. 180 Nothing in this document precludes use of a general purpose MIME email 181 packages to read and compose VPIM messages. While no special 182 configuration is required to receive VPIM compliant messages, some may 183 be required to originate compliant structures. 185 It is expected that a VPIM messaging system will be managed by a 186 system administrator who can perform TCP/IP network configuration. 187 When using facsimile or multiple voice encodings, it is suggested that 188 the system administrator maintain a list of the capabilities of the 189 networked mail machines to reduce the sending of undeliverable 190 messages due to lack of feature support. Configuration, 191 implementation and management of this directory listing capabilities 192 is a local matter. 194 3. Protocol Restrictions 196 This protocol does not limit the number of recipients per message. 197 Where possible, implementations should not restrict the number of 198 recipients in a single message. It is recognized that no 199 implementation supports unlimited recipients, and that the number of 200 supported recipients may be quite low. However, ESMTP currently does 201 not provide a mechanism for indicating the number of supported 202 recipients. 204 This protocol does not limit the maximum message length. Implementers 205 should understand that some machines will be unable to accept 206 excessively long messages. A mechanism is defined in the RFC 1425 207 SMTP service extensions to declare the maximum message size supported. 209 The message size indicated in the ESMTP SIZE command is in bytes, not 210 minutes or seconds. The number of bytes varies by voice encoding 211 format and must include the MIME wrapper overhead. If the length must 212 be known before sending, an approximate translation into minutes or 213 seconds can be performed if the voice encoding is known. 215 The following sections describe the restrictions and additions to 216 Internet mail protocols that are required to be compliant with this 217 VPIM v2 profile. Though various SMTP, ESMTP and MIME features are 218 described here, the implementor is referred to the relevant RFCs for 219 complete details. It is also advisable to check for IETF drafts of 220 various Internet Mail specifications that are later than the most 221 recent RFCs since, for example, MIME has yet to be published as a full 222 IETF Standard. The table in Appendix A summarizes the protocol details 223 of this profile. 225 4. Voice Message Interchange Format 227 The voice message interchange format is a profile of the Internet Mail 228 Protocol Suite. As such, this document assumes an understanding of 229 these specifications. Specifically, VPIM references components from 230 the message format standard for Internet messages [RFC822], the 231 Multipurpose Internet Message Extensions [MIME], the X.400 gateway 232 specification [X.400], delivery status notification 233 [DSN][DRPT][STATUS], and the electronic business card 234 [DIRECTORY][VCARD]. 236 4.1 Message Addressing Formats 238 RFC 822 addresses are based on the domain name system. This naming 239 system has two components: the local part, used for username or 240 mailbox identification; and the host part, used for global machine 241 identification. 243 4.1.1 VPIM Addresses 245 The local part of the address shall be a US-ASCII string uniquely 246 identifying a mailbox on a destination system. For voice messaging, 247 the local part is a printable string containing the mailbox ID of the 248 originator or recipient. While alpha characters and long mailbox 249 identifiers are permitted, most voice mail networks rely on numeric 250 mailbox identifiers to retain compatibility with the limited 10 digit 251 telephone keypad. The use of the domain naming system should be 252 transparent to the user. It is the responsibility of the voice mail 253 machine to lookup the fully-qualified domain name (FQDN) based on the 254 address entered by the user. (See section 6). 256 In the absence of a global directory, specification of the local part 257 is expected to conform to international or private telephone numbering 258 plans. It is likely that private numbering plans will prevail and 259 these are left for local definition. However, it is recommended that 260 public telephone numbers be noted according to the international 261 numbering plan described in [E.164]. The indication that the local 262 part is a pubilc telephone number is given by a preceding `+' (the `+' 263 would not be entered from a telephone keypad, it is added by the 264 system as a flag). Since the primary information in the numeric 265 scheme is contained by the digits, other character separators (e.g. `- 266 ') may be ignored (i.e. to allow parsing of the numeric local mailbox) 267 or may be used to recognize distinct portions of the telepone number 268 (e.g. country code). The specification of the local part of a VPIM 269 address can be split into the four groups described below: 271 1) mailbox number 272 - for use as a private numbering plan (any number of digits) 273 - e.g. 2722@octel.com 275 2) mailbox number+extension 276 - for use as a private numbering plan with extensions 277 any number of digits, use of `+' as separator 278 - e.g. 2722+111@octel.com 280 3) +international number 281 - for international telephone numbers conforming to E.164 282 maximum of 15 digits 283 - e.g. +16137637582@vm.nortel.ca 285 4) +international number+extension 286 - for international telephone numbers conforming to E.164 287 maximum of 15 digits, with an extension (e.g. behind a 288 PBX) that has a maximum of 15 digits. 289 - e.g. +17035245550+230@ema.org 291 4.1.2 Special Addresses 293 Special addresses are provided for compatibility with the conventions 294 of Internet mail. These addresses do not use numeric local addresses, 295 both to conform to current Internet practice and to avoid conflict 296 with existing numeric addressing plans. Two special addresses are 297 RESERVED for use as follows: 299 postmaster@domain 301 By convention, a special mailbox named "postmaster" MUST exist on all 302 systems. This address is used for diagnostics and should be checked 303 regularly by the system manager. This mailbox is particularly likely 304 to receive text messages, which is not normal on a voice processing 305 platform. The specific handling of these messages is an individual 306 implementation choice. 308 non-mail-user@domain 310 If a reply to a message is not possible, such as a telephone answering 311 message, then the special address _non-mail-user_ must be used as the 312 originator's address. Any text name such as "Telephone Answering," or 313 the telephone number if it is available, is permitted. This special 314 address is used as a token to indicate an unreachable originator. For 315 compatability with the installed base of mail user agents, 316 implementations that generate this special address MUST send a non- 317 delivery notification for reply messages sent to the undeliverable 318 address. The status code for such NDN's is 5.1.1 "Mailbox does not 319 exist". 321 Example: 323 From: Telephone Answering 325 4.1.3 Distribution Lists 327 There are many ways to handle distribution list (DL) expansions and 328 none are 'standard'. Simple alias is a behavior closest to what most 329 voice mail systems do today and what is to be used with VPIM messages. 330 That is: 332 Reply to the originator - (Address in the RFC822 Reply-to or From 333 field) 334 Errors to the submitter - (Address in the MAIL FROM: field of the 335 ESMTP exchange and the Return-Path: 336 RFC 822 field) 338 Some proprietary voice messaging protocols include only the recipient 339 of the particular copy in the envelope and include no "headers" except 340 date and per-message features. Most voice messaging systems do not 341 provide for "Header Information" in their messaging queues and only 342 include delivery information. As a result, recipient information MAY 343 be in either the To or CC headers. If all recipients cannot be 344 presented (e.g. unknown DL expansion) then the recipient headers MUST 345 be omitted to indicate that an accurate list of recipients (e.g. for 346 use with a reply-all capability) is not known. 348 4.2 Message Header Fields 350 Internet messages contain a header information block. This header 351 block contains information required to identify the sender, the list 352 of recipients, the message send time, and other information intended 353 for user presentation. Except for specialized gateway and mailing 354 list cases, headers do not indicate delivery options for the transport 355 of messages. 357 Exploder lists are noted for modifying or adding to the headers of 358 messages that pass through them. VPIM systems MUST be able to accept 359 and ignore headers that are not defined here. 361 The following header lines are permitted for use with VPIM voice 362 messages: 364 4.2.1 From 366 The originator's fully-qualified domain address (a mailbox address 367 followed by the fully-qualified domain name). The user listed in this 368 field should be presented in the voice message envelope as the 369 originator of the message. 371 Systems compliant with this profile SHOULD provide the text personal 372 name of the sender in a quoted phrase if the name is available. To 373 facilitate storage of the text name in a local dial-by-name cache 374 directory, the first and last name names must be separable. Text 375 names of the voice message originator MUST be represented in the form 376 "family, given, initials or additional names" and MUST contain the 377 same components as found in the Vcard N attribute (section 4.3.4), if 378 present. Text names of corporate or positional mailboxes MAY be 379 provided as a simple string. From [RFC822] 381 Example: 383 From: "User, Joe, S." <12145551212@mycompany.com> 385 From: Technical Support <611@serviceprovider.com> 387 The From address may be used for replies (see 4.5). However, if the 388 From: address contains , the user SHOULD not be 389 offered the option to reply, nor should notifications be sent to this 390 address. 392 4.2.2 To 394 The To header contains the recipient's fully-qualified domain address. 395 There may be one or more To: fields in any message. 397 Example: 399 To: 12145551213@mycompany.com 401 Systems compliant to this profile SHOULD provide a list of recipients 402 only if all recipients are provided. The To header MUST NOT be 403 included in the message if the sending message transport agent (MTA) 404 cannot resolve all the addresses in it, e.g. if an address is a DL 405 alias for which the expansion is unknown (see 4.1.3). If present, the 406 addresses in the To header MAY be used for a reply message to all 407 recipients. 409 Systems compliant to this profile MAY also discard the To addresses of 410 incoming messages because of the inability to store the information. 411 This would, of course, make a reply-to-all capability impossible. 413 4.2.3 Cc 415 The cc header contains additional recipients' fully-qualified domain 416 addresses. Many voice mail systems maintain only sufficient envelope 417 information for message delivery and are not capable of storing or 418 providing a complete list of recipients. 420 Systems compliant to this profile SHOULD provide a list of recipients 421 only if all disclosed recipients can be provided. The list of 422 disclosed recipients does not include those sent via a blind copy. If 423 not, systems SHOULD omit the To and Cc headers to indicate that the 424 full list of recipients is unknown. 426 Example: 428 Cc: 12145551213@mycompany.com 430 Systems compliant to this profile MAY discard the Cc addresses of 431 incoming messages as necessary. If a list of Cc or to addresses is 432 present, these addresses MAY be used for a reply message to all 433 recipients. 435 4.2.4 Date 437 The Date header contains the date, time, and time zone in which the 438 message was sent by the originator. The time zone SHOULD be 439 represented in a four-digit time zone offset, such as -0600 for North 440 American Eastern Standard Time. This may be supplemented by a time 441 zone name in parentheses, e.g., "-0800 (PDT)". Compliant 442 implementations SHOULD be able to convert RFC 822 date and time stamps 443 into local time. 445 Example: 447 Date: Wed, 28 Jul 96 10:08:49 -0900 (PST) 449 The sending system MUST report the time the message was sent. If the 450 VPIM sender is relaying a message from a system which does not provide 451 a timestamp, the time of arrival at the VPIM system SHOULD be used as 452 the date. From [RFC822] 454 4.2.5 Sender 456 The Sender header contains the actual address of the originator if the 457 message is sent by an agent on behalf of the author indicated in the 458 From: field and MAY be present in a VPIM message. 460 While it may not be possible to save this information in some voice 461 mail machines, discarding this information or the ESMTP MAIL FROM (see 462 4.2.6) address will make it difficult to send an error message to the 463 proper destination. From [RFC822] 465 4.2.6 Return Path 467 The Return-path header, if present, contains the address of the last 468 submitter of the message from the MAIL FROM parameter of the ESMTP 469 exchange (see 5.1.2). Error messages MUST be sent to this address 470 (see [DRPT] for additional details). Note that if the Return-path is 471 null ("<>"), e.g. no path, loop prevention or confidential, a 472 notification MUST NOT be sent. If the Return path address is not 473 available (either from this header or the MAIL FROM parameter) the 474 Sender or From addresses may be used to deliver notifications. 476 4.2.7 Message-id 478 The Message-id header contains a unique per-message identifier. A 479 unique message-id MUST be generated for each message sent from a 480 compliant implementation. 482 The message-id is not required to be stored on the receiving system. 483 This identifier MAY be used for tracking, auditing, and returning 484 read-receipt reports. From [RFC822] 486 Example: 488 Message-id: <12345678@mycompany.com> 490 4.2.8 Reply-To 492 If present, the reply-to header provides a preferred address to which 493 reply messages should be sent (see 4.5). If a reply-to header is 494 present, a reply-to sender message MUST be sent to the address 495 specified. From [RFC822] This preferred address of the originator 496 must also be provided in the originator's vCard EMAIL attribute, if 497 present (see 4.3.4). 499 4.2.9 Received 501 The Received header contains trace information added to the beginning 502 of a RFC 822 message by MTAs. This is the only header permitted to be 503 added by an MTA. Information in this header is useful for debugging 504 when using an US-ASCII message reader or a header parsing tool. 506 A compliant system MUST add Received headers when acting as a gateway 507 and MUST NOT remove any. These headers MAY be ignored or deleted when 508 the message is received at the final destination. From [RFC822] 510 4.2.10 MIME Version 512 The MIME-Version header indicates that the message conforms to the 513 MIME message format specification. Systems compliant with this 514 specification MUST include a comment with the words "(Voice 2.0)". RFC 515 1911 defines an earlier version of this profile and uses the token 516 (Voice 1.0). From [MIME][VPIM1] 518 Example: 520 MIME-Version: 1.0 (Voice 2.0) 522 A MIME message that contains this header is referred to in this 523 document as a VPIM Message. 525 4.2.11 Content-Type 527 The content-type header declares the type of content enclosed in the 528 message. One of the allowable contents is multipart/mixed, a 529 mechanism for bundling several message components into a single 530 message. The allowable contents are detailed in section 4.3 of this 531 document. From [MIME] 533 4.2.12 Content-Transfer-Encoding 535 Because Internet mail was initially specified to carry only 7-bit US- 536 ASCII text, it may be necessary to encode voice and fax data into a 537 representation suitable for that environment. The content-transfer- 538 encoding header describes this transformation if it is needed. 539 Compliant implementations MUST recognize and decode the standard 540 encodings, "Binary", "7bit, "8bit", "Base64" and "Quoted-Printable". 541 The allowable content-transfer-encodings are specified in section 4.3. 542 From [MIME] 544 4.2.13 Sensitivity 546 The sensitivity header, if present, indicates the requested privacy 547 level. The case-insensitive values "Personal" and "Private" are 548 specified. If no privacy is requested, this field is omitted. 550 If a sensitivity header is present in the message, a compliant system 551 MUST prohibit the recipient from forwarding this message to any other 552 user. A compliant system, however, SHOULD allow the user to reply to 553 a sensitive message, but SHOULD NOT include the original message 554 content. The sensitivity of the reply message MAY be set by the user. 556 If the receiving system does not support privacy and the sensitivity 557 is one of "Personal" or "Private", the message MUST be returned to the 558 sender with an appropriate error code indicating that privacy could 559 not be assured and that the message was not delivered. A non-delivery 560 notification to a private message need not be tagged private since it 561 will be sent to the originator. From: [X.400] 563 4.2.14 Importance 565 Indicates the requested priority to be given by the receiving system. 566 The case-insensitive values "low", "normal" and "high" are specified. 567 If no special importance is requested, this header may be omitted and 568 the value assumed to be "normal". 570 Compliant implementations MAY use this header to indicate the 571 importance of a message and may order messages in a recipient's 572 mailbox. From: [X400] 574 4.2.15 Subject 576 The subject field is often provided by email systems but is not widely 577 supported on Voice Mail platforms. For compatibility with text based 578 mailbox interfaces, a text subject field SHOULD be generated by a 579 compliant implementation but MAY be discarded if present by a 580 receiving system. From [RFC822] 582 It is recommended that voice messaging systems that do not support any 583 text user interfaces (e.g. access only by a telephone) insert a 584 generic subject header of "VPIM Message" for the benefit of text 585 enabled recipients. 587 4.3 Message Content Types 589 MIME, introduced in [MIME], is a general-purpose message body format 590 that is extensible to carry a wide range of body parts. It provides 591 for encoding binary data so that it can be transported over the 7-bit 592 text-oriented SMTP protocol. This transport encoding is in addition 593 to the audio encoding required to generate a binary object. 595 MIME defines two transport encoding mechanisms to transform binary 596 data into a 7 bit representation, one designed for text-like data 597 ("Quoted-Printable"), and one for arbitrary binary data ("Base64"). 598 While Base64 is dramatically more efficient for audio data, both will 599 work. Where binary transport is available, no transport encoding is 600 needed, and the data can be labeled as "Binary". 602 An implementation in compliance with this profile SHOULD send audio 603 and/or facsimile data in binary form when binary message transport is 604 available. When binary transport is not available, implementations 605 MUST encode the audio and/or facsimile data as Base64. The detection 606 and decoding of "Quoted-Printable", "7bit", and "8bit" MUST be 607 supported in order to meet MIME requirements and to preserve 608 interoperability with the fullest range of possible devices. However, 609 if a content is received that cannot be rendered to the user, an 610 appropriate non-delivery notification MUST be sent. 612 The content types described in this section are identified for use 613 with this profile. Other contents MUST NOT be used without prior 614 explicit per-destination configuration. If an implementation receives 615 a VPIM message (i.e. MIME-Version: 1.0 (Voice 2.0)) that contains 616 content types not specified in this profile, their handling is a local 617 implementation issue (e.g. they MAY be discarded if they cannot be 618 presented to the recipient). Conversely, if an implementation 619 receives a non-VPIM message with any of the following defined 620 contents, it SHOULD deliver those contents, but the full message 621 handling is a local issue (e.g. the unknown contents _or_ the entire 622 message MAY be discarded). It is recommended that implementations 623 issue notifications to the originator when any form of non-delivery to 624 the recipient occurs. 626 Each of the contents defined below can be sent individually in a VPIM 627 message or wrapped in a multipart/mixed to form a more complex 628 structure (several examples are given in Appendix B). When multiple 629 contents are present, they SHOULD be presented to the user in the 630 order that they appear in the message. 632 4.3.1 Text/Plain 634 MIME requires support of the basic Text/Plain content type. This 635 content type has limited applicability within the voice messaging 636 environment. Compliant implementations SHOULD NOT send the Text/Plain 637 content-type, but SHOULD only send this content if the recipient 638 system is known to support it. Compliant implementations MUST accept 639 Text/Plain messages, however, specific handling is left as an 640 implementation decision. From [MIME] 642 There are several mechanisms that can be used to support text on voice 643 messaging systems including text-to-speech and text-to-fax 644 conversions. If no rendering of the text is possible (i.e. it is not 645 possible for the recipient to determine if the text is a critical part 646 of the message), the entire message MUST be non-delivered and returned 647 to the sender with a media-unsupported error code. 649 4.3.2 Multipart/Mixed 651 MIME provides the facilities for enclosing several body parts in a 652 single message. Multipart/Mixed SHOULD be used for sending multi- 653 segment voice messages, that is for example, to preserve across the 654 network the distinction between an annotation and a forwarded message, 655 or between a spoken subject and the voice message. Compliant systems 656 MUST accept multipart/mixed body parts. Systems MAY collapse such a 657 multi-segment voice or fax message into a single segment if multi- 658 segment messages are not supported on the receiving machine. From 659 [MIME] 661 While any valid MIME body header MAY be used, the following header has 662 specific semantics when included with this body part: 664 4.3.2.1 Content-Description: 666 This field SHOULD be present to allow a text-based identification 667 of this body part as being a VPIM message. This is particularly 668 useful for identification when using a simple MIME mail package. 669 If there are multiple multipart/mixed bodies present on the same 670 level (i.e. not nested), then this header MUST be present to allow 671 differentiation. It is recommended that the value `VPIM Message' 672 be used to identify content compliant with this document. 674 4.3.3 Message/RFC822 676 MIME requires support of the Message/RFC822 message encapsulation body 677 part. This body part is used within a multipart/mixed message to 678 forward complete messages (see 4.4) or to reply with original content 679 (see 4.5). From [MIME] 681 4.3.4 Application/Directory 683 This content allows for the inclusion of a Versit vCard [VCARD] 684 electronic business card within a VPIM message. The format is 685 suitable as an interchange format between applications or systems, and 686 is defined independent of the method used to transport it. It 687 provides a useful mechanism to transport information about the 688 originator that can be used by the receiving VPIM system (see Section 6 689 or other local applications. 691 Each VPIM message SHOULD be created with an Application/Directory 692 content type [DIRECTORY] that MUST contain the preferred address and 693 telephone number of the message originator and SHOULD contain the 694 spoken name and the spelled name of the originator. The intent is 695 that the vCard be used as the source of information to contact the 696 originator (e.g. reply, call). 698 If included in a VPIM message, the vCard profile [VCARD] MUST be used 699 and MUST specify at least the following attributes: 701 TEL - Public switched telephone number in international (E.164) 702 format (various types, typically VOICE) 703 EMAIL - email address (various types, typically INTERNET; the type 704 VPIM is optionally used to denote the address that supports 705 VPIM messages) 707 The following attributes SHOULD be specified: 709 N - Family Name, Given Name, Additional Names, Honorific 710 Prefixes, and Suffixes (all present components in the From 711 text name MUST match) 712 ROLE - the role of the person identified in `N', but may be used 713 as an alternative to the `N' attribute when the sender is a 714 corporate or positional mailbox 715 SOUND - spoken name sound data (various types, typically 32KADPCM) 716 REV - Revision of Vcard in ISO 8601 date format 718 The vCard MAY use other attributes (e.g. capabilities) as defined in 719 [VCARD]. 721 If present, the spoken name attribute MUST be denoted by a content ID 722 pointing to an audio/* content elsewhere in the VPIM message. 724 A typical VPIM message (i.e. no forwarded parts), MUST only contain 725 one vCard -- more than one is an error condition. A VPIM message that 726 contains forwarded messages, though, may contain multiple vCards. 727 However, these vCards MUST be associated with the originator(s) of the 728 forwarded message(s) and the originator of the forwarding message. As 729 a result, all forwarded vCards will be contained in message/rfc822 730 contents -- only the vCard of forwarding originator will be at the 731 top-level. 733 Example: 735 BEGIN:VCARD 736 N:Parsons;Glenn 737 ORG:Nortel Technology 738 TEL;TYPE=VOICE,MSG,WORK:+1-613-763-7582 739 EMAIL;TYPE=INTERNET:glenn.parsons@nortel.ca 740 EMAIL;TYPE=INTERNET,VPIM:6137637582@vm.nortel.ca 741 SOUND;TYPE=32KADPCM;ENCODE=BASE64;VALUE=CID: 742 REV:19960831T103310Z 743 END:VCARD 745 4.3.5 Audio/32KADPCM 747 CCITT Recommendation G.726 [G726] describes the algorithm recommended 748 for conversion of a 64 kbit/s A-law or u-law PCM channel to and from a 749 32 kbit/s channel (this is the same algorithm as described in the 750 deprecated G.721). The conversion is applied to the PCM stream using 751 an Adaptive Differential Pulse Code Modulation (ADPCM) transcoding 752 technique. 754 An implementation compliant to this profile MUST use Audio/32KADPCM by 755 default for voice. Typically this body contains several minutes of 756 message content, however if used for spoken name or subject the 757 content should be considerably shorter (i.e. about 10 and 20 seconds 758 respectively). 760 If an implementation can only handle one voice body, then multiple 761 voice bodies (if present) SHOULD be concatenated, and SHOULD NOT be 762 discarded. It is recommended that this be done in the same order as 763 they were sent. 765 While any valid MIME body header MAY be used, several headers have the 766 following semantics when included with this body part: 768 4.3.5.1 Content-Description: 770 This field SHOULD be present to allow the parsable text 771 identification of these body parts. If more than one 772 Audio/32KADPCM body occurs within a single level (e.g. 773 multipart/mixed), then this header MUST be present to allow 774 differentiation. It is recommended that the following text values 775 be used as appropriate: 777 Voice Message - the primary voice message, 778 Voice Message Notification - a spoken delivery notification, 779 Originator Spoken Name - the spoken name of the originator, 780 Recipient Spoken Name - the spoken name of the recipient if 781 available to the originator and present if there is ONLY one 782 recipient, 783 Spoken Subject.- the spoken subject of the message, typically 784 spoken by the originator 786 Note that if an Originator Spoken Name audio body and a vCard are 787 both present in a VPIM message, the vCard SOUND attribute MUST 788 point to this audio body (see 4.3.4). 790 4.3.5.2 Content-Duration: 792 This field MAY be present to allow the specification of the length 793 of the audio bodypart in seconds. The use of this field on 794 reception is a local implementation issue. The formal BNF for this 795 header is: 797 duration := "Content-Duration" ":" 1*6DIGIT "seconds" 799 Example: 801 Content-Duration: 33 seconds 803 4.3.5.3 Content-Language: 805 This field MAY be present to allow the specification of the spoken 806 language of the bodypart. The encoding is defined in [LANG] (e.g. 807 EN-UK for UK English). The use of this field on reception is a 808 local implementation issue. 810 4.3.6 Proprietary Voice Formats 812 Proprietary voice encoding formats or other standard formats may be 813 supported under this profile provided a unique identifier is 814 registered with the IANA prior to use. These voice encodings should 815 be registered as sub-types of Audio. 817 Use of any other encoding except Audio/32KADPCM reduces 818 interoperability in the absence of explicit manual system 819 configuration. A compliant implementation MAY use any other encoding 820 with explicit per-destination configuration. 822 4.3.7 Image/TIFF 824 All implementations that support facsimile MUST generate and read 825 TIFF-F [TIFF][S100] compatible facsimile contents. The tags that MUST 826 be supported by systems complying to this recommendation are described 827 in the Enterprise Computer Telephony Forum's S.100 API specification 828 [S100]. The TIFF-F content, originally from [TPC.INT] has been 829 refined to reflect this common practice, and is summarized in Appendix 830 E for completeness. 832 An implementation MAY send this fax content in VPIM messages and MUST 833 be able to recognize it in received messages. If a fax message is 834 received that cannot be rendered to the user (e.g. the receiving VPIM 835 system does not support fax), then the system MUST non-deliver the 836 entire message with a media not supported error. 838 4.3.8 Multipart/report 840 The Multipart/Report is used for enclosing human-readable and machine 841 parsable notification (e.g. Message/delivery-status) body parts and 842 any returned message content. Compliant implementations MUST use the 843 Multipart/Report construct when returning messages, sending warnings, 844 or issuing read receipts. Compliant implementations MUST recognize 845 and decode the Multipart/Report content type. From [REPORT] 847 Multipart/Report messages that are VPIM messages (i.e. MIME-Version: 848 1.0 (Voice 2.0)) MUST include the human-readable description of the 849 error as a spoken audio/* content. 851 4.3.9 Message/delivery-status 853 This MIME body part is used for sending machine-parsable delivery 854 status notifications. Compliant implementations must use the 855 Message/delivery-status construct when returning messages or sending 856 warnings. Compliant implementations must recognize and decode the 857 Message/delivery-status content type and present the reason for 858 failure to the user. From [DSN] 860 4.4 Forwarded Messages 862 VPIM version 2 explicitly supports the forwarding of voice and fax 863 content with voice or fax annotation. Forwarded VPIM messages SHOULD 864 be sent as a multipart/mixed with the entire original message enclosed 865 in a message/rfc822 content type and the annotation as a separate 866 Audio/* or image/TIFF body part. 868 In the event that the RFC822 headers are not available for the 869 forwarded content, simulated headers with information as available 870 SHOULD be constructed to indicate the original sending timestamp, and 871 the original sender as indicated in the "From" line. The 872 message/rfc822 content MUST include at least the MIME-Version: 1.0 873 (Voice 2.0), the MIME content type and MIME content-encoding header as 874 necessary. 876 In the event that forwarding information is lost through concatenation 877 of the original message and the forwarding annotation, such as must be 878 done in an AMIS to VPIM gateway, the entire content MAY be sent as a 879 single Audio/* segment without including any forwarding semantics. 881 4.5 Reply Messages 883 Replies to VPIM messages (and Internet mail messages) are addressed to 884 the address noted in the reply-to header (see 4.2.8) if it is present, 885 else the From address (see 4.2.1) is used. Support of multiple 886 originator headers is often not possible on voice messaging systems, 887 so it may be necessary to choose only one. However, implementors 888 should note that this may make it impossible to send error messages 889 and replies to the proper destination. 891 In some cases, a reply message is not possible, such as with a message 892 created by telephone answering (i.e. classic voice mail). In this 893 case, the From field MUST contain the special address non-mail- 894 user@domain (see 4.1.2). The use of a null ESMTP MAIL FROM address 895 SHOULD also be used in this case (see 5.1.2). A receiving VPIM system 896 SHOULD not offer the user the option to reply to this kind of message. 898 5. Message Transport Protocol 900 Messages are transported between voice mail machines using the 901 Internet Extended Simple Mail Transfer Protocol (ESMTP). All 902 information required for proper delivery of the message is included in 903 the ESMTP dialog. This information, including the sender and 904 recipient addresses, is commonly referred to as the message 905 "envelope". This information is equivalent to the message control 906 block in many analog voice networking protocols. 908 ESMTP is a general-purpose messaging protocol, designed both to send 909 mail and to allow terminal console messaging. Simple Mail Transport 910 Protocol (SMTP) was originally created for the exchange of US-ASCII 7- 911 bit text messages. Binary and 8-bit text messages have traditionally 912 been transported by encoding the messages into a 7-bit text-like form. 913 [ESMTP] formalized an extension mechanism for SMTP, and subsequent 914 RFCs have defined 8-bit text networking, command streaming, binary 915 networking, and extensions to permit the declaration of message size 916 for the efficient transmission of large messages such as multi-minute 917 voice mail. 919 The following sections list ESMTP commands, keywords, and parameters 920 that are required and those that are optional for conformance to this 921 profile. 923 5.1 ESMTP Commands 925 5.1.1 HELO 927 Base SMTP greeting and identification of sender. This command is not 928 to be sent by compliant systems unless the more-capable EHLO command 929 is not accepted. It is included for compatibility with general SMTP 930 implementations. Compliant implementations MUST implement the HELO 931 command for backward compatibility but SHOULD NOT send it unless EHLO 932 is not supported. From [SMTP] 934 5.1.2 MAIL FROM (REQUIRED) 936 Originating mailbox. This address contains the mailbox to which 937 errors should be sent. This address may not be the same as the 938 message sender listed in the message header fields if the message was 939 received from a gateway or sent to an Internet-style mailing list. 940 Compliant implementations MUST implement the extended MAIL FROM 941 command. From [SMTP, ESMTP] 943 The MAIL FROM address MAY be passed as a local system parameter or 944 placed in a Return-Path: line inserted at the beginning of a VPIM 945 message. From [HOSTREQ] 947 Since error messages MUST be sent to the MAIL FROM address, the use of 948 the null address ("<>") is often used to prevent looping of error 949 notifications. This null address MAY also be used to note that a 950 particular message has no return path (e.g. a telephone answer 951 message). From [SMTP] 953 5.1.3 RCPT TO 955 Recipient's mailbox. This field contains only the addresses to which 956 the message should be delivered for this transaction. In the event 957 that multiple transport connections to multiple destination machines 958 are required for the same message, this list may not match the list of 959 recipients in the message header. Compliant implementations MUST 960 implement the extended RCPT TO command. From [SMTP, ESMTP] 962 5.1.4 DATA 964 Initiates the transfer of message data. Support for this command is 965 required in the event the binary mode command BDAT is not supported by 966 the remote system. Compliant implementations MUST implement the SMTP 967 DATA command for backwards compatibility. From [SMTP] 969 5.1.5 TURN 971 Requests a change-of-roles, that is, the client that opened the 972 connection offers to assume the role of server for any mail the remote 973 machine may wish to send. Because SMTP is not an authenticated 974 protocol, the TURN command presents an opportunity to improperly fetch 975 mail queued for another destination. Compliant implementations SHOULD 976 NOT implement the TURN command. From [SMTP] 978 5.1.6 QUIT 980 Requests that the connection be closed. If accepted, the remote 981 machine will reset and close the connection. Compliant 982 implementations MUST implement the QUIT command. From [SMTP] 984 5.1.7 RSET 986 Resets the connection to its initial state. Compliant implementations 987 MUST implement the RSET command. From [SMTP] 989 5.1.8 VRFY 991 Requests verification that this node can reach the listed recipient. 992 While this functionality is also included in the RCPT TO command, VRFY 993 allows the query without beginning a mail transfer transaction. This 994 command is useful for debugging and tracing problems. Compliant 995 implementations MAY implement the VRFY command. From [SMTP] 997 (Note that the implementation of VRFY may simplify the guessing of a 998 recipient's mailbox or automated sweeps for valid mailbox addresses, 999 resulting in a possible reduction in privacy. Various implementation 1000 techniques may be used to reduce the threat, such as limiting the 1001 number of queries per session.) From [SMTP] 1003 5.1.9 EHLO 1005 The enhanced mail greeting that enables a server to announce support 1006 for extended messaging options. The extended messaging modes are 1007 discussed in subsequent sections of this document. Compliant 1008 implementations MUST implement the ESMTP command and return the 1009 capabilities indicated later in this memo. From [ESMTP] 1011 5.1.10 BDAT 1013 The BDAT command provides a higher efficiency alternative to the 1014 earlier DATA command, especially for voice. The BDAT command provides 1015 for native binary transport of messages. Compliant implementations 1016 SHOULD support binary transport using the BDAT command.[BINARY] 1018 5.2 ESMTP Keywords 1020 The following ESMTP keywords indicate extended features useful for 1021 voice messaging. 1023 5.2.1 PIPELINING 1025 The "PIPELINING" keyword indicates ability of the receiving server to 1026 accept new commands before issuing a response to the previous command. 1027 Pipelining commands dramatically improves performance by reducing the 1028 number of round-trip packet exchanges and makes it possible to 1029 validate all recipient addresses in one operation. Compliant 1030 implementations SHOULD support the command pipelining indicated by 1031 this parameter. From [PIPE] 1033 5.2.2 SIZE 1035 The "SIZE" keyword provides a mechanism by which the SMTP server can 1036 indicate the maximum size message supported. Compliant 1037 implementations MUST provide the size capability and SHOULD honor any 1038 size limitations when sending. From [SIZE] 1040 5.2.3 CHUNKING 1042 The "CHUNKING" keyword indicates that the receiver will support the 1043 high-performance binary transport mode. Note that CHUNKING can be 1044 used with any message format and does not imply support for binary 1045 encoded messages. Compliant implementations SHOULD support binary 1046 transport indicated by this capability. From [BINARY] 1048 5.2.4 BINARYMIME 1050 The "BINARYMIME" keyword indicates that the SMTP server can accept 1051 binary encoded MIME messages. Compliant implementations SHOULD support 1052 binary transport indicated by this capability. Note that support for 1053 this feature requires support of CHUNKING. From [BINARY] 1055 5.2.5 NOTIFY 1057 The "NOTIFY" keyword indicates that the SMTP server will accept 1058 explicit delivery status notification requests. Compliant 1059 implementations MUST support the delivery notification extensions in 1060 [DRPT]. 1062 5.2.6 ENHANCEDSTATUSCODES 1064 The "ENHANCEDSTATUSCODES" keyword indicates that an SMTP server 1065 augments its responses with the enhanced mail system status codes 1066 [CODES]. These codes can then be used to provide more informative 1067 explanations of error conditions, especially in the context of the 1068 delivery status notifications format defined in [DSN]. Compliant 1069 implementations SHOULD support this capability. From [STATUS] 1071 5.3 ESMTP Parameters - MAIL FROM 1073 5.3.1 BINARYMIME 1075 The current message is a binary encoded MIME messages. Compliant 1076 implementations SHOULD support binary transport indicated by this 1077 parameter. From [BINARY] 1079 5.3.2 RET 1081 The RET parameter indicates whether the content of the message should 1082 be returned. Compliant systems SHOULD honor a request for returned 1083 content. From [DRPT] 1085 5.3.3 ENVID 1087 The ENVID keyword of the SMTP MAIL command is used to specify an 1088 "envelope identifier" to be transmitted along with the message and 1089 included in any DSNs issued for any of the recipients named in this 1090 SMTP transaction. The purpose of the envelope identifier is to allow 1091 the sender of a message to identify the transaction for which the DSN 1092 was issued. Compliant implementations MAY use this parameter. From 1093 [DRPT] 1095 5.4 ESMTP Parameters - RCPT TO 1097 5.4.1 NOTIFY 1099 The NOTIFY parameter indicates the conditions under which a delivery 1100 report should be sent. Compliant implementations MUST honor this 1101 request. From [DRPT] 1103 5.4.2 ORCPT 1105 The ORCPT keyword of the RCPT command is used to specify an "original" 1106 recipient address that corresponds to the actual recipient to which 1107 the message is to be delivered. If the ORCPT esmtp-keyword is used, 1108 it MUST have an associated esmtp-value, which consists of the original 1109 recipient address, encoded according to the rules below. Compliant 1110 implementations MAY use this parameter. From [DRPT] 1112 5.5 ESMTP - SMTP Downgrading 1114 To ensure a consistent level of service across an intranet or the 1115 global Internet, it is essential that VPIM compliant ESMTP be 1116 supported at all hops between a VPIM originating system and the 1117 recipient system. Unfortunately, in the situation where a `downgrade' 1118 is unavoidable the expected result is not defined. A downgrade is 1119 defined as the loss of VPIM transport features at some hop due to the 1120 lack of support. For example, a relay hop may be forced (by the next 1121 hop) to forward a VPIM using SMTP instead of ESMTP, or using DATA 1122 instead of BDAT. It is recommended that the downgrading system should 1123 continue to attempt to deliver the message, but MUST send an 1124 appropriate delivery notification to the originator, e.g. the message 1125 left an ESMTP host and was sent (unreliably) via SMTP. 1127 6. Directory Address Resolution 1129 It is the responsibility of a VPIM system to lookup the fully- 1130 qualified domain name (FQDN) based on the address entered by the user 1131 (if the entered address is not already a FQDN). This would typically 1132 be an issue on systems that offered only a telephone user interface. 1133 The mapping of the dialed target number to a routable FQDN address 1134 allowing delivery to the destination system can be accomplished 1135 through implementation-specific means. 1137 An implementation may wish to populate local directories with address 1138 information extracted from received messages. It is mandated that 1139 only address information from vCard attachments to VPIM messages be 1140 used to populate such a directory when the vCard is available. 1141 Stripping addresses from the headers of VPIM messages SHOULD NOT be 1142 used to populate directories as it only provides partial data. 1143 Alternatively, bilateral agreements could be made to allow the bulk 1144 transfer of vCards between systems. 1146 7. IMAP 1148 The use of client/server desktop mailbox protocols like IMAP or POP to 1149 retrieve VPIM messages from a IMAP or POP message store is possible 1150 without any special modifications to this VPIM specification. Email 1151 clients (and web browsers) typically have a table for mapping from 1152 MIME type to displaying application. The audio/*, image/tiff and 1153 application/directory contents can be configured so that they invoke 1154 the correct player/recorder for rendering. In addition with IMAP 1155 clients, the first multipart/mixed content (if present) will not 1156 appear since it is a generic part. The user instead will be presented 1157 with a message that has (for example) audio and image contents. 1159 8. Management Protocols 1161 The Internet protocols provide a mechanism for the management of 1162 messaging systems, from the management of the physical network through 1163 the management of the message queues. SNMP should be supported on a 1164 compliant message machine. 1166 8.1 Network Management 1168 The digital interface to the VM and the TCP/IP protocols SHOULD be 1169 managed. MIB II SHOULD be implemented to provide basic statistics and 1170 reporting of TCP and IP protocol performance. [MIB II] 1172 9. Conformance Requirements 1174 In order to claim conformance to this document and be called `VPIM 1175 compliant', a voice messaging system must implement all mandatory 1176 features of this profile in each of three areas: Content, Transport, 1177 and Notifications. In addition, systems which conform to this profile 1178 must not send messages with features beyond this profile unless 1179 explicit per-destination configuration of these enhanced features is 1180 provided. Such configuration information could be stored in a 1181 directory, though the implementation of this is currently a local 1182 matter. 1184 It is also possible, though not encouraged, to claim conformance to 1185 only specific areas (e.g. VPIM content compliant) of this profile. 1186 The delineation of these areas is as follows: 1188 Content - Section 4, except REPORT & NOTIFY and Section 1189 6. 1191 Transport - Section 5 except NOTIFY & RET, and Section 8 1193 Notifications - REPORT & NOTIFY from Section 4, NOTIFY, RET & 1194 ENHANCEDSTATUSCODES from Section 5, and all 1195 notification requirements. 1197 A summary of compliance requirements is contained in Appendix A. 1199 10. References 1201 [AMIS-A] Audio Messaging Interchange Specifications (AMIS) - Analog 1202 Protocol Version 1, Issue 2, February 1992 1204 [AMIS-D] Audio Messaging Interchange Specifications (AMIS) - Digital 1205 Protocol Version 1, Issue 3 August 1993 1207 [MIME] Borenstein, N., and N. Freed, "Multipurpose Internet Mail 1208 Extensions", RFC 1521, Bellcore, Innosoft, Sept 1993. 1210 [RFC822] Crocker, D., "Standard for the Format of ARPA Internet Text 1211 Messages", STD 11, RFC 822, UDEL, August 1982. 1213 [X.400] Hardcastle-Kille, S., "Mapping between X.400(1988) / ISO 10021 1214 and RFC 822", RFC 1327, May 1992. 1216 [PIPE] Freed, N., Cargille, A., "SMTP Service Extension for Command 1217 Pipelining" RFC 1854, October 1995. 1219 [ESMTP] Klensin, J., Freed, N., Rose, M., Stefferud, E., and D. Crocker, 1220 "SMTP Service Extensions" RFC 1869, United Nations University, 1221 Innosoft International, Inc., Dover Beach Consulting, Inc., Network 1222 Management Associates, Inc., The Branch Office, November 1995. 1224 [SIZE] Klensin, J, Freed, N., Moore, K, "SMTP Service Extensions for 1225 Message Size Declaration" RFC 1870, United Nations University, 1226 Innosoft International, Inc., November 1995. 1228 [8BIT] Klensin, J., Freed, N., Rose, M., Stefferud, E., D. Crocker, 1229 "SMTP Service Extension for 8bit-MIMEtransport" RFC 1426, United 1230 Nations University, Innosoft International, Inc., Dover Beach 1231 Consulting, Inc., Network Management Associates, Inc., The Branch 1232 Office, February 1993. 1234 [DNS1] Mockapetris, P., "Domain names - implementation and 1235 specification", RFC1035, Nov 1987. 1237 [DNS2] Mockapetris, P., "Domain names - concepts and facilities", RFC 1238 1034, Nov 1987. 1240 [SMTP] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, 1241 USC/Information Sciences Institute, August 1982. 1243 [BINARY] Vaudreuil, G., "SMTP Service Extensions for Transmission of 1244 Large and Binary MIME Messages", RFC 1830, October 1995. 1246 [DSN] Moore, K., Vaudreuil, G., "An Extensible Message Format for 1247 Delivery Status Notifications", RFC 1894, 01/15/1996. 1249 [REPORT] Vaudreuil, G., "The Multipart/Report Content Type for the 1250 Reporting of Mail System Administrative Messages", RFC 1892, 1251 01/15/1996. 1253 [DRPT] Moore, K. "SMTP Service Extensions for Delivery Status 1254 Notifications", RFC 1891, 01/15/1996 1256 [CODES] Vaudreuil, G. "Enhanced Mail System Status Codes", RFC 1893, 1257 01/15/1996. 1259 [STATUS] Freed, N. "SMTP Service Extension for Returning Enhanced Error 1260 Codes", RFC 2034, 10/30/1996. 1262 [G726] CCITT Recommendation G.726 (1990), General Aspects of Digital 1263 Transmission Systems, Terminal Equipment - 40, 32, 24,16 kbit/s 1264 Adaptive Differential Pulse Code Modulation (ADPCM). 1266 [MIB II] M. Rose, "Management Information Base for Network Management of 1267 TCP/IP-based internets: MIB-II", RFC 1158, May 1990. 1269 [RELATED] Levinson, E., "The MIME Multipart/Related Content-type", RFC 1270 1872, Dec 1995 1272 [DIRECTORY] Howes, Tim, Smith, Mark, "A MIME Content-Type for Directory 1273 Information" 1275 [VCARD] Dawson, Frank, Howes, Tim, "An Application/Directory MIME 1276 Content-Type Electronic Business Card Profile" 1279 [LANG] Alvestrand,H., "Tags for the Identification of Languages", RFC 1280 1766, Mar 1995 1282 [TPC.INT] C. Malamud, M. Rose, "Principles of Operation for the TPC.INT 1283 Subdomain: Remote Printing -- Technical Procedures", RFC 1528, 1284 10/06/1993 1286 [VPIM1] Vaudreuil, Greg, "Voice Profile for Internet Mail", RFC 1911, 1287 Feb 1996. 1289 [TIFF] Adobe Developers Association, TIFF (TM) Revision 6.0 - Final, 1290 June 3, 1992. 1292 [S100] Enterprise Computer Telephony Forum, S.100 Revision 1.0 - Media 1293 Services "C" Language - Application Programming Interfaces, February 1294 1996. 1296 [HOSTREQ] Braden, R., "Requirements for Internet Hosts -- Application 1297 and Support", STD 3, RFC 1123, October 1989. 1299 11. Security Consideration 1301 This document is a profile of existing Internet mail protocols. As 1302 such, it does not create any security issues not already existing in 1303 the profiled Internet mail protocols themselves. 1305 Further, the profile specified in this document does not in any way 1306 preclude the use of any Internet mail security protocol to encrypt, 1307 authenticate, or non-repudiate the messages. 1309 12. Acknowledgments 1311 The authors would like to offer a special thanks to the Electronic 1312 Messaging Association, especially the members of the Voice Messaging 1313 Committee, for their support of the VPIM specification and the efforts 1314 they have made to ensure its success. 1316 13. Authors' Addresses 1318 Glenn W. Parsons 1319 Nortel Technology 1320 P.O. Box 3511, Station C 1321 Ottawa, ON K1Y 4H7 1322 Canada 1323 Phone: +1-613-763-7582 1324 Fax: +1-613-763-8385 1325 Glenn.Parsons@Nortel.ca 1327 Gregory M. Vaudreuil 1328 Octel Communications 1329 17080 Dallas Parkway 1330 Dallas, TX 75248-1905 1331 United States 1332 Phone/Fax: +1-972-733-2722 1333 Greg.Vaudreuil@Octel.Com 1335 14. Appendix A - VPIM Requirements Summary 1337 The following table summarizes the profile of VPIM version 2 detailed 1338 in this document. For complete explanations of each feature it is 1339 recommended to read the accompanying text. The conformance table is 1340 separated into various columns: 1342 Feature - name of protocol feature (note that the indenting 1343 indicates 1344 a hierarchy of conformance, i.e. the conformance of a 1345 lower 1346 feature is only relevant if there is comformance to the 1347 higher feature) 1349 Section - reference section in main text of this document 1351 Area - conformance area to which each feature applies: 1352 C - content 1353 T - transport 1354 N - notifications 1356 Status - whether the feature is mandatory, optional, or prohibited. 1357 There are three different degrees of optional used in this table: 1358 Must - mandatory 1359 Should - encouraged optional 1360 May - optional 1361 Should not - discouraged optional 1362 Must not - prohibited 1364 Footnote - special comment about conformance for a particular 1365 feature 1366 VPIM version 2 Conformance 1367 | | | | |S| | 1368 | | | | | |H| |F 1369 | | | | | |O|M|o 1370 | | | |S| |U|U|o 1371 | | | |H| |L|S|t 1372 | |A|M|O| |D|T|n 1373 | |R|U|U|M| | |o 1374 | |E|S|L|A|N|N|t 1375 | |A|T|D|Y|O|O|t 1376 FEATURE |SECTION | | | | |T|T|e 1377 -------------------------------------------|----------|-|-|-|-|-|-|- 1378 | | | | | | | | 1379 Message Addressing Formats: | | | | | | | | 1380 Use DNS host names |4.1 |C|x| | | | | 1381 Use only numbers in mailbox IDs |4.1.1 |C| |x| | | | 1382 Use alpha-numeric mailbox IDs |4.1.1 |C| | |x| | | 1383 Support of postmaster@domain |4.1.2 |C|x| | | | | 1384 Support of non-mail-user@domain |4.1.2 |C| |x| | | | 1385 Support of distribution lists |4.1.3 |C| |x| | | | 1386 | | | | | | | | 1387 Message Header Fields: | | | | | | | | 1388 Encoding outbound messages | | | | | | | | 1389 From |4.2.1 |C|x| | | | | 1390 Addition of text name |4.2.1 |C| |x| | | | 1391 To |4.2.2 |C|x| | | | |1 1392 cc |4.2.3 |C| |x| | | |1 1393 Date |4.2.4 |C|x| | | | | 1394 Sender |4.2.5 |C| | |x| | | 1395 Return-Path |4.2.6 |C| | |x| | | 1396 Message-id |4.2.7 |C|x| | | | | 1397 Reply-To |4.2.8 |C| | |x| | | 1398 Received |4.2.9 |C|x| | | | | 1399 MIME Version: 1.0 (Voice 2.0) |4.2.10 |C|x| | | | | 1400 Content-Type |4.2.11 |C|x| | | | | 1401 Content-Transfer-Encoding |4.2.12 |C|x| | | | | 1402 Sensitivity |4.2.13 |C| | |x| | | 1403 Importance |4.2.14 |C| | |x| | | 1404 Subject |4.2.15 |C| |x| | | | 1405 Other Headers |4.2 |C| | |x| | | 1406 | | | | | | | | 1407 | | | | |S| | 1408 | | | | | |H| |F 1409 | | | | | |O|M|o 1410 | | | |S| |U|U|o 1411 | | | |H| |L|S|t 1412 | |A|M|O| |D|T|n 1413 | |R|U|U|M| | |o 1414 | |E|S|L|A|N|N|t 1415 | |A|T|D|Y|O|O|t 1416 FEATURE |SECTION | | | | |T|T|e 1417 -------------------------------------------|----------|-|-|-|-|-|-|- 1418 Detection & Decoding inbound messages | | | | | | | | 1419 From |4.2.1 |C|x| | | | | 1420 Utilize text personal name |4.2.1 |C| |x| | | | 1421 To |4.2.2 |C|x| | | | | 1422 cc |4.2.3 |C| | |x| | | 1423 Date |4.2.4 |C|x| | | | | 1424 Conversion of Date to local time |4.2.4 |C| |x| | | | 1425 Sender |4.2.5 |C| | |x| | | 1426 Return-Path |4.2.6 |C| | |x| | | 1427 Message ID |4.2.7 |C|x| | | | | 1428 Reply-To |4.2.8 |C|x| | | | | 1429 Received |4.2.9 |C| | |x| | | 1430 MIME Version: 1.0 (Voice 2.0) |4.2.10 |C|x| | | | | 1431 Content Type |4.2.11 |C|x| | | | | 1432 Content-Transfer-Encoding |4.2.12 |C|x| | | | | 1433 Sensitivity |4.2.13 |C|x| | | | |2 1434 Importance |4.2.14 |C| | |x| | | 1435 Subject |4.2.15 |C| | |x| | | 1436 Other Headers |4.2 |C|x| | | | |3 1437 | | | | | | | | 1438 Message Content Encoding: | | | | | | | | 1439 Encoding outbound audio/fax contents | | | | | | | | 1440 7BITMIME |4.3 |C| | | | |x| 1441 8BITMIME |4.3 |C| | | | |x| 1442 Quoted Printable |4.3 |C| | | | |x| 1443 Base64 |4.3 |C|x| | | | |4 1444 Binary |4.3 |C| |x| | | |5 1445 Detection & decoding inbound messages | | | | | | | | 1446 7BITMIME |4.3 |C|x| | | | | 1447 8BITMIME |4.3 |C|x| | | | | 1448 Quoted Printable |4.3 |C|x| | | | | 1449 Base64 |4.3 |C|x| | | | | 1450 Binary |4.3 |C|x| | | | |5 1451 | | | | | | | | 1452 | | | | |S| | 1453 | | | | | |H| |F 1454 | | | | | |O|M|o 1455 | | | |S| |U|U|o 1456 | | | |H| |L|S|t 1457 | |A|M|O| |D|T|n 1458 | |R|U|U|M| | |o 1459 | |E|S|L|A|N|N|t 1460 | |A|T|D|Y|O|O|t 1461 FEATURE |SECTION | | | | |T|T|e 1462 -------------------------------------------|----------|-|-|-|-|-|-|- 1463 Message Content Types: | | | | | | | | 1464 Inclusion in outbound messages | | | | | | | | 1465 Text/plain |4.3.1 |C| | | |x| | 1466 Multipart/Mixed |4.3.2 |C| |x| | | | 1467 Content-Description |4.3.2.1 |C| |x| | | |6 1468 Message/RFC822 |4.3.3 |C| | |x| | | 1469 Application/Directory |4.3.4 |C| |x| | | | 1470 include TEL, EMAIL |4.3.4 |C|x| | | | | 1471 include N, ROLE, SOUND, REV |4.3.4 |C| |x| | | | 1472 only one per level |4.3.4 |C|x| | | | | 1473 Audio/32KADPCM |4.3.5 |C|x| | | | | 1474 Content-Description |4.3.5.1 |C| |x| | | |6 1475 Content-Duration |4.3.5.2 |C| | |x| | | 1476 Content-Langauge |4.3.5.3 |C| | |x| | | 1477 Audio/* (other encodings) |4.3.6 |C| | |x| | | 1478 Image/TIFF |4.3.7 |C| | |x| | | 1479 Multipart/Report |4.3.8 |N|x| | | | | 1480 human-readable part is voice |4.3.8 |N|x| | | | | 1481 Message/delivery-status |4.3.9 |N|x| | | | | 1482 Other contents |4.3 |C| | | |x| |7 1483 | | | | | | | | 1484 Detection & decoding in inbound messages | | | | | | | | 1485 Text/plain |4.3.1 |C|x| | | | | 1486 send NDN if unable to render |4.3.1 |N|x| | | | |8 1487 Multipart/Mixed |4.3.2 |C|x| | | | | 1488 Content-Description |4.3.2.1 |C| | |x| | | 1489 Message/RFC822 |4.3.3 |C|x| | | | | 1490 Application/Directory |4.3.4 |C| |x| | | | 1491 recognize TEL, EMAIL |4.3.4 |C|x| | | | | 1492 recognize N, ROLE, SOUND, REV |4.3.4 |C| |x| | | | 1493 Audio/32KADPCM |4.3.5 |C|x| | | | | 1494 Content-Description |4.3.5.1 |C| |x| | | | 1495 Content-Duration |4.3.5.2 |C| | |x| | | 1496 Content-Langauge |4.3.5.3 |C| | |x| | | 1497 Audio/* (other encodings) |4.3.6 |C| | |x| | | 1498 Image/TIFF |4.3.7 |C|x| | | | | 1499 send NDN if unable to render |4.3.7 |N|x| | | | |8 1500 Multipart/Report |4.3.8 |N|x| | | | | 1501 Message/delivery-status |4.3.9 |N|x| | | | | 1502 Other contents |4.3 |C| | |x| | |7 1503 send NDN if unable to render |4.3 |N| |x| | | | 1504 | | | | | |S| | 1505 | | | | | |H| |F 1506 | | | | | |O|M|o 1507 | | | |S| |U|U|o 1508 | | | |H| |L|S|t 1509 | |A|M|O| |D|T|n 1510 | |R|U|U|M| | |o 1511 | |E|S|L|A|N|N|t 1512 | |A|T|D|Y|O|O|t 1513 FEATURE |SECTION | | | | |T|T|e 1514 ------------------------------------------|-----------|-|-|-|-|-|-|- 1515 | | | | | | | | 1516 Forwarded Messages | | | | | | | | 1517 use Message/RFC822 construct |4.4 |C| |x| | | | 1518 simulate headers if none available |4.4 |C| |x| | | | 1519 | | | | | | | | 1520 Reply Messages | | | | | | | | 1521 send to Reply-to, else From address |4.5 |C|x| | | | | 1522 do not send to non-mail-user |4.5 |C|x| | | | | 1523 | | | | | | | | 1524 Message Transport Protocol: | | | | | | | | 1525 ESMTP Commands | | | | | | | | 1526 HELO |5.1.1 |T|x| | | | | 1527 MAIL FROM |5.1.2 |T|x| | | | | 1528 support null address |5.1.2 |T|x| | | | | 1529 RCPT TO |5.1.3 |T|x| | | | | 1530 DATA |5.1.4 |T|x| | | | | 1531 TURN |5.1.5 |T| | | | |x| 1532 QUIT |5.1.6 |T|x| | | | | 1533 RSET |5.1.7 |T|x| | | | | 1534 VRFY |5.1.8 |T| | |x| | | 1535 EHLO |5.1.9 |T|x| | | | | 1536 BDAT |5.1.10 |T| |x| | | |5 1537 ESMTP Keywords & Parameters | | | | | | | | 1538 PIPELINING |5.2.1 |T| |x| | | | 1539 SIZE |5.2.2 |T|x| | | | | 1540 CHUNKING |5.2.3 |T| |x| | | | 1541 BINARYMIME |5.2.4,5.3.1|T| |x| | | | 1542 NOTIFY |5.2.5,5.4.1|N|x| | | | | 1543 ENHANCEDSTATUSCODES |5.2.6 |N| |x| | | | 1544 RET |5.3.2 |N| |x| | | | 1545 ENVID |5.3.3 |N| | |x| | | 1546 ORCPT |5.4.2 |N| | |x| | | 1547 | | | | | | | | 1548 ESMTP-SMTP Downgrading | | | | | | | | 1549 send delivery report upon downgrade |5.5 |N|x| | | | | 1550 | | | | | | | | 1551 | | | | |S| | 1552 | | | | | |H| |F 1553 | | | | | |O|M|o 1554 | | | |S| |U|U|o 1555 | | | |H| |L|S|t 1556 | |A|M|O| |D|T|n 1557 | |R|U|U|M| | |o 1558 | |E|S|L|A|N|N|t 1559 | |A|T|D|Y|O|O|t 1560 FEATURE |SECTION | | | | |T|T|e 1561 -------------------------------------------|----------|-|-|-|-|-|-|- 1562 Directory Address Resolution | | | | | | | | 1563 provide facility to resolve addresses |6 |C| |x| | | | 1564 use Vcards to populate local directory |6 |C|x| | | | |9 1565 use headers to populate local directory |6 |C| | | |x| | 1566 | | | | | | | | 1567 Management Protocols: | | | | | | | | 1568 Network management |8.1 |T| |x| | | | 1569 -------------------------------------------|----------|-|-|-|-|-|-|- 1571 Footnotes: 1573 1. MUST NOT include if all recipients are not known or resolvable. 1574 2. If a sensitive message is received by a system that does not 1575 support sensitivity, then it MUST be returned to the originator 1576 with an appropriate error notification. Also, a received 1577 sensitive message MUST NOT be forwarded to anyone. 1578 3. If the addtional headers are not understood they MAY be ignored 1579 4. When binary transport is not available 1580 5. When binary transport is available 1581 6. If multiple contents are present in a message, this header MUST be 1582 present 1583 7. Other contents must only be sent by bilateral agreement. 1584 8. If the content cannot be presented in some form, the entire 1585 message MUST be non-delivered. 1586 9. When the vCard is present in a message 1588 15. Appendix B - Example Voice Messages 1590 The following message is a full-featured message addressed to two 1591 recipients. The message includes the sender's spoken name and a short 1592 speech segment. The message is marked as important and private. 1594 To: 19725551212@vm1.mycompany.com 1595 To: 16135551234@VM1.mycompany.com 1596 From: "Parsons, Glenn" <12145551234@VM2.mycompany.com> 1597 Date: Mon, 26 Aug 93 10:20:20 -0700 (CST) 1598 MIME-Version: 1.0 (Voice 2.0) 1599 Content-type: Multipart/Mixed; Boundary="MessageBoundary" 1600 Content-Transfer-Encoding: 7bit 1601 Message-ID: VM2.mycompany.com-123456789 1602 Sensitivity: Private 1603 Importance: High 1605 --MessageBoundary 1606 Content-type: Audio/32KADPCM 1607 Content-Transfer-Encoding: Base64 1608 Content-Description: Originator Spoken Name 1609 Content-Language: EN-US 1610 Content-ID: part1@VM2-4321 1612 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1613 (This is a sample of the base-64 Spoken Name data) fgdhgd 1614 dlkgpokpeowrit09== 1616 --MessageBoundary 1617 Content-type: Audio/32KADPCM 1618 Content-Transfer-Encoding: Base64 1619 Content-Description: Voice Message 1620 Content-Duration: 25 seconds 1622 iIiIiIjMzN3czdze3s7d7fwfHhcvESJVe/4yEhLz8/FOQjVFRERCESL/zqrq 1623 (This is a sample of the base64 message data) zb8tFdLTQt1PXj 1624 u7wjOyRhws+krdns7Rju0t4tLF7cE0K0MxOTOnRW/Pn30c8uHi9== 1626 --MessageBoundary 1627 Content-type: Application/Directory 1628 Content-Transfer-Encoding: 7bit 1630 BEGIN:VCARD 1631 N:Parsons;Glenn;;Mr.; 1632 EMAIL;TYPE=INTERNET:12145551234@VM2.mycompany.com 1633 TEL:+1-217-555-1234 1634 SOUND;TYPE=32KADPCM;ENCODE=BASE64;VALUE=CID: 1635 REV:19951031T222710Z 1636 END:VCARD 1638 --MessageBoundary-- 1639 The following message is a forwarded single segment voice. Both the 1640 forwarded message and the forwarding message contain VCARDs with 1641 spoken names. 1643 To: 12145551212@vm1.mycompany.com 1644 From: "Vaudreuil, Greg" <19725552345@VM2.mycompany.com> 1645 Date: Mon, 26 Aug 93 10:20:20 -0700 (CST) 1646 MIME-Version: 1.0 (Voice 2.0) 1647 Content-type: Multipart/Mixed; Boundary="MessageBoundary" 1648 Content-Transfer-Encoding: 7bit 1649 Message-ID: VM2.mycompany.com-123456789 1651 --MessageBoundary 1652 Content-type: Audio/32KADPCM 1653 Content-Transfer-Encoding: Base64 1654 Content-Description: Originator Spoken Name 1655 Content-Language: EN-US 1656 Content-ID: part3@VM2-4321 1658 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1659 (This is a sample of the base-64 Spoken Name data) fgdhgd 1660 dlkgpokpeowrit09== 1662 --MessageBoundary 1663 Content-type: Audio/32KADPCM 1664 Content-Description: Voice Message 1665 Content-Transfer-Encoding: Base64 1667 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1668 (This is the voiced introductory remarks encoded in base64) 1669 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW 1670 dlkgpokpeowrit09== 1672 --MessageBoundary 1673 Content-type: Message/RFC822 1674 Content-Transfer-Encoding: 7bit 1676 To: 19725552345@VM2.mycompany.com 1677 From: "Parsons, Glenn, W." <16135551234@VM1.mycompany.com> 1678 From: Date: Mon, 26 Aug 93 8:23:10 -0600 (EST) 1679 Content-type: Multipart/Mixed; Boundary="MessageBoundary2" 1680 Content-Transfer-Encoding: 7bit 1681 MIME-Version: 1.0 (Voice 2.0) 1682 --MessageBoundary2 1683 Content-type: Audio/32KADPCM 1684 Content-Transfer-Encoding: Base64 1685 Content-Description: Originator Spoken Name 1686 Content-Language: EN-US 1687 Content-ID: part6@VM2-4321 1689 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1690 (This is a sample of the base-64 Spoken Name data) fgdhgd 1691 dlkgpokpeowrit09== 1693 --MessageBoundary2 1694 Content-type: Audio/32KADPCM 1695 Content-Description: Voice Message 1696 Content-Transfer-Encoding: Base64 1698 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 1699 (This is the original message audio data) fgwersdfmniwrjj 1700 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gQ5tkjpokfgW 1701 dlkgpokpeowrit09== 1703 --MessageBoundary2 1704 Content-type: Application/Directory 1705 Content-Transfer-Encoding: 7bit 1707 BEGIN:VCARD 1708 N:Parsons;Glenn;W;Mr.; 1709 EMAIL;TYPE=INTERNET:16135551234@VM2.mycompany.com 1710 TEL:+1-613-555-1234 1711 SOUND;TYPE=32KADPCM;ENCODE=BASE64;VALUE=CID: 1712 REV:19951031T222710Z 1713 END:VCARD 1715 --MessageBoundary2-- 1716 --MessageBoundary 1717 Content-type: Application/Directory 1718 Content-Transfer-Encoding: 7bit 1720 BEGIN:VCARD 1721 N:Vaudreuil;Greg;;Mr.; 1722 SOUND;TYPE=32kbADPCM;ENCODE=BASE64;VALUE=CID: 1723 EMAIL;TYPE=INTERNET,VPIM:19725552345@VM2.mycompany.com 1724 TEL:+1-972-555-2345 1725 REV:19951031T222710Z 1726 END:VCARD 1728 --MessageBoundary-- 1729 The following example is for a message returned to the sender by a 1730 VPIM gateway at VM1.company.com for a mailbox which does not exist. 1732 Date: Thu, 7 Jul 1994 17:16:05 -0400 1733 From: Mail Delivery Subsystem 1734 Message-Id: <199407072116.RAA14128@vm1.company.com> 1735 Subject: Returned voice message 1736 To: 2175552345@VM2.mycompany.com 1737 MIME-Version: 1.0 (Voice 2.0) 1738 Content-Type: multipart/report; report-type=delivery-status; 1739 boundary="RAA14128.773615765/VM1.COMPANY.COM" 1741 --RAA14128.773615765/VM1.COMPANY.COM 1742 Content-type: Audio/32KADPCM 1743 Content-Description: Voice Message Notification 1744 Content-Transfer-Encoding: Base64 1746 glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd 1747 (This is a voiced description of the error in base64) 1748 jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gdffkjpokfgW 1749 dlkgpokpeowrit09== 1751 --RAA14128.773615765/VM1.COMPANY.COM 1752 content-type: message/delivery-status 1754 Reporting-MTA: dns; vm1.company.com 1755 Original-Recipient: rfc822; 2145551234@VM1.mycompany.com 1756 Final-Recipient: rfc822; 2145551234@VM1.mycompany.com 1757 Action: failed 1758 Status: 5.1.1 (User does not exist) 1759 Diagnostic-Code: smtp; 550 Mailbox not found 1760 Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400 1762 --RAA14128.773615765/VM1.COMPANY.COM 1763 content-type: message/rfc822 1765 [original VPIM message goes here] 1767 --RAA14128.773615765/VM1.COMPANY.COM-- 1769 16. Appendix C _ Example Error Voice Processing Error Codes 1771 The following common voice processing errors and their corresponding 1772 status codes are given as examples. Text after the error codes are 1773 intended only for reference to describe the error code. 1774 Implementations should provide implementation specific informative 1775 comments after the error code rather than the text below. 1777 Error condition RFC 1893 Error codes 1778 ----------------------------- ---------------------------------- 1779 - 1781 Analog delivery failed 4.4.0 Persistent connection error 1782 because remote system is busy - other 1784 Analog delivery failed 4.4.1 Persistent protocol error 1785 because remote system is - no answer from host 1786 ring-no-answer 1788 Remote system did not answer 5.5.5 Permanent protocol error 1789 AMIS-Analog handshake ("D" in - wrong version 1790 response to "C" at connect 1791 time) 1793 Mailbox does not exist 5.1.1 Permanent mailbox error 1794 - does not exist 1796 Mailbox full or over quota 4.2.2 Persistent mailbox error 1797 - full 1799 Disk full 4.3.1 Persistent system error 1800 - full 1802 Command out of sequence 5.5.1 Permanent protocol error 1803 - invalid command 1805 Frame Error 5.5.2 Permanent protocol error 1806 - syntax error 1808 Mailbox does not support FAX 5.6.1 Permanent media error 1809 - not supported 1811 Mailbox does not support TEXT 5.6.1 Permanent media error 1812 - not supported 1814 Sender is not authorized 5.7.1 Permanent security error 1815 - sender not authorized 1817 Message marked private, but 5.3.3 Permanent system error 1818 system is not private capable - not feature capable 1820 17. Appendix D - audio/32KADPCM Content Type 1822 Mime type name: audio 1823 Mime Sub-Type name: 32KADPCM 1824 Required Parameters: None 1825 Optional Parameters: None 1826 Encoding Considerations: Binary or Base-64 generally preferred 1828 ITU-T Recommendation G.726 [G726] (was G.721) describes the algorithm 1829 recommended for conversion of a single 64 kbit/s A-law or mu-law PCM 1830 channel encoded at 8000 samples/sec to and from a 32 kbit/s channel. 1831 The conversion is applied to the PCM stream using an Adaptive 1832 Differential Pulse Code Modulation (ADPCM) encoding technique. 1834 No header information shall be included as part of the audio data. 1835 The 4-bit code words of the G.726 encoding MUST be packed into 1836 octets/bytes as follows: the first code word (A) is placed in the 1837 four least significant bits of the first octet, with the least 1838 significant bit (LSB) of the code word (A1) in the least significant 1839 bit of the octet; the second code word (B) is placed in the four most 1840 significant bits of the first octet, with the most significant bit 1841 (MSB) of the code word (B4) in the most significant bit of the octet. 1842 Subsequent pairs of the code words shall be packed in the same way 1843 into successive octets, with the first code word of each pair placed 1844 in the least significant four bits of the octet. It is preferred that 1845 the voice sample be extended with silence such that the encoded value 1846 comprises an even number of code words. However, if the voice sample 1847 comprises an odd number of code words, then the last code word shall 1848 be discarded. 1850 +--+--+--+--+--+--+--+--+ 1851 |A1|A2|A3|A4|B1|B2|B3|B4| 1852 +--+--+--+--+--+--+--+--+ 1853 LSB -> | 0| 1| 2| 3| 4| 5| 6| 7| <-MSB 1854 +--+--+--+--+--+--+--+--+ 1856 32K ADPCM / Octet Mapping 1858 In the context of VPIM, the Content-Description header SHOULD be used 1859 to describe the contents of the audio body. The header must be able 1860 to be parsed to find these identifying phrases: Voice Message, 1861 Originator Spoken Name, Recipient Spoken Name, or Spoken Subject. 1863 Other headers may be used with their defined semantics. 1865 18. Appendix E - image/TIFF Content Type 1867 Mime type name: image 1868 Mime Sub-Type name: TIFF 1869 Required Parameters: None 1870 Optional Parameters: None 1871 Encoding Considerations: Binary or Base-64 generally preferred 1873 18.1 References 1875 TIFF (Tag Image File Format) is defined in: 1877 TIFF (TM) Revision 6.0 - Final _ June 3, 1992 1879 Adobe Developers Association 1881 Adobe Systems Incorporated 1882 1585 Charleston Road 1883 P.O. Box 7900 Mountain View, CA 94039-7900 1885 A copy of this specification can be found in: 1887 ftp://ftp.adobe.com/pub/adobe/DeveloperSupport/TechNotes/PDFfiles 1889 TIFF Class F has previously never been documented in a detailed 1890 fashion. However, it is clearly defined in Section 10.7.4 Spatial 1891 Media of: 1893 Enterprise Computer Telephony Forum 1894 S.100 Revision 1.0 1895 Media Services "C" Language 1896 Application Programming Interfaces 1898 THE ECT Forum 1899 303 Vintage Park Drive 1900 Foster City, CA 94404-1138 1902 A copy of this specification can be found in: 1904 http://www.ectf.org/ectf_s100.html 1906 18.2 TIFF Class F 1908 The essential parts of the ECTF S.100 definition are repeated here: 1910 All implementations must be able to read and write TIFF files meeting 1911 the requirements below. Image data must not have any coding errors. 1912 Implementations may also read any other formats as long as available 1913 formats can be disclosed to applications at run time. 1915 ByteOrder: MM,II (Either byte order is allowed) 1917 These tags shown below must be readable. If not present, receiving 1918 implementation must use default shown: 1920 TIFF Tags 1922 Tag | Legal | Default | Comment 1923 ------------------|-------------|--------------|---------------------- 1924 BitsPerSample | 1 | 1 |one bit per sample 1925 CleanFaxData | 0 | 0 |data has no errors 1926 Compression | 3,4 | 3 |T.4 bi-level encoding, 1927 | | | MH or T.6, MMR 1928 FillOrder | 2,1 | 2 |LSB first or MSB first 1929 ImageWidth | 1728 | 1728 | 1930 ImageLength | >0 | |required 1931 NewSubFileType | 2 | 2 |single page of 1932 | | |multipage file 1933 Orientation | 1 | 1 |1st row=top left, 1934 | | | 1st col=top 1935 PageNumber | X/X | 0/1 |pg/tot, 0 base, 1936 | | | tot in 1st IFD 1937 PhotometricInterp | 0 | 0 |0 is white 1938 ResolutionUnit | 2 | 2 |inches 1939 RowsPerStrip |=ImageLength |=ImageLength | 1940 SamplesPerPixel | 1 | 1 |one sample per pixel 1941 StripByteCounts | >0 | |required 1942 StripOffsets | >0 | |required 1943 T4Options | 4 | 4 |MH, byte aligned EOL 1944 T6Options | 0 | 0 |MMR 1945 Xresolution | 204,200,77 | 204 | 1946 Yresolution | 196,98,100, | 196 | 1947 | 200,77,38.5 | | 1948 ------------------|-------------|--------------|---------------------- 1950 Other tags may be present, but must be of the sort that can be ignored 1951 safely by implementations (i.e. purely informational). 1953 Recommended informational tags are: 1955 Software, Datetime, BadFaxLines, ConsecutiveBadFaxLines 1957 19. Appendix F - Change History: RFC 1911 to this Document 1959 The updated profile in this document is based on the experience of a 1960 proof of concept demonstration of VPIM at EMA'96 in April 1996. This 1961 version of the profile is significantly different from the previous 1962 described in [VPIM1]. The changes are categorized as general, 1963 content, transport and conformance. They are detailed below: 1965 1. General 1967 - Refined audio/32KADPCM definition (i.e. nibble order) 1969 - Added a refined definition for image/TIFF (includes tag defaults) 1971 - Changed the Voice version to 2.0 1973 - Added Table of Contents and more examples 1975 - Various editorial updates to improve readability 1977 2. Content 1979 - Deprecated multipart/voice-message content because of the removal 1980 of positional dependence of contents and the desire to interoperate 1981 with minimal MIME implementations 1983 - Explicitly defined the forwarding model using message/RFC822 1985 - Explained the use of reply-to and from headers for addressing 1986 message replies 1988 - Deprecated the special `loopback' address because of security 1989 concerns and its use only for testing 1991 - Defined the non-mail-user reserved address to support the case in 1992 which replies to the originator are not possible 1994 - Eliminated the text name in the "To" and "CC" headers. Edited 1995 the conformance to require family and given name only for persons 1997 - Added support for facsimile using the refined image/TIFF content 1999 - Profiled the Vcard in the application/directory body part for 2000 transport of directory information about the originator 2002 - Loosened text restriction 2004 - Added additional details on delivery notifications 2006 - Added suggested addressing formats 2008 - Described handling of private messages 2010 - Described the handling of non-profiled contents in VPIM messages 2012 3. Transport 2014 - Moved binary support to optional 2016 - Added optional ESMTP keywords for return of content, enhanced 2017 status codes, original recipient, and envelope ID 2019 - Described use of null MAIL FROM address 2021 4. Compliance 2023 - Added an explicit section on conformance allowing conformance to 2024 all or any of three conformance areas 2026 - Improved conformance table