[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
LC results for draft-melnikov-imap-expunged and how to move forward
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
-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?