| Text as in RFC2421 |
Text as in draft-ietf-vpim-vpimv2r2-00.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, implementations
that generate this special address MUST send a negative delivery status
notification (DSN) for reply messages sent to the undeliverable address. |
| 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. |
| 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. |
| |
|
|
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
compliant 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 |
Voice mail
machines may not be able to support separate attributes for the
"From:" and "Reply-To:" header fields and the SMTP MAIL
FROM, VPIM-conforming systems SHOULD set these values to the same address. |
| |
|
|
SHOULD |
4.2.1 |
The
"From:" address SHOULD be used for replies (see 4.7). |
| |
|
|
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. |
| 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 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. |
| 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. |
| |
|
|
MAY |
4.2.2 |
There MAY be one
or more "To:" fields in any message. |
| 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
compliant 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). |
|
|
|
| MAY |
4.2.3 |
Systems
compliant to this profile MAY discard the Cc addresses of incoming messages
as necessary. |
|
|
|
| |
|
|
MAY |
4.2.3 |
Conforming
implementations MAY send "Cc:" lists if all recipients are known at
the time of origination. |
| 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. |
| |
|
|
MAY |
4.2.3 |
Systems
compliant 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 |
Systems
compliant 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. |
| |
|
|
MUST |
4.2.3 |
The list of
disclosed recipients MUST not include undisclosed recipients (ie., those sent
via a blind copy). |
| |
|
|
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. |
| |
|
|
MUST NOT |
4.2.3 |
The list of
disclosed recipients MUST not include undisclosed recipients (ie., those sent
via a blind copy). |
| |
|
|
MAY |
4.2.4 |
This MAY be
supplemented by a time zone name in parentheses, e.g., "-0900
(PDT)". |
| |
|
|
MUST |
4.2.4 |
The
"Date:" field MUST be present and contains the date, time, and time
zone in which the message was sent by the originator. |
| |
|
|
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. |
| |
|
|
SHOULD |
4.2.4 |
Compliant
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 that does not provide a time
stamp, the time of arrival at the gateway system SHOULD be used as the date. |
| 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. |
| 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
(see [DRPT] for additional details). |
MUST |
4.2.6 |
Any error
messages resulting from the delivery failure MUST be sent to this address. |
| |
|
|
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. |
| 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, delivery status and message disposition
notifications MUST NOT be sent. |
| |
|
|
MUST NOT |
4.2.6 |
The originator
system MUST not add this header. (RETURN-PATH) |
| |
|
|
SHOULD NOT |
4.2.6 |
Non-Delivery
notifications should not be sent after that final delivery. |
| |
|
|
MUST |
4.2.6 |
If
the receiving system is incapable of storing the return path to be used for
subsequent delivery errors, the receiving system must otherwise ensure that
further delivery errors don't happen. |
| 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. This identifier MAY be
used for tracking, auditing, and returning receipt notification reports. |
| 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-compliant
implementation. |
| |
|
|
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. |
| |
|
|
MAY |
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. |
| SHOULD NOT |
4.2.8 |
A compliant
system SHOULD NOT send a Reply-To header. |
SHOULD NOT |
4.2.8 |
A compliant
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 |
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. |
| |
|
|
SHOULD |
4.2.9 |
When acting as a
gateway, information about the system translated from SHOULD be included. |
| 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-compliant
system MUST add a "Received:" field. When acting as a gateway,
information about the system translated from SHOULD be included. |
| 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. |
SHOULD NOT |
4.2.9 |
A VPIM-compliant
system SHOULD 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
compliant 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. |
| MUST |
4.2.12 |
Compliant
implementations MUST recognize and decode the standard encodings,
"Binary", "7bit, "8bit", "Base64" and
"Quoted-Printable". |
MUST |
4.2.12 |
Compliant
implementations MUST recognize and decode the standard encodings,
"Binary", "7bit, "8bit", "Base64" and
"Quoted-Printable". |
| 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 "Personal" or
"Private" 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 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 one of
"Personal" or "Private", a negative delivery status
notification MUST be sent to the originator with the appropriate status code
(X.Y.Z) indicating that privacy could not be assured. |
| |
|
|
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 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 |
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 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 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. From: [X.400]. |
MAY |
4.2.14 |
Compliant
implementations MAY include this header to indicate the importance of a
message
|
| 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 compliant 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 if present by a receiving system. |
| |
|
|
RECOMMENDED |
4.2.15 |
It is
recommended that voice-messaging systems that do not support any text user
interfaces (e.g. access only by a telephone) insert a generic subject header
of "VPIM Message" or _ Voice Message_ for the benefit of GUI enabled recipients. |
| 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.16 |
This header MAY
be present to indicate that the sender is requesting a receipt notification
from the receiving user agent. |
| |
|
|
MAY |
4.2.16 |
VPIM-compliant
implementations MAY include this header to request a disposition indication
such as a listen confirmation. |
| 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. |
MAY |
4.2.17 |
This header MAY
be present to define future extension 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 |
4.2.17 |
However for
forward compatibility with future extensions, this header MUST be processed
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. |
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. |
| |
|
|
SHOULD NOT |
4.2.17 |
Sending systems
SHOULD NOT request disposition notification options by sending a
disposition-notification-options header. |
| MUST |
4.3 |
When binary
transport is not available, implementations MUST encode the audio and/or
facsimile data as Base64 |
MUST |
4 |
When binary
transport is not available, implementations MUST encode the audio and/or
facsimile data as Base64. |
| 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 |
An
implementation in compliance with this profile SHOULD send audio and/or
facsimile data in binary form when binary message transport is available (see
section 5).
|
| 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 |
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 |
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 |
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.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 |
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. |
| |
|
|
MAY |
4.3.1 |
This field MAY
be present to facilitate the text identification of these body parts in
simple email readers. |
| 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/*,
message/rfc822 and text/directory). |
| MUST |
4.3.1 |
Conformant
implementations MUST send the multipart/voice-message in a VPIM message |
MUST |
4.4.1 |
Conformant
implementations MUST send the 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 below a multipart/mixed) and be able to separate
the contents (e.g. spoken name or spoken subject). |
| |
|
|
MUST |
4.4.3 |
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. |
| 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 |
An
implementation compliant to this profile MUST send Audio/32KADPCM by default
for voice [ADPCM]. |
MUST |
4.4.4 |
An
implementation compliant 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.4 |
Receivers MUST
be able to accept and decode Audio/32KADPCM. |
| 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). |
|
|
|
| RECOMMENDED |
4.3.4 |
It is
RECOMMENDED that this be done in the same order as they were sent. |
RECOMMENDED |
4.4.4 |
It is
RECOMMENDED that this be done in the same order as they were sent. |
| 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.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 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. |
SHOULD |
4.4.4 |
If an
implementation can only handle one voice body, then multiple voice bodies (if
present) SHOULD be concatenated, and SHOULD NOT be discarded. |
| MAY |
4.3.4.1 |
This field MAY
be present to facilitate the text identification of these body parts in
simple email readers. |
|
|
|
| MUST |
4.3.4.2 |
This field (Content-Disposition) MUST be present to
allow the parsable identification of these body parts. |
MUST |
4.3.2 |
This field (Content-Disposition) 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.3 |
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. |
| 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 bodypart 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
bodypart. |
| |
|
|
SHOULD NOT |
4.4 |
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. |
| |
|
|
MAY |
4.4 |
unable to accept
or render prohibited contents MAY discard the contents as necessary to
deliver the voice content. |
| |
|
|
SHOULD |
4.4.2 |
This body part
SHOULD be used within a multipart/voice-message to forward complete messages
(see 4.6) or to reply with original content (see 4.7). |
| |
|
|
SHOULD |
4.4.2 |
The receiving
system SHOULD treat this attachment as a forwarded message. |
| |
|
|
SHOULD NOT |
4.4.3 |
Conforming
implementations SHOULD NOT send the text/directory content type. |
| |
|
|
SHOULD NOT |
4.4.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 |
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.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.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 |
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. |
|
|
|
| MUST |
4.3.5 |
Note that the
content type parameter application=faxbw MUST be included in outbound
messages. |
MUST |
4.4.5 |
Note that the
content type parameter application=faxbw MUST be included in outbound
messages. |
| MUST |
4.3.5 |
However, inbound
messages with or without this parameter MUST be rendered to the user |
MUST |
4.4.5 |
Inbound messages
in the multipart/voice-message with or without the application parameter MUST
be rendered to the user. |
| |
|
|
MUST |
4.4.5 |
Those that do
MUST support it within the multipart/voice-message and MAY support it outside
of the multipart/voice-message. |
| 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). |
SHOULD |
4.4.5 |
If the rendering
software encounters an error in the file format, some form of negative
delivery status notification SHOULD be sent to the originator. |
| 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.5 |
All VPIM
implementations that support facsimile MUST generate TIFF-F compatible
facsimile contents in the image/tiff; application=faxbw sub-type encoding by
default. |
| 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. |
|
|
|
| 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.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.5 |
Those that do
MUST support it within the multipart/voice-message and MAY support it outside
of the multipart/voice-message. |
| |
|
|
MAY |
4.4.5 |
Outside a
multipart/voice-message, a recipient system MAY reject (with appropriate NDN)
the entire message if it cannot handle the fax attachments. |
| |
|
|
SHOULD |
4.4.5 |
If the VPIM
message is a voice annotated fax, the implementation SHOULD send this fax
content in multipart/voice-message. |
| |
|
|
SHOULD |
4.4.5 |
Not all VPIM
systems support fax, but all SHOULD accept it. |
| |
|
|
SHOULD |
4.4.5 |
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. |
| 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]). |
MAY |
4.4.6 |
Proprietary
voice encoding formats or other standard formats MAY be sent under this
profile only if 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.4.6 |
A compliant
implementation MAY use any other encoding provided a unique identifier is
registered with the IANA prior to use (see [MIME4]). |
| |
|
|
MAY |
4.4.6 |
Systems MAY
accept other audio/* or image/* content types if they can decode them. |
| |
|
|
MUST |
4.4.6 |
Systems which
receive audio/* or image/* content types which they are unable to decode MUST
return the message to the originator with an NDN indicating media not
supported. |
| MUST |
4.4 |
Implementations
MUST issue negative delivery status notifications to the originator when any
form of non-delivery to the recipient occurs. |
|