re: prefer-language tag

At 21:13 98-02-17 -0800, you wrote:
>I have read draft-blanchet-preflang-00.txt.
>

Thanks for reading it, and thanks for your contructive comments.

>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.
>

Well, I was thinking of registering this new header as per registry
proposal in the drums wg: draft-ietf-drums-MHRegistry-03.txt .  So where is
the violation in this context?


>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.
>


The intent is to get this information (user preferred language) up to the
end point, because in each transit (for example mail relays in the SMTP
context), one of them can send back a message about the delivery of the
message, or other administrativia,...   (This discussion is valid for
email, but can be different for other protocols).  We need to forward that
information up to the end point.  Going through SMTP negotiation means that
if one server is not able to understand the new lang command, then this
information is lost up to the end.


>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".

The intent was to make a standard tag, and then apply it to the various
protocols, where the way it is done can be different. So, this draft was
not only for SMTP.

>
>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.
>

Well, I don't think this is an issue in my draft: yes this problem is
difficult (technically speaking), but it has been discussed in RFC 1766,
which my draft is refering too. I think this dialect issue is more related
to RFC 1766 than my draft. 

>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)

Yeap you are right.  I had some ideas on this but I prefer to submit the
basic idea before going into details.  There is always place for newer
drafts and contributors! Would you contribute to this work?


> 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.  

Can you point me on the drafts or proposals?

>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.
>
I know this is not an easy solution, and yes my draft is not intended to be
the solution for all.  It is a proposal. I would be willing to work on this
issue with any other proposal.

Regards, Marc.



-----------------------------------------------------------
Marc Blanchet			| Marc.Blanchet@viagenie.qc.ca
Viagenie inc.			| http://www.viagenie.qc.ca
3107 des hotels		| tel.: 418-656-9254 
Ste-Foy, Quebec		| fax.: 418-656-0183
Canada, G1W 4W5		| radio: VA2-JAZ
------------------------------------------------------------
pgp: 57 86 A6 83 D3 A8 58 32 F7 0A BB BD 5F B2 4B A7
------------------------------------------------------------
Auteur du livre TCP/IP Simplifié, Editions Logiques, 1997
------------------------------------------------------------

--Boundary (ID uEbHHWxWEwCKT9wM3evJ5w)

Received on Wednesday, 18 February 1998 14:09:27 UTC