[Extra] Benjamin Kaduk's No Objection on draft-ietf-extra-imap-fetch-preview-03: (with COMMENT)

[Benjamin Kaduk via Datatracker <[e-mail]>]

Benjamin Kaduk has entered the following ballot position for
draft-ietf-extra-imap-fetch-preview-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-extra-imap-fetch-preview/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

[Re-issuing ballot position to direct discussion of the ABNF for 'capability'
to Barry's ballot thread; the rest of the COMMENT is unchanged]

Section 3.1

   Alternately, the client may explicitly indicate which algorithm(s)
   should be used in a parenthesized list after the PREVIEW attribute
   containing the name of the algorithm.  These algorithms MUST be one

nit: there's potential for misparsing here (e.g., that the PREVIEW
attribute contains the name of the algorithm and the parenthesized list
is after that), so maybe put "after the PREVIEW attribte" in parentheses
or offset by commas.

   of the algorithms identified as supported in the PREVIEW capability
   responses.  [...]

nit: singular/plural mismatch between "these algorithms" and "one of".

Section 7

How much discussion was there about "SHOULD be registered" (as opposed
to "MUST be registered")?

Section 8

side note: This is one of the shortest IANA considerations sections I've
seen thta creates registries (in that it doesn't lay out a registration
template), but IANA seems to be saying they have what information they
need, so who am I to complain...

Section 9

I agree with Roman that there should be discussion of the caching/data
retention strategy for message previews.

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.