IMAP4 Extension: Message Preview Generation
draft-ietf-extra-imap-fetch-preview-10

Thank you for addressing my DISCUSSes and comments.

On the positive side, I really like the "it allows consistent representation of previews across all clients" in section 1.

Some questions though:

1) In the FUZZY algorithm (section 4.1), are we sure that removing all markup does significantly change the message? a  <br/> can sometimes be perceived as a '.' == end of sentence; and removing them could vastly change the meaning of the message.

2) Section 3.2 "A server SHOULD strive to generate the same string for a give message for each request." which seems to contradict the "consistent representation" stated in section 1.

Thanks to everyone who has worked on this document. I have a handful of comments
that should be considered prior to publication.

---------------------------------------------------------------------------

§3.1:

>  These algorithms MUST be one
>  of the algorithms identified as supported in the PREVIEW capability
>  responses.

This is confusing, as "algorithms" and "one of" don't make sense with each
other. Is it meant to say something like "...MUST be a subset of the
algorithms..."?

---------------------------------------------------------------------------

§3.1:

>  If a client requests an algorithm that is unsupported,
>  the server MUST return a tagged BAD response.

This appear to be underspecified, or at least nonintuitive. As written,
it seems to say that an algorithm list of (known-1, known-2, unknown, known-3)
would be considered invalid, even though there are plenty of supported,
requested algorithms that could be used. Is this actually intended to be an
error? If so, please make it explicit, as it's pretty counterintuitive.

(As an aside: it's also unnecessarily fragile from an interop perspective, so I
would suggest that this is not the desired behavior: I believe you want to
return an error only when *none* of the requested algorithms are supported).

---------------------------------------------------------------------------

§6, example 5:

>    C: E1 CAPABILITY
>    S: * CAPABILITY IMAP4rev1 PREVIEW=FUZZY SEARCHRES
>    S: E1 OK Capability command completed.
>    [...a mailbox is SELECTed...]
>    C: E2 SEARCH RETURN (SAVE) FROM "FOO"
>    C: E3 FETCH $ (UID PREVIEW (LAZY=FUZZY))

This example shows the use of a modifier ("LAZY") with an algorithm; however,
this modifier doesn't appear to be advertised by the server in its CAPABILITY
line. If I understand how this is supposed to work (looking at the definitions
in section 7), I would have expected:

     S: * CAPABILITY IMAP4rev1 PREVIEW=FUZZY PREVIEW=LAZY SEARCHRES

I'll note that this syntax effectively places algorithms and modifiers in the
same namespace, although IANA doesn't seem to be given any explicit
instructions about this. I think this needs to be cleaned up prior to
publication.  I would make this last point a DISCUSS, except that it appears
to be covered by Benjamin's DISCUSS already.

---------------------------------------------------------------------------
§1:

>  Using server generated previews allows global generation once per0

nit: "server-generated"

I support Barry's DISCUSS point on Section 3.2.

In Section 4.1, I suggest s/The FUZZY algorithm/The FUZZY algorithm identifier/
(since it doesn't refer to an actual algorithm)

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

In relation to Benjamin's Discuss. I also think there are necessary to clarify if the Capability usage of PREVIEW is a single algorithm or allows listing all the algorithms server supports.

A few small comments on the IANA section: It would be good to also provide a name for each of the new registries (but I'm sure IANA will ask about this in their review). However, I'm also wondering why you don't specify straight away the use of the IETF Review policy as specified in RFC5226? Is there something different in there that does not work for you?