Re: Three kinds of IMAP extensions

Hi Arnt,

There are few servers who has shown interest in implementing this draft.
So, I strongly feel, it won't get unimplemented.
 
The "Introduction" part of the draft conveys the problem pretty clearly.
Over last few months it has been reviewed through multiple iterations and review comments have been addressed.

We as a mobile client has faced this problem quite often.

Regards,
Jay
-----Original Message-----
From: imapext [mailto:[email protected]] On Behalf Of Arnt Gulbrandsen
Sent: Thursday, October 22, 2015 9:04 AM
To: [email protected]
Subject: Re: [imapext] 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

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