- From: Mark Crispin <MRC@CAC.Washington.EDU>
- Date: Tue, 17 Feb 1998 21:13:35 -0800 (PST)
- To: Marc Blanchet <Marc.Blanchet@viagenie.qc.ca>
- Cc: ietf-languages@apps.ietf.org, ietf-charsets@INNOSOFT.COM
I have read draft-blanchet-preflang-00.txt. The real meat of the proposal is a single paragraph: <Begin quote> 6. Placement of the tag This new tag will be normally placed in the headers of the protocols that use them. This memo do not attend to list protocols and specify where to place them. <End quote> Unfortunately, this is also its flaw. In the SMTP or NNTP context, this constitutes a layering violation. Email message headers are a different layer (RFC 822) from SMTP. It is *extremely* unlikely that the email protocol guys are going to accept this. SMTP/NNTP are more likely to get some sort of command to set the preferred language(s), e.g. LANG ja, de, en along with some sort of mechanism so that it is carried in the mail relay case. I suspect that the use of headers in draft-blanchet-preflang-00.txt in spite of the layering violation, was as a means to avoid the mail relay requirement. The problem is, that layering violation is quite serious and you're not going to get support for putting MTA functions in the RFC 822 headers. In other protocols, "headers" is a meaningless context. Consider FTP, POP3, or IMAP; there is no "header" that is transmitted from client to server to be used to convey the "preferred language" concept. Nor is there anything like a "tag". However, a LANG command is itself a complicated issue. In particular, many people tend to confuse "setting the language" with "setting the locale". These are two entirely different things which must not be mixed. On the other hand, it is often desirable to set both language and locale, and it is equally desirable to avoid multiple RTTs in "session initialization". Another question has to do with the ability to query the list of supported languages and the interaction between requests for dialects. "FR" means "any French", but "FR-fr" and "FR-qc" refer to two different dialects. Consider, for example, a preference of "FR-qc, EN". Does this mean "prefer English over a non-Quebec dialect of French"? Or does it mean "prefer Quebec dialect of French, then any French, then English"? It becomes obvious if we see something like "FR-qc, FR, EN" or "FR-qc, EN, FR". But if we don't have an obvious intent, then we need non-ambiguous rules for its interpretation. Otherwise, we will have many unhappy users. My own belief is that "FR-qc" means *only* "Quebec dialect of French", and that if the user's intent is "Quebec dialect of French, then any dialect of French" he must use "FR-qc, FR". Similarly, "EN-US, EN" to prefer US English than any English. This is because we have, in some languages, cases where dialects are considered to be "wrong" to the point that a person would prefer a foreign language than to receive the "wrong" dialect. But, the important thing is not how this question is decided, but that there be a decision that everyone adheres to. Anyway... The bottom line is that draft-blanchet-preflang-00.txt is probably not going to be the method that is eventually adopted. It omits some important details (such as exactly how the preference rules act) and it relies upon a vague use of "headers" which is not valid in most protocol concepts. ***HOWEVER***, the concept of a client/server negotiated list of languages, in user preferred order, is the right fundamental idea. It is what several of us have been working on for some time. The fact that a particular expression of the idea has problems doesn't mean that the idea itself is wrong. The fact that it hasn't been settled yet should suggest that there is not an easy solution. --Boundary (ID uEbHHWxWEwCKT9wM3evJ5w)
Received on Thursday, 19 February 1998 02:56:44 UTC