rfc2421.txt

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

               supports VPIM messages(see 18.1))

     VERSION - Indicates the version of the vCard profile.  Version 3.0
               [VCARD] MUST be used.

   The following attributes SHOULD be specified:

     N   -   Family Name, Given Name, Additional Names, Honorific
             Prefixes, and Suffixes. 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.

     ROLE -  The role of the person identified in `N' or `FN', but may
             also be used to distinguish when the sender is a corporate
             or positional mailbox

     SOUND - spoken name sound data (various types, typically 32KADPCM)

     REV  -  Revision of vCard in ISO 8601 date format

   The vCard MAY use other attributes as defined in [VCARD] or
   extensions attributes not yet defined (e.g. capabilities).

   If present, the spoken name attribute MUST be denoted by a content ID
   pointing to an audio/* content elsewhere in the VPIM message.

   A typical VPIM message (i.e. no forwarded parts), MUST only contain
   one vCard -- more than one is an error condition.  A VPIM message
   that contains forwarded messages, though, may contain multiple
   vCards.  However, these vCards MUST be associated with the
   originator(s) of the forwarded message(s) and the originator of the
   forwarding message.  As a result, all forwarded vCards will be



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


   contained in message/rfc822 contents -- only the vCard of forwarding
   originator will be at the top-level.

   Example:

     Content-Type: text/directory; charset=us-ascii; profile=vCard
     Content-Transfer-Encoding: 7bit

     BEGIN:VCARD
     N:Parsons;Glenn
     ORG:Northern Telecom
     TEL;TYPE=VOICE;MSG;WORK:[phone]
     EMAIL;TYPE=INTERNET;[e-mail]
     EMAIL;TYPE=INTERNET;VPIM:[e-mail]
     SOUND;TYPE=32KADPCM;ENCODING=URI: CID:<part1@VM2-4321>
     REV:19960831T103310Z
     VERSION: 3.0
     END:VCARD

4.3.4 Audio/32KADPCM

   An implementation compliant to this profile MUST send Audio/32KADPCM
   by default for voice [ADPCM].  Receivers MUST be able to accept and
   decode Audio/32KADPCM.  Typically this body contains several minutes
   of message content, however if used for spoken name or subject the
   content should be considerably shorter (i.e. about 10 and 20 seconds
   respectively).

   If an implementation can only handle one voice body, then multiple
   voice bodies (if present) SHOULD be concatenated, and SHOULD NOT be
   discarded.  It is RECOMMENDED that this be done in the same order as
   they were sent. 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).

   While any valid MIME body header MAY be used, several header fields
   have the following semantics when included with this body part:

4.3.4.1 Content-Description:

   This field MAY be present to facilitate the text identification of
   these body parts in simple email readers.  Any values may be used,
   though it may be useful to use values similar to those for Content-
   Disposition.

   Example:

       Content-Description: Big Telco Voice Message



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


4.3.4.2 Content-Disposition:

   This field MUST be present to allow the parsable identification of
   these body parts.  This is especially useful if, as is typical, more
   than one Audio/32KADPCM body occurs within a single level (e.g.
   multipart/voice-message).  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.  However, it is still useful to include a filename
   value, so this should be present if this information is available.
   From [DISP]

   In order to distinguish between the various types of audio contents
   in a VPIM voice message a new disposition parameter "voice" is
   defined with the parameter values below to be used as appropriate
   (see 18.2):

     Voice-Message - the primary voice message,
     Voice-Message-Notification - a spoken delivery notification
       or spoken disposition notification,
     Originator-Spoken-Name - the spoken name of the originator,
     Recipient-Spoken-Name - the spoken name of the recipient if
       available to the originator and present if there is ONLY one
       recipient,
     Spoken-Subject- the spoken subject of the message, typically
       spoken by the originator

   Note that there SHOULD only be one instance of each of these types of
   audio contents per message level.  Additional instances of a given
   type (i.e., parameter value) may occur within an attached forwarded
   voice message.

   Implementations that do not understand the "voice" parameter (or the
   Content-Disposition header) can safely ignore it, and will present
   the audio bodyparts in order (but will not be able to distinguish
   between them).

   Example:

       Content-Disposition: inline; voice=spoken-subject;
                           filename="msg001.726"

4.3.4.3 Content-Duration:

   This field MAY be present to allow the specification of the length of
   the audio bodypart in seconds.  The use of this field on reception is
   a local implementation issue.  From [DUR]




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


   Example:

       Content-Duration: 33

4.3.4.4 Content-Language:

   This field MAY be present to allow the specification of the spoken
   language of the audio bodypart.  The encoding is defined in [LANG].
   The use of this field on reception is a local implementation issue.

   Example for UK English:

       Content-Language: en-UK

4.3.5 Image/Tiff

   A common image encoding for facsimile, known as TIFF-F, is a
   derivative of the Tag Image File Format (TIFF) and is described in
   several documents.  For the purposes of VPIM, the F Profile of TIFF
   for Facsimile (TIFF-F) is defined in [TIFF-F] and the image/tiff MIME
   content type is defined in [TIFFREG].  While there are several
   formats of TIFF, only TIFF-F is profiled for use in a VPIM voice
   message.  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.

   All VPIM implementations that support facsimile SHOULD generate
   TIFF-F compatible facsimile contents in the image/tiff;
   application=faxbw sub-type encoding by default.  An implementation
   MAY send this fax content in VPIM voice messages and MUST be able to
   recognize and display it in received messages.  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.

   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.  Note that the content
   type parameter application=faxbw MUST be included in outbound
   messages.  However, inbound messages with or without this parameter
   MUST be rendered to the user (if the rendering software encounters an
   error in the file format, some form of negative delivery status
   notification MUST be sent to the originator).







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


4.3.6 Proprietary Voice or Fax Formats

   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]).  The voice
   encodings should be registered as sub-types of Audio and the fax
   encodings should be registered as sub-types of Image

   Use of any other encoding except audio/32kadpcm or image/tiff;
   application=faxbw reduces interoperability in the absence of explicit
   manual system configuration.  A compliant implementation MAY use any
   other encoding with explicit per-destination configuration.

4.4 Other Message Content Types

   An implementation compliant with this profile MAY send additional
   contents in a VPIM message, but ONLY outside of the multipart/voice-
   message.  The content types described in this section are identified
   for use with this profile. Additional contents not defined in this
   profile MUST NOT be used without prior explicit per-destination
   configuration. 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).  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).  Implementations MUST issue
   negative delivery status notifications to the originator when any
   form of non-delivery to the recipient occurs.

   The multipart contents defined below MAY be sent as the top level of
   a VPIM message (with other noted contents below them as required.) 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).  When multiple contents are present, they
   SHOULD be presented to the user in the order that they appear in the
   message.  Several examples are given in Appendix B.

4.4.1 Multipart/Mixed

   MIME provides the facilities for enclosing several body parts in a
   single message. 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.  Compliant systems MUST
   accept multipart/mixed body parts.  From [MIME2]



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


4.4.2 Text/Plain

   MIME requires support of the basic Text/Plain content type.  This
   content type has limited applicability within the voice messaging
   environment.  However, because VPIM is a MIME profile, MIME
   requirements should be met.  Compliant VPIM implementations SHOULD
   NOT send the Text/Plain content-type.  Compliant implementations MUST
   accept Text/Plain messages, however, specific handling is left as an
   implementation decision. From [MIME2]

   There are several mechanisms that can be used to support text (once
   accepted) on voice messaging systems including text-to-speech and
   text-to-fax conversions.  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.

4.4.3 Multipart/Report

   The Multipart/Report is used for enclosing human-readable and machine
   parsable notification (e.g. Message/delivery-status) body parts and
   any returned message content. The multipart/report content-type is
   used to deliver both delivery status reports indicating transport
   success or failure and message disposition notifications to indicate
   post-delivery events such as receipt notification. Compliant
   implementations MUST use the Multipart/Report construct. Compliant
   implementations MUST recognize and decode the Multipart/Report
   content type and its components in order to present the report to the
   user.  From [REPORT]

   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).  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.  Note that per
   [DSN] the human-readable part MUST always be present.