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

[Benjamin Kaduk <[e-mail]>]

On Wed, Apr 10, 2019 at 08:32:11PM -0600, 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]

[Ok]

> 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?

That would definitely simplify things (and IIUC remove the concerns here).
I don't want to pressure you or the WG into making that decision, though --
pick what seems best for the technology, and figuring out how to describe
it properly will come pretty easily after that.

> (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 missed the link, but I don't want to relitigate the question if it was
already covered.)

> 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.

With a "standards-track or IESG-approved experimental RFC" registration
policy, that's probably true.  It might be different with a lighter-weight
registration policy like "expert review", though.

> > 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).

I'm happy with that answer (and would be happy to see a document with such
a new response code appear).

Thanks,

Ben