rfc2421.txt

RFC 的详细文档！

4.2.6 Return Path

   The Return-path header is added by the final delivering SMTP server.
   If present, it contains the address from the MAIL FROM parameter of
   the ESMTP exchange (see 5.1.2). Any error messages resulting from the
   delivery failure MUST be sent to this address (see [DRPT] for
   additional details).  Note that if the Return-path is null ("<>"),
   e.g. no path, loop prevention or confidential, a notification MUST
   NOT be sent.  If the Return path address is not available (either
   from this header or the MAIL FROM parameter) the From address may be
   used to deliver notifications.

4.2.7 Message-id

   The Message-id header contains a unique per-message identifier.  A
   unique message-id MUST be generated for each message sent from a
   compliant implementation.

   The message-id is not required to be stored on the receiving system.
   This identifier MAY be used for tracking, auditing, and returning



Vaudreuil & Parsons         Standards Track                    [Page 11]

RFC 2421                        VPIM v2                   September 1998


   receipt notification reports.  From [RFC822]

   Example:

       Message-id: <[e-mail]>

4.2.8 Reply-To

   If present, the reply-to header provides a preferred address to which
   reply messages should be sent (see 4.6).  Typically, voice mail
   systems can only support one originator of a message so it is
   unlikely that this field can be supported.  A compliant system SHOULD
   NOT send a Reply-To header. However, if a reply-to header is present,
   a reply-to sender message MAY be sent to the address specified (that
   is, overwriting From). From [RFC822] This preferred address of the
   originator must also be provided in the originator's vCard EMAIL
   attribute, if present (see 4.3.3).

4.2.9 Received

   The Received header contains trace information added to the beginning
   of a RFC 822 message by MTAs.  This is the only header permitted to
   be added by an MTA.  Information in this header is useful for
   debugging when using an US-ASCII message reader or a header parsing
   tool.

   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..  These header fields MAY be
   ignored or deleted when the message is received at the final
   destination. From [RFC822]

4.2.10 MIME Version

   The MIME-Version header indicates that the message conforms to the
   MIME message format specification. Systems compliant with this
   specification SHOULD include a comment with the words "(Voice 2.0)".
   RFC 1911 defines an earlier version of this profile and uses the
   token (Voice 1.0). From [MIME1][VPIM1]

   Example:

       MIME-Version: 1.0 (Voice 2.0)

   This identifier is intended for information only and SHOULD NOT be
   used to semantically identify the message as being a VPIM message.
   Instead, the presence of the content defined in [V-MSG] SHOULD be
   used if identification is necessary.



Vaudreuil & Parsons         Standards Track                    [Page 12]

RFC 2421                        VPIM v2                   September 1998


4.2.11 Content-Type

   The content-type header declares the type of content enclosed in the
   message. 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.  The allowable contents are
   detailed in section 4.3 of this document.  From [MIME2]

4.2.12 Content-Transfer-Encoding

   Because Internet mail was initially specified to carry only 7-bit
   US-ASCII text, it may be necessary to encode voice and fax data into
   a representation suitable for that environment.  The content-
   transfer-encoding header describes this transformation if it is
   needed.  Compliant implementations MUST recognize and decode the
   standard encodings, "Binary", "7bit, "8bit", "Base64" and "Quoted-
   Printable".  The allowable content-transfer-encodings are specified
   in section 4.3.  From [MIME1]

4.2.13 Sensitivity

   The sensitivity header, if present, indicates the requested privacy
   level.  The case-insensitive values "Personal" and "Private" are
   specified. If no privacy is requested, this field is omitted.

   If a sensitivity header is present in the message, a compliant system
   MUST prohibit the recipient from forwarding this message to any other
   user.  A compliant system, however, SHOULD allow the responder to
   reply to a sensitive message, but SHOULD NOT include the original
   message content.  The sensitivity of the reply message MAY be set by
   the responder.

   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. The message
   contents SHOULD  be returned to the sender to allow for a voice
   context with the notification. A non-delivery notification to a
   private message SHOULD NOT be tagged private since it will be sent to
   the originator.  From: [X.400]

4.2.14 Importance

   Indicates the requested importance to be given by the receiving
   system.  The case-insensitive values "low", "normal" and "high" are
   specified.  If no special importance is requested, this header may be
   omitted and the value assumed to be "normal".




Vaudreuil & Parsons         Standards Track                    [Page 13]

RFC 2421                        VPIM v2                   September 1998


   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]

4.2.15 Subject

   The subject field is often provided by email systems but is not
   widely supported on Voice Mail platforms. 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.  From [RFC822]

   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" for the benefit of text
   enabled recipients.

4.2.16 Disposition-Notification-To

   This header MAY be present to indicate that the sender is requesting
   a receipt notification from the receiving user agent.  This message
   disposition notification (MDN) is typically sent by the user agent
   after the user has listened to the message and consented to an MDN
   being sent

   Example:

       Disposition-notification-to: [e-mail]

   The presence of a Disposition-notification-to header in a message is
   merely a request for an MDN described in 4.4.5.  The recipients' user
   agents are always free to silently ignore such a request so this
   header does not burden any system that does not support it.  From
   [MDN].

4.2.17 Disposition-Notification-Options

   This header MAY be present to define future extensions parameters for
   an MDN requested by the presence of the header in the previous
   section.  Currently no parameters are defined by this document or by
   [MDN].  However, this header MUST be parsed if present, if MDNs are
   supported.  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.  See [MDN] for complete
   details.






Vaudreuil & Parsons         Standards Track                    [Page 14]

RFC 2421                        VPIM v2                   September 1998


   Example:

       Disposition-notification-options:
          whizzbang=required,foo

4.3 Voice Message Content Types

   MIME, introduced in [MIME1], is a general-purpose message body format
   that is extensible to carry a wide range of body parts.  It provides
   for encoding binary data so that it can be transported over the 7-bit
   text-oriented SMTP protocol.  This transport encoding (denoted by the
   Content-Transfer-Encoding header field) is in addition to the audio
   encoding required to generate a binary object.

   MIME defines two transport encoding mechanisms to transform binary
   data into a 7 bit representation, one designed for text-like data
   ("Quoted-Printable"), and one for arbitrary binary data ("Base64").
   While Base64 is dramatically more efficient for audio data, either
   will work.  Where binary transport is available, no transport
   encoding is needed, and the data can be labeled as "Binary".

   An implementation in compliance with this profile SHOULD send audio
   and/or facsimile data in binary form when binary message transport is
   available.  When binary transport is not available, implementations
   MUST encode the audio and/or facsimile data as Base64.  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.
   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.

   The content types described in this section are identified for use
   within the multipart/voice-message content.  This content, which is
   the fundamental part of a VPIM message, is referred to as a VPIM
   voice message in this document.

   Only the contents profiled subsequently can be sent within a VPIM
   voice message construct (i.e., the mulitpart/voice-message content
   type) to form a simple or a more complex structure (several examples
   are given in Appendix B).  The presence of other contents within a
   VPIM voice message is an error condition and SHOULD result in a
   negative delivery status notification.  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.






Vaudreuil & Parsons         Standards Track                    [Page 15]

RFC 2421                        VPIM v2                   September 1998


4.3.1 Multipart/Voice-Message

   This MIME multipart structure provides a mechanism for packaging a
   voice message into one container that is tagged as VPIM v2 compliant.
   The semantic of multipart/Voice-Message (defined in [V-MSG]) is
   identical to multipart/mixed and may be interpreted as that by
   systems that do not recognize this content-type.

   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).  The most
   common will be: spoken name, spoken subject, the message itself,
   attached fax and directory info.  Forwarded messages are created by
   simply using the message/rfc822 construct.

   Conformant implementations MUST send the multipart/voice-message in a
   VPIM message.  In most cases, this Multipart/Voice-Message content
   will be the top level (i.e. in the Content-Type header).  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).

4.3.2 Message/RFC822

   MIME requires support of the Message/RFC822 message encapsulation
   body part.  This body part is used within a multipart/voice-message
   to forward complete messages (see 4.5) or to reply with original
   content (see 4.6). From [MIME2]

4.3.3 Text/Directory

   This content allows for the inclusion of a Versit vCard [VCARD]
   electronic business card within a VPIM message.  The format is
   suitable as an interchange format between applications or systems,
   and is defined independent of the method used to transport it.  It
   provides a useful mechanism to transport information about the
   originator that can be used by the receiving VPIM system (see 6) or
   other local applications

   Each vCard MUST be contained within a Text/Directory content type
   [MIMEDIR] within a VPIM message.  [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).