Re: [Extra] Benjamin Kaduk's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT)

["Chris Newman" <[e-mail]>]

On 10 Apr 2019, at 19:32, Michael Slusarz wrote:
> Benjamin,
>
> Thank you for the comments.  Disccusion below:
>
>> On April 5, 2019 at 3:05 PM Benjamin Kaduk via Datatracker 
>> <[e-mail]> wrote:
>>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> I wavered a lot about whether this was DISCUSS-worthy, but it seems 
>> like
>> we should at least talk about how big a risk for future confusion 
>> there
>> is:
>>
>> I'm a little confused by the ABNF for 'capability' in Section 7 -- it
>> seems to allow for (e.g.) PREVIEW=LAZYV2, but the introduction and
>> Section 3.1 talk only about *algorithms* in PREVIEW capability 
>> responses
>> (and not modifiers).  Is the intent to have capability tags for
>> (non-mandatory) priority modifiers?
>
> [Edit: looks like this was discussion item moved to Barry's ballot, 
> but I'll leave the discussion here for clarity in the thread history]
>
> I struggled with the decision to include priority modifier extensions 
> in the draft.
>
> Algorithm extensions make sense, as there can be competing or expanded 
> way of generating preview text in the future.  But priority modifiers 
> are tied to the behavior of the command, not the output of the 
> command.  In the case there would be a need for a priority modifier in 
> the future, that's a fundamental change to the semantics of the 
> command itself and would probably require extensive discussion.
>
> Under further thought and review, I would be perfectly fine with 
> removing the extension/registry for priority modifiers and simply 
> making it an explicit part of the base command.  This would simplify 
> the draft a bit.  Thoughts?

As a server implementor, I think that's a good proposal to resolve this 
issue.

		- Chris

> (To answer your original DISCUSS: a separate CAPABILITY string wasn't 
> defined, because it is implicit in PREVIEW=FUZZY, which is required to 
> implement PREVIEW, that LAZY must also be handled.  Not requiring 
> PREVIEW=LAZY, and not defining what a potential capability would look 
> like in the future, were explicit choices.)
>
>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> Section 7
>>
>> How much discussion was there about "SHOULD be registered" (as 
>> opposed
>> to "MUST be registered")?
>
> Alexey and I discussed in a previous thread, located here:
>
> I think a valid summation is that Alexy was pushing hard for MUST 
> register, but my reading of 6648 is that it allows flexibility in 
> allowing extensions, as long as you follow naming conventions.
>
> My personal example is that there is at least one additional PREVIEW 
> extension we may develop, and which may be implemented quickly, but 
> there is no intention to register that extension (at least at the 
> beginning) because it is a very specific use-case that may not be 
> generally useful to the wider Internet.  So demanding a MUST register 
> to me seems unduly harsh and inflexible.
>
>> Section 9
>>
>> I agree with Roman that there should be discussion of the 
>> caching/data
>> retention strategy for message previews.
>
> As mentioned in response to Roman, I worked on this language last week 
> and I will share with the group once I have access to that revision.
>
>> This existing text about denial-of-service attacks is probably fine,
>> though I might consider rephrasing it along the lines of "this 
>> mechanism
>> introduces a new way for clients to make requests that consume server
>> resources.  As is the case for all such mechanisms, it could be used 
>> as
>> part of a denial-of-service attack on server resources, e.g., via
>> excessive memory or CPU usage, or increased storage if preview 
>> results
>> are cached on the server after generation.  The additional attack
>> surface presented by this specific mechanism is not believed to 
>> higher
>> risk that other similar mechanisms in use already, since the 
>> individual
>> resource consumption per message processed is likely to be modest.
>> Nonetheless, servers MAY limit the resources consumed by preview
>> generation."
>>
>> As I write the above, though, I wonder how this interacts with the
>> previous text in Section 3.1 about how the "server MUST honor a 
>> client's
>> algorithm priority decision".  Does that mean that if some future
>> (expensive) algorithm is specified, once a server implements that
>> algorithm, any client can force its use and thus the expensive 
>> resource
>> consumption on the server?  It's not entirely clear to me how this 
>> MAY
>> interacts with that MUST, in such a hypothetical scenario.
>
> I don't see this as any different of a problem than with other IMAP 
> commands.  Example: a user issues a SORT/THREAD command in a large 
> mailbox, and that command would require 10,000s of message accesses to 
> return.  An IMAP server should be allowed to abort the response 
> somehow (we will return an unsorted list, for example), subject to 
> some kind of resource limitations, even though the requirements of the 
> command is that it must return a sorted list.
>
> More broadly, any IMAP command should be subject to this kind of 
> truncation if there is concern that completion risks resource 
> starvation as a consequence.  (On that note, I thought there was some 
> sort of "resource limitation" response code defined for this kind of 
> situation, e.g. in RFC 5530, but it looks like there isn't.  Maybe we 
> need something like this).
>
> michael
>
> _______________________________________________
> Extra mailing list
> [e-mail]
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_extra&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=K_BObr5Kfkr3rxt1oBPF9KFiEU3xl9LcD2OOJG3TXfI&m=_6NkoEgIENsYMaNoSASPfK2B1zYYYPt9O1NJVWklBGw&s=YRIPXtCQVIlTe3Fk5OkDQMENKX5db8JeL5XXhi7DfAU&e=