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

[Michael Slusarz <[e-mail]>]

> On 09/22/2020 2:01 PM Benjamin Kaduk via Datatracker <[e-mail]> wrote:
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> I agree with Martin D's comment.

Addressed in a separate message.


> 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").

Addressed in a separate message.


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

Oops ... I think "human-generated" is just fundamentally wrong here.  We are discussing text that is meant for human consumption, but it is not generated BY humans (it's generated programmatically by the server).

My re-read of RFC 5255 indicates that "human-readable text" is the phrase that is used there.  And that's what we already use elsewhere in that paragraph.  So I think this is just a typo, and should be this:

  and should thus use the rules defined for human-readable text described in the LANGUAGE extension


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

Agreed.


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

OK.


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

Fair enough.  Although the old dates are a valuable lesson (at least to me) on how long it sometimes takes to move a draft through the process :)


> 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?

The base IMAP4rev1 document doesn't even have this kind of warning.  If we think that this is necessary here then we should probably also push this idea to Alexey and Barry as they are working on the new IMAP revision, since this warning would apply to message data in general.

I don't believe this draft fundamentally changes anything in IMAP.  If you can access a mail in a mailbox, you can access its full body.  This extension just provides an alternative view of that body data, so it doesn't provide a novel way of accessing data.


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

For historical context: this is the exact issue that was discussed and addressed in the last draft (-09).  Previously, we would have allow a NIL response in this case that could have been returned in this situation.  However, we decided instead that a non-LAZY request must always return some sort of determinative response.

Preview data is "nice-to-have" info, as opposed to "must have" information like the actual message bodies.  As such, I feel it needs to be left up to the server to decide in extreme cases that it would rather provide no preview, which is an annoyance, than causing access to the mail data to be affected, which is a critical problem.

It may not be preview generation that is *causing* the excessive resource usage.  It could be the system is overloaded in general due to other problems.  The server is best positioned to determine which ancillary activities it may have to curtail in order to provide the basic mail access, and it is reasonable to predict that preview generation may be one of those activities.

As to what the expected server behavior should be?  I think that's dependent on the reasons behind the excessive resource usage.  The document defines a server's options: send nothing or send something less than a perfect preview.  The server should make the decision based on the information available to it; I don't think it's the job of this document to demand a specific kind of response.

michael