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

[Barry Leiba <[e-mail]>]

Well, there's a general thing with IMAP: What does a server do if you
FETCH ENVELOPE or FETCH BODYSTRUCTURE and the server has a problem
generating the response (say, some transient error in parsing the
message because of a back-end database glitch?  There are two choices:
fill in NIL for strings and 0 for numbers and just fake up a response,
which can really screw up clients... or reply NO and hope that the
client will handle that well enough, and will maybe try again later --
which can really screw up clients.  In retrospect, maybe it would have
been nice to have the 3xx/4xx/5xx sort of mechanism, allowing for
temporary errors with semantics of "try again later, for some
unspecified value of 'later'."  But it's not that way, and there's
really nothing that can be done about it now.

Barry

On Wed, Sep 23, 2020 at 12:50 PM Rob Wilton (rwilton) <[e-mail]> wrote:
>
> Hi Barry,
>
> Please see inline ...
>
> > -----Original Message-----
> > From: iesg <[e-mail]> On Behalf Of Barry Leiba
> > Sent: 23 September 2020 12:59
> > To: Rob Wilton (rwilton) <[e-mail]>
> > Cc: [e-mail]; Bron Gondwana <[e-mail]>; The IESG
> > <[e-mail]>; [e-mail]; draft-ietf-extra-imap-fetch-
> > [e-mail]
> > Subject: Re: Robert Wilton's Discuss on draft-ietf-extra-imap-fetch-
> > preview-09: (with DISCUSS and COMMENT)
> >
> > > 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.
> [RW]
>
> Sure.
>
> My concern is, for the non LAZY case, what does the server return if a preview should be available but the server cannot construct it at that point in time, for any reason?  Is it possible for the server to return an error? E.g., should it just fail the entire request?  If the only option is to return an empty string that they seems to imply not only that it cannot return a preview now, but it may well never be able to return a preview (which may not true).  I.e., the client has no way to distinguish between a transient failure at generating the preview and a semi-permanent indication that the preview cannot be generated for that particular message.
>
> I have memories of using IMAP clients where they effectively get stuck/broken and seem to have to slowly resync all the data from the server.  Hence my fear is that the server will fail to produce the preview at one point in time, and then the client is stuck without any previews for a subset of messages because a zero length preview string implies that there is no preview available and it SHOULD NOT ask again.
>
> Of course, I don't know IMAP, and hence I might just be missing something basic about how IMAP works ...
>
>
> >
> > > 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.
> [RW]
>
> Okay.  Will look/respond to your subsequent email.
>
> Thanks,
> Rob
>
>
> >
> > Barry
>