Re: Three kinds of IMAP extensions

Narendra Bisht writes:
> What we mean here, essentially, is that having one limit at 
> server side is better than having the different clients having 
> different limits.

Hm.

I'm sitting in my office now, where there's a misconfiguration on one of 
the upstream connections, and because of that the internet connection is 
slower than it should be. I could get it fixed if I were to pick up the 
phone and spend some time listening to "your call is important, please hold 
the line". But I don't bother phoning, because I already have so much 
bandwidth that more doesn't matter.

Two months ago I was on a farm in southern Italy on vacation, reading mail 
on my phone. It was very nice, but the connection wasn't too fast and I 
paid per byte.

Can you explain to me as a user why it is better if two email readers 
behave in the same way regarding bandwidth?

> The motive is pretty simple and clear. We want to have a limit 
> that can act like a guideline for the client, so that the client 
> get rid of try-and-fail.

If you go back to the first message in this thread, you'll find the 
description of the three kinds of extensions. Consider the motive you just 
mentioned.

This document and its motive, is this like CONDSTORE? Lots of people 
understand it and think that it's effective at solving a problem they have?

Or is it like C=D? Implementing the spec is simple and the document 
explains the benefit?

I think neither, which leaves the third possibility: It will not be 
implemented.

> We understand that this might not be a very regular thing, but 
> it might not be a rare thing either.

Right, and the problem is solvable. It's just that your document doesn't 
explain what the problem is, why your solution works at all, or why it 
works well enough to be worth implementing. Because it doesn't, I think it 
will go unimplemented, and that is a problem. We already have many 
unimplemented IMAP extensions.

Arnt

_______________________________________________
imapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imapext