August 1, 2008 IETF 72 - Dublin, Ireland 1

Revising QRESYNC

(RFC 5162)Timo Sirainen

Alexey Melnikov

1. QRESYNC – CLOSE #1

C1: STORE n +FLAGS \DeletedC2: Flag changes (\Deleted especially)C1: CLOSE

✔ Problem: C1 loses C2's changes.✔ Solution: Send all of the C2's changes

to C1 before the "OK Closed".

2. QRESYNC – Close #2

C1: STORE 1 +FLAGS \DeletedC2: STORE 2 +FLAGS \DeletedC2: STORE 1 -FLAGS \DeletedC1: CLOSE

✔ Problem: C1 thinks 1 was expunged, while 2 was expunged in reality.

✔ Solution: Require CLOSE to send VANISHED for everything that was sent and don't guess what was expunged.– Backwards compatibility: Only if no VANISHED is sent.

3. QRESYNC – Delayed Expunges

C1: a EXPUNGES1: * VANISHED 1234S1: a OK [HIGHESTMODSEQ 2]

C2: b store 1 -flags \seenS2: * 1 FETCH (FLAGS () MODSEQ (3))S2: b OK<< C2 disconnects >>

Problem: C2 loses VANISHED 1234

3. QRESYNC – Delayed Expunges

Solution: Send lower HIGHESTMODSEQ when MODSEQs would otherwisegrow it too large.

C1: a store 1 +flags \seenS1: * 1 FETCH (FLAGS (\Seen) MODSEQ (1))S1: a OK

C2: b expungeS2: * VANISHED 1234S2: b OK [HIGHESTMODSEQ 2]C1: c store 1 -flags \seen

S1: * 1 FETCH (FLAGS () MODSEQ (3))S1: * OK [HIGHESTMODSEQ 1]S1: c OK

3. QRESYNC – Delayed Expunges:Client Logic

1. When receiving FETCH MODSEQs, keep track of the highest value but don’t update HIGHESTMODSEQ yet.

2. When untagged or tagged HIGHESTMODSEQ resp code is received, set highest FETCH MODSEQ value to zero. Always update the current HIGHESTMODSEQ value with the given value, even if it shrinks.

3. When receiving a tagged reply process its resp code first. After that if highest FETCH MODSEQ value is larger than HIGHESTMODSEQ, update it.

4. UID in Unilateral FETCH

✔ Unilaterally sent FETCH replies should always contain UID field.– The spec already recommends clients to avoid

handling sequences, so client developers may be tempted to just ignore replies without UIDs completely.

– Even if clients use sequences normally, it’s difficult because VANISHED replies may contain duplicates etc.

• It would require a LOT of effort to make my ImapTest tool handle non-UID FETCH + VANISHED correctly

5. Message sequence match data optimization

✔ Message sequence match data could be used better by servers to optimize VANISHED replies.

✔ Doesn't require spec changes, but could be useful to mention in the updated spec.

✔ Current spec mentions only that the data can be used to drop VANISHED from beginning of the mailbox. It could also drop them from the middle.

August 1, 2008 IETF 72 - Dublin, Ireland 10

Other ToDo

✔ Some very minor errors in examples (missing human readable text in some cases)

✔ Need to describe interaction between THREAD and CONDSTORE/QRESYNC–i.e. how QRESYNC affects the

THREAD response?

August 1, 2008 IETF 72 - Dublin, Ireland 11

Conversion parameters for IMAP CONVERT

Alexey Melnikov

draft-melnikov-lemonade-convert-params-01.txt

August 1, 2008 IETF 72 - Dublin, Ireland 12

Conversion parameters for image/* and video/*

✔ Clarified that if only one of PIX-X (width) or PIX-Y (height) is specified, that aspect ratio is preserved during resizing

✔ Should there be a parameter for croping images?

✔ Clarified how “color-levels” (image depth) and “color” (color scheme) are to be used for changing image depth

✔ Added “quality-factor” conversion parameter to lossful image formats (e.g. Jpeg) - 0-100%– Is this useful?

August 1, 2008 IETF 72 - Dublin, Ireland 13

Conversion parameters for audio/* and video/*

✔ bitrate✔ Encoding-method

– FBR (for fixed bit rate)– VBR (for variable bit rate)

✔ min-bit-rate✔ frameRate

August 1, 2008 IETF 72 - Dublin, Ireland 14

Conversion parameters for text/plain

✔ FORMAT=FLOWED/FIXED– Is this useful?