rfc1766.txt

RFC 的详细文档！

      Content-Type: multipart/alternative;
             differences=content-language
      Content-Language: no-nynorsk, no-bokmaal

   Voice recording from the London docks

      Content-type: audio/basic
      Content-Language: en-cockney

   Document in Sami, which does not have an ISO 639 code, and is spoken
   in several countries, but with about half the speakers in Norway,
   with six different, mutually incomprehensible dialects:

      Content-type: text/plain; charset=iso-8859-10
      Content-Language: i-sami-no (North Sami)

   An English-French dictionary

      Content-type: application/dictionary
      Content-Language: en, fr (This is a dictionary)

   An official EC document (in a few of its official languages)




Alvestrand                                                      [Page 5]

RFC 1766                      Language Tag                    March 1995


      Content-type: multipart/alternative
      Content-Language: en, fr, de, da, el, it

   An excerpt from Star Trek

      Content-type: video/mpeg
      Content-Language: x-klingon

4.  Use of Content-Language with Multipart/Alternative

   When using the Multipart/Alternative body part of MIME, it is
   possible to have the body parts giving the same information content
   in different languages. In this case, one should put a Content-
   Language header on each of the body parts, and a summary Content-
   Language header onto the Multipart/Alternative itself.

4.1.  The differences parameter to multipart/alternative

   As defined in RFC 1541, Multipart/Alternative only has one parameter:
   boundary.

   The common usage of Multipart/Alternative is to have more than one
   format of the same message (f.ex. PostScript and ASCII).

   The use of language tags to differentiate between different
   alternatives will certainly not lead all MIME UAs to present the most
   sensible body part as default.

   Therefore, a new parameter is defined, to allow the configuration of
   MIME readers to handle language differences in a sensible manner.

    Name: Differences
    Value: One or more of
         Content-Type
         Content-Language

   Further values can be registered with IANA; it must be the name of a
   header for which a definition exists in a published RFC.  If not
   present, Differences=Content-Type is assumed.

   The intent is that the MIME reader can look at these headers of the
   message component to do an intelligent choice of what to present to
   the user, based on knowledge about the user preferences and
   capabilities.

   (The intent of having registration with IANA of the fields used in
   this context is to maintain a list of usages that a mail UA may
   expect to see, not to reject usages.)



Alvestrand                                                      [Page 6]

RFC 1766                      Language Tag                    March 1995


   (NOTE: The MIME specification [RFC 1521], section 7.2, states that
   headers not beginning with "Content-" are generally to be ignored in
   body parts. People defining a header for use with "differences="
   should take note of this.)

   The mechanism for deciding which body part to present is outside the
   scope of this document.

    MIME EXAMPLE:

    Content-Type: multipart/alternative; differences=Content-Language;
              boundary="limit"
    Content-Language: en, fr, de

    --limit
    Content-Language: fr

    Le renard brun et agile saute par dessus le chien paresseux
    --limit
    Content-Language: de
    Content-Type: text/plain; charset=iso-8859-1
    Content-Transfer-encoding: quoted-printable

    Der schnelle braune Fuchs h=FCpft =FCber den faulen Hund
    --limit
    Content-Language: en

    The quick brown fox jumps over the lazy dog
    --limit--

   When composing a message, the choice of sequence may be somewhat
   arbitrary. However, non-MIME mail readers will show the first body
   part first, meaning that this should most likely be the language
   understood by most of the recipients.

5.  IANA registration procedure for language tags

   Any language tag must start with an existing tag, and extend it.

   This registration form should be used by anyone who wants to use a
   language tag not defined by ISO or IANA.










Alvestrand                                                      [Page 7]

RFC 1766                      Language Tag                    March 1995


----------------------------------------------------------------------
LANGUAGE TAG REGISTRATION FORM

Name of requester          :
E-mail address of requester:
Tag to be registered       :

English name of language   :

Native name of language (transcribed into ASCII):

Reference to published description of the language (book or article):
----------------------------------------------------------------------

   The language form must be sent to <[e-mail]> for a 2-
   week review period before submitting it to IANA.  (This is an open
   list. Requests to be added should be sent to <ietf-types-
   [e-mail]>.)

   When the two week period has passed, the language tag reviewer, who
   is appointed by the IETF Applications Area Director, either forwards
   the request to [e-mail], or rejects it because of significant
   objections raised on the list.

   Decisions made by the reviewer may be appealed to the IESG.

   All registered forms are available online in the directory
   ftp://ftp.isi.edu/in-notes/iana/assignments/languages/

6.  Security Considerations

   Security issues are not discussed in this memo.

7.  Character set considerations

   Codes may always be expressed using the US-ASCII character repertoire
   (a-z), which is present in most character sets.

   The issue of deciding upon the rendering of a character set based on
   the language tag is not addressed in this memo; however, it is
   thought impossible to make such a decision correctly for all cases
   unless means of switching language in the middle of a text are
   defined (for example, a rendering engine that decides font based on
   Japanese or Chinese language will fail to work when a mixed
   Japanese-Chinese text is encountered)






Alvestrand                                                      [Page 8]

RFC 1766                      Language Tag                    March 1995


8.  Acknowledgements

   This document has benefited from innumberable rounds of review and
   comments in various fora of the IETF and the Internet working groups.
   As so, any list of contributors is bound to be incomplete; please
   regard the following as only a selection from the group of people who
   have contributed to make this document what it is today.

   In alphabetical order:

   Tim Berners-Lee, Nathaniel Borenstein, Jim Conklin, Dave Crocker,
   Ned Freed, Tim Goodwin, Olle Jarnefors, John Klensin, Keith Moore,
   Masataka Ohta, Keld Jorn Simonsen, Rhys Weatherley, and many, many
   others.

9.  Author's Address

   Harald Tveit Alvestrand
   UNINETT
   Pb. 6883 Elgeseter
   N-7002 TRONDHEIM
   NORWAY

   EMail: [e-mail]
   Phone: [phone]

10.  References

    [ISO 639]
         ISO 639:1988 (E/F) - Code for the representation of names of
         languages - The International Organization for
         Standardization, 1st edition, 1988 17 pages Prepared by
         ISO/TC 37 - Terminology (principles and coordination).

    [ISO 3166]
         ISO 3166:1988 (E/F) - Codes for the representation of names
         of countries - The International Organization for
         Standardization, 3rd edition, 1988-08-15.

    [RFC 1521]
         Borenstein, N., and N. Freed, "MIME Part One: Mechanisms for
         Specifying and Describing the Format of Internet Message
         Bodies", RFC 1521, Bellcore, Innosoft, September 1993.

    [RFC 1327]
         Kille, S., "Mapping between X.400(1988) / ISO 10021 and RFC
         822", RFC 1327, University College London, May 1992.




Alvestrand                                                      [Page 9]