Re: [Extra] Working Group Last Call - draft-ietf-extra-imap-fetch-preview-08

[Alexey Melnikov <[e-mail]>]

On 07/07/2020 05:38, Bron Gondwana wrote:

> On Tue, Jul 7, 2020, at 13:22, Michael Slusarz wrote:
>>> On 07/02/2020 3:20 AM Timo Sirainen <[e-mail]> wrote:
>>>
>>>
>>> On 2. Jul 2020, at 4..56, Bron Gondwana < [e-mail] 
>>> <mailto:[e-mail]>> wrote:
>>>
>>>> As discussed in the interim meeting, this document was brought back 
>>>> to the working group to be reverted to an earlier and simpler version.
>>>>
>>>> This email announces a 2 week working group last call for any 
>>>> further comments on this version before I re-submit to IESG for 
>>>> publication.  Please reply with any comments by Thursday, July 16th 
>>>> 2020.  Let's get this one off our plates before IETF108.
>>>
>>>    It is possible that preview text is not available now, but might be
>>>    available later -- perhaps the server's preview-generating resources
>>>    are overloaded, there is a server-imposed timeout during preview
>>>    generation, or there is some transient issue with fetching the
>>>    message body.  In such cases, the server will return NIL as the
>>>    preview response, and the client can try to retrieve the preview
>>>    later.
>>> This sounds like it's possible for server to return NIL even when 
>>> the LAZY modifier isn't specified. Is this really wanted? I'd think 
>>> client developers would prefer that only LAZY can return NILs. 
>>> Either way, it's not clearly enough specified what is intended.
>> I was originally going to agree with Timo ... but then I remember we 
>> added this part as a direct response to a potential DoS situation - 
>> what happens if preview requests are (subjectively) taking too much time.
>>
>> If a server can't produce a preview within a certain time threshold, 
>> it should somehow be able to abort the request. NIL might not be the 
>> best solution, but what if it empty string ("") is returned?  Then a 
>> caching client may never have preview text for that message, even 
>> though the inability to return the text may be a temporary issue.
>>
>> LAZY means a server should return preview only if it is pre-generated 
>> (or can be generated without noticeable delay to user).  non-LAZY 
>> request should return PREVIEW unless it exceeds some sort of 
>> server-defined timeout.  But in the latter case - unless the server 
>> knows it can never create a PREVIEW, it does seem that NIL is the 
>> semantically correct response, at least given the current 
>> definitions.  Empty string means the server has canonically decided 
>> that no reasonable preview can be generated..
>>
>> Another suggestion might be to return NO response to the FETCH ... 
>> but semantics of that are a little tortured if the rest of the FETCH 
>> request could be returned, or if preview can be returned for all but 
>> one of the messages requested in the FETCH.
>>
>> In the IMAP spec we have: "The LIST command SHOULD return its data 
>> quickly, without undue delay."  Maybe adopt this language and leave 
>> it to server to figure out what is "undue delay?"  But that doesn't 
>> address whether empty string or NIL is the correct response if undue 
>> delay is reached...
>
> I'm good with the server returning a NO to the whole fetch with text 
> like "preview generation took too long, try again with LAZY".  I mean 
> - the Cyrus server does something like that with SEARCH results that 
> take too long these days - it'll just tell you "NO try again with a 
> less expensive search" if it takes over 30s with our config.  I expect 
> we'd do the same with FETCH - send a NO (possibly part way through the 
> fetch results) if we hit this kind of error.

I think returning NO to FETCH is problematic and will cause problems 
with clients as they don't expect it. Untagged NO might be slightly better.

> Maybe some client advice:
>
> 1) make the initial fetch with PREVIEW (LAZY) and the other fields you 
> care about.
> 2) for items that got a NIL response, batch request non-lazy PREVIEW 
> in sensible-sized batches (e.g. 64 at a time)

These recommendations are good.