| 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. |
|
|
|
| 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.1 |
Compliant
systems MUST accept multipart/mixed body parts. |
|
|
|
| SHOULD |
4.4.1 |
Multipart/Mixed
SHOULD only be used for sending complex voice or multimedia messages. |
|
|
|
| |
|
|
MAY |
4.4.7 |
A VPIM voice
message MAY be included within a message with a multipart/mixed top level
content type. |
| MUST |
4.4.2 |
Compliant
implementations MUST accept Text/Plain messages, however, specific handling
is left as an implementation decision. |
MUST |
4.4.8 |
Outside
a Multipart/Voice-message, compliant implementations MUST accept Text/Plain
messages, however, specific handling is left as an implementation decision. |
| 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. |
MUST |
4.4.8 |
If no rendering
of the text is possible and no indication of its presence can be given to the
recipient, the entire message MUST be returned to the sender with a negative
delivery status notification and a media-unsupported status code. |
| SHOULD NOT |
4.4.2 |
Compliant VPIM
implementations SHOULD NOT send the Text/Plain content-type. |
SHOULD NOT |
4.4.8 |
Compliant VPIM
implementations SHOULD NOT send the Text/Plain content-type. |
| |
|
|
SHOULD NOT |
4.4.8 |
The recipient
SHOULD NOT reject the entire message if the text component cannot be accepted
or rendered. |
| |
|
|
MAY |
4.4.8 |
However, an the
spirit of liberal acceptance, a conforming implementation MAY accept and
render a VPIM voice message contained in a multipart/mixed. |
| |
|
|
MAY |
4.4.8 |
Within a
multipart/voice message, the text/plain content type MAY be dropped from the
message if necessary to deliver the audio components. |
| |
|
|
SHOULD |
4.5 |
VPIM
Receipt Notification messages (4.5.3) SHOULD be sent to the sender specified
in the disposition-Notification-To header field (4.2.16). |
| |
|
|
SHOULD |
4.5 |
The MDN SHOULD
be sent after the message has been presented to the recipient or if the
message has somehow been disposed of without being presented to the recipient
(e.g. if it were deleted before playing it). |
| MUST |
4.4.3 |
Compliant
implementations MUST use the Multipart/Report construct. |
MUST |
4.5.1 |
Compliant
implementations MUST use the Multipart/Report construct. |
| 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.5.1 |
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.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. |
MUST |
4.5.1 |
As well,
implementers MUST be able to handle the human readable description of the
error as text or audio. |
| MUST |
4.4.3 |
Note that per
[DSN] the human-readable part MUST always be present. |
MUST |
4.5.1 |
Note that per
[DSN] the human-readable part MUST always be present. |
| 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.5.1 |
Multipart/Report
messages from VPIM implementations SHOULD include the human-readable
description of the error as a spoken audio/* content (this speech MAY be made
available to the notification recipient). |
| 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). |
MAY |
4.5.1 |
Multipart/Report
messages from VPIM implementations SHOULD include the human-readable
description of the error as a spoken audio/* content (this speech MAY be made
available to the notification recipient). |
| 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.5.1 |
As well, VPIM
implementations MAY generate Multipart/Report messages that encode the
human-readable description of the error as text. |
| MUST |
4.4.4 |
Compliant
implementations MUST use the Message/delivery-status construct when returning
messages or sending warnings. |
MUST |
4.5.2 |
Compliant
implementations MUST use the Message/delivery-status construct when returning
messages or sending warnings |
| 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.5.3 |
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.4.5 |
These MDNs,
however, MUST only be sent in response to the presence of the
Disposition-notification-to header in 4.2.16. |
MUST |
4.5.3 |
These MDNs,
however, MUST only be sent in response to the presence of the
Disposition-notification-to header described 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.5.3 |
Conforming
implementations SHOULD use the Message/Disposition-notification construct
when sending post-delivery message status notifications. |
| MUST |
4.5 |
However, note
that at least one of "From", "Subject", or
"Date" MUST be present. |
MUST |
4.6 |
However, 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.6 |
As well, the
message/rfc822 content MUST include at least the "MIME-Version",
and "Content-Type" header fields. |
| 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.6 |
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.6 |
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. |
| 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.6 |
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. An
example of this loss is an AMIS message being forwarded through an
AMIS-to-VPIM gateway. |
| 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.6 |
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.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 |
4.7 |
A receiving VPIM
system SHOULD NOT offer the user the option to reply to this kind of message. |
| SHOULD |
4.6 |
A null ESMTP
MAIL FROM address SHOULD also be used in this case (see 5.1.2). |
SHOULD |
4.7 |
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) |
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 NOT |
4.6 |
Also, the
Return-path address should not be used for replies. |
|
|
|
| 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. |
MUST |
4.5 & 4.8 |
VPIM delivery
status notification messages (4.5.2) MUST be sent to the originator of the
message when any form of non-delivery of the subject message or its
components occurs. |
| 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.5 & 4.8 |
These error
messages MUST be sent to the address in the Mail From (5.1.2) if available
(same as 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. |
MUST |
4.5 & 4.8 |
However, the
notification MUST be contained in a multipart/report container (4.5.1) 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.5 & 4.8 |
However, the
notification MUST be contained in a multipart/report container (4.5.1) 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). |
SHOULD |
4.8 |
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). |
| 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. |
SHOULD NOT |
5.1.1 |
This command
SHOULD not be sent by compliant systems unless the more-capable EHLO command
is not accepted. |
| 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. |
MUST |
5.1.1 |
Compliant
servers MUST implement the HELO command for backward compatibility. This
command SHOULD not be sent by compliant systems unless the more-capable EHLO
command is not accepted. |
| 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. |
SHOULD NOT |
5.1.1 |
Compliant
servers MUST implement the HELO command for backward compatibility. This
command SHOULD not be sent by compliant systems unless the more-capable EHLO
command is not accepted. |
| 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. |
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 |
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 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. |
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). |
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. |
MUST |
5.1.4 |
Compliant
implementations MUST implement the SMTP DATA command for backward
compatibility. |
| SHOULD NOT |
5.1.5 |
Compliant
implementations SHOULD NOT implement the TURN command. |
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.6 |
Compliant
implementations MUST implement the QUIT command. |
| MUST |
5.1.7 |
Compliant
implementations MUST implement the RSET command. |
MUST |
5.1.7 |
Compliant
implementations MUST implement the RSET command. |
| MAY |
5.1.8 |
Compliant
implementations MAY implement the VRFY 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. |
MUST |
5.1.9 |
Compliant
implementations MUST implement the ESMTP command and return the capabilities
indicated later in section 5. |
| SHOULD |
5.1.10 |
Compliant
implementations SHOULD support binary transport using the BDAT command |
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.1 |
Compliant
implementations SHOULD support the command pipelining indicated by this
keyword. |
| SHOULD |
5.2.2 |
Clients SHOULD
advertise SIZE= when sending messages to servers that indicate support for
the SIZE extension. |
SHOULD |
5.2.2 |
Clients SHOULD
advertise SIZE= when sending messages to servers that indicate support for
the SIZE extension. |
| MUST |
5.2.2 |
Compliant
servers MUST provide size extension to indicate the maximum size message that
can be accepted. |
MUST |
5.2.2 |
Compliant
servers MUST provide size extension to indicate the maximum size message that
can be accepted. |
| SHOULD NOT |
5.2.2 |
Clients SHOULD
NOT send messages larger than the size indicated by the server. |
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.3 |
Compliant
implementations MAY support binary transport indicated by this capability. (CHUNKING) |
| MAY |
5.2.4 |
Compliant
implementations MAY support binary transport indicated by this capability. (BINARYMIME) |
MAY |
5.2.4 |
Compliant
implementations MAY support binary transport indicated by this capability. (BINARYMIME) |
| MUST |
5.2.5 |
Compliant
implementations MUST support the delivery notification extensions in [DRPT]. |
MUST |
5.2.5 |
Compliant
implementations MUST support the delivery notification extensions in [DRPT]. |
| SHOULD |
5.2.6 |
Compliant
implementations SHOULD support this capability. (ENHANCEDSTATUSCODES) |
SHOULD |
5.2.6 |
Compliant
implementations SHOULD support this capability. (ENHANCEDSTATUSCODES) |
| SHOULD |
5.3.1 |
Compliant
implementations SHOULD support binary transport indicated by this parameter. (BINARYMIME) |
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. |
SHOULD |
5.3.2 |
Compliant
systems SHOULD honor a request for returned content. |
| MAY |
5.3.3 |
Compliant
implementations MAY use this parameter. (ENVID) |
MAY |
5.3.3 |
Compliant
implementations MAY use this parameter. (ENVID) |
| 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.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.4.2 |
If the ORCPT
esmtp-keyword is used, it MUST have an associated esmtp-value, which consists
of the original recipient address. |
| MAY |
5.4.2 |
Compliant
implementations MAY use this parameter. (ORCPT) |
MAY |
5.4.2 |
Compliant
implementations MAY use this parameter. (ORCPT) |
| 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.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.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.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. |
| 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. |
| 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: |
|
|
|
|
|
|
|
|
|
|
|
|
|
Unchanged text |
|
|
New text in
draft-ietf-vpim-vpimv2r2-00.txt |
|
|
Changed text |
|
|
Deleted from RFC2421 |
|
|
|
|
| Red text added for clarity - not in Spec |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|