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