Differences in the text of RFC2421 and draft-ietf-vpim-vpimv2r2-01.txt


*Legend at bottom of page
Text as in RFC2421 Text as in draft-ietf-vpim-vpimv2r2-01.txt
Keyword Section Text Keyword Section Text
MUST 2.1 5) Error reports must be machine-parsable so that helpful responses can be voiced to users whose only access mechanism is a telephone. MUST 2.1 5) Error reports must be machine-parsable so that helpful responses  can be voiced to users whose only access mechanism is a telephone.
SHOULD NOT 3 Where possible, server implementations should not restrict the number of recipients in a single message. SHOULD NOT 3 Where possible, server implementations should not restrict the number of recipients in a single message.
RECOMMENDED 4.1.1 However, it is RECOMMENDED that public telephone numbers be noted according to the international numbering plan described in [E.164]. RECOMMENDED 4.1.1 However, it is RECOMMENDED that public telephone numbers be noted according to the international numbering plan described in [E.164].
MUST 4.1.2 By convention, a special mailbox named "postmaster" MUST exist on all systems. MUST 4.1.2 By convention, a special mailbox named "postmaster" MUST exist on all systems.
MUST 4.1.2 If a reply to a message is not possible, such as a telephone answering message, then the special address "non-mail-user" must be used as the originator's address. SHOULD 4.1.2 If a reply to a message is not possible, such as a telephone-answering message, then the special address "non-mail-user" SHOULD be used as the originator’s address. 
MUST 4.1.2 For compatibility with the installed base of mail user agents, implementations that generate this special address MUST send a negative delivery status notification (DSN) for reply messages sent to the undeliverable address. MUST 4.1.2 For compatibility with the installed base of mail user agents, MUST reject the message when a message addressed to "non-mail-user" is received. 
MAY 4.1.3 Most voice messaging systems do not provide for "Header Information" in their messaging queues and only include delivery information.  As a result, recipient information MAY be in either the To or CC header fields. MAY 4.1.3 Most voice messaging systems do not provide for "Header Information" in their messaging queues and only include delivery information.  As a result, recipient information MAY be in either the "To:" or "Cc:" header fields.
MUST 4.1.3 If all recipients cannot be presented (e.g. unknown DL expansion) then the recipient header fields MUST be omitted to indicate that an accurate list of recipients (e.g. for use with a reply-all capability) is not known. SHOULD 4.1.3 If all recipients cannot be presented then the recipient header fields SHOULD be omitted to indicate that an accurate list of recipients (e.g. for use with a reply-all capability) is not known.
MUST 4.2 VPIM systems MUST be able to accept and ignore header fields that are not defined here. MUST 4.2 VPIM systems MUST be able to accept and ignore header fields that are not defined here.
      MUST 4.2.1 The originator's fully qualified domain address (a mailbox address followed by the fully qualified domain name) MUST be present.
SHOULD 4.2.1 Systems conforming with this profile SHOULD provide the text personal name of the voice message originator in a quoted phrase, if the name is available. SHOULD 4.2.1 Systems conforming with this profile SHOULD provide the text personal name of the voice message originator in a quoted phrase, if the name is available.
MAY 4.2.1 Text names of corporate or positional mailboxes MAY be provided as a simple string. MAY 4.2.1 Text names of corporate or positional mailboxes MAY be provided as a simple string.
SHOULD 4.2.1 The From address SHOULD be used for replies (see 4.6) SHOULD 4.2.1 The "From:" address SHOULD be used for replies (see 4.9).
SHOULD NOT 4.2.1 However, if the From address contains <non-mail-user@domain>, the user SHOULD NOT be offered the option to reply, nor should notifications be sent to this address.      
SHOULD 4.2.1 Voice mail machines may not be able to support separate attributes for the FROM, REPLY-TO, and SENDER header field and the SMTP MAIL   FROM command, VPIM conforming systems SHOULD set these values to the same address. SHOULD 4.2.1 Voice mail machines may not be able to support separate attributes for the "From:" header fields and the SMTP MAIL FROM, VPIM-conforming systems SHOULD set these values to the same address.
      MAY 4.2.2 There MAY be one or more "To:" fields in any message.
SHOULD 4.2.2 Systems compliant to this profile SHOULD provide a list of recipients only if all recipients are provided. SHOULD 4.2.2 Systems SHOULD provide a list of recipients only if all recipients are available.
      SHOULD 4.2.2 Systems such as gateways from protocols which do not indicate the complete list of recipients SHOULD provide a "To:" line.
MAY 4.2.2 If present, the addresses in the To header MAY be used for a reply message to all recipients. MAY 4.2.2 If present, the addresses in the "To:" field MAY be used for a reply message to all recipients.
      SHOULD NOT 4.2.2 Because these systems cannot accurately enumerate all recipients in the "To:" headers, recipients SHOULD NOT be enumerated.
MAY 4.2.2 Systems compliant to this profile MAY also discard the To addresses of incoming messages because of the inability to store the information. MAY 4.2.2 Systems conforming to this profile MAY discard the addresses in the "To:" fields if they are unable to store the information.
MUST NOT 4.2.2 The To header MUST NOT be included in the message if the sending message transport agent (MTA) cannot resolve all the addresses in it, e.g. if an address is a DL alias for which the expansion is unknown (see 4.1.3).      
SHOULD 4.2.3 Systems compliant to this profile SHOULD provide a list of recipients only if all disclosed recipients can be provided. MAY 4.2.3 Conforming implementations MAY send "Cc:" lists if all recipients are known at the time of origination.
does not 4.2.3 The list of disclosed recipients does not include those sent via a blind copy. MUST NOT 4.2.3 The list of disclosed recipients MUST NOT include undisclosed recipients (i.e., those sent via a blind copy).
SHOULD 4.2.3 If not, systems SHOULD omit the To and Cc header fields to indicate that the full list of recipients is unknown. SHOULD 4.2.3 If not, systems SHOULD omit the "Cc:" fields to indicate that the full list of recipients is unknown or otherwise unavailable.
MAY 4.2.3 Systems compliant to this profile MAY discard the Cc addresses of incoming messages as necessary. MAY 4.2.3 Systems conforming to this profile MAY add all the addresses in the "Cc:" field to the "To:" field, others MAY discard the addresses in the "Cc:" fields.
MAY 4.2.3 If a list of Cc or to addresses is present, these addresses MAY be used for a reply message to all recipients. MAY 4.2.3 If a list of "Cc:" addresses is present, these addresses MAY be used for a reply message to all recipients.
      MUST 4.2.4 The "Date:" field MUST be present and contains the date and time the message was sent by the originator.
MUST 4.2.4 The sending system MUST report the time the message was sent MUST 4.2.4 The sending system MUST report the time the message was sent.
SHOULD 4.2.4 The time zone SHOULD be represented in a four-digit time zone offset, such as -0500 for North American Eastern Standard Time. MUST 4.2.4 The time zone MUST be present and SHOULD be represented in a four-digit time zone offset, such as -0500 for North American Eastern Standard Time.
MAY 4.2.4 This may be supplemented by a time zone name in parentheses, e.g., "-0900 (PDT)". MAY 4.2.4 This MAY be supplemented by a time zone name in parentheses, e.g., "-0900 (PDT)".
SHOULD 4.2.4 Compliant implementations SHOULD be able to convert RFC 822 date and time stamps into local time. SHOULD 4.2.4 Conforming implementations SHOULD be able to convert [RFC822] date and time stamps into local time.
SHOULD 4.2.4 If the VPIM sender is relaying a message from a system which does not provide a time stamp, the time of arrival at the VPIM system SHOULD be used as the date. SHOULD 4.2.4 If the VPIM sender is relaying a message from a system that does not provide a time stamp, the time of arrival at the gateway system SHOULD be used as the date.
MAY 4.2.5 The Sender header field contains the actual address of the originator if the message is sent by an agent on behalf of the author indicated in the From: field. This header field MAY be sent by VPIM conforming system. MAY 4.2.5 The "Sender:" field contains the actual address of the originator if an agent on behalf of the author indicated in the "From:" field sends the message. This header field MAY be sent by VPIM-conforming systems.
      MAY 4.2.5 If the address in the "Sender:" field cannot be preserved in the recipient's message queues or in the next-hop protocol from a gateway, the field MAY be silently discarded.
MUST 4.2.6 Any error messages resulting from the delivery failure MUST be sent to this address. MUST 4.2.6 Any error messages resulting from the delivery failure MUST be sent to this address.
      MUST NOT 4.2.6 The originating system MUST not add this header.
MUST NOT 4.2.6 Note that if the Return-path is null ("<>"), e.g. no path, loop prevention or confidential, a notification MUST NOT be sent. MUST NOT 4.2.6 Note that if the Return-path is null ("<>"), e.g. no path, loop prevention or confidential, a notification MUST NOT be sent.
      MUST 4.2.6 Systems that do not support the return path MUST ensure that at the time the message is acknowledged, the message is delivered to the recipient's ultimate mailbox.
      SHOULD NOT 4.2.6 Non-Delivery notifications SHOULD NOT be sent after that final delivery.
      MUST 4.2.7 The "Message-ID:" is not required to be stored on the receiving system.  When provided in the original message, it MUST be used when sending a MDN.
MAY 4.2.7 The message-id is not required to be stored on the receiving system. This identifier MAY be used for tracking, auditing, and returning receipt notification reports. MAY 4.2.7 The "Message-ID:" is not required to be stored on the receiving system.  When provided in the original message, it MUST be used when sending a MDN.  This identifier MAY be used for tracking and auditing.  From [RFC822]
MUST 4.2.7 A unique message-id MUST be generated for each message sent from a compliant implementation. MUST 4.2.7 A unique message-id MUST be generated for each message sent from a VPIM-conforming implementation.
SHOULD NOT 4.2.8 A compliant system SHOULD NOT send a Reply-To header. SHOULD NOT 4.2.8 A conforming system SHOULD NOT send a "Reply-To:" header.
MAY 4.2.8 However, if a reply-to header is present, a reply-to sender message MAY be sent to the address specified (that is, overwriting From). MAY 4.2.8 If a "Reply-To:" field is present, a reply-to-sender message MAY be sent to the address specified (that is, in lieu of the address in the "From:" field).
      MUST 4.2.8 If only one address of the originator is supported in the message store or in the next-hop protocol from a multi-protocol gateway, the address in the "From:" field MUST be used and the "Reply-To:" field MAY be silently discarded.
MUST 4.2.8 This preferred address of the originator must also be provided in the originator's vCard EMAIL attribute, if present (see 4.3.3).      
MAY 4.2.9 These header fields MAY be ignored or deleted when the message is received at the final destination. MAY 4.2.9 These header fields MAY be ignored or deleted when the message is received at the final destination.
MUST 4.2.9 A compliant system MUST add Received header fields when acting as a gateway and MUST NOT remove any Received fields when relaying messages to other  MTAs or gateways MUST 4.2.9 A VPIM-conforming system MUST add a "Received:" field.
MUST NOT 4.2.9 A compliant system MUST add Received header fields when acting as a gateway and MUST NOT remove any Received fields when relaying messages to other  MTAs or gateways. MUST NOT 4.2.9 A VPIM-conforming system MUST NOT remove any "Received:" fields when relaying messages to other MTAs or gateways.
SHOULD 4.2.10 Systems compliant with this specification SHOULD include a comment with the words "(Voice 2.0)". SHOULD 4.2.10 Systems conforming with this specification SHOULD include a comment with the words "(Voice 2.0)".
SHOULD 4.2.10 Instead, the presence of the content defined in [V-MSG] SHOULD be used if identification is necessary. SHOULD 4.2.10 Instead, the presence of the content defined in [V-MSG] SHOULD be used if identification is necessary.
SHOULD NOT 4.2.10 This identifier is intended for information only and SHOULD NOT be used to semantically identify the message as being a VPIM message. SHOULD NOT 4.2.10 This identifier is intended for information only and SHOULD NOT be used to semantically identify the message as being a VPIM message.
SHOULD 4.2.11 The typical top level content in a VPIM Message SHOULD be multipart/voice-message, a mechanism for bundling several components into a single identifiable voice message. SHOULD 4.2.11 The typical top-level content in a VPIM Message SHOULD be Multipart/Voice-Message.  The allowable contents are detailed starting in section 4.4 of this document.
MUST 4.2.12 Compliant implementations MUST recognize and decode the standard encodings, "Binary", "7bit, "8bit", "Base64" and "Quoted-Printable". MUST 4.2.12 Conforming implementations MUST recognize and decode the standard encodings, "Binary", "7bit, "8bit", "Base64" and "Quoted-Printable".
SHOULD 4.3 An implementation in compliance with this profile SHOULD send audio and/or facsimile data in binary form when binary message transport is available. SHOULD 4.2.12 An implementation in conformance with this profile SHOULD send audio and/or facsimile data in binary form when binary message transport is available (see section 0).
MUST 4.3 When binary transport is not available, implementations MUST encode the audio and/or facsimile data as Base64 MUST 4.2.12 When binary transport is not available, implementations MUST encode the audio and/or facsimile data as Base64. 
MUST 4.3 The detection and decoding of "Quoted-Printable", "7bit", and "8bit" MUST be supported in order to meet MIME requirements and to preserve interoperability with the fullest range of possible devices. MUST 4.2.12 The detection and decoding of "Quoted-Printable", "7bit", and "8bit" MUST be supported in order to meet MIME requirements and to preserve interoperability with the fullest range of possible devices.
      MUST 4.2.13 If a user marks a message "Private", a conforming implementation MUST send only the "Private" sensitivity level.
      SHOULD NOT 4.2.13 A conforming implementation SHOULD NOT send the values "Personal" or "Company-Confidential".
MUST 4.2.13 If a sensitivity header is present in the message, a compliant system MUST prohibit the recipient from forwarding this message to any other user. MUST 4.2.13 If a "Sensitivity:" field with a value of "Private" is present in the message, a conforming system MUST prohibit the recipient from forwarding this message to any other user.
MUST 4.2.13 If the receiving system does not support privacy and the sensitivity is one of "Personal" or "Private", a negative delivery status notification must sent to the originator with the appropriate status code indicating that privacy could not be assured. MUST 4.2.13 If the receiving system does not support privacy and the sensitivity is "Private", a negative delivery status notification MUST be sent to the originator with the appropriate status code (5.6.0) "Other or undefined protocol status" indicating that privacy could not be assured.
      MAY 4.2.13 A VPIM-conforming implementation MAY include this header to indicate the sensitivity of a message.
      SHOULD 4.2.13 If the message is of "Normal" sensitivity, this field SHOULD be omitted.
SHOULD 4.2.13 A compliant system, however, SHOULD allow the responder to reply to a sensitive message, but SHOULD NOT include the original message content. SHOULD 4.2.13 A conforming system, however, SHOULD allow the responder to reply to a sensitive message, but SHOULD NOT include the original message content.
SHOULD 4.2.13 The message contents SHOULD  be returned to the sender to allow for a voice context with the notification. SHOULD 4.2.13 The message contents SHOULD  be returned to the sender to allow for a voice context with the notification.
MAY 4.2.13 The sensitivity of the reply message MAY be set by the responder. MAY 4.2.13 The responder MAY set the sensitivity of the reply message.
SHOULD NOT 4.2.13 A compliant system, however, SHOULD allow the responder to reply to a sensitive message, but SHOULD NOT include the original message content. SHOULD NOT 4.2.13 A conforming system, however, SHOULD allow the responder to reply to a sensitive message, but SHOULD NOT include the original message content.
SHOULD NOT 4.2.13 A non-delivery notification to a private message SHOULD NOT be tagged private since it will be sent to the originator. SHOULD NOT 4.2.13 A non-delivery notification to a private message SHOULD NOT be tagged private since it will be sent to the originator.
MAY 4.2.14 Compliant implementations MAY use this header to indicate the importance of a message and may order messages in a recipient's mailbox. MAY 4.2.14 Conforming implementations MAY include this header to indicate the importance of a message.
MAY 4.2.14 If no special importance is requested, this header may be omitted and the value assumed to be "normal". MAY 4.2.14 If no special importance is requested, this header MAY be omitted and the value of the absent header assumed to be "normal".
SHOULD 4.2.15 For compatibility with text based mailbox interfaces, a text subject field SHOULD be generated by a compliant implementation but MAY be discarded if present by a receiving system. SHOULD 4.2.15 For compatibility with text-based mailbox interfaces, a text subject field SHOULD be generated by a conforming implementation.
MAY 4.2.15 For compatibility with text based mailbox interfaces, a text subject field SHOULD be generated by a compliant implementation but MAY be discarded if present by a receiving system. MAY 4.2.15 The subject MAY be discarded by a receiving system.
MAY 4.2.16 This header MAY be present to indicate that the sender is requesting a receipt notification from the receiving user agent.      
MAY 4.2.17 This header MAY be present to define future extensions parameters for an MDN requested by the presence of the header in the previous section.      
MUST 4.2.17 However, this header MUST be parsed if present, if MDNs are supported.      
MUST NOT 4.2.17 If it contains a extension parameter that is required for proper MDN generation (noted with "=required"), then an MDN MUST NOT be sent if the parameter is not understood.      
MAY 4.3.4.1 This field MAY be present to facilitate the text identification of these body parts in simple email readers. MAY 4.3.1 This field MAY be present to facilitate the text identification of these body parts in simple email readers.
      MAY 4.3.1 This field MAY be added to a voice body part to offer a freeform description of the voice content.
      MAY 4.3.1 This field MAY be displayed to the recipient.  However, since it is only informative it MAY be ignored.
MUST 4.3.4.2 This field MUST be present to allow the parsable identification of these body parts. MUST 4.3.2 This field MUST be present to allow the parsable identification of body parts within a VPIM voice message.
MUST 4.3.4.2 Since a VPIM voice message is intended to be automatically played upon display of the message, in the order in which the audio contents occur, the audio contents must always be of type inline. MUST 4.3.2 Since a VPIM voice message is intended to be automatically played upon display of the message, in the order in which the audio contents occur, the audio contents MUST always be of type inline.
SHOULD 4.3.4.2 However, it is still useful to include a filename value, so this should be present if this information is available. SHOULD 4.3.2 However, it is still useful to include a filename value, so this SHOULD be present if this information is available. 
SHOULD 4.3.4.2 Note that there SHOULD only be one instance of each of these types of audio contents per message level. SHOULD 4.3.2 Note that there SHOULD only be one instance of each of these types of audio contents per message level.
      MUST NOT 4.3.2 If there are multiple recipients for a given message, recipient-spoken-name MUST NOT be used.
MAY 4.3.4.3 This field MAY be present to allow the specification of the length of the audio bodypart in seconds. MAY 4.3.3 This field MAY be present to allow the specification of the length of the audio body part in seconds.
MAY 4.3.4.4 This field MAY be present to allow the specification of the spoken language of the audio bodypart. MAY 4.3.4 This field MAY be present to allow the specification of the spoken language of the audio body part.
      MAY 4.3.4 A sending system MAY add this field to indicate the language of the voice.
      MAY 4.3.4 It MAY be used as a hint to the recipient (e.g., end-user or an automated translation process) as to the language of the voice message.
SHOULD 4.3 The presence of other contents within a VPIM voice message is an error condition and SHOULD result in a negative delivery status notification. SHOULD NOT 4.4 The presence of other contents within a VPIM voice message is not permitted. Conforming implementations SHOULD NOT create a message containing prohibited contents.
      MAY 4.4 In the spirit of liberal acceptance, a conforming implementation MAY accept and render prohibited content. Systems unable to accept or render prohibited contents MAY discard the prohibited contents as necessary to deliver the acceptable content.
SHOULD 4.3 When multiple contents are present within the multipart/voice-message, they SHOULD be presented to the user in the order that they appear in the message. SHOULD 4.4 When multiple contents are present within the Multipart/Voice-Message, they SHOULD be presented to the user in the order that they appear in the message.
MUST 4.3 However, if a content is received in a transfer encoding that cannot be rendered to the user, an appropriate negative delivery status notification MUST be sent      
MUST 4.3.1 The Multipart/Voice-Message content-type MUST only contain the profiled media and content types specified in this section (i.e. audio/*, image/*, message/rfc822 and text/directory) MUST 4.4.1 The Multipart/Voice-Message content-type MUST only contain the profiled media and content types specified in this section (i.e. Audio/*, Image/*, and Message/RFC822).
MUST 4.3.1 Conformant implementations MUST send the multipart/voice-message in a VPIM message MUST 4.4.1 Conformant implementations MUST use Multipart/Voice-Message in a VPIM message. 
MUST 4.3.1 Conformant implementations MUST recognize the Multipart/Voice-Message content (whether it is a top level content or below a multipart/mixed) and be able to separate the contents (e.g. spoken name or spoken subject). MUST 4.4.1 Conformant implementations MUST recognize the Multipart/Voice-Message content (whether it is a top-level content or contained in a Multipart/Mixed) and MUST be able to separate the contents (e.g. spoken name or spoken subject).
      SHOULD 4.4.2 This body part SHOULD be used within a Multipart/Voice-Message to forward complete messages (see 4.8) or to reply with original content (see 4.9).
      SHOULD 4.4.2 The receiving system SHOULD treat this attachment as a forwarded message.
      MAY 4.4.2 The receiving system MAY flatten the forwarding structure (i.e., remove this construct to leave multiple voice contents or even concatenate the voice contents to fit in a recipient’s mailbox), if necessary.
MUST 4.3.4 An implementation compliant to this profile MUST send Audio/32KADPCM by default for voice [ADPCM]. MUST 4.4.3 An implementation conforming to this profile MUST send Audio/32KADPCM by default for voice [ADPCM].
MUST 4.3.4 Receivers MUST be able to accept and decode Audio/32KADPCM. MUST 4.4.3 Receivers MUST be able to accept and decode Audio/32KADPCM.
SHOULD 4.3.4 If an implementation can only handle one voice body, then multiple voice bodies (if present) SHOULD be concatenated, and SHOULD NOT be discarded. SHOULD 4.4.3 If an implementation can only handle one voice body, then multiple voice bodies (if present) SHOULD be concatenated, and MUST NOT be discarded.
SHOULD NOT 4.3.4 If an implementation can only handle one voice body, then multiple voice bodies (if present) SHOULD be concatenated, and SHOULD NOT be discarded. MUST NOT 4.4.3 If an implementation can only handle one voice body, then multiple voice bodies (if present) SHOULD be concatenated, and MUST NOT be discarded.
RECOMMENDED 4.3.4 It is RECOMMENDED that this be done in the same order as they were sent. SHOULD 4.4.3 If concatenated, the contents SHOULD be in the same order they appeared in the multipart.
MUST 4.3.5 Further, since the TIFF-F file format is used in a store-and-forward mode with VPIM, the image MUST be encoded so that there is only one image strip per facsimile page. MUST 4.4.4 Further, since the TIFF-F file format is used in a store-and-forward mode with VPIM, the image MUST be encoded so that there is only one image strip per facsimile page.
SHOULD 4.3.5 All VPIM implementations that support facsimile SHOULD generate TIFF-F compatible facsimile contents in the image/tiff; application=faxbw sub-type encoding by default. MUST 4.4.4 All VPIM implementations that support facsimile MUST generate TIFF-F compatible facsimile contents in the Image/TIFF subtype using the application=faxbw encoding by default.
      SHOULD 4.4.4 If the VPIM message is a voice-annotated fax, the implementation SHOULD send this fax content in Multipart/Voice-Message.
      MAY 4.4.4 If the message is a simple fax, an implementation MAY send it without using the Multipart/Voice-Message to be more compatible with fax-only (RFC 2305) implementations.
MAY 4.3.5 While any valid MIME body header MAY be used (e.g., Content-Disposition to indicate the filename), none are specified to have special semantics for VPIM and MAY be ignored. MAY 4.4.4 While any valid MIME body header MAY be used (e.g., Content-Disposition to indicate the filename), none are specified to have special semantics for VPIM and MAY be ignored.
MUST 4.3.5 Note that the content type parameter application=faxbw MUST be included in outbound messages. MUST 4.4.4 Note that the content-type parameter application=faxbw MUST be included in outbound messages.
      SHOULD 4.4.4 Not all VPIM systems support fax, but all SHOULD accept it within the multipart/voice-message.
      SHOULD 4.4.4 Within a Multipart/Voice-Message, a receiving system that cannot render fax content SHOULD accept the voice content of a VPIM message and discard the fax content.
MUST 4.3.5 If a fax message is received that cannot be rendered to the user (e.g. the receiving VPIM system does not support fax), then the system MUST return the message with a negative delivery status notification with a media not supported status code. MAY 4.4.4 Outside a Multipart/Voice-Message, a recipient system MAY reject (with appropriate NDN) the entire message if it cannot store or is not capable of rendering a message with fax attachments.
      MAY 4.4.4 VPIM conforming systems MAY support fax outside of (or without) the Multipart/Voice-Message.
      MAY 4.5 The following MIME contents MAY be included within a multipart/voice message.
      MUST NOT 4.5 Other contents MUST NOT be included.
      SHOULD NOT 4.5.1 Conforming implementations SHOULD NOT send the Text/Directory content type.
      MUST 4.5.1 For compatibility with an earlier specification of VPIM v2, the Text/Directory content type MUST be accepted by a conforming implementation, but need not be stored, processed, or rendered to the recipient.
MAY 4.3.6 Proprietary voice or fax encoding formats or other standard formats MAY be supported under this profile provided a unique identifier is registered with the IANA prior to use (see [MIME4]). SHOULD NOT 4.5.2 A conforming implementation SHOULD NOT use any other encoding unless a unique identifier is registered with the IANA prior to use (see [MIME4]).
SHOULD 4.3.6 The voice encodings should be registered as sub-types of Audio and the fax encodings should be registered as sub-types of Image.
 SHOULD 4.5.2 The voice encodings SHOULD be registered as subtypes of Audio. The fax encodings SHOULD be registered as subtypes of Image.
      SHOULD NOT 4.5.2 Proprietary voice encoding formats or other standard formats SHOULD NOT be sent under this profile unless the sender has a reasonable expectation that the recipient will accept the encoding. 
MAY 4.3.6 A compliant implementation MAY use any other encoding with explicit per-destination configuration. MAY 4.5.2 Systems MAY accept other Audio/* or Image/* content types if they can decode them.
      MUST 4.5.2 Systems which receive Audio/* or Image/* content types which they are unable to deposit or unable to render MUST return the message (and SHOULD include the original content) to the originator with an NDN indicating media not supported.
      SHOULD 4.5.2 Systems which receive Audio/* or Image/* content types which they are unable to deposit or unable to render MUST return the message (and SHOULD include the original content) to the originator with an NDN indicating media not supported.
SHOULD 4.4.1 Multipart/Mixed SHOULD only be used for sending complex voice or multimedia messages.  That is, as the top level Content-Type when sending one of the following contents (in addition to the VPIM voice message) in a VPIM message.  MAY 4.5.3 A VPIM voice message MAY be included within a message with a Multipart/Mixed top-level content type.
MUST 4.4.1 Compliant systems MUST accept multipart/mixed body parts. MAY 4.5.3 However, an the spirit of liberal acceptance, a conforming implementation MAY accept and render a VPIM voice message contained in a Multipart/Mixed.
SHOULD 4.4.2 However, because VPIM is a MIME profile, MIME requirements should be met.  SHOULD 4.5.4 However, because VPIM is a MIME profile, MIME requirements SHOULD be met.
SHOULD NOT 4.4.2 Compliant VPIM implementations SHOULD NOT send the Text/Plain content-type. SHOULD NOT 4.5.4 Conforming VPIM implementations SHOULD NOT send the Text/Plain content-type.
      MAY 4.5.4 Implementations MAY send the Text/Plain content-type outside the Multipart/Voice-Message.
      MAY 4.5.4 Within a Multipart/Voice-Message, the Text/Plain content-type MAY be dropped from the message, if necessary, to deliver the audio/fax components.
MUST 4.4.2 If no rendering of the text is possible (i.e., it is not possible for the recipient to determine if the text is a critical part of the message), the entire message MUST be returned to the sender with a negative delivery status notification and a media-unsupported status code. SHOULD NOT 4.5.4 The recipient SHOULD NOT reject the entire message if the text component cannot be accepted or rendered.
MUST 4.4.2 Compliant implementations MUST accept Text/Plain messages, however, specific handling is left as an implementation decision. MUST 4.5.4 Outside a Multipart/Voice-Message, conforming implementations MUST accept Text/Plain;  however, specific handling is left as an implementation decision.
MUST 4.4.4 Compliant implementations MUST use the Message/delivery-status construct when returning messages or sending warnings. MUST 4.6 A VPIM-compliant implementation MUST be able to send DSN's that conform to [REPORT] and [DSN].
MUST 4.7 VPIM delivery status notification messages (4.4.4) MUST be sent to the originator of the message when any form of non-delivery of the subject message or its components occurs. SHOULD 4.6 Unless requested otherwise, a non-delivery DSN SHOULD be sent when any form of non-delivery of a message occurs.
SHOULD 4.4.3 Multipart/Report messages from VPIM implementations SHOULD include the human-readable description of the error as a spoken audio/* content (this speech SHOULD also be made available to the notification recipient). SHOULD 4.6 A VPIM-compliant implementation SHOULD provide a spoken delivery status in the "human-readable" body part of the DSN, but MAY provide a textual status.
MAY 4.4.3 As well, VPIM implementations MUST be able to handle (and MAY generate) Multipart/Report messages that encode the human-readable description of the error as text. MAY 4.6 A VPIM-compliant implementation SHOULD provide a spoken delivery status in the "human-readable" body part of the DSN, but MAY provide a textual status.
MUST 4.4.3 Compliant implementations MUST recognize and decode the Multipart/Report content type and its components in order to present the report to the user. MUST 4.6 A VPIM-compliant implementation MUST be able to receive DSN's that conform to [REPORT] and [DSN].
MUST 4.4.4 Compliant implementations MUST recognize and decode the Message/delivery-status content type and present the reason for failure to the sender of the message. MUST 4.6 A VPIM-compliant implementation MUST be able to receive DSN's that conform to [REPORT] and [DSN].
      MUST 4.6 A VPIM-compliant implementation MUST be able to receive a DSN whose "human-readable" body part contains a spoken delivery status phrase.
      SHOULD 4.7 A VPIM-compliant implementation SHOULD support the ability to request MDN's.
      SHOULD 4.7 A VPIM-compliant implementation SHOULD support the ability to send MDN's, but these MDN's MUST conform to [REPORT] and [MDN].
MUST 4.4.3 Compliant implementations MUST use the Multipart/Report construct. MUST 4.7 A VPIM-compliant implementation SHOULD support the ability to send MDN's, but these MDN's MUST conform to [REPORT] and [MDN].
      SHOULD 4.7 When sending an MDN, a VPIM-compliant implementation SHOULD provide a spoken message disposition in the "human-readable" body part of the MDN, but MAY provide a textual status.
      MAY 4.7 When sending an MDN, a VPIM-compliant implementation SHOULD provide a spoken message disposition in the "human-readable" body part of the MDN, but MAY provide a textual status.
      SHOULD 4.7 A VPIM-compliant implementation SHOULD respond to an MDN request with an MDN response.
      MUST 4.7 A VPIM-compliant implementation MUST be able to receive MDN's that conform to [REPORT] and [MDN], if it is capable of requesting MDN's.
      MUST 4.7 If a VPIM-compliant implementation is capable of receiving MDN's, it MUST be able to receive a MDN whose "human-readable" body part contains a spoken message disposition phrase. 
RECOMMENDED 4.5 Since only the first (i.e. message/rfc822) can be recognized as a forwarded message (or even multiple forwarded messages), it is RECOMMENDED that this construct be used whenever possible. RECOMMENDED 4.8 Since only the first (i.e. Message/RFC822) can be recognized as a forwarded message (or even multiple forwarded messages), it is RECOMMENDED that this construct be used whenever possible.
SHOULD 4.5 Forwarded VPIM messages SHOULD be sent as a multipart/voice-message with the entire original message enclosed in a message/rfc822 content type and the annotation as a separate Audio/* or image/* body part. SHOULD 4.8 Forwarded VPIM messages SHOULD be sent as a Multipart/Voice-Message with the entire original message enclosed in a Message/RFC822 content-type and the annotation as a separate Audio/* or Image/* body part.
SHOULD 4.5 If the RFC822 header fields are not available for the forwarded content, simulated header fields with available information SHOULD be constructed to indicate the original sending timestamp, and the original sender as indicated in the "From" line. SHOULD 4.8 If the RFC822 header fields are not available for the forwarded content, simulated header fields with available information SHOULD be constructed to indicate the original sending timestamp, and the original sender as indicated in the "From:" field. 
MUST 4.5 However, note that at least one of "From", "Subject", or "Date" MUST be present. MUST 4.8 Note that at least one of "From:", "Subject:", or "Date:" MUST be present.
MUST 4.5 As well, the message/rfc822 content MUST include at least the "MIME-Version", and "Content-Type" header fields. MUST 4.8 As well, the Message/RFC822 content MUST include at least the "MIME-Version:", and "Content-Type:" header fields.
MAY 4.5 In the event that forwarding information is lost through concatenation of the original message and the forwarding annotation, such as must be done in a gateway between VPIM and the AMIS voice messaging protocol, the entire audio content MAY be sent as a single Audio/* segment without including any forwarding semantics. MAY 4.8 In the event that forwarding information is lost, the entire audio content MAY be sent as a single Audio/* segment without including any forwarding semantics.
MUST 4.3.3 Each vCard MUST be contained within a Text/Directory content type [MIMEDIR] within a VPIM message.      
MUST 4.3.3 [MIMEDIR] requires that the character set MUST be defined as a parameter value (typically us-ascii for VPIM)      
MUST 4.3.3 (the value MUST be vCard within VPIM messages)      
MUST 4.3.3 Each VPIM message SHOULD be created with a Text/Directory (vCard profile) content type that MUST contain the preferred email address, telephone number, and text name of the message originator as well as the vCard version.      
MUST 4.3.3 If the text/directory content-type is included in a VPIM message, the vCard profile [VCARD] MUST be used and MUST specify at least the following attributes:      
MUST 4.3.3 VERSION - Indicates the version of the vCard profile.  Version 3.0 [VCARD] MUST be used.      
MUST 4.3.3 Because it is expected that recipients using a telephone user interface will use the information in the vCard to identify the originator, and the GUI will see the information presented in the FROM line, all present components in the text name of the FROM header field MUST match the values provided by the Vcard.      
MUST 4.3.3 If present, the spoken name attribute MUST be denoted by a content ID pointing to an audio/* content elsewhere in the VPIM message.      
MUST 4.3.3 A typical VPIM message (i.e. no forwarded parts), MUST only contain one vCard -- more than one is an error condition.      
MUST 4.3.3 However, these vCards MUST be associated with the originator(s) of the forwarded message(s) and the originator of the forwarding message.      
SHOULD 4.3.3 [MIMEDIR] requires that the character set MUST be defined as a parameter value (typically us-ascii for VPIM) and that the profile SHOULD be defined (the value MUST be vCard within VPIM messages).      
SHOULD 4.3.3 Each VPIM message SHOULD be created with a Text/Directory (vCard profile) content type that MUST contain the preferred email address, telephone number, and text name of the message originator as well as the vCard version.      
SHOULD 4.3.3 The vCard SHOULD contain the spoken name and role of the originator, as well as the revision date.       
SHOULD 4.3.3 The following attributes SHOULD be specified:      
MAY 4.3.3 Any other vCard attribute MAY also be present.      
MAY 4.3.3 The vCard MAY use other attributes as defined in [VCARD] or extensions attributes not yet defined (e.g. capabilities).      
MAY 4.3.4 While any valid MIME body header MAY be used, several header fields have the following semantics when included with this body part:      
MUST 4.3.4 Note that if an Originator Spoken Name audio body and a vCard are both present in a VPIM message, the vCard SOUND attribute MUST point to this audio body (see 4.3.3).      
MUST 4.3.5 However, inbound messages with or without this parameter MUST be rendered to the user      
MUST 4.3.5 (if the rendering software encounters an error in the file format, some form of negative delivery status notification MUST be sent to the originator).      
MAY 4.3.5 An implementation MAY send this fax content in VPIM voice messages and MUST be able to recognize and display it in received messages.      
MUST 4.3.5 An implementation MAY send this fax content in VPIM voice messages and MUST be able to recognize and display it in received messages.      
MUST 4.4 Implementations MUST issue negative delivery status notifications to the originator when any form of non-delivery to the recipient occurs.      
SHOULD 4.4 Conversely, if an implementation receives a non-VPIM message (i.e., without a mulitpart/voice-message content type) with any of the contents defined in 4.3 & 4.4, it SHOULD deliver those contents, but the full message handling is a local issue (e.g. the unknown contents _or_ the entire message MAY be discarded).      
SHOULD 4.4 As well, the multipart/mixed content SHOULD be used as the top level of a VPIM message to form a more complex structure (e.g., with additional content types).      
SHOULD 4.4 When multiple contents are present, they SHOULD be presented to the user in the order that they appear in the message.      
MUST NOT 4.4 Additional contents not defined in this profile MUST NOT be used without prior explicit per-destination configuration.      
MAY 4.4 An implementation compliant with this profile MAY send additional contents in a VPIM message, but ONLY outside of the multipart/voice-message.      
MAY 4.4 If an implementation receives a VPIM message that contains content types not specified in this profile, their handling is a local implementation issue (e.g. the unknown contents MAY be discarded if they cannot be presented to the recipient).      
MAY 4.4 The multipart contents defined below MAY be sent as the top level of a VPIM message (with other noted contents below them as required.)      
MUST 4.4.3 Note that per [DSN] the human-readable part MUST always be present.      
MUST 4.4.5 These MDNs, however, MUST only be sent in response to the presence of the Disposition-notification-to header in 4.2.16.      
SHOULD 4.4.5 Conforming implementations SHOULD use the Message/Disposition-notification construct when sending post-delivery message status notifications.      
SHOULD 4.6 The vCard EMAIL attribute, if present, SHOULD be the same as the reply-to address and may be the same as the From address.      
SHOULD NOT 4.6 While the vCard is the senders preferred address it SHOULD NOT be used to generate a reply.      
SHOULD NOT 4.6 A receiving VPIM system SHOULD NOT offer the user the option to reply to this kind of message. SHOULD NOT 5 The recipient’s VPIM system SHOULD NOT offer the option to reply to this kind of message (unless an outcalling feature is offered – which is out of scope for VPIM).
SHOULD 4.6 A null ESMTP MAIL FROM address SHOULD also be used in this case (see 5.1.2).      
MUST 4.6 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) SHOULD 5 In some cases, replying to a message is not possible, such as with a message created by telephone answering (i.e. classic voice mail).  In this case, the From field SHOULD contain the special address non-mail-user@domain (see 4.1.2).
SHOULD NOT 4.6 Also, the Return-path address should not be used for replies.      
MUST 4.7 These error messages must be sent to the return path (4.2.6) if present, otherwise, the From (4.2.1) address may be used.      
MUST 4.7 However, the notification MUST be contained in a multipart/report container (4.4.3) and SHOULD contain a spoken error message.      
SHOULD 4.7 However, the notification MUST be contained in a multipart/report container (4.4.3) and SHOULD contain a spoken error message.      
SHOULD 4.7 A delivery status notification SHOULD be generated if the message could not be delivered because of unknown contents (e.g., on traditional   voice processing systems).      
           
      MUST 5.1 A conforming system MUST implement all mandatory SMTP and ESMTP commands.
MUST 5.2.5 Compliant implementations MUST support the delivery notification extensions in [DRPT]. MUST 5.2.1 The DSN extension MUST be supported by VPIM conforming implementations.
      MUST 5.2.1 In addition, beyond the requirements of [DRPT], conforming implementations MUST support NOTIFY parameter on the RCPT command to allow indication of when the originator requests a notification.
      SHOULD 5.2.1 The RET parameter SHOULD be supported to return the original message with the notification.
MAY 5.4.2 Compliant implementations MAY use this parameter. (ORCPT) MAY 5.2.1 Parameters ORCPT and ENVID MAY be supported.
MAY 5.3.3 Compliant implementations MAY use this parameter. (ENVID)  MAY 5.2.1 Parameters ORCPT and ENVID MAY be supported.
MUST 5.2.2 Compliant servers MUST provide size extension to indicate the maximum size message that can be accepted. MUST 5.2.2 The SIZE extension MUST be supported by VPIM-compliant implementations.
SHOULD 5.2.6 Compliant implementations SHOULD support this capability. (ENHANCEDSTATUSCODES) SHOULD 5.2.3 The ENHANCEDSTATUSCODES extension SHOULD be supported by VPIM-compliant implementations.
SHOULD NOT 5.1.1 Compliant servers MUST implement the HELO command for backward compatibility but clients SHOULD NOT send it unless EHLO is not supported.      
MUST 5.1.1 Compliant servers MUST implement the HELO command for backward compatibility but clients SHOULD NOT send it unless EHLO is not supported.      
SHOULD NOT 5.1.1 Compliant servers MUST implement the HELO command for backward compatibility but clients SHOULD NOT send it unless EHLO is not supported.      
MUST 5.1.2 Since delivery status notifications MUST be sent to the MAIL FROM address, the use of the null address ("<>") is often used to prevent looping of messages.      
SHOULD 5.1.2 VPIM implementations SHOULD use the same address in the MAIL FROM command as is used in the From header field.      
SHOULD 5.1.2 The MAIL FROM address SHOULD be stored in the local message store for the purposes of generating a delivery status notification to the originator.      
SHOULD 5.1.2 The address indicated in the MAIL FROM command SHOULD be passed as a local system parameter or placed in a Return-Path: line inserted at the beginning of a VPIM message.      
MAY 5.1.2 This null address MAY be used to note that a particular message has no return path (e.g. a telephone answer message).      
MUST 5.1.4 Compliant implementations MUST implement the SMTP DATA command for backwards compatibility.      
SHOULD NOT 5.1.5 Compliant implementations SHOULD NOT implement the TURN command.      
MUST 5.1.6 Compliant implementations MUST implement the QUIT command.      
MUST 5.1.7 Compliant implementations MUST implement the RSET command.      
MAY 5.1.8 Compliant implementations MAY implement the VRFY command.      
MUST 5.1.9 Compliant implementations MUST implement the ESMTP command and return the capabilities indicated later in this memo.      
SHOULD 5.1.10 Compliant implementations SHOULD support binary transport using the BDAT command      
SHOULD 5.2.1 Compliant implementations SHOULD support the command pipelining indicated by this keyword. SHOULD 5.2.4 The PIPELINING extension SHOULD be supported by VPIM-compliant implementations.
SHOULD 5.2.2 Clients SHOULD advertise SIZE= when sending messages to servers that indicate support for the SIZE extension.      
SHOULD NOT 5.2.2 Clients SHOULD NOT send messages larger than the size indicated by the server.      
MAY 5.2.3 Compliant implementations MAY support binary transport indicated by this capability. (CHUNKING) MAY 5.2.5 The CHUNKING extension MAY be supported by VPIM-compliant implementations.
MAY 5.2.4 Compliant implementations MAY support binary transport indicated by this capability. (BINARYMIME) MAY 5.2.6 The BINARYMIME extension MAY be supported by VPIM-compliant implementations.
SHOULD 5.3.1 Compliant implementations SHOULD support binary transport indicated by this parameter. (BINARYMIME)      
SHOULD 5.3.2 Compliant systems SHOULD honor a request for returned content.      
MUST 5.4.1 The NOTIFY parameter indicates the conditions under which a delivery report should be sent. Compliant implementations MUST honor this request.      
MUST 5.4.2 If the ORCPT esmtp-keyword is used, it MUST have an associated esmtp-value, which consists of the original recipient address, encoded according to the rules below.      
MUST 5.5 It is RECOMMENDED that the downgrading system should continue to attempt to deliver the message, but MUST send an appropriate delivery notification to the originator, e.g. the message left an ESMTP host and was sent (unreliably) via SMTP. MUST 5.3 It is RECOMMENDED that the downgrading system should continue to attempt to deliver the message, but MUST send an appropriate delivery status notification to the originator, e.g. the message left an ESMTP host and was sent relayed to a non-DSN-aware destination, and this may be the last DSN received.
RECOMMENDED 5.5 It is RECOMMENDED that the downgrading system should continue to attempt to deliver the message, but MUST send an appropriate delivery notification to the originator, e.g. the message left an ESMTP host and was sent (unreliably) via SMTP. RECOMMENDED 5.3 It is RECOMMENDED that the downgrading system should continue to attempt to deliver the message, but MUST send an appropriate delivery status notification to the originator, e.g. the message left an ESMTP host and was sent relayed to a non-DSN-aware destination, and this may be the last DSN received.
SHOULD NOT 6 Addresses or names parsed from the header fields of VPIM messages SHOULD NOT be used to populate directories as it only provides partial data. MAY 6 Addresses or names parsed from the header fields of VPIM messages MAY be used to populate directories.
SHOULD 8 SNMP should be supported on a compliant message machine.
 SHOULD 7 SNMP SHOULD be supported on a VPIM-conforming machine.
MAY 8.1 The digital interface to the VM and the TCP/IP protocols MAY be managed. MAY 7.1 The digital interface to the VM and the TCP/IP protocols MAY be managed.
MAY 8.1 MIB II MAY be implemented to provide basic statistics and reporting of TCP and IP protocol performance MAY 7.1 MIB II MAY be implemented to provide basic statistics and reporting of TCP and IP protocol performance.
MUST 9 However, they must also create VPIM conforming delivery status notifications in the event of delivery problems. MUST 8 However, they must also create VPIM-conforming delivery status notifications in the event of delivery problems.
SHOULD 10.2.3 This expectation of privacy by users SHOULD be preserved as much as possible. SHOULD 9.2.3 This expectation of privacy by users SHOULD be preserved as much as possible.
Legend:          
   
  Text Unchanged    New text in draft-ietf-vpim-vpimv2r2-01.txt
  Significant text change    Deleted from RFC2421
  Minor text change
Red text added for clarity - not in Spec