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

From: Dave Crocker <[email-masked]>
Date: Mon, 6 Feb 2017 11:25:15 -0800

On 2/3/2017 4:26 PM, The IESG wrote:
> A new IETF WG has been proposed in the Applications and Real-Time Area.

A November version of this charter was circulated and while there have 
been some changes to produce the current draft charter, some issues 
noted earlier have not been reflected here (and did not receive comments 
in November.)

> JSON Mail Access Protocol (jmap)
> -----------------------------------------------------------------------
> Current status: Proposed WG
>
> Chairs:
>   TBD
>
> Assigned Area Director:
>   Alexey Melnikov <[email-masked]>
>
> Applications and Real-Time Area Directors:
>   Ben Campbell <[email-masked]>
>   Alissa Cooper <[email-masked]>
>   Alexey Melnikov <[email-masked]>
>
> Mailing list:
>   Address: [email-masked]
>   To subscribe: https://www.ietf.org/mailman/listinfo/jmap
>   Archive: https://mailarchive.ietf.org/arch/search/?email_list=jmap
>
> Group page: https://datatracker.ietf.org/group/jmap/
>
> Charter: https://datatracker.ietf.org/doc/charter-ietf-jmap/
>
> A number of JSON-based representations of email have been developed
> that are proprietary, non-standard, and incompatible with each other.
> These protocols are proliferating due
> to existing standards being insufficient or poorly suited to the
> environments they are operating in, particularly mobile and webmail.

 From my November comments:

      As with others, I take 'representations' to mean formats.  And 
given what JSON is[0] that seems an appropriate interpretation even 
without that word.  So I take this asserted need as having a form of 
email data format that is an alternative to RFC 5322/MIME.

      Prior to chartering, we should document just how extensive the 
current problem of multiple JSON email formats is, to establish the 
practical benefit of unifying it. The theoretical benefit should be 
obvious, but that's not enough to justify the cost of a working group. 
We should establish real market need.

      Having spent quite a bit of my early career on email gatewaying, 
I'll comment that getting a common interchange format is especially 
powerful.  The active protocols aren't irrelevant, but stabilizing the 
message object itself is, IMO, far more important. I'm more than a 
little biased about this strategic approach: It provided the unifying 
base for email, during the Internet's early growth into commercial 
markets.  And it happens that focusing on this narrow requirement 
permits end-to-end -- and I mean the real kind:  author to recipient, 
not just originating operator to receiving operator -- benefits without 
having to change the infrastructure, other than insertion of gateways.

      Working groups need task serialization.  So I'll suggest that 
having an effort to standardize an JSON representation of an 
RFC5322/MIME object would be the highest-leverage first task.

Adding to this:

JSON is a meta-format.  It isn't a 'protocol'.  Something encoded in 
JSON is a format, not a protocol.  Hence one of the tasks apparently 
being chartered would be to create a new message access protocol, 
encoded in JSON.  While that might be worth doing, there needs to be 
clarity that this is more than a 'representation'.  There also needs to 
be clarity about the relationship between the JSON encodings and the 
encodings in 'native' Internet Mail.

> The use of multiple protocols
> to perform actions within a single application creates significant
> support challenges, as users may get a variety of partial failure modes
> (for example, can receive email, but can not send new messages).
> This is further exacerbated if the different protocols are
> authenticated separately.

 From my November comments:

      There is no justification given for this approach.  For each 
activity, there needs to be a clear and solid need documented, based on 
actual industry activities or at least industry statements.  Besides 
clarifying /what/ needs doing, it should serve to indicate likely 
industry uptake after the work is done.

Adding to this:

The IETF email technical community looked at the question of making 
email submission part of IMAP or keeping it separate.  It took an entire 
year to debate this point extensively and (imo) constructively, and 
decided to keep them separate.  The current charter draft appears to 
have decided otherwise, but offers only the barest of justifications, 
which I suspect has not factored in the earlier evaluation.

> The JMAP working group will specify a mechanism to allow clients to
> both view and send email from a server over a single stateless HTTPS
> channel with minimal round trips. A single protocol for receipt and
> submission will resolve long-standing difficulties users face
> setting up clients to talk to servers.
>
> The protocol will support
> push notification of changes using the mechanism defined in RFC 8030.
> This will give mobile clients benefits in terms of battery life and
> network usage. It will also support push notifications via server-sent
> events (https://www.w3.org/TR/eventsource/) for direct connection to
> clients that can support persistent TCP connections.
>
> The work of this group is limited to developing a protocol for a client
> synchronising data with a server. Any server-to-server issues
> are out of scope for this working group.
> New end-to-end encryption mechanisms are out of scope, but the work
> should
> consider how to integrate with existing standards such as S/MIME and
> OpenPGP.

Why not TLS, also?

...

> The working group will deliver the following:
>
> - A problem statement detailing the deployment environment and
>   situations that motivate work on a new protocol for client to
>   server email synchronisation.  The working group may choose
>   not to publish this as an RFC.
>
> - A document describing an extensible protocol and data structures, with
>   support for flood control and batched operations, and operating over
>   a stateless connection such as HTTPS.

'flood control'?  what does this mean, since I assume the target 
protocol won't be using a flooding algorithm.  If it really means 
'congestion control', that's not typically part of an application 
protocol, so why would it be an issue here?

 From the November comments

      Since client/server email access typically benefits from having 
the server retain state about the client's activities, I can't tell 
whether this actually means stateless lower-level transport or whether 
it really does mean a stateless email protocol.  So this needs to be 
made much more clear, as to the what and the why, as well as to the 
benefit that will accrue.

      Given the considerable complexity of HTTP, I continue to fail to 
see why making it be a universal, lower-layer transport is so popular. 
Again, the need and the benefit need to be documented.

Adding to this:

    HTTP/HTTPS are not stateless, since they are connection-based.

> - A document describing how to use the extensible protocol over HTTPS
>   with the data structures expressed as JSON.
>
> - A document describing a data model for email viewing, management,
>   searching, and submission on top of the extensible protocol.
>
> - An executable test suite and documented test cases to assist
>   developers of JMAP servers to ensure they conform to the
>   specifications.

 From the November comments:

      This last is useful, but I think it's not typically an IETF work 
product?

d/

[0] http://www.json.org/
-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 6 Feb 2017 19:41:57 +0000

Hi Dave,

I am mostly proxying proponents of the Charter, but I did some editing 
pass over it, so I am replying to some of your comments.

On 06/02/2017 19:25, Dave Crocker wrote:
> noted earlier have not been reflected here (and did not receive 
> comments in November.)
>
>
> not just originating operator to receiving operator -- benefits 
> without having to change the infrastructure, other than insertion of 
> gateways.
>
I don't think there is intent to specify full mapping of RFC5322/MIME to 
JSON. IMAP has BODYSTRUCTURE element that contains parsed representation 
of message structure and most commonly used header fields for different 
body parts. The intent is to do the same here.
Additionally, it is still possible to retrieve full RFC5322/MIME 
payloads over JMAP.

I have tried to reflect your comments in the Charter, but I struggled a 
bit. If you can suggest how to make the above clearer, that would be 
much appreciated.
> clarity that this is more than a 'representation'.
No, it is a representation. See above.
> There also needs to be clarity about the relationship between the JSON 
> encodings and the encodings in 'native' Internet Mail.

See drafts (and above).
> activity, there needs to be a clear and solid need documented, based 
> on actual industry activities or at least industry statements.  
> Besides clarifying /what/ needs doing, it should serve to indicate 
> likely industry uptake after the work is done.

I am not sure what kind of justification is needed. This is a clear 
deployment problem.
> email submission part of IMAP or keeping it separate.  It took an 
> entire year to debate this point extensively and (imo) constructively, 
> and decided to keep them separate.  The current charter draft appears 
> to have decided otherwise, but offers only the barest of 
> justifications, which I suspect has not factored in the earlier 
> evaluation.
There was a followup discussion about doing an IMAP extension for 
submission and how it should look like to remain compatible with SMTP 
Submission. I don't think this is an attempt to just ignore earlier 
discussions.

>> consider how to integrate with existing standards such as S/MIME and

TLS is assumed. I think the Charter text says HTTPS elsewhere.
> it really does mean a stateless email protocol. 

Stateless lower level transport. The addition of "such as HTTPS" was 
trying to make this clearer.

> So this needs to be made much more clear, as to the what and the why, 
> as well as to the benefit that will accrue.
>

Presence of tools for manipulating JSON and ease of development. This 
was mentioned on the JMAP mailing list. I don't think this needs to be 
said here.

>    HTTP/HTTPS are not stateless, since they are connection-based.
Yeah, I struggled with this a bit. Each request/response can be sent on 
a separate connection and it is stateless in that sense.

>      This last is useful, but I think it's not typically an IETF work 

I don't mind deleting this, but I would like to see if IESG approves 
this as is ;-).

Best Regards,
Alexey

---

From: "Adrien de Croy" <[email-masked]>
Date: Mon, 06 Feb 2017 20:04:39 +0000

>>    HTTP/HTTPS are not stateless, since they are connection-based.
A lot of the people on the HTTP WG would have an issue with this 
statement.

In fact there has been a lot of discussion about the evils of 
connection-oriented anything in regard to HTTP, especially around 
authentication (e.g. NTLM).

There are proxies that reuse upstream connections between different 
clients, the protocol (1.1 at least) is designed to be stateless in 
terms of each message being independent of others, whether on the same 
connection or not.

So I wouldn't start a new protocol based on the presumption that 
HTTP/HTTPS is connection-oriented and not stateless.

---

From: Dave Crocker <[email-masked]>
Date: Mon, 6 Feb 2017 12:11:47 -0800

Alexey, thanks for the quick followup.

inline...

> Additionally, it is still possible to retrieve full RFC5322/MIME

This highlights the need to have far more clarity about what specific 
work is to be done and what is not.  The existing text has some generic 
out-of-scope text, but nothing as frankly useful as your above comment. 
Given that comment, I can't text what parts of the resulting jmap 
service will use 'native' Internet Mail technical details and what parts 
will be new-for-JSON.

> bit. If you can suggest how to make the above clearer, that would be

I make a point of offering candidate text when I think I understand the 
context and needs well enough.  Unfortunately I don't have that here. 
Hence, questions and general suggestions is the best I can offer.  Sorry.

> No, it is a representation. See above.

As soon as one says that the task is client/server interaction, one is 
declaring the goal of a protocol.  So it is more than just a format 
(representation.)

 >> encodings and the encodings in 'native' Internet Mail.

Drafts?  What drafts?  Perhaps you mean:

    https://tools.ietf.org/html/draft-jenkins-jmap

Except that no draft is cited in the charter.

> I am not sure what kind of justification is needed. This is a clear

As I said, there was a year-long, serious and diligent debate about this 
in the IETF and it came to a different conclusion.  So it's not nearly 
as 'clear' as you are asserting.

> Submission. I don't think this is an attempt to just ignore earlier

Discussion is different than deployment.  The fact that it isn't used 
now suggests that the benefit(s) you are asserting aren't as clear-cut 
as is being implied here.  To the extent that the current proposal does 
indeed represent a consideration of the prior, extended IETF work in 
this realm, the charter should indicate the basis for making a different 
choice here, in terms of the points considered earlier.

> trying to make this clearer.

Didn't succeed, given that HTTP runs over TCP.

> was mentioned on the JMAP mailing list. I don't think this needs to be

A new protocol is choosing to operate over a very complex substrate. 
Having some basic justification for that choice, in the charter, seems 
somewhere between appropriate and obligatory.

> a separate connection and it is stateless in that sense.

In other words, jmap will be stateless.  That's what the charter should say.

...Except that that seems odd, since it means that every exchange would 
have to self-identify and self-authorize.

I suspect that's not what's going to be defined.  So, really, it isn't 
obvious to me at all what will be stateless.

d/

-- 

   Dave Crocker

---

From: Neil Jenkins <[email-masked]>
Date: Tue, 07 Feb 2017 13:52:49 +1100

Hi

I'll try to clarify a few of these points.

*Message representation*

JMAP defines a JSON structure that represents in a consistent and
structured way all the information that the vast majority of clients
need from an RFC5322 message. The server deals with the complexities of
MIME, encoding issues, parsing headers etc. The intention is that the
server will still operate with RFC5322 messages for storage and
certainly transmission; the JSON representation is not intended to
replace RFC5322, just relieve client authors from having to deal with
it. Clients can also just fetch the properties they need, reducing
bandwidth overhead.

Clients that want to or need to (for example those doing PGP in the
client) can still fetch the RFC5322 if needed.

*Industry need*

A number of proprietary protocols have been popping up as
alternatives to IMAP, which all also have their own JSON
representation of message objects. Here are a few examples, the
latter two being from whole companies that formed just to try to help
people not have to deal with IMAP:

 * Gmail[1]
 * Outlook[2]
 * Nylas[3]
 * Context.io[4]

In addition, we’re seeing most new mobile email clients proxy everything
via their own server rather than talking directly to the user’s mail
store. Examples include Mailbox (now defunct), Alto, Outlook and Newton.
This is bad for security and privacy, and also bad for the client
authors as they have to run server infrastructure in addition to just
building their clients.

Despite not only being proprietary but patented (and expensive!),
ActiveSync has seen a big increase in adoption, and not just with
Microsoft servers, due to its better support for mobile environments and
ease of setup (one login for mail receive/send, contacts and calendars).

*Protocol vs representation*

JMAP is a protocol. It primarily defines a way of syncing data objects
in a network-efficient, developer friendly way. Objects are defined to
represent mailboxes, threads and messages in a consistent manner. These
are encoded as JSON for transmission over HTTPS.

*Message submission*

> likely industry uptake after the work is done.

This *is* based on industry statements. This is a very common support
problem we see here at FastMail, and from our conversations with other
mailbox vendors, we don't think this is just us.

*Flood control*

In IMAP, suppose you have a mailbox with 1,000,000 messages in it
selected, and another client expunges the lot. You get * 1 EXPUNGE
sent to you 1 million times (and you don't even know how many you are
going to receive); the only option is to drop the connection if it
gets too much. By flood control, we mean the client can ensure it does
not get flooded with data, especially important on low-bandwidth
connections like many mobile networks and in developing countries.
Reducing data usage is of course vital for saving battery, another key
concern for mobile.

Similarly, the server has well defined ways of rate limiting the
amount of work the client can ask it to do to ensure it too does
not get flooded and either accidentally or deliberately DOSed by
client requests.

*Why HTTP underneath*

The short answer is it’s good enough, widely understood and it’s by far
the easiest thing for developers to adopt. There’s support in basically
all OSes and programming languages. It’s easy to read and debug.

HTTP doesn’t tend to run into firewall issues, and is so commonly used
it has integrations which can help with optimisation (for example, iOS
has built-in support for optimising radio usage by batching HTTP calls
from different apps where possible, which their mail team have told us
they would like to be able to use). This isn’t an innate advantage of
HTTP, but rather an advantage of its ubiquity.

*Statelessness*

The protocol does not make use of any connection persistence to the
server. HTTPS may establish this underneath, but the protocol on top
is agnostic to it. Each request to the server contains an
authorisation token (in the Authorization header) to identify and
authenticate the request.

Neil.

Links:

  1. https://developers.google.com/gmail/api/v1/reference/
  2. https://msdn.microsoft.com/office/office365/APi/mail-rest-operations
  3. https://nylas.com/cloud/docs
  4. https://context.io/docs/lite

---

From: Gren Elliot <[email-masked]>
Date: Tue, 7 Feb 2017 03:26:45 -0800

Hi,

Just to add my voice to the call for easier configuration where we don’t
force users to configure countless different things.  Trying to setup a new
device for use with open protocols is a complete nightmare - you end up
needing to configure 2 things for mail (IMAP and SMTP) plus something for
Contacts (CardDAV - perhaps LDAP as well) plus something for Calendar
(CalDAV).  Many users, myself included are also at the mercy of frequent
forced password changes, which necessitate modifying the configuration of
each of these on each device.  Bizarrely, I suspect across 99% odd of use
cases, this separation is completely artificial as the same password is
used on the server for all services (and cannot be different because most
servers regard them as all relating to the same account).  This
configuration complexity must waste countless hours across the world and is
a major reason why businesses welcome ActiveSync - just to solve this one
huge problem with the open protocol landscape. There may be some good
esoteric academic reasons why keeping IMAP and message submission protocols
separate but I think the real world has clearly showed that the added
complexity is too expensive.

I believe JMAP is intending to extend from just Mail to encompass Calendar
and Contacts too and I truly hope it will (in a way that doesn’t require
servers to offer everything)

Folks at Calconnect and the IETF have been working on
https://tools.ietf.org/html/draft-daboo-aggregated-service-discovery-03 which
attempts to ease the configuration burden but that looks like being a long
process and needs buy in from device vendors to be really successful.  I
see most of the need behind this work as a sticky plaster trying to cover
up the un-necessary mess we have created :-(

It would be nice to see config dialogs where user’s are asked for minimal
information (user name, perhaps server name) and then the device discovers
what is available there (Mail/Contacts/Calendar/…) and offers the user a
way to select them and perhaps a choice of preferred client(s) to handle
each service.  The way Android handles some things, where a single bit of
software is responsible for server access and perhaps local caching and
other clients can provide UIs to access this is kind of neat too.

Regards,
Gren Elliot
Zimbra Software Engineer at Synacor

---

From: Dave Crocker <[email-masked]>
Date: Tue, 7 Feb 2017 06:21:00 -0800

On 2/7/2017 3:26 AM, Gren Elliot wrote:
> force users to configure countless different things.  Trying to setup a
> new device for use with open protocols is a complete nightmare - you end
> up needing to configure 2 things for mail (IMAP and SMTP)
...
> It would be nice to see config dialogs where user’s are asked for
> minimal information (user name, perhaps server name) and then the device
> discovers what is available there (Mail/Contacts/Calendar/…) and offers
> the user a way to select them and

This issue is for user interface design, not underlying protocol design. 
  Hence while it is extremely important in terms of usability, it is 
outside the scope of the IETF.

Having these functions embedded into a single protocol implicitly 
requires that these different functions share the same configuration 
data.  While such sharing might be common practice, requiring the 
sharing limits operational choices.

d/
-- 

   Dave Crocker

---

From: Ted Lemon <[email-masked]>
Date: Tue, 7 Feb 2017 10:18:45 -0500

On Feb 7, 2017, at 9:21 AM, Dave Crocker <[email-masked]> wrote:
> This issue is for user interface design, not underlying protocol design.  Hence while it is extremely important in terms of usability, it is outside the scope of the IETF.

I must beg to differ.   While it's true that we don't care explicitly about UI, we certainly care about enabling UIs that work.   Providing a query that returns the information required to send mail is definitely worth doing.   Of course, that could be just allowing a message to be uploaded, and having a command that says "deliver this message".   It's not clear to me that submission by way of SMTP is actually a win here—it's really an extra step, since you probably were going to save the draft using the mailbox protocol anyway.

---

From: Gren Elliot <[email-masked]>
Date: Tue, 7 Feb 2017 07:33:16 -0800

From: Dave Crocker <[email-masked]> <[email-masked]>
Reply: [email-masked] <[email-masked]> <[email-masked]>
Date: 7 February 2017 at 14:21:10
To: Gren Elliot <[email-masked]> <[email-masked]>
Cc: [email-masked] <[email-masked]> <[email-masked]>, iesg <[email-masked]>
<[email-masked]>, [email-masked] <[email-masked]> <[email-masked]>
Subject:  Re: [Jmap] WG Review: JSON Mail Access Protocol (jmap) - reducing
configuration complexity

...

With the current standards landscape, there is no way round the fact that
users (often not tech savvy ones) need to specify separate hostnames and
ports for IMAP and message submission, plus potentially URLs for CalDAV /
CardDAV (the latter 2 could reasonably be combined without IETF help but
sadly seldom are).  Without further standardisation, no wonderful interface
design can escape from that.  I certainly think that it should be within
the scope of the IETF to improve the standards to the point where good
interface design is possible.  That doesn’t actually require moving to a
single protocol.  As mentioned before in relation to aggregated service
discovery, this could be achieved by standardising a bootstrapping
mechanism where the user only provides minimal information which points to
a store of detailed configuration information that the user never needs to
be aware of.  Alternatively, or perhaps in addition, having a single
protocol would achieve most of the same aims - much as ActiveSync achieves
and I hope JMAP will achieve.

Requiring sharing would indeed limit operational choices - so it shouldn’t
be required.  I think it is important that a JMAP service should be able to
offer (and advertise) whatever subset of full services it wants to.  In the
most common situation, a single JMAP service would provide mail access,
mail submission, contacts access, calendar access etc, but there is no
reason why multiple, dedicated JMAP services couldn’t be used, one just
doing mail access, one doing mail submission etc.  In the most common
situation, you would be much better off than you are now.  In the other
case, you would be no worse off than you are currently and at least there
would be consistency in how you configure each service.
Regards,
Gren Elliot

---

From: Bron Gondwana <[email-masked]>
Date: Wed, 08 Feb 2017 08:49:39 +1100

> outside the scope of the IETF.

This reasoning is why so many non-IETF protocols have been gaining marketshare in the client space.  The underlying protocols need to support usable interface design, and be simple enough to implement that somebody who wants to write a great new email client doesn't spend their first 6 months fighting the protocols and then give up.

> sharing limits operational choices.

As others have already said, there's nothing stopping individual JMAP accounts from offering different facilities (except for sending and receiving mail, where the sending at least needs to be tied to an account which supports an Outbox - I guess in theory you could just make the email disappear from the Outbox after sending and have no facility to fetch new mail, though you'd want a Draft folder as well with storage capability, and you also need storage capability for uploaded attachments.)

That said, if all you want to do is sent email with no access to read, JMAP is probably the wrong choice for this very specific thing.  That's fine, JMAP isn't trying to solve every problem in a compromised way, it's trying to solve a very common use case very well.  Making things much harder for 99.9% of users so that they're a little easier for 0.1% of users is far too common a failure mode of designing standards that try to be everything for everybody.

-- 
  Bron Gondwana
  [email-masked]

---

From: The IESG <[email-masked]>
Date: Fri, 03 Feb 2017 16:26:02 -0800

A new IETF WG has been proposed in the Applications and Real-Time Area.
The IESG has not made any determination yet. The following draft charter
was submitted, and is provided for informational purposes only. Please
send your comments to the IESG mailing list ([email-masked]) by
2017-02-13.

Chairs:
  TBD

Assigned Area Director:

Mailing list:
  Address: [email-masked]

The working group will coordinate with the Security Area on credential
management and authentication.

Input to working group discussions shall include:

- CONDSTORE and QRESYNC
[RFC 7162]

- Collection Synchronisation for WebDav
[RFC 6578]

- LEMONADE and experiences from adoption of its output
[https://datatracker.ietf.org/wg/lemonade/charter/]

- SMTP SUBMISSION
[RFC 6409]

- SMTP BURL
[RFC 4468]

Milestones:

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 6 Feb 2017 16:01:58 -0500

On Mon, Feb 6, 2017 at 3:04 PM, Adrien de Croy <[email-masked]> wrote:

> clients, the protocol (1.1 at least) is designed to be stateless in terms
> of each message being independent of others, whether on the same connection
> or not.
>

​+1

I was hoping we could go a different route here:

1) Write the QUIC protocol. Gives us a multiplexed TCP capability
2) Write a thin shim on QUIC for Web services to replace HTTP presentation
3) Use the result and JSON encoding as the presentation layer for AppsNG​

​Doing JMAP on QUIC right now is error 32: Research on Research. But doing
JMAP on HTTP means inventing a second MUX layer. Also bad.​

​There is clearly potential ​to improve on IMAP user experience. GMAIL
isn't very much different but it is a lot more responsive because the
protocol does things like return the overviews for the 20 latest headers
that the app is trying to present to the user rather than the client going
into hyperspace as it downloads 15 years of messages.

Yes, I know it is possible to do some of the same stuff if the
application's IMAP foo is really good. But being able to optimize the round
trips because you control both ends of the protocol is very powerful.

HTTP has a lot of cruft in it to support browsers running on the 1990s
Internet when the whole continent of Australia was connected by a 56Kb
dialup and T1 was considered lightning fast. And one of the problems with
that sort of cruft is that no matter how rubbish it is or how many problems
it creates, there will always be people who squeak if you try to take it
out.

I am profoundly unimpressed by arguments about using HTTP features like
caching in Web services. If HTTP caching works for your Web Service it is
probably because what you are doing is re-implementing HTTP in HTTP badly.

---

From: Randy Bush <[email-masked]>
Date: Tue, 07 Feb 2017 23:11:41 +0900

> Trying to setup a new device for use with open protocols is a complete
> nightmare - you end up needing to configure 2 things for mail (IMAP
> and SMTP)

and now, because we will have to be backward compatible, it will be
three.  so that third had best be a really massive win.  and i am not
seeing it.  what i am seeing is second system syndrome in a wrapper of
whatever today's wrapping fashion is.

randy

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 8 Feb 2017 13:11:46 +0000

Bron Gondwana writes:
> This reasoning is why so many non-IETF protocols have been 
> gaining marketshare in the client space.  The underlying 
> protocols need to support usable interface design, and be simple 
> enough to implement that somebody who wants to write a great new 
> email client doesn't spend their first 6 months fighting the 
> protocols and then give up.

This, +1.

There are things I don't like about the JMAP document. Noone seems to bring 
any of them up. Instead we get things like "IETF protocols in this space 
must support having one password for sending mail and another for reading". 
Bleh.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 8 Feb 2017 13:34:55 +0000

Hi Dave,

> Except that no draft is cited in the charter.

I realized that I accidentally deleted an important sentence from the 
Charter while doing editing. One of the paragraphs should have read:

The work of this group is limited to developing a protocol for a client
synchronising data with a server. The work will be based on
draft-jenkins-jmap and draft-jenkins-jmapmail. Any server-to-server issues
are out of scope for this working group.
New end-to-end encryption mechanisms are out of scope, but the work should
consider how to integrate with existing standards such as S/MIME and 
OpenPGP.

Best Regards,
Alexey

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 8 Feb 2017 13:39:19 +0000

Dave,

On 06/02/2017 20:11, Dave Crocker wrote:
> work is to be done and what is not.  The existing text has some 
> generic out-of-scope text, but nothing as frankly useful as your above 
> comment. Given that comment, I can't text what parts of the resulting 
> jmap service will use 'native' Internet Mail technical details and 
> what parts will be new-for-JSON.
>
>
> I make a point of offering candidate text when I think I understand 
> the context and needs well enough.  Unfortunately I don't have that 
> here. Hence, questions and general suggestions is the best I can 
> offer.  Sorry.
>
>
>>> Adding to this:
>>>
> As I said, there was a year-long, serious and diligent debate about 
> this in the IETF and it came to a different conclusion.  So it's not 
> nearly as 'clear' as you are asserting.
>
>
>>> Adding to this:
>>>
> as is being implied here.  To the extent that the current proposal 
> does indeed represent a consideration of the prior, extended IETF work 
> in this realm, the charter should indicate the basis for making a 
> different choice here, in terms of the points considered earlier.
>
>
>

The protocol is HTTP version agnostic, for the most part.
The original thought was that it is less stateful than IMAP, which 
requires a mailbox to be opened for some operation. But the server still 
needs to maintain state (for example to track flag modifications). So 
saying "stateless" is incorrect, so I deleted it in 2 places in the Charter.

  [...]

> ...Except that that seems odd, since it means that every exchange 
> would have to self-identify and self-authorize.
True.
> obvious to me at all what will be stateless.

As you pointed out, saying stateless is not really correct.

Best Regards,
Alexey

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 9 Feb 2017 12:05:20 -0500

One big improvement on the status quo would be to combine the functionality
of IMAP and SUBMIT.

Having two different protocols doesn't work folk. Particularly since
authentication remains a bad joke in SMTP and IMAP. I just sent three
copies of the same message to my CEO because my mail app thought it hadn't
been sent at all and kept retrying.