rfc2277.txt

RFC 的详细文档！

   exchange is able to present text in multiple languages to the other
   side, and the other side has a preference for one of these; the most
   common example is the text part of error responses, or Web pages that
   are available in multiple languages.

   Negotiating a language should be regarded as a permanent requirement
   of the protocol that will not go away at any time in the future.

   In many cases, it should be possible to include it as part of the
   connection establishment, together with authentication and other
   preferences negotiation.

4.5.  Default Language

   When human-readable text must be presented in a context where the
   sender has no knowledge of the recipient's language preferences (such
   as login failures or E-mailed warnings, or prior to language
   negotiation), text SHOULD be presented in Default Language.

   Default Language is assigned the tag "i-default" according to the
   procedures of RFC 1766. It is not a specific language, but rather
   identifies the condition where the language preferences of the user
   cannot be established.




Alvestrand               Best Current Practice                  [Page 5]

RFC 2277                     Charset Policy                 January 1998


   Messages in Default Language MUST be understandable by an English-
   speaking person, since English is the language which, worldwide, the
   greatest number of people will be able to get adequate help in
   interpreting when working with computers.

   Note that negotiating English is NOT the same as Default Language;
   Default Language is an emergency measure in otherwise unmanageable
   situations.

   In many cases, using only English text is reasonable; in some cases,
   the English text may be augumented by text in other languages.

5.  Locale

   The POSIX standard [POSIX] defines a concept called a "locale", which
   includes a lot of information about collating order for sorting, date
   format, currency format and so on.

   In some cases, and especially with text where the user is expected to
   do processing on the text, locale information may be usefully
   attached to the text; this would identify the sender's opinion about
   appropriate rules to follow when processing the document, which the
   recipient may choose to agree with or ignore.

   This document does not require the communication of locale
   information on all text, but encourages its inclusion when
   appropriate.

   Note that language and character set information will often be
   present as parts of a locale tag (such as no_NO.iso-8859-1; the
   language is before the underscore and the character set is after the
   dot); care must be taken to define precisely which specification of
   character set and language applies to any one text item.

   The default locale is the "POSIX" locale.

6.  Documenting internationalization decisions

   In documents that deal with internationalization issues at all, a
   synopsis of the approaches chosen for internationalization SHOULD be
   collected into a section called "Internationalization
   considerations", and placed next to the Security Considerations
   section.

   This provides an easy reference for those who are looking for advice
   on these issues when implementing the protocol.





Alvestrand               Best Current Practice                  [Page 6]

RFC 2277                     Charset Policy                 January 1998


7.  Security Considerations

   Apart from the fact that security warnings in a foreign language may
   cause inappropriate behaviour from the user, and the fact that
   multilingual systems usually have problems with consistency between
   language variants, no security considerations relevant have been
   identified.

8.  References

   [10646]
        ISO/IEC, Information Technology - Universal Multiple-Octet Coded
        Character Set (UCS) - Part 1: Architecture and Basic
        Multilingual Plane, May 1993, with amendments

   [RFC 2119]
        Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [WR] Weider, C., Preston, C., Simonsen, K., Alvestrand, H,
        Atkinson, R., Crispin, M., and P. Svanberg, "The Report of the
        IAB Character Set Workshop held 29 February - 1 March, 1996",
        RFC 2130, April 1997.

   [RFC 1958]
        Carpenter, B., "Architectural Principles of the Internet", RFC
        1958, June 1996.

   [POSIX]
        ISO/IEC 9945-2:1993 Information technology -- Portable Operating
        System Interface (POSIX) -- Part 2: Shell and Utilities

   [REG]
        Freed, N., and J. Postel, "IANA Charset Registration
        Procedures", BCP 19, RFC 2278, January 1998.

   [UTF-8]
        Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC
        2279, January 1998.

   [BCP9]
        Bradner, S., "The Internet Standards Process -- Revision 3," BCP
        9, RFC 2026, October 1996.








Alvestrand               Best Current Practice                  [Page 7]

RFC 2277                     Charset Policy                 January 1998


9.  Author's Address

   Harald Tveit Alvestrand
   UNINETT
   P.O.Box 6883 Elgeseter
   N-7002 TRONDHEIM
   NORWAY

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









































Alvestrand               Best Current Practice                  [Page 8]

RFC 2277                     Charset Policy                 January 1998


10.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
























Alvestrand               Best Current Practice                  [Page 9]