One of the beauties I’ve always appreciated about IMAP was its conceptual model
of how the message store and folders should work. Whether I agreed with all of
the decisions on how somethings should work or not, the model was well thought
out. The various warts^H^H^H^H^H/hacks^H^H^H^H^H^/enhancements we’ve added on
top have mostly kept that model intact, and that’s a good thing.
Any replacement needs to start with a similarly well-thought-out model. It
needs to cover all of the cases of online use and offline caching with
synchronization.
We’ve certainly learned a few things from the various IMAP extensions, and I
agree that simplification can be achieved in various areas.
The least-interesting part, IMO, is the transport of commands, be it expressed
in JSON, XML, or any other encoding-du-jour.
Tony Hansen
On 11/9/16, 3:13 PM, "ietf-smtp on behalf of Dave Crocker"
<ietf-smtp-bounces(_at_)ietf(_dot_)org on behalf of
dcrocker(_at_)gmail(_dot_)com> wrote:
On 11/10/2016 1:13 AM, Ned Freed wrote:
> An extensive rework the existing IMAP protocol is a daunting task. Not
only
> does it require in-depth knowledge of the existing protocol, it requires
> considerable knowledge of how that protocol is used.
>
> Like it or not, a key advantage of starting over is that you don't have to
> worry about backwards compatibility with anything.
The email technical community has, IMO, a really excellent track record
of incremental enhancement. Anytime someone calls for tossing out one
email protocol or another (or all of them) and starting over, I press to
first get a clear statement of what is needed that we don't have, a
basis for claiminge community consensus for it, and the basis for
believing we can't do yet-more incremental enhancement to get it.
IMAP seems to be the one case where starting over is strongly worth
considering, and that is because of the continuing concern over its
complexity and the established challenges of getting it to work well.
As with others, I'm always concerned about the hype of
currently-fashionable technical choices; on the average, I take such
hype as serving to argue /against/ whatever is being promoted, if only
because the hype blinds folk from doing pragmatic analysis. But JSON
has been establishing a pretty reasonable track record of actual use in
a variety of applications.
So let's look at the proposal in two simple terms: Is there a need, and
does the existing proposal look like a good foundation for satisfying it?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp
_______________________________________________
ietf-smtp mailing list
ietf-smtp(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf-smtp