Subject: [EAI] simpledowngrade proto-02

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 19 Mar 2012 14:15:20 +0100

Hi,

I find it rather irritating that the draft embargo before each meeting
also applies to WGs that do not meet.

http://arnt.gulbrandsen.priv.no/tmp/draft-ietf-eai-simpledowngrade-02.txt resembles
what will be -02 when the datatracker again allows submissions. It's
better than -01. Feel free to review.

Arnt

---

From: John C Klensin <[email-masked]>
Date: Mon, 19 Mar 2012 09:43:10 -0400

--On Monday, March 19, 2012 14:15 +0100 Arnt Gulbrandsen
<[email-masked]> wrote:

> I find it rather irritating that the draft embargo before each
> meeting also applies to WGs that do not meet.

Many of us find many aspects of the way that embargo works and
is interpreted very irritating.  Please let's not have that
discussion on this mailing list.

thanks, 
 john

---

From: [email-masked]
Date: Mon, 19 Mar 2012 10:04:37 -0700 (PDT)

> discussion on this mailing list.

+Aleph-one

				Ned

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 19 Mar 2012 19:27:49 +0000

> better than -01. Feel free to review.
I've reviewed -02 and here are my comments:

I generally like simplicity of the approach in your document and I am 
happy for it to go forward. (I am still undecided about picking one 
downgrade mechanism versa allowing multiple.)

2. Information preserved and lost

    The synthetic message is not intended to convey any information to
    the MUA. Nothing parsable is added, not even a marker to say "this
    message has been downgraded".

Actually I really want to have a way to tell the user that the message 
is synthetic. Maybe allow editing of the Subject line?

In Section 2.1 you talk about 14 header fields, I've only counted 12.

In Section 3: I really dislike relaxation of base IMAP rules about sizes 
without at least signalling that with an IMAP capability. I understand 
that this is targeting legacy MUAs, but at least a new capability would 
help with protocol traces.

But really, an IMAP server can synthesize a message and remember its 
size. We've been through this discussion before with IMAP CONVERT.

Thank you,
Alexey

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Mon, 19 Mar 2012 21:44:50 +0100

> is synthetic. Maybe allow editing of the Subject line?

If anything, then I think a new pseudoflag like \recent, or a response
code. My preference would be the response code.

   response-codes =/ "DOWNGRADED" SP sequence-set

> In Section 2.1 you talk about 14 header fields, I've only counted 12.

Barry pointed that out earlier today. I removed two fields during
editing and forgot to update the number. (Message-ID and one other, I
think. I really hate that they use address-like syntax.)

I dropped the number.

> help with protocol traces.

Good point. Enough of an argument to add a response code.

> size. We've been through this discussion before with IMAP CONVERT.

a) This is a peculiar case, since it only ever applies to unaware
clients and not, for example to any messages that are legal according to
core IMAP. b) IMAP CONVERT is not a shining success of deployment and
usage, so I think that if this document should follow any of its
example, then good concrete reason is needed.

Barry inspired me today: http://rant.gulbrandsen.priv.no/good-bad-rfc

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 20 Mar 2012 10:18:06 +0000

>     response-codes =/ "DOWNGRADED" SP sequence-set
This is useful for debugging, but not useful to users (two separate 
changes). Users need to know that they are not looking at the original 
message.
> think. I really hate that they use address-like syntax.)
Ok.
> Good point. Enough of an argument to add a response code.
I like that.
> example, then good concrete reason is needed.
Although true, I don't think preconditions for the Lemonade discussion 
have changed, so I think the conclusions are still valid.

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 21 Mar 2012 21:25:05 +0100

> +Aleph-one

One excellent way to avoid discussing offtopic subjects is to discuss
downgrade-02. Do you think you might be able to review it? It's two
pages plus boilerplate and references, and you have to slow down and
read anything carefully, please let me know where.

http://arnt.gulbrandsen.priv.no/tmp/draft-ietf-eai-simpledowngrade-02.txt until
it appears in the i-d directories.

Arnt

---

From: Barry Leiba <[email-masked]>
Date: Wed, 28 Mar 2012 17:24:56 +0200

> Good point. Enough of an argument to add a response code.

Cool; I approve of using a response code.  Telling someone who can loo at
protocol traces that there are non-EAI clients around is fine.  Let's not
fool ourselves into thinking there's ANY value in informing the end user
(Barry's mother).

> core IMAP.

It worries me that if a client SELECTs a mailbox with, say, 50,000 messages
and does a "FETCH 1:* UID FLAGS RFC822.SIZE", we'll have to convert EVERY
message just to get the size, even though the user isn't likely to actually
fetch the bodies of more than a few.

Let's not, please.

Barry

---

From: John C Klensin <[email-masked]>
Date: Thu, 29 Mar 2012 10:07:40 -0400

--On Wednesday, March 28, 2012 17:24 +0200 Barry Leiba
<[email-masked]> wrote:

>>> In Section 3: I really dislike relaxation of base IMAP rules
>>> about sizes without at least signalling that with an IMAP
>>> capability. I understand that this is targeting legacy MUAs,
>>> but at least a new capability would help with protocol
>>> traces.
>> 
> Cool; I approve of using a response code.  Telling someone who
> can loo at protocol traces that there are non-EAI clients
> around is fine.  Let's not fool ourselves into thinking
> there's ANY value in informing the end user (Barry's mother).

I very slightly disagree, but only very slightly.  This is a
matter for UI design.  Our job is to make sure the UI designer/
implementer(s) have sufficient information available to be sure
that they can do the right thing as they see it and a response
code seems right for that.   As a sometime UI designer, I'd want
to be really careful about what I tell (and don't tell) Barry's
mother.  But, from my point of view, the ideal thing to tell her
is that something happened that was bad enough that she called
the family computer and email expert (presumably Barry) asked
what was going on, and was able to supply enough information
(even if it wasn't comprehensible to her) to Barry for him to
say "whoops, time to get your client upgraded and to do it right
now".   That model, I hope obviously, extends far beyond EAI and
IMAP.

    john

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 29 Mar 2012 22:13:10 +0200

> have changed, so I think the conclusions are still valid.

Those conclusions played a part in getting zero deployment, so I weigh
the factors differently now. My two cents, of course, but I've come to
place great emphasis on having a short, easily-read spec that's both
easy and simple to implement.

-03 is there now. The diff from -02 is small; the document seems to
converge.

http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=draft-ietf-eai-simpledowngrade-03.txt

The main news is the response code you and Barry want:

  C: a UID FETCH ...
  S: 42 FETCH (UID 69 ...
  ...
  S: a OK [DOWNGRADED 69,71,73] Done

Two issues to discuss:
a) Is DOWNGRADED the right name? Typist hat off: I don't think that
really matters, DOWNGRADE is good enough.
b) Should both downgrade documents use it, compatibly?

Arnt

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 29 Mar 2012 22:20:20 +0200

I wrote:
> -03 is there now.

The number 65 in an example should be 70. Sorry, fixed.

Arnt