Re: [Extra] Snippet Draft Submitted (was Re: RFC4466 and fetch responses)

[Bron Gondwana <[e-mail]>]

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 Tue, 17 Apr 2018, at 05:31, Michael Slusarz wrote:
> 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
>> <[e-mail]> 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 Sat, 14 Apr 2018, at 00:28, Michael Slusarz wrote: 
>>>> On April 11, 2018 at 11:08 PM Bron Gondwana <
>>>> [e-mail]> wrote:>>>> 
>>>> 
>>>> 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.>>> 
>>> 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.>>> 
>>>> 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? 
>>> 
>>> I agree that the latter example is more correct - or at least
>>> consistent with the way that we added a new FETCH attribute.>>> 
>>> michael 
> 



--
  Bron Gondwana, CEO, FastMail Pty Ltd
  [e-mail]