Re: Fwd: Re: [Jmap] Fwd: Re: WG Review: JSON Mail Access Protocol (jmap)

+1 to both points.  With regard to changed proposals, the
charter improvements will help, but there have been several
comments that imply people have ideas about how to "do things
better" that would invalidate that compatibility assessment.
The combination of the charter, your choices about WG
leadership, and fairly aggressive monitoring need to prevent
such an outcome.

best,
   john


--On Thursday, February 16, 2017 17:15 -0800
ned+ietf(_at_)mauve(_dot_)mrochek(_dot_)com wrote:

> > John and Ned,
> > On 12/02/2017 20:15, John C Klensin wrote:
> > > --On Wednesday, February 8, 2017 12:39 -0800 Ned Freed
> > > <ned(_dot_)freed(_at_)mrochek(_dot_)com>  wrote:
> >   [snip]
> > > > (2) in particular creates additional requirements that
> > > > need to be explicitly called out in the charter. In
> > > > particular, it's imperative that (a) It be reasonable to
> > > > implement JMAP->IMAP/SUBMIT proxies, even if that
> > > > constrains JMAP in ways some folks do not like, (b) The
> > > > list of IMAP extensions needed to properly implement JMAP
> > > > be called out, and (c) The security considerations
> > > > involved in operating such a proxy need to be described in
> > > > detail.
> > I updated Charter text to mention these.
> Good.
>
> > > Exactly.  If one expects JMAP to be wildly successful, and
> > > unless there is either a plausible plan to make all of those
> > > IMAP clients go away (even if there are no new ones), I
> > > think that list should include either its being reasonable
> > > to implement and support IMAP/SUBMIT-> JMAP proxies or other
> > > overlays or a charter requirement to discuss residual use
> > > cases for IMAP.    I'm particularly concerned about
> > > supporting IMAP-native clients with a JMAP-native mailstore.
> > >
> > > > > 2). Both are supported by the same software (i.e. Cyrus
> > > > > and Dovecot use case). I doubt that incremental cost of
> > > > > configuring both is much higher than just configuring one
> > > > > of them.
> > > > > In either case configuring JMAP clients is a simple(r)
> > > > > proposition: just distribute HTTP URI for a JMAP instance.
> > > > > > and to support, also for a long time, the ability to
> > > > > > convert between the two formats.
> > > > > There are no 2 formats, both IMAP and JMAP operate on RFC
> > > > > 5322 objects, so the rest of your argument is invalid.
> > > > Agreed. I have to say I really don't understand the
> > > > confusion surrounding this point. IMAP has bodystructure
> > > > plus a couple of other formats for returning message data,
> > > > and a means of creating new messages from pieces of other
> > > > messages, none of which look remotely like MIME/RFC 5322,
> > > > and nobody cares.
> > > >
> > > > This is effectively the same thing; why should anyone care
> > > > here?
> > > I can't speak for anyone else, but I'm concerned about what
> > > it takes to create and maintain servers and mailstores that
> > > are compatible with both IMAP and JMAP.  If that means
> > > proxies, we either need to address the question of IMAP
> > > proxies over JMAP and JMAP mailstores as well as the JMAP
> > > over IMAP-compatible ones or I'd like the charter is
> > > require a good explanation of why that isn't necessary.
> > > That might be "IMAP-based systems with JMAP overlays
> > > forever", but, the more people argue that JMAP will take
> > > over (rapidly or otherwise), the less plausible that
> > > position feels.
> > I've done some prototyping of existing JMAP proposal and I am
> > quite confident that underlying models are close enough that
> > implementing one on top of another is doable. IMAP+QRESYNC
> > extension require IMAP mailstores to store change sequence
> > numbers, which is required feature in JMAP.
> I agree with the assessment, but what if the propsoal changes
> substantially?
> That's the case I'm worried about.
>
>                               Ned