Subject: [EAI] FWD: Re: Draft revised charter

From: John C Klensin <[email-masked]>
Date: Tue, 11 May 2010 12:03:44 -0400

Charles initially and accidentally sent his note to my rather
than posting it to the list.  What follows is a somewhat edited
version of my reply to him (some prior material has been
removed, some new material inserted).

--On Monday, 10 May, 2010 10:00 +0100 Charles Lindsey
<[email-masked]> wrote:

> Whilst we are agreed that the alt-address mechanisms must go,
> that is not to say the whole of the downgrade mechanisms
> should go wth them. Although the emphasis on it may well be
> reduced, it should still remain as an option for sites that
> wished to use it and be described in an RFC. There is much
> more to downgrading than fixing up non-deliverable addresses,
> and even for that recent discussions in this WG indicated that
> a punycode-based solution could be devised without too much
> difficulty.

Charles, let me summarize where I think we are:

First, it is useful to distinguish between downgrading in
transit (specifically between when the message leaves the
Submission environment and when SMTP "final delivery" (as
described in RFC 5321) is made and downgrading either before or
after that range.  For those intermediate hosts to start making
local decisions about how to alter messages in transit violates
the "don't mess with messages in transit" principle that we've
established for email after great pain caused by the
alternatives and invites massive unpredictability and
interoperability problems. 

Second, there is a strong sense within the WG that getting the
core documents -- header extensions, SMTP extensions, and
general mechanisms for use of non-ASCII fields among conforming
systems -- is critical.   Based on what happens each time the
"downgrade" issues are opened and examined against deployment
and interoperability risks, it is clear that reaching consensus
on any specific downgrading model, even one that does not
involve in-transit changes, will be a long, slow, and painful
process if, indeed, it is possible.   

There is also the matter that the IETF has been extremely
reluctant to try to specify interface protocols between the
submission MUA and Submission server and between the delivery
MTA and mail stores, etc.  At most, we provide alternatives and
guidance, not single standardized answers.

So the charter is designed to do just that: eliminate in-transit
downgrading from the agenda, move forward very quickly on the
core documents, and then go back and deal, as necessary, with
the front-end and back end functions.   It actually anticipates
that some downgrading will occur on the submission side and that
receiving back-end protocols like POP and IMAP will need feature
to deal with transitional situations.  But, because we don't
even have agreement now about what to do, much less how to do
it, discussion of those options should properly be deferred
until the core documents are done and constrained by not
requiring in-transit modifications or imposing requirements on
those core documents.

Note that in-transit is in-transit: if one is going to downgrade
in the Submission server, then there is no in-transit issue.  If
one is going to downgrade in the first hop past the Submission
server (the MTA to which the Submission server sends the
message), then all of the downgrade problems appear, including
the need to either carry alternate address information or to
"automatically encode" and discover whether that is safe.

Incidentally, I believe that your inference about emerging
consensus that a punycode-based solution was not far away is
incorrect.   At least some of us who think we understand why
such solutions are impossible without risking disruptions to the
installed base (due to fundamental differences between email and
DNS, among other things) simply sat that discussion out because
we had been through all of the arguments before, nothing new was
being said, and participating in going through them again would
be just a waste of time.

If you still disagree, a very specific proposal about how to
proceed would be appropriate.  Handwaving about what some
systems might want to do is not, IMO, helpful.

regards,
    john

---------- End Forwarded Message ----------

---

From: Shawn Steele <[email-masked]>
Date: Tue, 11 May 2010 19:20:05 +0000

FWIW: I'm happy with the revised charter.

-Shawn