Subject: Re: [Jmap] New draft: JMAP IMAPDATA

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Mar 2018 15:05:14 +0000

Hmm.  I get that, but then really what does it have to do with JMAP?  Why
not just use IMAP for this use case?  Or define an IMAP shim for http to
cover it. My worry is that we will wind up back in the IMAP world of many
optional features, which has a really clear track record of breaking
interop in subtle ways.

On Mar 22, 2018 11:39, "Bron Gondwana" <[email-masked]> wrote:

Absolutely, there's no way it should be part of the core specification, and
there's no requirement to implement it.  I would expect a server that
didn't have an IMAP datastore under it wouldn't offer it.

Bron.

On Thu, 22 Mar 2018, at 22:37, Dave Richards wrote:

Is there a broader use case?  My gut feel is that it compromises
JMAP....but given it’s an extension, it’s not a compromise on the core
promise.

 <http://www.atmail.com/>

*DAVE RICHARDS*  * Chief Executive Officer*
*e.* [email-masked] <[email-masked]>  *p.* +61
404 005 116 <+61404005116>
22/224 David Low Way, Peregian Beach, QLD, Australia
*atmail.com <http://atmail.com/>*      *Your brand. Your email.*

On 22 Mar 2018, at 21:24, Bron Gondwana <[email-masked]> wrote:

For me - it's admin and debugging tools.

On Thu, 22 Mar 2018, at 22:20, Dave Richards wrote:

Hi Bron,

What’s the use case?

Dave

 <http://www.atmail.com/>

*DAVE RICHARDS*  * Chief Executive Officer*
*e.* [email-masked] <[email-masked]>  *p.* +61
404 005 116 <+61404005116>
22/224 David Low Way, Peregian Beach, QLD, Australia
*atmail.com <http://atmail.com/>*      *Your brand. Your email.*

On 22 Mar 2018, at 21:14, Bron Gondwana <[email-masked]> wrote:

On Thu, 22 Mar 2018, at 20:35, Ted Lemon wrote:

On Mar 22, 2018, at 5:04 AM, Dave Richards <[email-masked]>
wrote:

What's the use case here?

I tend to agree with Dave. This looks like it would just introduce new
interop problems. Now we have IMAP-aware JMAP clients and non-IMAP-aware
clients that will have different behavior. How is this a win?

I'm confused about what you think the issue is.  It's an optional extension
which if the server doesn't implement it, you don't see the options at all.

It's just to allow IMAP-aware clients to be able to match metadata between
the two systems, or to allow administration tools to see the underlying
IMAP metadata for messages.

(It's also an example of an extension that touches a bit more than S/MIME)

Bron.

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email-masked]

_______________________________________________
Jmap mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jmap

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email-masked]

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [email-masked]

_______________________________________________
Jmap mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/jmap

Subtle

---

From: Bron Gondwana <[email-masked]>
Date: Fri, 23 Mar 2018 02:42:53 +1100

Putting my chair hat on for a second, it's clear this draft does not
enjoy consensus for adoption as a working group document.
Putting my author hat back on, that's fine - I have no burning need for
it to be a general standard.  I'll keep revising it and leave it shelved
for now.  I'll implement it in our servers as a vendor extension.
The good thing about JMAPs vendor extension mechanism is: if you don't
want it, the server has to act as if it's not even there, so it can't
pollute anything else.
Cheers,

Bron.

On Fri, 23 Mar 2018, at 02:05, Ted Lemon wrote:
> Hmm.  I get that, but then really what does it have to do with JMAP?
> Why not just use IMAP for this use case?  Or define an IMAP shim for
> http to cover it. My worry is that we will wind up back in the IMAP
> world of many optional features, which has a really clear track record
> of breaking interop in subtle ways.> 
> On Mar 22, 2018 11:39, "Bron Gondwana" <[email-masked]> wrote:>> __
>> Absolutely, there's no way it should be part of the core
>> specification, and there's no requirement to implement it.  I would
>> expect a server that didn't have an IMAP datastore under it wouldn't
>> offer it.>> 
>> Bron.
>> 
>> 
>>> JMAP....but given it’s an extension, it’s not a compromise on the
>>> core promise.>>> 
>>> 
>>> 
>>> 
>>> atmail logo
>>>  
>>> *e.* [email-masked][1]  *p.* +61 404 005 116[2]
>>> 22/224 David Low Way, Peregian Beach, QLD, Australia *atmail.com[3]*
>>>    *Your brand. Your email.*>>> 
>>> 
>>> On 22 Mar 2018, at 21:24, Bron Gondwana <[email-masked]>
>>> wrote:>>>> For me - it's admin and debugging tools.
>>>> 
>>>> 
>>>>> atmail logo
>>>>> *e.* [email-masked][4]  *p.* +61 404 005 116[5]
>>>>>    *atmail.com[6]*      *Your brand. Your email.*>>>>> 
>>>>> 
>>>>> On 22 Mar 2018, at 21:14, Bron Gondwana <[email-masked]>
>>>>> wrote:>>>>>> 
>>>>>>> On Mar 22, 2018, at 5:04 AM, Dave Richards
>>>>>>> <[email-masked][7]> wrote:>>>>>>>> What's the use case here?  
>>>>>>> 
>>>>>>> I tend to agree with Dave. This looks like it would just
>>>>>>> introduce new interop problems. Now we have IMAP-aware JMAP
>>>>>>> clients and non-IMAP-aware clients that will have different
>>>>>>> behavior. How is this a win?>>>>>> 
>>>>>> I'm confused about what you think the issue is.  It's an optional
>>>>>> extension which if the server doesn't implement it, you don't see
>>>>>> the options at all.>>>>>> 
>>>>>> It's just to allow IMAP-aware clients to be able to match
>>>>>> metadata between the two systems, or to allow administration
>>>>>> tools to see the underlying IMAP metadata for messages.>>>>>> 
>>>>>> (It's also an example of an extension that touches a bit more
>>>>>> than S/MIME)>>>>>> 
>>>>>> Bron.
>>>>>> 
>>>>>> --
> _________________________________________________
> Jmap mailing list
> [email-masked]

Links:

  1. mailto:[email-masked]
  2. tel:+61404005116
  3. http://atmail.com/
  4. mailto:[email-masked]
  5. tel:+61404005116
  6. http://atmail.com/
  7. mailto:[email-masked]..com