W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1996

(ACCEPT*) Consensus

From: Koen Holtman <koen@win.tue.nl>
Date: Sat, 13 Apr 1996 20:22:09 +0200 (MET DST)
Message-Id: <199604131822.UAA01749@wsooti04.win.tue.nl>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Cc: Koen Holtman <koen@win.tue.nl>

I am pleased to announce that I believe there to be consensus on the
text for the sections:

  3.10 Language Tags 
  (9. Status Code Definitions) 416 Not Acceptable
  10.1 Accept 
  10.2 Accept-Charset 
  10.3 Accept-Encoding 
  10.4 Accept-Language 
  14.7 Privacy issues connected to Accept headers

The only open issue connected to these sections is the issue on
whether the specification should use the term `charset' or `character
set'.

This closes the following issues on the HTTP/1.1 issues list:

 QMXB NOTACCEPT LANGUAGETAGS ACCEPT ACCEPTCHARSET ACCEPTENCODING
 ACCEPTLANGUAGE BOTH ACCEPT-PRIVACY

If you believe that there is no consensus on one of these issues,
please announce this as soon as possible.

Below is the consensus text.  The change bars are computer-generated,
and indicate changes with respect to the text posted on Friday, April
5.  Changed words behind the changebars are typeset in capital
letters.

See the end of this message for diffs between
draft-ietf-http-v11-spec-01.txt and the new consensus text.

=====================================================================

3. Protocol Parameters 

  3.10 Language Tags 

   [##Note: I moved the language tag matching discussion that used to
   be in this Section to Section 10.4 (Accept-Language).  Some other
   minor edits were made.##]

  A language tag identifies a natural language spoken, written, or
  otherwise conveyed by human beings for communication of information to
| other human beings. Computer languages are explicitly excluded. HTTP
  uses language tags within the Accept-Language and Content-Language
  fields.

  The syntax and registry of HTTP language tags is the same as that
  defined by RFC 1766 [1]. In summary, a language tag is composed of 1
  or more parts: A primary language tag and a possibly empty series of
  subtags:

          language-tag  = primary-tag *( "-" subtag )

          primary-tag   = 1*8ALPHA
          subtag        = 1*8ALPHA

  Whitespace is not allowed within the tag and all tags are
  case-insensitive.  The namespace of language tags is administered by
  the IANA. Example tags include:

         en, en-US, en-cockney, i-cherokee, x-pig-latin

  where any two-letter primary-tag is an ISO 639 language abbreviation
  and any two-letter initial subtag is an ISO 3166 country code.


9. Status Code Definitions

| 416 Not Acceptable

|  [##Note: The previous version had the 413, not 416 above, but
|  413 has since been taken by another new error type.##]

|  [##Note: the new 416 is similar to the 406 response code in the old
   draft.  406 cannot be used for content negotiation compatibility
   reasons##]
|

  The resource identified by the Request-URI and Host request header
  (present if the request-URI is not an absoluteURI) is only capable of
  generating response entities which have content characteristics not
  acceptable according to the accept headers sent in the request.

  HTTP/1.1 servers are allowed to return responses which are not
  acceptable according to the accept headers sent in the request. In
| some cases, this may even be preferable over sending a 416
  response. User agents are encouraged to inspect the headers of an
| incoming response to determine if it is acceptable. If THE RESPONSE is
| not ACCEPTABLE, user agents should interrupt the receipt of the
| response if doing so would save network resources.  If it IS unknown
  whether an incoming response would be acceptable, a user agent should
  temporarily stop receipt of more data and query the user for a
  decision on further actions.

   [## Note: the paragraph above could be moved to a more convenient
   location in the 1.1 document if the editor finds one.  Note that
   the above rule was discussed extensively on the content negotiation
   mailing list.  A short summary of the main reason behind this rule:
   20 line HTTP servers.##]


10 Header Field Definitions 

  10.1 Accept 

  The Accept request-header field can be used to specify certain media
  types which are acceptable for the response.  Accept headers can be
  used to indicate that the request is specifically limited to a small
  set of desired types, as in the case of a request for an in-line
  image.

  The field may be folded onto several lines and more than one
  occurrence of the field is allowed, with the semantics being the same
  as if all the entries had been in one field value.

         Accept         = "Accept" ":" #(
|                              media-range
                               [ ( ":" | ";" ) 
                                 range-parameter 
                                 *( ";" range-parameter ) ]
|                             | extension-token )


         media-range    = ( "*/*"
                          | ( type "/" "*" )
                          | ( type "/" subtype )
                          ) *( ";" parameter )

         range-parameter = ( "q" "=" qvalue ) 
                         | extension-range-parameter
         extension-range-parameter = ( token "=" token )
         extension-token = token 

  The asterisk "*" character is used to group media types into ranges,
  with "*/*" indicating all media types and "type/*" indicating all
  subtypes of that type. The range-parameter q is used to indicate the
  media type quality factor for the range, which represents the user's
  preference for that range of media types. The default value is q=1. In
  Accept headers generated by HTTP/1.1 clients, the character separating
  media-ranges from range-parameters should be a ":". HTTP/1.1 servers
  should be tolerant of use of the ";" separator by HTTP/1.0 clients.

  The example 

|        Accept: audio/*: q=0.2, audio/basic

  should be interpreted as "I prefer audio/basic, but send me any audio
  type if it is the best available after an 80% mark-down in quality."

  If no Accept header is present, then it is assumed that the client
  accepts all media types. If Accept headers are present, and if the
| SERVER cannot send a response which is acceptable according to the
  Accept headers, then the server should send an error response with the
| 416 (not acceptable) status code, though the sending of an
| UNACCEPTABLE response is also allowed.

  A more elaborate example is 

|        Accept: text/plain: q=0.5, text/html,
|                text/x-dvi: q=0.8, text/x-c

  Verbally, this would be interpreted as "text/html and text/x-c are the
  preferred media types, but if they do not exist, then send the
  text/x-dvi entity, and if that does not exist, send the text/plain
  entity."

  Media ranges can be overridden by more specific media ranges or
  specific media types. If more than one media range applies to a given
  type, the most specific reference has precedence. For example,

         Accept: text/*, text/html, text/html;level=1, */*

  have the following precedence: 

         1) text/html;level=1
         2) text/html
         3) text/*
         4) */*

  The media type quality factor associated with a given type is
  determined by finding the media range with the highest precedence
  which matches that type. For example,

         Accept: text/*:q=0.3, text/html:q=0.7, text/html;level=1,
                 */*:q=0.5

| would cause the following VALUES to be associated: 

         text/html;level=1                          = 1
         text/html                                  = 0.7
         text/plain                                 = 0.3
         image/jpeg                                 = 0.5
         text/html;level=3                          = 0.7

        Note: A user agent may be provided with a default set of
        quality values for certain media ranges. However, unless
        the user agent is a closed system which cannot interact
        with other rendering agents, this default set should be
        configurable by the user. 


  10.2 Accept-Charset 

  The Accept-Charset request-header field can be used to indicate what
  character sets are acceptable for the response. This field allows
  clients capable of understanding more comprehensive or special-purpose
  character sets to signal that capability to a server which is capable
  of representing documents in those character sets. The ISO-8859-1
  character set can be assumed to be acceptable to all user agents.

         Accept-Charset = "Accept-Charset" ":"
                   1#( charset [ ";" "q" "=" qvalue ] )

  Character set values are described in Section 3.4. Each charset may be
  given an associated quality value which represents the user's
  preference for that charset. The default value is q=1. An example is

         Accept-Charset: iso-8859-5, unicode-1-1;q=0.8

  If no Accept-Charset header is present, the default is that any
  character set is acceptable. If an Accept-Charset header is present,
| and if the SERVER cannot send a response which is acceptable according
  to the Accept-Charset header, then the server should send an error
| response with the 416 (not acceptable) status code, though the sending
| of an UNACCEPTABLE response is also allowed.

  10.3 Accept-Encoding 

  The Accept-Encoding request-header field is similar to Accept, but
  restricts the content-coding values (Section 3.5) which are acceptable
  in the response.

         Accept-Encoding         = "Accept-Encoding" ":" 
                                   #( content-coding )

  An example of its use is 

         Accept-Encoding: compress, gzip

  If no Accept-Encoding header is present in a request, the server may
  assume that the client will accept any content coding. If an
| Accept-Encoding header is present, and if the SERVER cannot send a
  response which is acceptable according to the Accept-Encoding header,
| then the server should send an error response with the 416 (not
  acceptable) status code.


  10.4 Accept-Language 

  The Accept-Language request-header field is similar to Accept, but
  restricts the set of natural languages that are preferred as a
  response to the request.

         Accept-Language         = "Accept-Language" ":"
                                   1#( language-range [ ";" "q" "=" qvalue ] )

          language-range     = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) 
                         | "*" )

  Each language-range may be given an associated quality value which
  represents an estimate of the user's comprehension of the languages
  specified by that range. The quality value defaults to "q=1" (100%
  comprehension). For example,

         Accept-Language: da, en-gb;q=0.8, en;q=0.7

  would mean: "I prefer Danish, but will accept British English (with
  80% comprehension) and other types of English (with 70%
  comprehension)."

  A language-range matches a language-tag if it exactly equals the tag,
| or if it EXACTLY EQUALS a prefix (A SUB-SEQUENCE STARTING AT THE FIRST
| CHARACTER) of the tag such that the first tag character following the
  prefix is "-".  The special range "*", if present in the
  Accept-Language field, matches every tag not matched by any other
  ranges present in the Accept-Language field.

       Note: This use of a prefix matching rule does not imply that
       language tags are assigned to languages in such a way that it is
       always true that if a user understands a language with a certain
       tag, then this user will also understand all languages with tags
       for which this tag is a prefix. The prefix rule simply allows the
       use of prefix tags if this is the case.

  The language quality factor assigned to a language-tag by the
  Accept-Language field is the quality value of the longest
  language-range in the field that matches the language-tag. If no
  language-range in the field matches the tag, the language quality
  factor assigned is 0. If no Accept-Language header is present in a
  request, the server should assume that all languages are equally
| acceptable. If an Accept-Language header is present, THEN ALL
| LANGUAGES WHICH ARE ASSIGNED A QUALITY FACTOR GREATER THAN 0 are
| ACCEPTABLE. IF the SERVER cannot GENERATE a response FOR an audience
| capable of understanding at least one ACCEPTABLE LANGUAGE, it CAN send
  a response that uses one or more un-accepted languages.

  It may be contrary to be privacy expectations of the user to send an
  Accept-Language header with the complete linguistic preferences of the
  user in every request. For a discussion of this issue, see Section
| 14.7.

        Note: As intelligibility is highly dependent on the individual
        user, it is recommended that client applications make the
        choice of linguistic preference available to the user. If the
        choice is not made available, then the Accept-Language
        header field must not be given in the request. 


14 Security Considerations

| 14.7 Privacy issues connected to Accept headers

   [## Note: I believe someone else (Brian Behlendorf?) was also
   writing text about this, so I only include some concerns about
   Accept-Language important from a European viewpoint.  The concern
   of user tracking through Accept headers is not covered below, see
   Section 6.2 of draft-holtman for a discussion of this concern##]

|  [## Note: update in the above note: Brian Behlendorf does not seem
|  to be responding, so I will take over writing text about user
|  tracking.##]

  Accept request headers can reveal information about the user to all
  servers which are accessed. The Accept-Language header in particular
  can reveal information the user would consider to be of a private
  nature, because the understanding of particular languages is often
  strongly correlated to the membership of a particular ethnic
  group. User agents which offer the option to configure the contents of
  an Accept-Language header to be sent in every request are strongly
  encouraged to let the configuration process include a message which
  makes the user aware of the loss of privacy involved.

  An approach that limits the loss of privacy would be for a user agent
  to omit the sending of Accept-Language headers by default, and to ask
| the user whether it should start sending Accept-Language headers to a
| server if it detects, by looking for any Vary or Alternates response
  headers generated by the server, that such sending could improve the
  quality of service.

=====================================================================


Below is a diff listing between draft-ietf-http-v11-spec-01.txt and
the new consensus text.

Lines preceded by - were in draft-ietf-http-v11-spec-01.txt.
Lines preceded by + are the new consensus wording.

The diff listing below was computer generated and edited by hand to
improve readability.

=====================================================================

 3. Protocol Parameters 

 3.10 Language Tags 

 A language tag identifies a natural language spoken, written, or
 otherwise conveyed by human beings for communication of information to
 other human beings. Computer languages are explicitly excluded.  HTTP
-uses language tags within the Accept-Language, Content-Language, and
-URI-header fields.
+uses language tags within the Accept-Language and Content-Language
+fields.

 The syntax and registry of HTTP language tags is the same as that
 defined by RFC 1766 [1]. In summary, a language tag is composed of 1
 or more parts: A primary language tag and a possibly empty series of
 subtags:

      language-tag  = primary-tag *( "-" subtag )

      primary-tag   = 1*8ALPHA
      subtag        = 1*8ALPHA

 Whitespace is not allowed within the tag and all tags are
 case-insensitive. The namespace of language tags is administered by
 the IANA. Example tags include:

     en, en-US, en-cockney, i-cherokee, x-pig-latin

 where any two-letter primary-tag is an ISO 639 language abbreviation
 and any two-letter initial subtag is an ISO 3166 country code.

-In the context of the Accept-Language header (Section 10.4), a
-language tag is not to be interpreted as a single token, as per RFC
-1766, but as a hierarchy. A server should consider that it has a match
-when a language tag received in an Accept-Language header matches the
-initial portion of the language tag of a document. An exact match
-should be preferred. This interpretation allows a browser to send, for
-example:
-
-    Accept-Language: en-US, en; ql=0.95
-
-when the intent is to access, in order of preference, documents in
-US-English ("en-US"), 'plain' or 'international' English ("en"), and
-any other variant of English (initial "en-").
-
-    Note: Using the language tag as a hierarchy does not imply 
-    that all languages with a common prefix will be understood 
-    by those fluent in one or more of those languages; it simply 
-    allows the user to request this commonality when it is true 
-    for that user.

 9.  Status Code Definitions

-406 None Acceptable
-
-The server has found a resource matching the Request-URI, but not one
-that satisfies the conditions identified by the Accept and
-Accept-Encoding request headers. Unless it was a HEAD request, the
-response should include an entity containing a list of resource
-characteristics and locations from which the user or user agent can
-choose the one most appropriate. The entity format is specified by the
-media type given in the Content-Type header field. Depending upon the
-format and the capabilities of the user agent, selection of the most
-appropriate choice may be performed automatically.

+416 Not Acceptable
+ 
+The resource identified by the Request-URI and Host request header
+(present if the request-URI is not an absoluteURI) is only capable of
+generating response entities which have content characteristics not
+acceptable according to the accept headers sent in the request.
+
+HTTP/1.1 servers are allowed to return responses which are not
+acceptable according to the accept headers sent in the request. In
+some cases, this may even be preferable over sending a 416
+response. User agents are encouraged to inspect the headers of an
+incoming response to determine if it is acceptable. If the response is
+not acceptable, user agents should interrupt the receipt of the
+response if doing so would save network resources.  If it is unknown
+whether an incoming response would be acceptable, a user agent should
+temporarily stop receipt of more data and query the user for a
+decision on further actions.

 10.  Header Field Definitions


 10.1  Accept

-The Accept response-header field can be used to indicate a list of
-media ranges which are acceptable as a response to the request. The
-asterisk "*" character is used to group media types into ranges, with
-"*/*" indicating all media types and "type/*" indicating all subtypes
-of that type. The set of ranges given by the client should represent
-what types are acceptable given the context of the request. The Accept
-field should only be used when the request is specifically limited to
-a set of desired types, as in the case of a request for an in-line
-image, or to indicate qualitative preferences for specific media
-types.

+The Accept request-header field can be used to specify certain media
+types which are acceptable for the response.  Accept headers can be
+used to indicate that the request is specifically limited to a small
+set of desired types, as in the case of a request for an in-line
+image.

 The field may be folded onto several lines and more than one
 occurrence of the field is allowed, with the semantics being the same
 as if all the entries had been in one field value.

     Accept         = "Accept" ":" #(
                      media-range

-                     [ ";" "q" "=" qvalue ]
-                     [ ";" "mxb" "=" 1*DIGIT ] )

+                     [ ( ":" | ";" ) 
+                     range-parameter 
+                     *( ";" range-parameter ) ]
+                     | extension-token )


     media-range    = ( "*/*"
                    |   ( type "/" "*" )
                    |   ( type "/" subtype )
                      ) *( ";" parameter )

+       range-parameter = ( "q" "=" qvalue ) 
+                       | extension-range-parameter
+       extension-range-parameter = ( token "=" token )
+       extension-token = token 
+

-The parameter q is used to indicate the quality factor, which
-represents the user's preference for that range of media types. The
-parameter mxb gives the maximum acceptable size of the Entity-Body, in
-decimal number of octets, for that range of media types.  Section 12
-describes the content negotiation algorithm which makes use of these
-values. The default values are: q=1 and mxb=undefined (i.e.,
-infinity).

+The asterisk "*" character is used to group media types into ranges,
+with "*/*" indicating all media types and "type/*" indicating all
+subtypes of that type. The range-parameter q is used to indicate the
+media type quality factor for the range, which represents the user's
+preference for that range of media types. The default value is q=1. In
+Accept headers generated by HTTP/1.1 clients, the character separating
+media-ranges from range-parameters should be a ":". HTTP/1.1 servers
+should be tolerant of use of the ";" separator by HTTP/1.0 clients.

 The example

-       Accept: audio/*; q=0.2, audio/basic
+       Accept: audio/*: q=0.2, audio/basic

 should be interpreted as "I prefer audio/basic, but send me any audio
 type if it is the best available after an 80% mark-down in quality."

-If no Accept header is present, then it is assumed that the client
-accepts all media types with quality factor 1. This is equivalent to
-the client sending the following accept header field:
-
-    Accept: */*; q=1
-
-or
-
-    Accept: */*
-
-If a single Accept header is provided and it contains no field value,
-then the server must interpret it as a request to not perform any
-preemptive content negotiation (Section 12) and instead return a 406
-(none acceptable) response if there are variants available for the
-Request-URI.

+If no Accept header is present, then it is assumed that the client
+accepts all media types. If Accept headers are present, and if the
+server cannot send a response which is acceptable according to the
+Accept headers, then the server should send an error response with the
+416 (not acceptable) status code, though the sending of an
+unacceptable response is also allowed.

 A more elaborate example is

-    Accept: text/plain; q=0.5, text/html,
-            text/x-dvi; q=0.8; mxb=100000, text/x-c
+    Accept: text/plain: q=0.5, text/html,
+            text/x-dvi: q=0.8, text/x-c

 Verbally, this would be interpreted as "text/html and text/x-c are the
 preferred media types, but if they do not exist, then send the
-text/x-dvi entity if it is less than 100000 bytes, otherwise send the
-text/plain entity."
+text/x-dvi entity, and if that does not exist, send the text/plain
+entity."

 Media ranges can be overridden by more specific media ranges or
 specific media types. If more than one media range applies to a given
 type, the most specific reference has precedence. For example,

-    Accept: text/*, text/html, text/html;version=2.0, */*
+    Accept: text/*, text/html, text/html;level=1, */*

 have the following precedence:

-    1) text/html;version=2.0
+    1) text/html;level=1
     2) text/html
     3) text/*
     4) */*

-The quality value associated with a given type is determined by
-finding the media range with the highest precedence which matches that
-type. For example,
+The media type quality factor associated with a given type is
+determined by finding the media range with the highest precedence
+which matches that type. For example,

-    Accept: text/*;q=0.3, text/html;q=0.7, text/html;version=2.0,
-            */*;q=0.5
+    Accept: text/*:q=0.3, text/html:q=0.7, text/html;level=1,
+            */*:q=0.5

 would cause the following values to be associated:

-    text/html;version=2.0                      = 1
+    text/html;level=1                          = 1
     text/html                                  = 0.7
     text/plain                                 = 0.3
     image/jpeg                                 = 0.5
     text/html;level=3                          = 0.7

-It must be emphasized that the Accept field should only be used when
-it is necessary to restrict the response media types to a subset of
-those possible or when the user has been permitted to specify
-qualitative values for ranges of media types. If no quality factors
-have been set by the user, and the context of the request is such that
-the user agent is capable of saving the entity to a file if the
-received media type is unknown, then the only appropriate value for
-Accept is "*/*", or an empty value if the user desires reactive
-negotiation.
-
     Note: A user agent may be provided with a default set of 
     quality values for certain media ranges. However, unless the 
     user agent is a closed system which cannot interact with 
     other rendering agents, this default set should be 
     configurable by the user.


 10.2  Accept-Charset

 The Accept-Charset request-header field can be used to indicate what
 character sets are acceptable for the response. This field allows
 clients capable of understanding more comprehensive or special-purpose
 character sets to signal that capability to a server which is capable
-of representing documents in those character sets. The US-ASCII
+of representing documents in those character sets. The ISO-8859-1
 character set can be assumed to be acceptable to all user agents.

-    Accept-Charset = "Accept-Charset" ":" 1#charset

+       Accept-Charset = "Accept-Charset" ":"
+                 1#( charset [ ";" "q" "=" qvalue ] )


-Character set values are described in Section 3.4. An example is
- 
-    Accept-Charset: iso-8859-1, unicode-1-1
-
-If no Accept-Charset field is given, the default is that any character
-set is acceptable. If the Accept-Charset field is given and the
-requested resource is not available in one of the listed character
-sets, then the server should respond with the 406 (none acceptable)
-status code.

+Character set values are described in Section 3.4. Each charset may be
+given an associated quality value which represents the user's
+preference for that charset. The default value is q=1. An example is
+
+       Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
+   
+If no Accept-Charset header is present, the default is that any
+character set is acceptable. If an Accept-Charset header is present,
+and if the server cannot send a response which is acceptable according
+to the Accept-Charset header, then the server should send an error
+response with the 416 (not acceptable) status code, though the sending
+of an unacceptable response is also allowed.

 10.3  Accept-Encoding

 The Accept-Encoding request-header field is similar to Accept, but
 restricts the content-coding values (Section 3.5) which are acceptable
 in the response.

     Accept-Encoding         = "Accept-Encoding" ":" 
                               #( content-coding )

 An example of its use is

     Accept-Encoding: compress, gzip

-If no Accept-Encoding field is present in a request, the server may
+If no Accept-Encoding header is present in a request, the server may
 assume that the client will accept any content coding. If an
-Accept-Encoding field is present, but contains an empty field value,
-then the user agent is refusing to accept any content coding.
+Accept-Encoding header is present, and if the server cannot send a
+response which is acceptable according to the Accept-Encoding header,
+then the server should send an error response with the 416 (not
+acceptable) status code.


 10.4  Accept-Language

 The Accept-Language request-header field is similar to Accept, but
 restricts the set of natural languages that are preferred as a
 response to the request.

     Accept-Language = "Accept-Language" ":"
-                      1#( language-tag [ ";" "q" "=" qvalue ] )
+                      1#( language-range [ ";" "q" "=" qvalue ] )

+        language-range     = ( ( 1*8ALPHA *( "-" 1*8ALPHA ) ) 
+                             | "*" )

-The language-tag is described in Section 3.10. Each language may be
-given an associated quality value which represents an estimate of the
-user's comprehension of that language. The quality value defaults to
-"q=1" (100% comprehension) for listed languages. This value may be
-used in the server's content negotiation algorithm (Section 12). For
-example,
- 
-    Accept-Language: da, en-gb;q=0.8, de;q=0.55
-
-would mean: "I prefer Danish, but will accept British English (with
-80% comprehension) or German (with a 55% comprehension)."

+Each language-range may be given an associated quality value which
+represents an estimate of the user's comprehension of the languages
+specified by that range. The quality value defaults to "q=1" (100%
+comprehension). For example,

+       Accept-Language: da, en-gb;q=0.8, en;q=0.7

+would mean: "I prefer Danish, but will accept British English (with
+80% comprehension) and other types of English (with 70%
+comprehension)."

+A language-range matches a language-tag if it exactly equals the tag,
+or if it exactly equals a prefix (a sub-sequence starting at the first
+character) of the tag such that the first tag character following the
+prefix is "-".  The special range "*", if present in the
+Accept-Language field, matches every tag not matched by any other
+ranges present in the Accept-Language field.
+
+     Note: This use of a prefix matching rule does not imply that
+     language tags are assigned to languages in such a way that it is
+     always true that if a user understands a language with a certain
+     tag, then this user will also understand all languages with tags
+     for which this tag is a prefix. The prefix rule simply allows the
+     use of prefix tags if this is the case.

-If the server cannot fulfill the request with one or more of the
-languages given, or if the languages only represent a subset of a
-multi-linguistic Entity-Body, it is acceptable to serve the request in
-an unspecified language. This is equivalent to assigning a quality
-value of "q=0.001" to any unlisted language.
-
-If no Accept-Language header is present in the request, the server
-should assume that all languages are equally acceptable.

+The language quality factor assigned to a language-tag by the
+Accept-Language field is the quality value of the longest
+language-range in the field that matches the language-tag. If no
+language-range in the field matches the tag, the language quality
+factor assigned is 0. If no Accept-Language header is present in a
+request, the server should assume that all languages are equally
+acceptable. If an Accept-Language header is present, then all
+languages which are assigned a quality factor greater than 0 are
+acceptable. If the server cannot generate a response for an audience
+capable of understanding at least one acceptable language, it can send
+a response that uses one or more un-accepted languages.
+
+It may be contrary to be privacy expectations of the user to send an
+Accept-Language header with the complete linguistic preferences of the
+user in every request. For a discussion of this issue, see Section
+14.7.
+


     Note: As intelligibility is highly dependent on the 
     individual user, it is recommended that client applications 
     make the choice of linguistic preference available to the 
     user. If the choice is not made available, then the 
     Accept-Language header field must not be given in the 
     request.

+14 Security Considerations
+
+14.7 Privacy issues connected to Accept headers
+
+Accept request headers can reveal information about the user to all
+servers which are accessed. The Accept-Language header in particular
+can reveal information the user would consider to be of a private
+nature, because the understanding of particular languages is often
+strongly correlated to the membership of a particular ethnic
+group. User agents which offer the option to configure the contents of
+an Accept-Language header to be sent in every request are strongly
+encouraged to let the configuration process include a message which
+makes the user aware of the loss of privacy involved.
+
+An approach that limits the loss of privacy would be for a user agent
+to omit the sending of Accept-Language headers by default, and to ask
+the user whether it should start sending Accept-Language headers to a
+server if it detects, by looking for any Vary or Alternates response
+headers generated by the server, that such sending could improve the
+quality of service.

[end of text.]
Received on Saturday, 13 April 1996 11:28:39 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:50 EDT