re: prefer-language tag

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

Agreed. This is  basically a nonstarter in the email world, and even if
there were enough buy-in to get it approved there's no way it could
make it through the standards process.

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

One way of doing this is to carry the language preference along as part of the
envelope. LANG would then appear as a parameter to MAIL FROM.

This solves the problem where an MTA is dealing with messages from widely
varying origins with different language preferences.

The tricky part is that adding such tags to messages in transit probably needs
to be possible. Consider, for example, the case of a site with a large
installed base of different user agents. By its nature the site has a strong
preference for a particular language or set of languages. But the individual
user agents cannot be upgraded to add this information to the messages they
send. The site's server, however, can be. So the right solution is to have
the server add a LANG tag to every message coming from a local user that
doesn't already have one.

This all sounds simple enough, but it is also easy to see how such a facility
could be abused. The definition of such a facility needs to be flexible enough
to allow certain forms of tag addition but not so flexible that it lets bad
things happen.

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

And this, of course, is the other side of the problem. Mark is right; it is
a complex issue.

There are also charset issues to be reckoned with. SMTP responses routinely
get embedded in nondelivery (and delivery) notifications. This then means
that special handling is required.

The availability and acceptable of UTF-8 does help a lot, and is certainly
something we've only had available of late, but there are still issues. A
specification describing support of a LANG extension to SMTP will also
have to carefully describe how to deal with UTF-8 text when generating
[N]DNs.

> The fact that it hasn't been settled yet should suggest that there is not an
> easy solution.

Agreed.

				Ned

--Boundary (ID uEbHHWxWEwCKT9wM3evJ5w)

Received on Wednesday, 18 February 1998 12:22:41 UTC