- From: Martin J. Duerst <duerst@w3.org>
- Date: Mon, 23 Feb 1998 17:50:11 +0900
- To: "John D. Burger" <john@mitre.org>, Mark Crispin <MRC@CAC.Washington.EDU>
- Cc: Marc Blanchet <Marc.Blanchet@viagenie.qc.ca>, ietf-languages@apps.ietf.org, ietf-charsets@INNOSOFT.COM
At 13:57 98/02/19 -0500, John D. Burger wrote: > Mark Crispin wrote: > > > Here's what I think the behavior should be: > > 1) If the user requests a "generic" form of the language, it will match either > > a server's "generic" form or a dialect of the server's choosing. > > 2) If the user requests a specific dialect of the language, it will match > > either that dialect on the server or a generic form offered by the server, > > but *NOT* any other dialect. > > As I understand RFC 1766, this is expressively not allowed (Section 2.1): > > There is no guaranteed relationship between languages whose tags > start out with the same series of subtags; especially, they are NOT > guraranteed [sic] to be mutually comprehensible, although this will > sometimes be the case. > > Applications should always treat language tags as a single token; the > division into main tag and subtags is an administrative mechanism, > not a navigation aid. > > In particular, I suppose there are examples involving Chinese (e.g., ZH, > ZH-TW, and ZH-CN) where the proposed behaviour is problematic. Yes indeed. A much clearer examlpe are generic prefixes. x-klingon and x-sloboddian-lower will not be mutually understandable, even though x-sloboddian-lower and x-sloboddian-upper might be. But that is not a problem. A user will as for "en", or "fr-ca, fr", or so, if he/she thinks that this is okay, and zh-tw or x-sloboddian where necessary. Regards, Martin. --Boundary (ID uEbHHWxWEwCKT9wM3evJ5w)
Received on Tuesday, 24 February 1998 22:59:32 UTC