- From: Martin J. Duerst <mduerst@ifi.unizh.ch>
- Date: Mon, 20 Jan 1997 13:47:47 +0100 (MET)
- To: Koen Holtman <koen@win.tue.nl>
- Cc: Larry Masinter <masinter@parc.xerox.com>, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
On Tue, 14 Jan 1997, Koen Holtman wrote:
> Martin J. Duerst:
> >
> >[...] Anyway, this still
> >leaves the case
> >
> >> >en-us en NO?!
>
> The same principle applies here: it need not be in general true that xx is
> mutually understandable with xx-aa. Even the prefix matching that _is_
> allowed by 1.1:
>
> Accept-L Content-L
> en en-us
>
> is skating thin ice: if a user agent sends xx, it has to know if there are
> any languages tagged xx-aa that are not mutually understandable with xx, so
> that it can send `Accept-Language: xx, xx-aa;q=0' if this is the case.
Saying "Even ... allowed by 1.1" seems to assume that prefix matching might
work better with
Accept-L Content-L
en en-us
than with
en-us en
I don't see any general arguments that could support this. There is
an asymmetry in 1.1 that is not justified.
> Note that the situation is not that bad in practice with the RFC1766
> language tags. But additional language tagging schemes, with less nice
> matching properties, could be defined in future, and we wanted HTTP to be
> ready for that.
Certainly. But as for practice, it will mostly be that either a
given prefix implies that all its extensions are mutually intelligible,
(e.g. the "en" example and many others) or that it implies that most of
its extensions are not mutually intelligible (e.g. the x- prefix for
experimental, and other generic prefixes that may come into use
in the future). So we can rather safely assume that while both
user preferences and document tags will contain "en", they won't
contain "x". Therefore, prefix matching including the two cases
above still work.
Regards, Martin.
Received on Monday, 20 January 1997 05:53:49 UTC