Subject: [EAI] IETF Last Call comment on downgrade

From: John C Klensin <[email-masked]>
Date: Wed, 07 Jan 2009 11:47:43 -0500

Hi.

Just FYI, I just posted a lengthy note to the IETF list on the
downgrade Last Call (deliberately late, as the note indicates).
It supports publishing the document as Experimental, but reviews
all of the reasons why EAI might be a lot cleaner and simpler
with a traditional "either the address is deliverable or it is
not" model rather than in-transit downgrading.

I didn't cross-post it here because I use different addresses
for the two lists.

I've said all of this before (although at more length to the
design team than the WG); none of it should come as any surprise
to anyone who has been following the WG's work.

A summary of the suggestion in the note is that 

* The document should be published as Experimental; if we are
going to support in-transit downgrading, it is probably the best
that can be done.

* During the experiment period, the community should review
costs and benefits very carefully, especially wrt interactions
with the non-EAI-aware systems with which downgrading is
expected to help, leakage of the new address forms to older
systems and how the latter react, relative costs of
implementation, etc.

best new year's wishes to all.
      best,
      john

_______________________________________________
IMA mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ima

---

From: Martin Duerst <[email-masked]>
Date: Fri, 09 Jan 2009 18:09:16 +0900

Hello John,

As far as I'm aware of, all the documents from this WG
so far have been published as experimental (or informational
for those that don't specify any kind of protocol or format).

Are you saying that downgrade should be even more
experimental than experimental? Or that you think
that while the others should go to proposed in a
next round, that shouldn't apply to downgrade?
Or what?

Regards,     Martin.

>best new year's wishes to all.

#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[email-masked]

---

From: "YAO Jiankang" <[email-masked]>
Date: Fri, 9 Jan 2009 17:41:28 +0800

----- Original Message ----- 
From: "Martin Duerst" <[email-masked]>
To: "John C Klensin" <[email-masked]>; <[email-masked]>
Sent: Friday, January 09, 2009 5:09 PM
Subject: Re: [EAI] IETF Last Call comment on downgrade

> experimental than experimental? 

>Or that you think

I think that your second understanding is what John wants to express.

---

From: John C Klensin <[email-masked]>
Date: Fri, 09 Jan 2009 10:31:57 -0500

> Hello John,

Sorry for not being clear.  This is really an issue about
technical tradeoffs, rather than a procedural one, but I think
it is useful to think/talk about it right now in procedural
terms..

> for those that don't specify any kind of protocol or format).

Yes.  I note that documents from an IETF WG are published as
Experimental for at least two different reasons:

	(i) To get a chance to demonstrate that they work, for
	any values of "work" that may be relevant.  The
	expectation is that once that demonstration completes,
	the results can be evaluated, the protocols adjusted as
	needed, and decisions made that would lead to
	standards-track publication of a revision/update.
	
	(ii) To publish them as what, in another SDO, are
	jokingly referred to as "substandards" --not ready for
	standardization-- with the expectation that they will
	never advance further.

I certainly believe that the entire EAI package, including
downgrade, falls into the first group.

> next round, that shouldn't apply to downgrade?

I take the classification of "experimental" seriously -- as an
opportunity to get a specification (or collection of
specifications) published in solid, public, form to assist in
generating interoperable implementations and testing and
evaluating them.  I think those evaluations actually ought to
occur and that it is a flaw in the IETF procedures that
experimental documents do not require a statement about
evaluation periods... and an automatic move to Historic if the
evaluations are not completed and published within a set period
of time.  A corollary to that is that I don't believe the second
group above should exist at all.   However, please note that I
have been making both of those suggestions for around 20 years
now and have gotten nowhere -- for better or worse, we are stuck
with ad hoc arrangements in which some Experimental
specifications are evaluated much more carefully than others.

What I'm suggesting is that Downgrade --and the EAI suite
including Downgrade-- should be evaluated very carefully and
that the evaluation should include what I see as a very explicit
tradeoff between:

	(1) With Downgrade in its present form, some messages
	are going to get through that would not otherwise go
	through.  Some subset of those messages are going to
	arrive without information loss and the recipient (or
	agents intermediate between the delivery MTA and the
	recipient) will be able to deduce and reconstruct the
	form of the original message.   We don't know how many
	messages that would otherwise be undeliverable will get
	through as a result of having Downgrade, nor do we know
	what level of information loss will occur.  We also
	don't know how much the "<non-ascii-string
	<ascii-string>>" will leak into non-EAI environments
	(although experience with email predicts "quite a lot",
	nor what problems such leakage will cause. The answers
	to those questions are obviously part of the experiment.
	
	(2) Without Downgrade in its present form,
	implementation of EAI becomes easier, perhaps even
	vastly easier.  The "<non-ascii-string <ascii-string>>"
	syntax disappears, as does the collection of
	"Downgraded" headers, so we don't need to worry about
	their effects or about long-term clutter to the
	protocols or syntax.  We don't know whether easier and
	less complex implementation will lead to more
	implementations, earlier implementations, or to fewer
	bugs and interoperability problems than would occur with
	those full-Downgrade implementations.    We also don't
	know how many implementations will choose the shortcut
	path -- rejecting messages requiring downgrading rather
	than going through the downgrade procedure.  The answers
	to those questions may be, and are likely to remain,
	more speculative than those above, but they are also
	obviously part of the experiment.

That is a more or less classic engineering design tradeoff
issue, with one set of advantages being on a somewhat different
scale than the other, i.e., putting them on a single scale is
hard or impossible without biasing the outcome.  It is also
typical of such tradeoffs in the real world, because full
information is simply not available or likely to become
available.   We just need to gather what information we can and
make a educated guesses.  I am suggesting that the tradeoff is
important and that those guesses should be as educated, and
data-based, as possible.

When we got started with the EAI work, our hypothesis was that
Downgrading was both necessary and reasonably straightforward.
We've learned that it was less straightforward than we expected,
that the number of cases in which it could be applied were fewer
than expected (e.g., the requirement that all non-ASCII
addresses be associated with alternate forms).   We also had not
seriously considered the mailing list issues, nor anticipated
the conclusion we seem to have reached.   On the other side of
things, we probably have a better understanding of the ways in
which the need to downgrade can, and cannot, be controlled by
careful and thoughtful system configuration.  

Give that, the question of "is this particular feature really
worth the trouble" is one that we have properly not asked since
EAI was chartered.  I believe that it is one that we should
start asking seriously as soon as Downgrade is approved, with
the complexity of that specification and its interactions with
the other specifications as part of the data.

My note was simply a plea that the community ask it and a
heads-up that the question was important.  That doesn't make
Downgrade any different from any other Experimental spec except
that someone has explicitly proposed evaluation criteria other
than "implement it and see if it interworks with cooperating
implementations".

Now, if what you are really asking about is my personal
opinion... At this point, I believe we would be better off 

	* without Downgrade as specified
	* pushing for rapid implementation and deployment of an
	  internationalized email solution that is free of
	  in-transit downgrading and the associated syntax,
	  header, digital signature, etc., issues
	* concentrating our efforts on address downgrading
	  procedures that could be applied at the endpoints -- 
     the sending MUA or submission MTA and after SMTP final
	  delivery, rather than figuring out how to make
	  in-transit work
	* getting more specific about the cases in which
	  in-transit downgrading might be needed and how they can
	  best be avoided by careful configuration.

Some of those statements argue strongly for revisiting and
publishing the Scenarios document, perhaps in the form of an
"operational hints" document.

But those are just personal beliefs.  Worse, they are based on
some speculative reasoning.  My main interest at this point is a
careful and fair experimental and evaluation process that gives
us more information about risks and tradeoffs.

Does that answer your question?

      john