[Extra] Robert Wilton's Discuss on draft-ietf-extra-imap-fetch-preview-09: (with DISCUSS and COMMENT)

[Robert Wilton via Datatracker <[e-mail]>]

Robert Wilton has entered the following ballot position for
draft-ietf-extra-imap-fetch-preview-09: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-extra-imap-fetch-preview/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Hi,

Thanks for this document.  I found it easy to read and understand, but have one
potential issue that probably warrants a bit of discussion.  I don't have any
great knowledge of IMAP, so this may already be handled elsewhere, but I had a
concern about returning zero-length strings under error conditions.

   It is possible that the server has determined that no meaningful
   preview text can be generated for a particular message, and that
   decision won't change later.  Examples of this involve encrypted
   messages, content types the server does not support previews of, and
   other situations where the server is not able to extract information
   for a preview.  In such cases, the server MUST return a zero-length
   string.  Clients SHOULD NOT send another FETCH for a preview for such
   messages.  (As discussed previously, preview data is not immutable so
   there is chance that at some point in the future the server would be
   able to generate meaningful text.  However, this scenario is expected
   to be rare so a client should not continually send out requests to
   try to capture this infrequent occurrence.)

   ... A server MUST NOT return NIL
   to a FETCH PREVIEW request made without the LAZY modifier.

When the LAZY modifier is not being used, then what would be returned if the
server was transiently unable to return the preview for any reason?  Does it
still have to return a zero-length string in this error case?  Is there some
way that the server can indicate that it cannot satisfy the request now but
without indicating that no preview is available?


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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