rfc2421.txt

RFC 的详细文档！

   electronic business card [MIMEDIR][VCARD].

4.1 Message Addressing Formats

   RFC 822 addresses are based on the domain name system.  This naming
   system has two components: the local part, used for username or
   mailbox identification; and the host part, used for global machine
   identification.

4.1.1 VPIM Addresses

   The local part of the address shall be a US-ASCII string uniquely
   identifying a mailbox on a destination system.  For voice messaging,
   the local part is a printable string containing the mailbox ID of the
   originator or recipient.  While alpha characters and long mailbox
   identifiers are permitted, most voice mail networks rely on numeric
   mailbox identifiers to retain compatibility with the limited 10 digit
   telephone keypad.  As a result, some voice messaging systems may only
   be able to handle a numeric local part.  The reception of
   alphanumeric local parts on these systems may result in the address
   being mapped to some locally unique (but confusing to the recipient)
   number or, in the worst case the address could be deleted making the
   message un-replyable.  Additionally, it may be difficult to create
   messages on these systems with an alphanumeric local part without
   complex key sequences or some form of directory lookup (see 6).

   The use of the domain naming system should be transparent to the
   user.  It is the responsibility of the voice mail machine to lookup
   the fully-qualified domain name (FQDN) based on the address entered
   by the user (see 6).

   In the absence of a global directory, specification of the local part
   is expected to conform to international or private telephone
   numbering plans.  It is likely that private numbering plans will
   prevail and these are left for local definition.  However, it is
   RECOMMENDED that public telephone numbers be noted according to the
   international numbering plan described in [E.164]. The indication



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


   that the local part is a public telephone number is given by a
   preceding `+' (the `+' would not be entered from a telephone keypad,
   it is added by the system as a flag).  Since the primary information
   in the numeric scheme is contained by the digits, other character
   separators (e.g.  `-') may be ignored (i.e. to allow parsing of the
   numeric local mailbox) or may be used to recognize distinct portions
   of the telephone number (e.g. country code).  The specification of
   the local part of a VPIM address can be split into the four groups
   described below:

     1) mailbox number
        - for use as a private numbering plan (any number of digits)
        - e.g.  [e-mail]

     2) mailbox number+extension
        - for use as a private numbering plan with extensions
          any number of digits, use of `+' as separator
        - e.g.  [e-mail]

     3) +international number
        - for international telephone numbers conforming to E.164
          maximum of 15 digits
        - e.g.  [e-mail]

     4) - for international telephone numbers conforming to E.164
          maximum of 15 digits, with an extension (e.g. behind a
          PBX) that has a maximum of 15 digits.
        - e.g.  [e-mail]

   Note that this address format is designed to be compatible with
   current usage within the voice messaging industry.  It is not
   compatible with the addressing formats of RFCs 2303-2304.  It is
   expected that as telephony services become more widespread on the
   Internet, these addressing formats will converge.

4.1.2 Special Addresses

   Special addresses are provided for compatibility with the conventions
   of Internet mail.  These addresses do not use numeric local
   addresses, both to conform to current Internet practice and to avoid
   conflict with existing numeric addressing plans. Two special
   addresses are RESERVED for use as follows:

   postmaster@domain

   By convention, a special mailbox named "postmaster" MUST exist on all
   systems.  This address is used for diagnostics and should be checked
   regularly by the system manager. This mailbox is particularly likely



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


   to receive text messages, which is not normal on a voice processing
   platform.  The specific handling of these messages is an individual
   implementation choice.

   non-mail-user@domain

   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.  Any text name such as "Telephone
   Answering", or the telephone number if it is available, is permitted.
   This special address is used as a token to indicate an unreachable
   originator. 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.  The status code for such NDN's is
   5.1.1 "Mailbox does not exist".

   Example:

       From: Telephone Answering <[e-mail]>

4.1.3 Distribution Lists

   There are many ways to handle distribution list (DL) expansions and
   none are 'standard'.  Simple alias is a behavior closest to what most
   voice mail systems do today and what is to be used with VPIM
   messages.  That is:

     Reply to the originator - (Address in the RFC822 Reply-to or From
                                field)
     Errors to the submitter - (Address in the MAIL FROM: field of the
                                ESMTP exchange and the Return-Path:
                                RFC 822 field)

   Some proprietary voice messaging protocols include only the recipient
   of the particular copy in the envelope and include no "header fields"
   except date and per-message features.  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. 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.







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


4.2 Message Header Fields

   Internet messages contain a header information block.  This header
   block contains information required to identify the sender, the list
   of recipients, the message send time, and other information intended
   for user presentation.  Except for specialized gateway and mailing
   list cases, header fields do not indicate delivery options for the
   transport of messages.

   Distribution list processors are noted for modifying or adding to the
   header fields of messages that pass through them.  VPIM systems MUST
   be able to accept and ignore header fields that are not defined here.

   The following header lines are permitted for use with VPIM voice
   messages:

4.2.1 From

   The originator's fully-qualified domain address (a mailbox address
   followed by the fully-qualified domain name).  The user listed in
   this field should be presented in the voice message envelope as the
   originator of the message.

   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.  Text names of corporate or positional mailboxes MAY be
   provided as a simple string. From [RFC822]

   Example:

       From: "Joe S. User" <[e-mail]>

       From: Technical Support <[e-mail]>

   The From address SHOULD be used for replies (see 4.6).  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.

   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.  Use of addresses different than those present in the
   From header field address may result in unanticipated behavior.







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


4.2.2 To

   The To header contains the recipient's fully-qualified domain
   address.  There may be one or more To: fields in any message.

   Example:

       To: [e-mail]

   Systems compliant to this profile SHOULD provide a list of recipients
   only if all recipients are provided.  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).  If present,
   the addresses in the To header MAY be used for a reply message to all
   recipients.

   Systems compliant to this profile MAY also discard the To addresses
   of incoming messages because of the inability to store the
   information.  This would, of course, make a reply-to-all capability
   impossible.

4.2.3 Cc

   The cc header contains additional recipients' fully-qualified domain
   addresses. Many voice mail systems maintain only sufficient envelope
   information for message delivery and are not capable of storing or
   providing a complete list of recipients.

   Systems compliant to this profile SHOULD provide a list of recipients
   only if all disclosed recipients can be provided.  The list of
   disclosed recipients does not include those sent via a blind copy. If
   not, systems SHOULD omit the To and Cc header fields to indicate that
   the full list of recipients is unknown.

   Example:

       Cc: [e-mail]

   Systems compliant to this profile MAY discard the Cc addresses of
   incoming messages as necessary.    If a list of Cc or to addresses is
   present, these addresses MAY be used for a reply message to all
   recipients.








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


4.2.4 Date

   The Date header contains the date, time, and time zone in which the
   message was sent by the originator.  The time zone SHOULD be
   represented in a four-digit time zone offset, such as -0500 for North
   American Eastern Standard Time.  This may be supplemented by a time
   zone name in parentheses, e.g., "-0900 (PDT)".  Compliant
   implementations SHOULD be able to convert RFC 822 date and time
   stamps into local time.

   Example:

       Date: Wed, 28 Jul 96 10:08:49 -0800 (PST)

   The sending system MUST report the time the message was sent. 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.  From [RFC822]

4.2.5 Sender

   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.  If it is present in a VPIM message, the receiving VPIM
   implementation may ignore the field and only present the From header
   field.