On Fri, 5 Oct 2007, Eric Rescorla wrote:
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.
+1.
Assuming that a typical FLAGS response is about 40 octets, then fetching
all flags is 1,200,000 octets. This may be a bit slow over a 2.5G
wireless network, but "quite painful" overstates the case somewhat.
Also, this is only an issue for "disconnected" clients that insist upon
synchronizing a local copy with the server. True "online" clients don't
have this issue, and don't care about flags in messages that the user
isn't viewing.
Being an online client kind of guy, I see the problem as a flaw in the
disconnected client model, especially as the whole idea of reconnect seems
to be to make disconnected have similar real-time characteristics as
online. I sympathize, but only to a limited degree.
-- Mark --
http://panda.com/mrc
Democracy is two wolves and a sheep deciding what to eat for lunch.
Liberty is a well-armed sheep contesting the vote.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf