Subject: [EAI] Simpledowngrade

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 8 Mar 2012 15:30:35 +0100

Hi,

Any more comments? If not we might as well get a document shepherd. It's now or later, and there is nothing to be gained by mere delay.

Except... A review or two?

Arnt

---

From: John C Klensin <[email-masked]>
Date: Thu, 08 Mar 2012 09:41:18 -0500

--On Thursday, March 08, 2012 15:30 +0100 Arnt Gulbrandsen
<[email-masked]> wrote:

> Hi,
> 
> Any more comments? If not we might as well get a document
> shepherd. It's now or later, and there is nothing to be gained
> by mere delay.
> 

<co-chair hat=on>

I would certainly prefer to see a review or two from those who
have not been involved before concluding that we have sufficient
WG consensus to start talking about document shepherds.  I don't
know quite how to proceed without it -- IETF Last Call and
AUTH48 are not the times to discover that we don't have
agreement on the text or, worse, don't know what it means.

</co-chair>

   john

---

From: "Jiankang YAO" <[email-masked]>
Date: Fri, 9 Mar 2012 10:29:52 +0800

There are two kinds of downgrades.
simple downgrade:  draft-ietf-eai-simpledowngrade-00
complex downgrade: draft-ietf-eai-popimap-downgrade-04

in the pop and imap documents, we recommend simple downgrade or complex downgrade or both?

It is up to the implementors to decide which downgrade is to be implemented?

Jiankang Yao

  ----- Original Message ----- 
  From: Arnt Gulbrandsen 
  To: [email-masked] 
  Sent: Thursday, March 08, 2012 10:30 PM
  Subject: [EAI] Simpledowngrade

  Hi,

  Arnt 

------------------------------------------------------------------------------

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

---

From: John C Klensin <[email-masked]>
Date: Fri, 09 Mar 2012 07:05:27 -0500

> complex downgrade: draft-ietf-eai-popimap-downgrade-04

See my status summary note, but there are at least three, the
third being some sort of "message unavailable" report to the
client.  A couple of ways to do that have been outlined on the
list.  The WG needs to decide whether to write the third up in
an I-D and, if so, get someone to do it.

> or complex downgrade or both?

Unless others disagree, I think where we are headed is to note
that there are multiple options, but not make a recommendation.
I believe that the same thinking that argued for separating the
original popimap-downgrade material from the POP and IMAP specs
suggests that we not duplicate that explanation into the POP and
IMAP document but, instead, keep it separate, even if that means
yet another document (or, frighteningly, opening and updating
Framework).

> It is up to the implementors to decide which downgrade is to

Yes.  And up to whomever selects implementations to decide which
one to select.  

Let me restate this into several questions for the WG.  If we
can't get discussion, reviews of documents, and answers soon, we
are in trouble.

(1) Does the WG want a document describing the third, "no
downgrade", option?  If yes, who understands that option well
enough to write it up and is going to volunteer?  If no, I
believe that options can be incorporated as hand waving into
"the explanation" (see (2)).

(2) Whatever is decided, this multiple-choice situation with
more than one alternative, tradeoffs, and recommendations (if
any) will need to be written up.  Do we want that explanation
duplicated in the POP and IMAP documents or do we want it in one
place only?  And do we want a thorough explanation or just a
statement that there are alternatives, leaving implementers and
those who select server software largely on their own as to what
to select?   Whether separate or duplicated, this material is
referenced as "the explanation" above and below.

	Note, first, that going with the statement plan might
	make the "duplicate" strategy more attractive while
	explaining everything we know and have talked about
	might favor a "one place" strategy.  There are lots of
	alternatives in between those two extremes.  Second,
	fwiw, I believe that most of what would need to go into
	even a thorough and complete explanation has already
	appeared in discussions on the list and in
	popimap-downgrade so, while some collecting, drawing
	together, and writing are needed, the explanation should
	not require significant new work or involve material the
	WG hasn't already had a chance to examine.

(3) Have people reviewed the latest version of popimap-downgrade
and, if so, do you think it is ready to go modulo wherever "the
explanation" goes?  If not, when and how is that going to get
done?  Also, should some of the newer text about choices be
removed from popimap-downgrade and put into "the explanation".

(4) Have people reviewed the current version of simpledowngrade
and, if so, do you think it is ready to go modulo wherever "the
explanation" goes?  If not, when and how is that going to get
done? 

A warning: I believe that the co-chairs have the authority to
make document organization decisions.  I have no intention of
exercising that authority if the WG has preferences and even
very rough consensus about them.   But, if no one, or almost no
one, expresses opinions, I/we will interpret that as
indifference and make decisions that will expedite getting the
work done.

     john

---

From: "John Levine" <[email-masked]>
Date: 9 Mar 2012 17:43:34 -0000

Having (as best I recall) originally proposed the no downgrade a/k/a
hostage approach, I'd be happy with language that says to downgrade
but leaves the details to the implementation.  The details of the
downgrade have little effect on interoperation, so there's no need to
offer any more advice than is required not to break things
unnecessarily.

The main bit of advice would be not to downgrade to something that
looke like a valid legacy message, e.g., don't turn UTF-8 mailboxes
into INVALID or Mr. Invalid will be getting a lot of other people's
mail.

R's,
John