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

[Barry Leiba <[e-mail]>]

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

The idea here is that there are three conditions:

1. The server determines that there's no preview available for this
message, and it returns an empty string: "" or the equivalent literal
{0}.

2. The server returns a non-empty preview.

3. The client uses LAZY, indicating that it's OK to defer the
generation of a preview and the server decides that deferral is the
best approach, so it returns NIL.  At some later time, the client
might re-send the FETCH without LAZY.  If it does, the server will
respond with (1) or (2).

So, NIL does not mean that no preview is available for the message; it
means that the server is invoking the option given it by the LAZY
modifier, and is deferring the response.

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

Perhaps some slight re-phrasing of this text will address your comment
℗rhaps changing the word "identical"), but the point here isn't that
all clients will always present the preview in exactly the same way:
indeed, one might present less text than another due to space
limitations in the UI.  The point here is that if a message says that
we have to discuss document status in the EXTRA working group and we
should do it over lunch tomorrow and should we go for Chinese or
Indian food and at what time... we won't wind up with one client's
preview saying that the message is about the EXTRA working group's
document status while another's says it's about lunch plans tomorrow
and still another's that it's about China and India.  I think this is
useful text making a useful point, and that we shouldn't remove it.

Barry