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

[[ nits ]]

[ section 4.2 ]

* "may want to additional display" ->
  "may want to additionally display"

In Section 1, this reads oddly:

   Using server-generated previews allows global generation once per
   message, and then cached for the retention period of the source
   message.

Perhaps add "they can be" before "cached"?

Down in Section 7, I'm not sure the URL is necessary or wise to include.  If IANA should choose to change it for whatever reason, this reference becomes obsolete.  I think the name of the registry is sufficient.

Thank you for addressing my feedback from the initial IESG review of this document.

Thank you for writing this document - I found it easy to read, useful, and interesting (even to a non-IMAP person!).

I was initially concerned that this would be adding significant load to the server, but the explanation on the tradeoff answered that - thanks!

I'd note that the shepherd write-up is now out of date - Barry, not Alexey is the responsible AD (this isn't worth updating, just mentioning)

I agree with Martin D's comment.

I was a little surprised to not see any mention of the analogous JMAP
capability (but I guess I'm not actually sure whether one or the other
"came first").

Section 3.3

   The server SHOULD limit the length of the preview text to 200 preview
   characters.  This length should provide sufficient data to generally
   support both various languages (and their different average word
   lengths) and diverse client display size requirements.

Does the internationalization directorate agree with this analysis?

   format, size, and filename.  This descriptive text is not a product
   of the message body itself but is rather auto-generated data by the
   server, and should thus use the rules defined for human-generated
   text described in the LANGUAGE extension (if supported on the
   server).

nit: is "human-generated text" the right description here?  A quick read
of RFC 5255 suggests that "generated for human consumption" is usually
the appropriate characterization of text affected by the langauge
selection.

Section 4.2

   Once this initial FETCH is complete, the client can then issue FETCH
   requests, without the LAZY modifier, to load the preview data for the

nit: "PREVIEW data item" would be more consistent with the previous
paragraph (and make it harder to skip over the fact that the preview
data is being FETCHed, not the entire message).

   messages in which preview data was not returned.  It is RECOMMENDED
   that these FETCH requests be issued in small batches, e.g. 50
   messages per FETCH command, since preview generation may be expensive
   and a single large request may exceed server resource limits.

nit: comma after "e.g.".

Section 5

I'd consider updating the dates in the examples to be closer to the
publication date of the document.

Section 8

Does it go without saying that a given user should only have access to
preview content for messages that it has access to the full content of?

   results are stored on the server after generation.  Servers MAY limit
   the resources that preview generation uses.  In order to mitigate

Would this result in the server generating empty-string previews for
some messages that it would otherwise have produced a non-empty preview
for?  I'd like to see a little more description of expected server
behavior in the case of excessive resource usage for preview generation.

I don't understand the purpose of the phrase "and that decision won't change later" in Section 3.2. Even if the decision were to change later, if there is nothing to present there will still be an empty response, no?

Hi,

thank you for this document.
Couple of minor comments relating to normative language, plus a question.

   A server SHOULD strive to generate
shouldn't that be: A server SHOULD generate

   should be sized to prevent possible overflow errors
SHOULD?

Whether the server uses a cached preview or generates a new one (may be identical to cached) is implementation specific?

nits:
s/additional display/additionally display/

Discuss cleared.

One minor comment:

   This standardized display can reduce user confusion when using
   multiple clients, as abbreviated message representations in clients
   will show identical message contents.

I didn't really find this reasoning to be compelling, and perhaps it could be removed.  In my experience the amount of preview displayed depends on client behaviour or settings (e.g., how much space to allow for previews).

Regards,
Rob