Subject: [Extra] RFC4466 and fetch responses

From: Bron Gondwana <[email-masked]>
Date: Thu, 12 Apr 2018 15:08:46 +1000

One thing I notice is that RFC4466 doesn't provide suggested structure
for fetch responses, but RFC4551 defined the fetch MODSEQ response as:

MODSEQ ( <permsg-modsequence> )
Which seems clearly to be that the intent at the time was that all new
FETCH responses would be wrapped, since that's nothing more exciting
than a string of digits, and FETCH responses have unwrapped values that
can be LITERAL like RFC822 or otherwise complexly structured like
BODYSTRUCTURE.
So:

C: 26 fetch 1:* (emailid threadid)
S: * 1 FETCH (EMAILID M820545e479bbb58345c66b88 THREADID T13f69c0572d2be91)S: * 2 FETCH (EMAILID M50f1074ce64d74cfb5f194fa THREADID Tc102deaded247fdd)S: 26 OK Completed (0.000 sec)

Should they be wrapped as well?

C: 26 fetch 1:* (emailid threadid)
S: * 1 FETCH (EMAILID (M820545e479bbb58345c66b88) THREADID (T13f69c0572d2be91))S: * 2 FETCH (EMAILID (M50f1074ce64d74cfb5f194fa) THREADID (Tc102deaded247fdd))S: 26 OK Completed (0.000 sec)

---

Thoughts?

Bron.

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

---

From: Michael Slusarz <[email-masked]>
Date: Fri, 13 Apr 2018 08:28:06 -0600 (MDT)

> On April 11, 2018 at 11:08 PM Bron Gondwana <[email-masked]> wrote: 
>  
> 
> One thing I notice is that RFC4466 doesn't provide suggested structure for fetch responses, but RFC4551 defined the fetch MODSEQ response as: 
>  
> Which seems clearly to be that the intent at the time was that all new FETCH responses would be wrapped, since that's nothing more exciting than a string of digits, and FETCH responses have unwrapped values that can be LITERAL like RFC822 or otherwise complexly structured like BODYSTRUCTURE. 

In a (soon-to-be submitted for review) RFC we've been working on, I too followed the "new" MODSEQ approach of wrapping everything in the response after the FETCH attribute identifier in parentheses:

msg-att-dynamic =/ "SNIPPET" SP "(" snippet-alg SP nstring ")"

Granted, the response in question has more than one element so it logically should be grouped using parentheses, but there's also nothing inherently wrong with a one-element list either.

This response decision has been implemented and exists in released versions of Dovecot, so we will not be changing the implementation. 

> S: * 1 FETCH (EMAILID M820545e479bbb58345c66b88 THREADID T13f69c0572d2be91) 
> S: * 2 FETCH (EMAILID M50f1074ce64d74cfb5f194fa THREADID Tc102deaded247fdd) 
> S: 26 OK Completed (0.000 sec) 
>  
> S: * 1 FETCH (EMAILID (M820545e479bbb58345c66b88) THREADID (T13f69c0572d2be91)) 
> S: * 2 FETCH (EMAILID (M50f1074ce64d74cfb5f194fa) THREADID (Tc102deaded247fdd)) 
> S: 26 OK Completed (0.000 sec) 
> 
>  
> --- 
>  
> Thoughts? 

I agree that the latter example is more correct - or at least consistent with the way that we added a new FETCH attribute.

michael

---

From: Bron Gondwana <[email-masked]>
Date: Sat, 14 Apr 2018 11:54:52 +1000

Great. I've already updated my code and deployed it in our testing
infrastructure, so I'll update the spec to match.
I'm interested in this snippet draft. We already do snippets in Cyrus
with a custom command, so making it match would be great.
Cheers,

Bron.

On Sat, 14 Apr 2018, at 00:28, Michael Slusarz wrote:
>> On April 11, 2018 at 11:08 PM Bron Gondwana
>> <[email-masked]> wrote:>> 
>> 
>> One thing I notice is that RFC4466 doesn't provide suggested
>> structure for fetch responses, but RFC4551 defined the fetch MODSEQ
>> response as:>>  
>> Which seems clearly to be that the intent at the time was that all
>> new FETCH responses would be wrapped, since that's nothing more
>> exciting than a string of digits, and FETCH responses have unwrapped
>> values that can be LITERAL like RFC822 or otherwise complexly
>> structured like BODYSTRUCTURE.> 
> In a (soon-to-be submitted for review) RFC we've been working on, I
> too followed the "new" MODSEQ approach of wrapping everything in the
> response after the FETCH attribute identifier in parentheses:> 
> Granted, the response in question has more than one element so it
> logically should be grouped using parentheses, but there's also
> nothing inherently wrong with a one-element list either.> 
> This response decision has been implemented and exists in released
> versions of Dovecot, so we will not be changing the implementation.> 
>> So:
>>  
>> S: * 1 FETCH (EMAILID M820545e479bbb58345c66b88 THREADID
>>    T13f69c0572d2be91)>> S: * 2 FETCH (EMAILID M50f1074ce64d74cfb5f194fa THREADID
>>    Tc102deaded247fdd)>> S: 26 OK Completed (0.000 sec)
>>  
>> S: * 1 FETCH (EMAILID (M820545e479bbb58345c66b88) THREADID
>>    (T13f69c0572d2be91))>> S: * 2 FETCH (EMAILID (M50f1074ce64d74cfb5f194fa) THREADID
>>    (Tc102deaded247fdd))>> S: 26 OK Completed (0.000 sec)
>> 
>>  
>> ---
>>  
>> Thoughts?
> 
> I agree that the latter example is more correct - or at least
> consistent with the way that we added a new FETCH attribute.> 
> michael

---

From: Michael Slusarz <[email-masked]>
Date: Mon, 16 Apr 2018 13:31:56 -0600 (MDT)

Hi Bron,

Snippet Draft has been submitted to:

https://datatracker.ietf.org/doc/draft-slusarz-imap-fetch-snippet/

michael

> On April 13, 2018 at 7:54 PM Bron Gondwana <[email-masked]> wrote:
> 
>     Great. I've already updated my code and deployed it in our testing infrastructure, so I'll update the spec to match.
> 
>     I'm interested in this snippet draft. We already do snippets in Cyrus with a custom command, so making it match would be great.
> 
>     Cheers,
> 
>     Bron.
> 
> 
> >             > > >             On April 11, 2018 at 11:08 PM Bron Gondwana < [email-masked] mailto:[email-masked] > wrote:
> > > 
> > >

---

From: Bron Gondwana <[email-masked]>
Date: Tue, 17 Apr 2018 11:15:26 +1000

I've had a read through.  It looks like it could be used to implement
what we've called "preview" in JMAP.  The "preview" field in the JMAP
Email object is a close match to SNIPPET=FUZZY.  It's defined like this:
http://jmap.io/spec-mail.html#email/get

*preview*: String (immutable; server-set) Up to 256 characters of plain
text, summarising the message body. This is intended to be shown as a
preview line on a mailbox listing, and may be truncated when shown. The
server may choose which part of the message to include in the preview,
for example skipping quoted sections and salutations and collapsing white-
space can result in a more useful preview.
Is there a reason why you chose 100 and 200 characters specifically for
the lengths?  We should definitely agree on a matching length across the
two protocols.  I think that's the only inconsistency with FUZZY.
============

Meanwhile, JMAP also adds another type of snippet, the "SearchSnippet".
This is based on our experience with the XSNIPPETS command in Cyrus
IMAPd and the FastMail interface built on it, which looks like this: 

The JMAP version is documented here:

http://jmap.io/spec-mail.html#searchsnippet/get

This is really quite useful from a user perspective, having search-
related previews in a search!  The XSNIPPETS command in Cyrus is
basically a SEARCH, except it emits a matching SNIPPET response for each
message rather than just a list of IDs.
Cheers,

Bron.

>> On April 13, 2018 at 7:54 PM Bron Gondwana
>> infrastructure, so I'll update the spec to match.>> 
>> with a custom command, so making it match would be great.>> 
>> Cheers, 
>> 
>> Bron.
>> 
>> 
>>>> On April 11, 2018 at 11:08 PM Bron Gondwana <
>>>> [email-masked]> wrote:>>>> 
>>>> 
>>>> response as:>>>>   
>>>> exciting than a string of digits, and FETCH responses have
>>>> unwrapped values that can be LITERAL like RFC822 or otherwise
>>>> complexly structured like BODYSTRUCTURE.>>> 
>>> response after the FETCH attribute identifier in parentheses:>>> 
>>> nothing inherently wrong with a one-element list either.>>> 
>>> versions of Dovecot, so we will not be changing the implementation.>>> 
>>>> So: 
>>>>   
>>>>    T13f69c0572d2be91)>>>> S: * 2 FETCH (EMAILID M50f1074ce64d74cfb5f194fa THREADID
>>>>    Tc102deaded247fdd)>>>> S: 26 OK Completed (0.000 sec) 
>>>>   
>>>>    (T13f69c0572d2be91))>>>> S: * 2 FETCH (EMAILID (M50f1074ce64d74cfb5f194fa) THREADID
>>>>    (Tc102deaded247fdd))>>>> S: 26 OK Completed (0.000 sec) 
>>>> 
>>>>   
>>>> --- 
>>>>   
>>>> Thoughts? 
>>> 
>>> consistent with the way that we added a new FETCH attribute.>>> 
>>> michael 
>

---

From: Bron Gondwana <[email-masked]>
Date: Wed, 18 Apr 2018 07:28:57 +1000

By the way - I figure given our timelines and how busy we are with
other documents, putting a call for adoption for this document on the
agenda for Montreal will be plenty early enough!  Are you likely to
make it to Montreal?
Cheers,

Bron.

> _________________________________________________
> Extra mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/extra