LC results for draft-melnikov-imap-expunged and how to move forward

[Alexey Melnikov <alexey.melnikov@xxxxxxxxx>]

Let me try to summarize the results of IETF LC and suggest some changes 
and how to move forward.

1). LC comments.

Mark is concerned about benefits versa costs of the extension. Mark has 
proposed an alternative mechanism for quick mailbox resynchronization to 
which Philip replied that we already decided against any server side 
mechanism in the Lemonade WG.
Dave and Arnt are largely in favor of the extension (Dave: "my 
alternative proposal is not easier to implement" + "we need this for 
QRESYNC (draft-ietf-lemonade-reconnect-client-01.txt)", Arnt: some 
issues need to be clarified + some protocol changes required)

Several people got confused by how much extra state needs to be stored 
on the server (Fact: as of -01, *no* extra state needs to be stored on 
the server. But see extra comments below). This suggests that some 
clarifications are needed in this area.

Is this largely correct?

2). What to do next.

If I interpreted overall comments correctly, I think there is some 
support for the proposed extension. However there are some ambiguities 
in the document that need to be clarified.
Below I am listing some changes that I am planning to do. Hopefully 
after doing the changes I can convince some people in "confused" and 
"undecided" groups to support the document.

3). Detailed technical changes that needs to be done in next revision.

a). Dave/Arnt/Pete Resnick: add a SELECT/EXAMINE parameter that similar 
to the current FETCH parameter
(Pete prefers REPORTEXPUNGES to be on SELECT instead of FETCH.)

Question: do we want to reference ENABLE command, now that Arnt 
published a draft?

b). Arnt requested clarification on how long the switch from the EXPUNGE 
response to the EXPUNGED response lasts. I've clarified that this change 
lasts till the connection is closed.

c). Randy: change the new untagged response to something more unique. 
Suggestions are TOMBSTONE (Randy) or VANISHED (me). I like VANISHED, as 
it is 1 letter shorter ;-).

d). Several people got confused by how much extra server state needs to 
be stored and under what circumstances.

-00 required to store a modsequence for each expunged message. This can 
potentially result in potentially very long list, with no upper limit on 
its length.
-01 was changed to require absolutely no extra state on the server.

Arnt and Dave have convinced me that what described in -01 can consume 
too much bandwidth. And I agree with Mark and Peter Coates that holding 
expunged data indefinitely (as in -00) is not a good idea.

So, I would suggest to do the following changes:
Allow implementations to either store modsequences for expunged messages 
(+ allow there expiration) or not store any extra state. The latter 
would be compliant, but would be clearly marked as "poor 
implementation". Because this would not make any difference from 
protocol point of view (apart from wasting bandwidth), there is no 
reason to completely disallow such implementations. For the former case 
I would add an extra section describing why holding expunged data 
indefinitely is a bad thing. This section would also recommend how to 
properly "expire" old expunged records.

e). The change d). would mean that the EXPUNGED extension would depend 
on CONDSTORE. I am thinking that the updated EXPUNGED extension should 
just be folded into the QRESYNC extension. Comments?

Is there any desire to do a separate "ENABLE EXPUNGED" extension, the 
sole purpose of which would be to make servers send EXPUNGED responses 
instead of EXPUNGE responses?