IMAP4 Extension: Message Preview Generation
RFC 8970
Yes
No Objection
Note: This ballot was opened for revision 09 and is now closed.
Alvaro Retana No Objection
Erik Kline No Objection
[[ nits ]] [ section 4.2 ] * "may want to additional display" -> "may want to additionally display"
Martin Duke No Objection
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?
Murray Kucherawy No Objection
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.
Robert Wilton (was Discuss) No Objection
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
Roman Danyliw No Objection
Thank you for addressing my feedback from the initial IESG review of this document.
Warren Kumari No Objection
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)
Éric Vyncke No Objection
(Barry Leiba; former steering group member) Yes
This was balloted before, but has had major changes since then and is a very different document. It's just been through another last call, and I've cleared out the old ballot so we can have a fresh look.
(Alissa Cooper; former steering group member) No Objection
(Benjamin Kaduk; former steering group member) No Objection
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.
(Deborah Brungard; former steering group member) No Objection
(Magnus Westerlund; former steering group member) No Objection
(Martin Vigoureux; former steering group member) No Objection
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/