re: prefer-language tag

[Ned Freed <Ned.Freed@INNOSOFT.COM>]

> On Wed, 18 Feb 1998 17:04:10 -0500, Marc Blanchet wrote:
> > 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?

> The problem is a "layering violation".

> RFC 822 headers are data for the end user's MUA.  It is not for the use of MTA
> protocols (such as SMTP or NNTP).

And in fact may not be available at the point where the language needs to be
known.

For example, consider the following SMTP dialogue:

   HELO innosoft.com
   2xx OK
   MAIL FROM:<ned@innosoft.com>
   2xx OK
   RCPT TO:<nosuchuser@foo.com>
   5xx No such user nosuchuser@foo.com

Now suppose I want to internationalize the response to RCPT TO. This cannot
be based on the anything in the message proper since the message hasn't
been communicated yet, and indeed may never been sent at all.

> Unfortunately, the layering violation is a show-stopper.  It would get vetoed
> by the email protocol guys; and if not by them by the IESG.  This is not the
> first time that this has happened to an elegant solution to a problem which
> urgently needs solving.  So don't feel bad!

Absolutely. Often as not it is the inelegant solution that requires incremental
upgrades to the installed base to deploy that wins.

> There's several documents that can come out of this discussion:

> 1) A tagged architecture for conveying protocol operation preferences (not
>    just languages).
> 2) [What your document started out as] An expansion of RFC 1766 languages tags
>    to convey the concept of "preferred language", and how the preferences are
>    prioritized (e.g. my dialect issue).
> 3) - n) How this framework is to be implemented in a particular protocol.

I have no problem with the notion of a generic tagging mechanism for this sort
of thing. For one thing, it allows for a one-time upgrade to get the basic
protocol elements in place. I do have a problem, however, with anything that
binds this to either the content being transferred (what Mark refers to as the
layering violation) or to a protocol session as a whole. Tagging has to be done
on a per-transaction basis; in some cases this may be the same as per-session
or per-content, but in other cases it may not be.

				Ned