[Extra] AD review of draft-ietf-extra-imap-fetch-preview-00

[Alexey Melnikov <[e-mail]>]

Hi,

This document is nearly ready for IETF LC and IESG review, but I have a
few comments that require a bit of work to address:

In Section 1:

   A server that supports the PREVIEW extension indicates this with one
   or more capability names consisting of "PREVIEW=" followed by a
   supported preview algorithm name.  This format provides for future
   upwards-compatible extensions and/or the ability to use locally-
   defined preview algorithms.

This is not reflected in the ABNF section (Section 7). See my comment on
section 7 below.


In Section 3.2:

   The algorithm used by the server to generate the preview is returned
   preceding the preview string.

   The server returns a variable-length string that is the generated
   preview for that message.

Having an example at this point would make it easier for reader to
understand the document.

In Section 4.1:

   If the FUZZY algorithm generates a preview that is not based on the
   body content of the message and the LANGUAGE [RFC5255] extension is

Is preview is not based on the body content, what is it based on?
Do you mean header fields from the message?

   supported by the server, the preview text SHOULD be generated
   according to the the language rules that apply to human-readable
   text.

In Section 5.1:

How would the client know when to try to retrieve LAZY preview again?

In Section 7:

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in ABNF [RFC5234].  It includes definitions
   from IMAP [RFC3501].

     capability        =/ "PREVIEW=FUZZY"

This doesn't quite much what you specify in Section 1.
Maybe change it to:

        capability        =/ "PREVIEW=" preview-alg
?


     fetch-att         =/ "PREVIEW" [SP "(" preview-alg-fetch *(SP
                          preview-alg-fetch) ")"]

     msg-att-dynamic   =/ "PREVIEW" SP "(" preview-alg SP nstring ")"

     preview-alg       =  "FUZZY" / preview-alg-ext

     preview-alg-ext   =  preview-atom  ; New algorithms MUST be
                                        ; registered with IANA

And you don't define the procedure for registering these in the IANA
Considerations section.

     preview-mod-ext   =  preview-atom  ; New priority modifiers MUST be
                                        ; registered with IANA

As above: this needs to have the corresponding IANA Considerations text.


In Section 10:

   There are no known additional security issues with this extension
   beyond those described in the base protocol described in IMAP4
   [RFC3501].

I am not entirely convinced that this is true. This extension either
requires more disk storage or more computation on the server. Both can
cause some form of Denial-of-Service.
(And disk storage space might be worth calling out as a separate
operational consideration)

Best Regards,
Alexey