thing(lang=no)" for equality, I will generally expect a match, while
   the word "ask(no)" is a kind of tree, and is hardly useful as a
   command verb.

4.2.  Requirement for language tagging

   Protocols that transfer text MUST provide for carrying information
   about the language of that text.

   Protocols SHOULD also provide for carrying information about the
   language of names, where appropriate.

   Note that this does NOT mean that such information must always be
   present; the requirement is that if the sender of information wishes
   to send information about the language of a text, the protocol
   provides a well-defined way to carry this information.










 
RFC 2277                     Charset Policy                 January 1998


4.3.  How to identify a language

   The RFC 1766 language tag is at the moment the most flexible tool
   available for identifying a language; protocols SHOULD use this, or
   provide clear and solid justification for doing otherwise in the
   document.

   Note also that a language is distinct from a POSIX locale; a POSIX
   locale identifies a set of cultural conventions, which may imply a
   language (the POSIX or "C" locale of course do not), while a language
   tag as described in RFC 1766 identifies only a language.

4.4.  Considerations for language negotiation

   Protocols where users have text presented to them in response to user
   actions MUST provide for support of multiple languages.

   How this is done will vary between protocols; for instance, in some
   cases, a negotiation where the client proposes a set of languages and
   the server replies with one is appropriate; in other cases, a server
   may choose to send multiple variants of a text and let the client
   pick which one to display.

   Negotiation is useful in the case where one side of the protocol
   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.





 
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