-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Ernest,

Am Montag, 17. November 2003 17:49 schrieb Ernest Cline:
> > Obviously you never had a 406 response yet.
> > As soon as the negotiation is only using the language dimension,
>
> requesting
>
> > doc.de.xhtml with an Accept-Language: en header is okay. But as soon as
> > content negotiation gets another dimension and is used for more than just
>
> the
>
> > language such negotiating requests will result in 406 responses.
>
> Requesting
>
> > doc.de for choosing between doc.de.xhtml as application/xhtml+xml and
> > doc.de.html as text/html with Accept: application/xhtml+xml and
> > Accept-Language: en gives a 406 response.
> >
> > That's why I want @hreflang to override or extend the user agent's
>
> default
>
> > Accept-Language header.
>
> Well of course.  Given what you've described, here is what should happen
> in such a case.
>
> 1) The UA sends the request with:
>    Accept: application/xhtml+xml
>    Accept-Language: en
> 2) The server sends back the 406 response which ideally should contain
>     (if I'm interpreting RFC 2616 correctly, which I may not):
>    Accept: application/xhtml+xml, text/html
>    Accept-Language: de
> 3) The user agent decides whether to request a German language
>    version of the resource.  Perhaps the user agent informs the user
>    and gets his input  Perhaps the user agent has a backup set of
>    accept headers it uses when its initial
That's what currently happens.
But it can be improved.
If the user knows that a link she follows is a link to a German page, sending 
"Accept-Language: en" makes no sense because that gives de a quality of zero 
and will result in a totally superflous 406 response.
I think now I know why the HTTP RFC says "should result in a 406 response" in 
the sections about Accept and Accept-Encoding but not Accept-Language.
Of course a better interpretation of the LanguagePriority forcing the server 
to send a certain language would improve the nasty 406 situation about 
servers, but on the other hand, doesn't solve the main problem:
Deliver the language the user requested right away.


> (Alternatively, the UA first sends an OPTIONS request to determine
> what the document supports, and then decides what to request.  This
> has the downside of causing more traffic for the usual case, but has
> the advantage of not sending what could be a very user specific set
> of Accept headers out with every request)
Just by the way, the options request is to determine what the server supports 
for HTTP/1.1. For Content Negotiation it doesn't matter wether it's an 
OPTIONS or a HEAD request, it's important to use Negotiate: vlist to force a 
300 Multiple Choices response describing all alternates in case multiple 
choices exist.


> In any case, having an author to be able to override the user's chosen
> preference to not download the German language version strikes me
> as a bad idea.
Not to me. Imagine the user agent is configured to accept German. Now someone 
from Poland visits that person, uses his user agent and tries to use a 
negotiating website that has a Polish variant. Do you want every link to 
result in a 406 response over and over again? If the user chooses to see a 
Polish document by following a link stating so, why not send the Polish 
variant right away?

Also, I don't say the author's settings shall completely override the user's 
choice. I suggest they are combined by multiplying their q values, taking a q 
value of 0.5 as a default q value languages that haven't been configured in 
the user agent. Or may be sum them up and divide them by two. Or something 
different.

>  The user could have chosen a Accept-Language
> field of "en,de;q=0.001" or "en,*;q=0.001" to indicate that if an
> English language version of the document is not available, it should
> accept a German version.
Yes, for instance.

> One can argue that existing user agents
> do not do a good job of implement Accept headers and explaining
> their consequences, but I am convinced that giving the author
> the ability to override user settings is not desirable.
Yes, current user agents do not do a good job of implementing Accept headers.
A perfect Accept-Language would look like this (in this case of course 
specific to my preferences):
Accept-Language: de, en;q=0.9, pl;q=0.2, *;q=0.1
I don't mind these 25 extra bytes it is longer than the usual variant of 
Internet Explorer or Mozilla.

> > By the way, most servers (including Apache HTTP 1.3.x, I didn't test this
> > on 2.x yet) will not allow configuring requesting a URL doc.*.xhtml using
> > a URI ending on doc.xhtml.
>
> The specific format of the internal filename is irrelevant.
Of course it's irrelevant.

> So long as
> it has some method of deciding that the particular version of a resource
> has some particular set of characteristics.
Yes.

By the way, what I said wasn't completely true, there's RewriteURL, but it's 
not accessible on many servers for paranoia reasons.

I just wanted to add the note in case someone reads the thread and then starts 
asking questions...


Bye
- -- 
ITCQIS GmbH
Christian Wolfgang Hujer
Geschäftsführender Gesellschafter (Shareholding CEO)
Telefon: +49  (0)89  27 37 04 37
Telefax: +49  (0)89  27 37 04 39
E-Mail: Christian.Hujer@itcqis.com
WWW: http://www.itcqis.com/ 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.2-rc1-SuSE (GNU/Linux)

iD8DBQE/uQxFzu6h7O/MKZkRApVNAJ4/T3GA7liVfXcYqWj+neaBSr7AGQCg17FY
y/0ocEOZQzDsUfSJYkB2Wys=
=75uz
-----END PGP SIGNATURE-----