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

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.

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
>> <brong@fastmailteam.com> 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 <
>>>> brong@fastmailteam.com> 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 
> 

> _________________________________________________
> Extra mailing list
> Extra@ietf.org
> https://www.ietf.org/mailman/listinfo/extra

--
  Bron Gondwana, CEO, FastMail Pty Ltd
  brong@fastmailteam.com