- From: Ned Freed <Ned.Freed@INNOSOFT.COM>
- Date: Wed, 18 Feb 1998 16:38:36 -0800 (PST)
- To: Mark Crispin <MRC@CAC.Washington.EDU>
- Cc: Marc Blanchet <Marc.Blanchet@viagenie.qc.ca>, ietf-languages@apps.ietf.org, ietf-charsets@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 --Boundary (ID uEbHHWxWEwCKT9wM3evJ5w)
Received on Wednesday, 18 February 1998 16:52:29 UTC