At Fri, 05 Oct 2007 12:18:20 +0100, Alexey Melnikov wrote: > > Hi Eric, > Thank you for your comments. > > (Today is about the worst time for me to reply to your comments, as I am > going on holidays tomorrow.) > > Eric Rescorla wrote: > > >$Id: draft-ietf-lemonade-reconnect-client-06-rev.txt,v 1.1 2007/10/04 22:25:53 ekr Exp $ > > > > > >OVERALL > >This document describes an extension to IMAP to provide faster > >synchronization between client and server. As far as I can > >tell, the optimizations are: > > > >- Removing one round trip needed to discover which messages > > have been expunged. > > > > > Yes, if compared to the case when the client/server also implement the > CONDSTORE extension (RFC 4551). > (Actually it removed 2 round trips per mailbox synchronization.) > > When compared to RFC 3501, this extension can potentially provides huge > bandwidth saving. If a client wants to synchronize flag changes in a > mailbox, the client needs to fetch flags for *all* mailboxes. For a > 30,000 message mailbox that I currently have is quite painful over a > slow link. I don't think it makes sense to compare this to 3501 without 4551, since 4551 is already an RFC. The question is whether this document should be advanced. What's the optimization compared to 4551? Also, you say it's "quite painful" now. How much less painful is it with this document. How about if compression is used. This seems like something where measurements would be nice. > >DETAILED COMMENTS > >S 2. > >This would be improved by some overall diagram of the new and > >old behavior and some measurement, even an ad hoc one, of > >the performance improvement. > > > > > Ok. An older version of this document had some numbers, but people > complained about "irrelevant text". Maybe I'm missing something, but those comparisons are to 3501, not CONDSTORE, right? > >S 3.3, 3.4, 3.5. > >These would all benefit from a statement of how they differ from > >3501, rather than just stating new rules. > > > > > (Actually, 3.5 updates UID EXPUNGE which was defined in RFC 4315.) > > Right. I believe some people wanted to see sections replacing the old > definitions, as opposed to just pointing out the difference from RFC 3501. As a wordsmithing issue, I would recommend adding a single clarificatory master section with these replacement definitions as subsections. > >S 3.6. > > The VANISHED response has two forms. The first form contains the > > EARLIER tag, which signifies that the response was caused by a UID > > FETCH (VANISHED) or a SELECT/EXAMINE (QRESYNC) command. This > > response is sent if the UID set parameter to the UID FETCH (VANISHED) > > command includes UIDs of messages that are no longer in the mailbox. > > When the client sees a VANISHED EARLIER response it MUST NOT > > decrement message sequence numbers for each successive message in the > > mailbox. > > > > The second form doesn't contain the EARLIER tag and is described > > below. Once a client has used "(VANISHED)" with a UID FETCH or > > "(QRESYNC)" with SELECT/EXAMINE command, the server SHOULD use the > > VANISHED response without the EARLIER tag instead of the EXPUNGE > > response. The server SHOULD continue using VANISHED in lieu of > > EXPUNGE for the duration of the connection. In particular this > > affects the EXPUNGE [RFC3501] and UID EXPUNGE [UIDPLUS] commands, as > > well as messages expunged in other connections. Such VANISHED > > response MUST NOT contain the EARLIER tag. > > > >This is pretty unclear to the non-IMAP expert. Could you explain > >in english what this is trying to accomplish in the document, > >not just specify the protocol mechanics. > > > > > Basically the VANISHED response is used for 2 purposes: to report UIDs > of messages expunged earlier and to report UIDs of messages expunged now. > The difference between the two is that in the former case the client > doesn't need to decrement the number of messages in the mailbox, while > in the latter case it must. > The former can be distinguished from the latter by presence of the > "(EARLIER)" label. OK. That could be clearer in the main text. > >S 4.1. > > Strictly speaking, a server implementation that doesn't remember > > modsequences associated with expunged messages can be considered > > compliant with this specification. Such implementations return all > > expunged messages specified in the UID set of the UID FETCH > > (VANISHED) command every time, without paying attention to the > > specified CHANGEDSINCE modsequence. Such implementations are > > discouraged, as they can end up returning VANISHED responses bigger > > than the result of a UID SEARCH command for the same UID set. > > > >Isn't this inconsistent with: > > > > If the server is capable of storing modification sequences for the > > selected mailbox, it MUST increment the per-mailbox mod-sequence if > > at least one message was permanently removed due to the execution of > > the EXPUNGE command. For each permanently removed message the server > > MUST remember the incremented mod-sequence and corresponding UID. If > > at least one message got expunged, the server MUST send the updated > > per-mailbox modification sequence using the HIGHESTMODSEQ response > > code (defined in [CONDSTORE]) in the tagged OK response. > > > >If not, why not? > > > > > No, there is no inconsistency: > > "a server implementation that doesn't remember modsequences" == "a > server is incapable of storing modsequences". > The second paragraph you quoted is conditional on server's ability to > store modsequences. This behaviour is optional for servers. OK. I misread this. Thanks. > >S 5. > > The client MUST also take note of any MODSEQ FETCH data items > > received from the server. Whenever the client receives a tagged > > response to a command, it calculates the highest value among all > > MODSEQ FETCH data items received since the last tagged response. If > > this value is bigger than the client's copy of the HIGHESTMODSEQ > > value, then the client MUST use this value as its new HIGHESTMODSEQ > > value. > > > >So, I probably misunderstand something, but my read of 4551 made > >it seem like you could do a MODSEQ FETCH that would not return > >all the metadata for every message. > > > Yes, if the client issues a FETCH MODSEQ for a subset of messages. > However the previous paragraph in the same section requires the client > to perform a full synchronization. OK. > >In that case, wouldn't this > >procedure risk you having a modseq that is higher than some > >messages you haven't examined yet? What am I missing. > > > > > The intent of this paragraph is to talk about unsolicited FETCH MODSEQ > returned by the server *after* a full synchronization is complete (the > previous paragraph in the same section). So the situation you describe > can't happen, because the server is required to send all unsolicited > FETCH MODSEQ responses. > The beginning of this paragraph is ambiguous, so I suggest that it > should be clarified by changing the first quoted sentence to read: > > After completing full synchronization, the client MUST also take note of > any MODSEQ FETCH data items received from the server. WFM. -Ekr _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf