(Top Post)
Exactly. Could not have said it better myself.
There is one additional issue here. JMAP (or some hypothetical
xMAP) can either aspire to be a cleaner, more modern, less
LISP-like interface to (more or less, see below) the same
functionality as IMAP _or_ it can aspire to be a better idea,
with a different underlying architecture and/or reference model,
functionality, etc.
Can't have it both ways, at least without moving from
discussions about proxies and overlays and into discussions
about translators that are a lot more like gateways, gateways
that, like most of their predecessors, mostly work and mostly
preserve functionality and semantics.
My confusion about this effort -- and it has been considerable--
is that I've heard different statements claiming goals in both
categories. That isn't acceptable, if one because a WG proposal
for one approach should be evaluated differently from one
proposing the there one. The choice really must be made now
and, whatever it is, should be absolutely crystal-clear in the
charter... in addition to the things Dave describes below, which
should also be spelled out.
john
--On Monday, February 13, 2017 09:30 -0800 Dave Crocker
<dhc@xxxxxxxxxxxx> wrote:
> On 2/13/2017 9:17 AM, Dave Cridland wrote:
>> I don't think this is true.
> ...
>> JMAP, on the other hand, can cope with both gmail style
>> labels and IMAP-style mailboxes, by stated design.
>
>
> The constraints/flexibility of an effort depend on the goals
> it asserts and the support for those goals. I think it's
> dandy to target an access protocol that is substantially
> different from the features/style/whatever of IMAP. The
> requirements are to be very clear about the
> features/style/whatever of the new effort, very clear about
> the expected benefits, and very clear about the support for
> that.
>
> Given the long history of IMAP, the proposed JMAP effort
> should offer clear assertions of the relative differences and
> benefits of the new effort, to aid in assessing likely appeal
> of the effort.
>
> So, for example, the above comment about JMAP's handling of
> different reference models is substantive and appealing.
> However the various notes that have been posted about JMAP
> leave me thinking that there is less clarity about the effort
> than one would like, among JMAP's supporters.
>
> The embodiment of the clarity needs to be the charter text and
> I don't think it's made its case well enough. For example, I
> don't see a reference to the ability to support different
> referencing models.
>
> d/