rfc2421.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

4.4.4 Message/Delivery-status

   This MIME body part is used for sending machine-parsable delivery
   status notifications.  Compliant implementations MUST use the
   Message/delivery-status construct when returning messages or sending
   warnings.  Compliant implementations MUST recognize and decode the
   Message/delivery-status content type and present the reason for
   failure to the sender of the message.  From [DSN]




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


4.4.5 Message/Disposition-notification

   This MIME body part is used for sending machine-parsable receipt
   notification message disposition notifications.  Conforming
   implementations SHOULD use the Message/Disposition-notification
   construct when sending post-delivery message status notifications.
   These MDNs, however, MUST only be sent in response to the presence of
   the Disposition-notification-to header in 4.2.16.  Conforming
   implementations should recognize and decode the Message/Disposition-
   notification content type and present the notification to the user.
   From [MDN]

4.5 Forwarded Messages

   VPIM version 2 explicitly supports the forwarding of voice and fax
   content with voice or fax annotation.  However, only the two
   constructs described below are acceptable in a VPIM message.  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.

   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.
   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.  However, note that
   at least one of "From", "Subject", or "Date" MUST be present.  As
   well, the message/rfc822 content MUST include at least the "MIME-
   Version", and "Content-Type" header fields. From [MIME2]

   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.

4.6 Reply Messages

   Replies to VPIM messages (and Internet mail messages) are addressed
   to the address noted in the reply-to header (see 4.2.8) if it is
   present, else the From address (see 4.2.1) is used. The vCard EMAIL
   attribute, if present, SHOULD be the same as the reply-to address and
   may be the same as the From address.  While the vCard is the senders
   preferred address it SHOULD NOT be used to generate a reply.  Also,
   the Return-path address should not be used for replies.




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


   Support of multiple originator header fields is often not possible on
   voice messaging systems, so it may be necessary to choose only one
   when gatewaying a VPIM message to another voice message system.
   However, implementers should note that this may make it impossible to
   send error messages and replies to their proper destinations.

   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).  A null ESMTP MAIL FROM address SHOULD also
   be used in this case (see 5.1.2).  A receiving VPIM system SHOULD NOT
   offer the user the option to reply to this kind of message.

4.7 Notification Messages

   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.  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.

   VPIM Receipt Notification messages (4.4.5) should be sent to the
   sender specified in the Disposition-Notification-To header field
   (4.2.16), only 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).

   VPIM Notification messages may be positive or negative, and can
   indicate delivery at the server or receipt by the client.  However,
   the notification MUST be contained in a multipart/report container
   (4.4.3) and SHOULD contain a spoken error message.

   If a VPIM system receives a message with contents that are not
   understood (see 4.3 & 4.4), its handling is a local matter.  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).  In some cases, the message may be
   delivered (with a positive DSN sent) to a mailbox before the
   determination of rendering can be made.

5. Message Transport Protocol

   Messages are transported between voice mail machines using the
   Internet Extended Simple Mail Transfer Protocol (ESMTP).  All
   information required for proper delivery of the message is included
   in the ESMTP dialog.  This information, including the sender and
   recipient addresses, is commonly referred to as the message



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


   "envelope".  This information is equivalent to the message control
   block in many analog voice messaging  protocols.

   ESMTP is a general-purpose messaging protocol, designed both to send
   mail and to allow terminal console messaging.  Simple Mail Transport
   Protocol (SMTP) was originally created for the exchange of US-ASCII
   7-bit text messages.  Binary and 8-bit text messages have
   traditionally been transported by encoding the messages into a 7-bit
   text-like form.  [ESMTP] formalized an extension mechanism for SMTP,
   and subsequent RFCs have defined 8-bit text networking, command
   streaming, binary networking, and extensions to permit the
   declaration of message size for the efficient transmission of large
   messages such as multi-minute voice mail.

   The following sections list ESMTP commands, keywords, and parameters
   that are required and those that are optional for conformance to this
   profile.

5.1 ESMTP Commands

5.1.1 HELO

   Base SMTP greeting and identification of sender.  This command is not
   to be sent by compliant systems unless the more-capable EHLO command
   is not accepted.  It is included for compatibility with general SMTP
   implementations.  Compliant servers MUST implement the HELO command
   for backward compatibility but clients SHOULD NOT send it unless EHLO
   is not supported.  From [SMTP]

5.1.2 MAIL FROM (REQUIRED)

   Originating mailbox.  This address contains the mailbox to which
   errors should be sent.  VPIM implementations SHOULD use the same
   address in the MAIL FROM command as is used in the From header field.
   This address is not necessarily the same as the message Sender listed
   in the message header fields if the message was received from a
   gateway or sent to an Internet-style mailing list. From [SMTP, ESMTP]

   The MAIL FROM address SHOULD be stored in the local message store for
   the purposes of generating a delivery status notification to the
   originator. 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.  From [HOSTREQ]

   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.  This null address MAY be used to note that a
   particular message has no return path (e.g. a telephone answer



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


   message).  From [SMTP]

5.1.3 RCPT TO

   Recipient's mailbox. The parameter to this command contains only the
   address to which the message should be delivered for this
   transaction.  It is the set of addresses in one or more RCPT TO
   commands that are used for mail routing. From [SMTP, ESMTP]

   Note: In the event that multiple transport connections to multiple
   destination machines are required for the same message, the set of
   addresses in a given transport connection may not match the list of
   recipients in the message header fields.

5.1.4 DATA

   Initiates the transfer of message data.  Support for this command is
   required.  Compliant implementations MUST implement the SMTP DATA
   command for backwards compatibility.  From [SMTP]

5.1.5 TURN

   Requests a change-of-roles, that is, the client that opened the
   connection offers to assume the role of server for any mail the
   remote machine may wish to send.  Because SMTP is not an
   authenticated protocol, the TURN command presents an opportunity to
   improperly fetch mail queued for another destination.  Compliant
   implementations SHOULD NOT implement the TURN command.  From [SMTP]

5.1.6 QUIT

   Requests that the connection be closed.  If accepted, the remote
   machine will reset and close the connection.  Compliant
   implementations MUST implement the QUIT command.  From [SMTP]

5.1.7 RSET

   Resets the connection to its initial state.  Compliant
   implementations MUST implement the RSET command. From [SMTP]

5.1.8 VRFY

   Requests verification that this node can reach the listed recipient.
   While this functionality is also included in the RCPT TO command,
   VRFY allows the query without beginning a mail transfer transaction.
   This command is useful for debugging and tracing problems.  Compliant
   implementations MAY implement the VRFY command.  From [SMTP] (Note
   that the implementation of VRFY may simplify the guessing of a



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


   recipient's mailbox or automated sweeps for valid mailbox addresses,
   resulting in a possible reduction in privacy.  Various implementation
   techniques may be used to reduce the threat, such as limiting the
   number of queries per session.)  From [SMTP]

5.1.9 EHLO

   The enhanced mail greeting that enables a server to announce support
   for extended messaging options.  The extended messaging modes are
   discussed in subsequent sections of this document.  Compliant
   implementations MUST implement the ESMTP command and return the
   capabilities indicated later in this memo.  From [ESMTP]

5.1.10 BDAT

   The BDAT command provides a higher efficiency alternative to the
   earlier DATA command, especially for voice. The BDAT command provides
   for native binary transport of messages. Compliant implementations
   SHOULD support binary transport using the BDAT command [BINARY].

5.2 ESMTP Keywords

   The following ESMTP keywords indicate extended features useful for
   voice messaging.

5.2.1 PIPELINING

   The "PIPELINING" keyword indicates ability of the receiving server to
   accept new commands before issuing a response to the previous
   command.  Pipelining commands dramatically improves performance by
   reducing the number of round-trip packet exchanges and makes it
   possible to validate all recipient addresses in one operation.
   Compliant implementations SHOULD support the command pipelining
   indicated by this keyword.  From [PIPE]

5.2.2 SIZE

   The "SIZE" keyword provides a mechanism by which the SMTP server can
   indicate the maximum size message supported.  Compliant servers MUST
   provide size extension to indicate the maximum size message that can
   be accepted.  Clients SHOULD NOT send messages larger than the size
   indicated by the server.  Clients SHOULD advertise SIZE= when sending
   messages to servers that indicate support for the SIZE extension.
   From [SIZE]







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


5.2.3 CHUNKING

   The "CHUNKING" keyword indicates that the receiver will support the
   high-performance binary transport mode.  Note that CHUNKING can be
   used with any message format and does not imply support for binary
   encoded messages. Compliant implementations MAY support binary
   transport indicated by this capability.