[Top] [All Lists]

Re: [ietf-smtp] Fwd: Request to form a new WG: JMAP

2016-11-09 14:34:38
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 

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 
    > 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?
       Dave Crocker
       Brandenburg InternetWorking
    ietf-smtp mailing list

ietf-smtp mailing list