Re: Fwd: Request to form a new WG: JMAP

> Hi Ned,

> If this work goes forward, there is definitely some wordsmithing to do
> to address your comments. Quick answers to some of them below:

Sounds good.

> On 07/11/2016 18:05, Ned Freed wrote:
> > Without getting into whether or not this is in general a good idea, I
> > want to
> > note that the proposal as written is self-contradictory, making it very
> > difficult to evaluate. In particular:
> >
> >> Name:    JSON Mail Access Protocol
> >> Acronym: jmap
> >> Area:    Applications and Real-Time Area (art)
> >
> >> Charter for Working Group
> >
> >> Many companies and projects are developing their own JSON based
> >> representations of email which 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.
> >
> > "Representation of email" would seem to imply that we're talking about
> > a new
> > message format.

> No, the email format is unchanged.

I note in passing that this is actually a departure from some of the
existing APIs, where messages are mapped into and out of JSON at least
some of the time.

> > Whoops! Now we're talking we're limiting ourselves to synchronization of
> > the client with the server.
> Yes, basically the IMAP side of things.
> > Which would seem to exclude SUBMIT, unless
> > you're doing SUBMIT with magic folders

> Most likely, yes.

And as I indicated previously, that's a problem, because magic folder are a
poor means of doing message submission, mostly because of their lousy error
handling.

I'll also note that none of the existing APIs I know of use magic folders. For
example, the Gmail API has two methods to send mail - message.send and
drafts.send, which return the error information you need. And the Outlook API
is very similar except that HTTP POST is used

But this really isn't the time to get into details. My point here is that if
you're going to do message submission, you need to get it right - something
essentially none of the current specifications do -  and that's going to
require an expansion of the model being proposed here.

				Ned

_______________________________________________
ietf-smtp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ietf-smtp