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.