Subject: [Jmap] New draft: JMAP IMAPDATA

From: Bron Gondwana <[email-masked]>
Date: Thu, 22 Mar 2018 01:07:09 +1100

Hi all,

As promised, I have written an initial draft of an extension for JMAP
Mail to allow access to data about the underlying IMAP store, including
CONDSTORE data and SAVEDATE (from EXTRA).
https://datatracker.ietf.org/doc/draft-gondwana-jmap-imapdata/

It's very much a first-pass draft.  It's designed to deal with the
possibility that there can be multiple messages with the same MSGID
(Email/id) in any one mailbox, so it has a double-depth hash, which we
haven't seen in JMAP before.
This kind of deep structure may suggest a need to look at a syntax for
pattern matching properties:
["Email/get", {
  "ids": [x, y, z],
  "properties": [ "imapdata/*/*/savedate" ],
}, "n"]

And it certainly raises questions about whether '/' should be allowed in
ids.  Arnt raised the same issue over in the EXTRA working group.
Cheers,

Bron.

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

---

From: Dave Richards <[email-masked]>
Date: Thu, 22 Mar 2018 15:04:15 +1000

Hi Bron,

What's the use case here?  

My feeling is that even if IMAP is packaged into the server, or behind the JMAP service (as is the case for atmail), this should be incidental to the JMAP service and such an extension undermines JMAP as a standard.  Thoughts?

Dave

> On 22 Mar 2018, at 12:07 am, Bron Gondwana <[email-masked]> wrote:
> 
> Hi all,
> 
> As promised, I have written an initial draft of an extension for JMAP Mail to allow access to data about the underlying IMAP store, including CONDSTORE data and SAVEDATE (from EXTRA).
> 
> https://datatracker.ietf.org/doc/draft-gondwana-jmap-imapdata/ <https://datatracker.ietf.org/doc/draft-gondwana-jmap-imapdata/>
> 
> It's very much a first-pass draft.  It's designed to deal with the possibility that there can be multiple messages with the same MSGID (Email/id) in any one mailbox, so it has a double-depth hash, which we haven't seen in JMAP before.
> 
> This kind of deep structure may suggest a need to look at a syntax for pattern matching properties:
> 
> ["Email/get", {
>   "ids": [x, y, z],
> And it certainly raises questions about whether '/' should be allowed in ids.  Arnt raised the same issue over in the EXTRA working group.
> 
> Cheers,
> 
> Bron.
> 
> --
>   [email-masked] <mailto:[email-masked]>
> 
> 
> _______________________________________________
> Jmap mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/jmap <https://www.ietf.org/mailman/listinfo/jmap>

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

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 22 Mar 2018 08:34:27 +0000

Hi Dave,

> On 22 Mar 2018, at 05:04, Dave Richards <[email-masked]> wrote:
> 
> Hi Bron,
> 

With a disclaimer that I haven’t read this draft yet:

Alignment with IMAP is a part of our Charter, so personally I don’t think so.

Best Regards,
Alexey

>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/jmap
> 
> 
> 
> 
> 
>  
> e. [email-masked]  p. +61 404 005 116
> atmail.com     Your brand. Your email.    
> 
> 
> 
> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/jmap

---

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

> 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?

---

From: Bron Gondwana <[email-masked]>
Date: Thu, 22 Mar 2018 22:14:57 +1100

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.

---

From: Dave Richards <[email-masked]>
Date: Thu, 22 Mar 2018 21:20:46 +1000

Hi Bron,

What’s the use case?

Dave

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

> On 22 Mar 2018, at 21:14, Bron Gondwana <[email-masked]> wrote:
> 
> 
> 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.
> 
> --

---

From: Bron Gondwana <[email-masked]>
Date: Thu, 22 Mar 2018 22:24:55 +1100

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
> 
> 
> 
> 
> atmail logo
>  
> *DAVE RICHARDS*  * Chief Executive Officer* *e.*
> [email-masked]  *p.* +61 404 005 116[1]> 22/224 David Low Way, Peregian Beach, QLD, Australia *atmail.com[2]*
>    *Your brand. Your email.*> 
> 
> On 22 Mar 2018, at 21:14, Bron Gondwana
> <[email-masked]> wrote:>> 
>>> <[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?>> 
>> options at all.>> 
>> underlying IMAP metadata for messages.>> 
>> (It's also an example of an extension that touches a bit more than
>> S/MIME)>> 
>> Bron.
>> 
>> --

Links:

  1. tel:+61404005116
  2. http://atmail.com/

---

From: Dave Richards <[email-masked]>
Date: Thu, 22 Mar 2018 21:37:18 +1000

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.

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

---

From: Bron Gondwana <[email-masked]>
Date: Thu, 22 Mar 2018 22:39:01 +1100

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.> 
> 
> 
> 
> atmail logo
>  
> On 22 Mar 2018, at 21:24, Bron Gondwana
> <[email-masked]> wrote:>> For me - it's admin and debugging tools.
>> 
>> 
>>> [email-masked]  *p.* +61 404 005 116[3]>>> 22/224 David Low Way, Peregian Beach, QLD, Australia *atmail.com[4]*
>>>    *Your brand. Your email.*>>> 
>>> 
>>> On 22 Mar 2018, at 21:14, Bron Gondwana <[email-masked]>
>>> wrote:>>>> 
>>>>> <[email-masked]> wrote:>>>>>> What's the use case here?  
>>>>> 
>>>>> aware clients that will have different behavior. How is this a
>>>>> win?>>>> 
>>>> extension which if the server doesn't implement it, you don't see
>>>> the options at all.>>>> 
>>>> between the two systems, or to allow administration tools to see
>>>> the underlying IMAP metadata for messages.>>>> 
>>>> S/MIME)>>>> 

Links:

  1. tel:+61404005116
  2. http://atmail.com/
  3. tel:+61404005116
  4. http://atmail.com/