>
> http://info.cern.ch/hypertext/WWW/Protocols/HTTP/HTRQ_Headers.html
> still says ISOXXX under Accept-Language. I think that's where it was,
> can't reach the server to verify, darn it.
(try www0 instead of info. We'll switch them when the other
services are ready. Our first time with solaris 2 -- rough
if you were weaned on bsd)
> TimBL should make a ruling on this so we can all head in one direction:
I though I had -- in Accept-Langauge. Until you metioned using
parameters to Accept:
> Someone else pointed out Accept-Language: but I think this is the wrong
> approch. I think this information should be in the Accept: header along
> with the other client profile information. I can see the arguments for
> special casing headers for some client profile but I would opt to be
> consistent. I'll be happy either way, I just want us to make an informed
> decision.
There are a number of ways in which a documents can have variants.
One is data representation, unfortunately known in MIME as content-type.
Another orthogonal way is language. Another orthogonal way is
version. I think we should keep these things independent.
Accept -- Content-Type
Accept-Language -- Content-Language
(n/a) -- Version
Note also the URI parameters are the same
URI: http://info.cern.ch/ vary=(content-type, content-language, version)
This is an attempt to rationalise the whole variant business
and I think it is the best bet so far.
Content-Language is being discussed on the rfc822 list.
It is also more practical to be orthogonal.Language preference
is NOT related to content-type. Suppose I wanted to give the list
of image and text types I can handle, already several dozen, and
had for each to specify two or three language versions?
Can you concieve of someone wanting to specify that if it
is postscript they prefer French, but in GIFs they only want
Japanese?
The spec currently defines it as Accept-Language and
Content-Language. I'd like to keep it that way but I'm open
to argument of course as always.
Tim
> --sanders