Hi, > Christof Drescher writes: > > Tim and Mark (2nd choice) favor ghost messessages, while Arnt opposes > > it (what are your reasons?). > > It violates the IMAP cache semantics. In IMAP, the client knows that if > it has fetched some part of a message, that message won't change. If a > message is silently replaced with a ghost and later expunged, the > message has changed from the client's point of view.
sounds reasonable. > > Arnt favors (or least dislikes) a forced disconnection, > > Least dislikes. > > I think the best solution, purely from a client's point of view, is to > keep the message around until it's been expunged in all sessions. But I > realize that it may cause server implementors pain. Not only that. Two examples: 1) Mails which confidential data should be erasable as soon as possible; it is not acceptable (especially on heavily connected mailboxes) to have it delivered after an EXPUNGE anymore. 2) we work on a shared Mailbox ourselves, where each mail should be work on only once. We set it flagged when we're on it, and delete it when we're done. Does not help if they fly around after expunge either. > > Question: Are there clients which gracefully reconnect without error > > message? I doubt it, and I don't think this should be "advisable" for > > client implementors, should it? > > Certainly there are, and since NAT boxes tend to tear down connections > all the time I expect more and more clients to silently reconnect. OK, but it's actually the same. It would need a "formal" recommendation to try again after a connection loss, just like "if you get a ghost message, send NOOP" or "if you get a NO, try a NOOP first"... One could take the path which serves existing clients the most - but at least something should be done to clear it up... > About NO to fetch: > > > Why?! Where is it not compatible (I only answer "NO", which should > > always be compatible?!). Anyway, it's a "recommended" way to handle > > this situation, as far as I understand RFC2180?! > > I was confused and phrased the answer much too strongly. Sorry. :-) > My objection to this is only that clients aren't likely to be tested for > this case. A well-written client will effectively never get a NO to a > FETCH command, so the author won't test its handling of NO. > > (The extreme worst case is that the client runs through its algorith to > find out what it should do next and decides to send the exact same > FETCH command again. In that case, I hope the user isn't on a > pay-per-byte connection.) > > So I'm currently favoring this tagged NO [PLEASENOOP] thing, or second > > ghost messages. > > PLEASENOOP isn't a bad idea, but no RFC2060/RFC3501 clients know about > it, so IMO it's not a sufficient answer. My idea would be to try it (NO [PLEASENOOP] first; if the client does NOT catch up after this command (the test is very simple to implement), the server can still disconnect the client (which would help for clients not (yet) supporting it). But unfortunately, Mark seems to not like it. :-( Christof
