- From: Koen Holtman <koen@win.tue.nl>
- Date: Thu, 9 Jan 1997 19:11:07 +0100 (MET)
- To: "Martin J. Duerst" <mduerst@ifi.unizh.ch>
- Cc: masinter@parc.xerox.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Martin J. Duerst: > [...] >I'll take these issues first. For Accept-Language, RFC2068 says >explicitly what q=0 means: [...] >This clearly means that q=0 means NOT ACCEPTABLE. Whether this >has to be interpreted as being a special case for Accept-Language, >or an example of a general principle, is beyond my knowledge >of the RFC and its creation process. The q=0 for Accept-Language is to be interpreted as an example of a general principle. Earlier versions of the document (the 00 and 01 internet drafts I believe) had a section which said that the server should give a `none acceptable' error message if it only had variants with q=0. [...] >To give an example, we have the following situation: > >Accept-Language Document Match? >language-range language-tag > >en en YES >en-us en-us YES >en en-us YES >en-us en NO?! >en-us en-uk NO?! > > >The idea is that Accept-Language defines language-ranges, >whereas the documents will be tagged exactly. I don't know >exactly how the group arrived at this asymmetry, If I recall correctly, en-us does not match en-uk because it need not in general be true that two languages tagged a-x and a-y are mutually comprehensible. I don't know if there are actual examples of such tags a-x and a-y in the registry now, but there could be in future, and we wanted HTTP to be prepared for that. >Regards, Martin. Koen.
Received on Thursday, 9 January 1997 10:14:10 UTC