Re: [lemonade] Re: Comments on draft-ietf-lemonade-reconnect-client-06

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]