[IEE] Tunneling and packaging (was: Re: Packaging IEE Messages)

[John C Klensin <[e-mail]>]

Dave,

This is the more technical response I promised.   As suggested
in the prior, procedural, note I think it deserves a response
because I believe that a tunneling/embedding approach may be of
great value in downgrading and hence should be better
understood.   But I don't see it as an alternative to the
present proposals, only partially because of the reasons
explained below.

I've tried to respond below to a few questions and comments from
Charles and Martin, since this seems to be the right context.

--On Sunday, 11 December, 2005 10:12 -0800 Dave Crocker
<[e-mail]> wrote:

>...
> PROBLEMS:
> 
> The various threads that have explored different ways to make
> IEE messages -- as distinct from 'legacy' messages -- seem to
> have uncovered the usual problems of trying to run a
> dual-stack service.  In effect, IEE messages are not
> compatible with the existing message-parsing infrastructure,
> so we are trying to find a way to distinguish them, without
> breaking anything.

Well, it does more than that, although what it does depends on a
number of assumptions about implementations and design.  Whether
those assumptions are reasonable or not is an analysis that will
have to be part of this effort.

One of those assumptions is that the typical implementation of
i18n messages will simply be 8bit clean, and UTF-8 clean,
internally with some adjustments to compensate for this
protocol.  If the result of this approach requires running what
are essentially two different protocols over the same port and
signaling path, as your comments about "dual-stack", etc.,
suggest, then we are in big trouble.  We have looked briefly
(again, more work needs to be done) at a few MUA and MTA
implementations in UTF-8 operating environments, and
implementation of the proposed protocol (absent downgrading and
as of the time of the Vancouver IETF) appears to require:

	* Disabling the syntax check requiring that addresses be
	in ASCII
	
	* Disabling the syntax check requiring that headers be
	in ASCII
	
	* Adding the appropriate capability announcement to the
	EHLO response in the SMTP server.

You will note the strong resemblance between this and most
practical (and actual) implementations of 8BITMIME.  That option
(again, modulo downgrading) is really not "I have these special
capabilities" or "I have dual-stack-like capability for handling
that bizarre form" but "my code paths can accept this without
problem".

This is why I've been resistant to Charles's suggestions about
changing the syntax of various header lines.  I think that
requires, not disabling a few tests, but recasting every MUA (or
other module that deals with headers) to support a dual code
path and turns implementing this into a much bigger deal.

The answer to Martin's question in that regard is that I'm still
unconvinced that a specific marker is needed except maybe after
delivery.  If folks want it, adding it is pretty painless as far
as I can tell, but necessity is still, IMO, not demonstrated.

> The SMTP option approach essentially checks for a safe path
> between originator and recipient.  There is a long-term appeal
> to this approach, given that it provides the cleanest handling
> of the new object itself. Unfortunately this approach has an
> enormously high barrier to adoption, since it requires
> changing much of the SMTP infrastructure before gaining much
> utility. I am afraid, therefore, that this looks like a good
> *adjunct* procedure, rather than an appealing first step.

See above and my earlier note.  From my standpoint, "gaining
much utility" has to do with communities who need this and
mutually consent to its use.  It is simply not required that it
be deployed everywhere on the Internet in order to gain utility,
although such deployment would obviously be valuable and
increase network effects as it occurs.  What is key is that
those who have not yet decided to play are protected from any
ill side effects as the result of its use by those who are using
it.

That brings me back to another place where I think Charles and I
have a disconnect.  SMTP, [2]822, and MIME are an inherently
strong-envelope environment, as evidenced by the fact that there
is no requirement that any of the envelope addresses appear in
the headers.    Clearly, there are weak-envelope and no-envelope
environments in the mail world.  But the right way to deal with
them, IMO, is to be sure that the right conversions can be done
at gateways, that they have headers (or whatever they use) that
can carry the information that strong-envelope environments
carry in the envelope (assuming that information is relevant),
and so on.  The solution is not to try to force the strong
envelope environment to turn into a weak envelope one or to
create the sorts of redundancies between headers and envelope
that have led to trouble over and over again.

> Changing the message header, to add a single field -- as a
> flag -- or multiple fields -- as alternate content -- makes
> the header a mess to parse, creates dangers with
> synchronization across headers, and otherwise looks like an
> attempt to merge two, frankly incompatible formats.

But, unless one wants to do that for other reasons, it is a
classic strawman.   If one adopted the principle that no
downgrading would be done at all prior to MTA final delivery
--that sending an i18n message to an MTA that couldn't handle it
would result in a bounce (see the framework document and my
earlier I-Ds for an analysis of why this wouldn't be quite as
terrible as would appear on first glance)--  turns this into a
message store and MUA issue, which is quite a different one from
worrying about a very heterogeneous origination, transport, and
delivery environment.

> One almost wishes that email had an "envelope" header section,
> as distinct from the "content" header.  (In effect, this
> serves to create an ordering between 2 sets of header fields.)
> After all, the reason that Content-type works, in describing
> alternate forms of data, is that it is guaranteed to occur
> before the content it labels.  Hence it does not impose a
> 2-pass parsing model.

Yes.  Of course.  FWIW, I explored this one in
draft-klensin-email-envelope-00 almost two years ago.  That
version of the idea got all of the traction it deserved, i.e.,
about zero, but the point was that it is possible to make this
change if we were really motivated.  It stops a bit short of
"new mail protocol", but not much.   Of course, there is also a
strong argument for a three-layer envelope, separating what we
describe in Internet mail as the current (addressing and
transport instructions) envelope, message trace and related
information, and headers, ideally with all three forced into a
canonical form rather than having the last two as
randomly-ordered text fields.  Hmm.  I wonder if one could call
those P1, P2, and P3?  <sigh>.    But that discussion is, IMO
fortunately, badly off topic -- see prior note about procedures.

> TUNNELING:
> 
> In looking for an approach that might be simple and
> sufficient, it occurs to me that there is an easy way to
> achieve a similar effect, that is entirely comfortable within
> the current SMTP *and* Header processing environment:
> 
>     Content-type: message/iee
> 
> The new form is entirely packaged as a body-part, within an
> old-form message.  There is no danger to existing parsers or
> handlers.  And there is explicit labeling of the new form.

But it prevents the use of internationalized addresses _in the
envelope_, which is the key goal of this process.   In a 7bit
transport environment, it also raises some issues with the
double-encoding problem, although I imagine we could work those
out.

> Best of all, this is an approach that is quite similar to that
> done in adopting MIME and ESMTP.  That is, they have proved
> complementary, with a low barrier to adoption and quite a bit
> of benefit for early adopters.

But the barriers are not low, since it requires that every MUA
that is going to deal with these things contain unpacking logic.
It also forces the user (or some very intelligent heuristics and
conventions) to be able to decide whether replies are to go to
the outer header address (and with those subject lines,
in-reply-to fields, etc.) or to the ones contained in the body
part.  I suggest we have some experience with that exact type of
"stacked header" situation and the associated user choices with
message/digest and that the experience has not been a happy one
... the end user just needs a little too much understanding.

> So, the legacy header is used as an envelope header, and the
> header within message/iee is used as the "real" rfc2822bis
> message header.

Now, all of that said, I suspect that there may be a role for
message encapsulation (along the lines of message/iee) for
downgrading.  If alternate (i.e., ASCII) addresses are
available, it might be far more sensible to do downgrading along
exactly the lines you suggest, thereby avoiding introducing an
entire new header collection and syntax-set just to accommodate
the downgrade cases.   For a discussion of that theme that is
incomplete --but a little more complete than your email message
-- see draft-klensin-email-i18n-message-00 (2 Feb 2004).  Of
course, that approach still has the interpretation and unpacking
problems identified above, but it is transitional --part of a
temporary problem until more systems either get their
configurations together or upgrade to be able to handle i18n
mail properly-- not a permanent blot on the landscape and,
worse, an impediment to using non-ASCII scripts on the Internet
in the same fashion in which ASCII is used.

     john



_______________________________________________
IMA mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ima