Re: [Extra] Barry Leiba's Discuss on draft-ietf-extra-imap-fetch-preview-03: (with DISCUSS and COMMENT)

[Barry Leiba <[e-mail]>]

Hi, Michael,
I'm sorry it took me so long to get back to this, and I won't let that
happen again.

> > ----------------------------------------------------------------------
> > DISCUSS:
> > ----------------------------------------------------------------------
> >
> > — Section 3.1 —
> >
> > I don’t understand “the client’s priority decision”: what decision is that?
> > And what’s the point of giving the server a list of algorithms here, given that
> > they all have to be ones that are supported by the server?  Won’t the server
> > always have to use the first one in the list?  If not, please add some text
> > explaining what the server does.
>
> Consensus seems to be this section is confusing, or unclear, or unneeded, or some combination of this three.

But it's still there and still unexplained in version -05.  Let's see
where we can go with it:

> I'll start with providing a (future) real-world example, and why this
> behavior exists in its present form.  Given a hypothetical future
> algorithm "IMAGE" (generate image/jpeg preview if image data exists in
> message), I issue this preview command:
>
> a FETCH 1 (PREVIEW (LAZY=IMAGE FUZZY))
>
> This is asking the server: provide me an image preview of the message,
> but ONLY if 1) the message actually contains image information and 2)
> that image information is already generated or can be generated very
> quickly.  Otherwise, fall back to FUZZY generation.

Hm.  That really seems like a contrived example.  How would the client
software possibly know whether there's useful information in the
image, or whether the information in the accompanying text is more or
less important?  Suppose I have two messages:

1. text/plain that basically says nothing; image/jpeg that has a
diagram that explains everything

2. text/plain that has the entire real content of the message;
image/jpeg of the senders company logo

It's pretty clear from that explanation that for message 1 I want some
sort of description of the image and for message 2 I want a preview of
the text.  But how would the client software know that, and,
therefore, know what to ask for?

Apart from that, if we're going to do any sort of text-based preview
of an image, I would think we'd just say that when FUZZY is applied to
an image, that's what it does.

> I find that use-case plausible, albeit not something useful given the
> current landscape of a single algorithm.  The alternative would be to
> have to send PREVIEW algorithms one at a time, non-pipelined, which is
> precisely the kind of inefficient client/server interaction this
> extension is trying to minimize.

We disagree on the plausibility.  Realistically, I can't think of
*any* other plausible preview algorithms that a *client* might ask for
without user interaction.  The most I can see is something about how
to apply FUZZY to non-text media types.

> I do agree that there is language that can surely be cleaned up here,
> especially regarding error handling.  But I will hold off on rewriting
> the section until we can have some discussion/consensus as to whether
> the proposed usage discussed above is something that others believe we
> should be supporting.

*If* we're going to keep the multi-algorithm syntax, I think the new
paragraph you added has it covered, and the paragraph with the phrase
"priority decision" is now unnecessary.

But I'd still like to see someone give a good argument for a case
where having a client ask for multiple algorithms to be applied could
really be useful and practical.

> > — Section 3.2 —
> >
> >    If the preview is not available, the server MUST return NIL as the
> >    PREVIEW response.  A NIL response indicates to the client that
> >    preview information MAY become available in a future PREVIEW FETCH
> >    request.  Note that this is semantically different than returning a
> >    zero-length string, which indicates an empty preview.
> >
> > I think the MUST here is hard to follow, because the text doesn’t make a clear
> > enough distinction between “preview is not available” and “an empty preview”.
> > Can you expand the text a bit to explain the distinction more clearly, as this
> > is a protocol requirement?
>
> "Preview not available" examples =
>   * Preview generation isn't available at the moment (previews are generated in a separate thread, and that pool is saturated)
>   * Body text is not available at the moment, so preview can't be generated.
>   * The preview text has not been generated within the alotted time (e.g. LAZY modifier)

OK, so you're saying that NIL means that there's some transient issue,
and that a non-empty preview might be available later... and an empty
string means that there's no preview text available for this message
and never will be.  Yes?

If that's right (and actually a necessary distinction), I suggest this:

OLD
   If the preview is not available, the server MUST return NIL as the
   PREVIEW response.  A NIL response indicates to the client that
   preview information MAY become available in a future PREVIEW FETCH
   request.

   Examples why a preview may not be available include: the preview
   generation process is not available due to transient server resource
   limitations, the message body text is unavailable, or a server-
   imposed timeout was reached during generation.

   A NIL response is semantically different than returning a zero-length
   string, which indicates that no meaningful preview text can be
   generated for the message.

NEW
   It is possible that preview text is not available now, but might be
   available later -- perhaps the server's preview-generating resources
   are overloaded, there is a server-imposed timeout during preview
   generation, or there is some transient issue with fetching the
   message body.  In such cases, the server will return NIL as the
   preview response, and the client might possibly try again later.

   On the other hand, it's possible that the server has determined that
   no meaningful preview text can be generated for a particular
   message, and that 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 will
   return a zero-length string.  Clients should not send another FETCH
   for a preview for such messages.

END

But let's be sure we really think the distinction is important.

> > — Section 8 —
> >
> > It seems like a bad idea to have to keep the IMAP Capabilities registry in sync
> > with the two new registries: as it stands, when you add a new algorithm you
> > have to add it to the Preview Algorithms registry, and also add a corresponding
> > entry in the Capabilities registry... and similarly for a modifier, if I have
> > that right above.
> >
> > Why not follow the model of AUTH= and RIGHTS=, and just reserve the PREVIEW=
> > capability in the registry, allowing it to apply to entries from the two new
> > registries?  That avoids inconsistencies in registrations if we later add
> > algorithms or modifiers.
>
> See above.  With my proposal to remove priority modifiers, I believe this discussion
> point becomes moot.

It does not; it's still an issue with algorithms.  If you register
"PREVIEW=FUZZY" as a capability string and also register "FUZZY" as an
algorithm, you're doing double registration and are prone to getting
inconsistencies.

But if, instead, you just register "PREVIEW=" as a capability string
and let that stand for any "PREVIEW=X", where X is a registered
preview algorithm, you don't get into that sort of trouble.  That's
what AUTH= and RIGHTS= did.  Is there a reason not to do that?

> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > — Section 3.2 —
> >
> >    This relaxed requirement permits a
> >    server to offer previews as an option without requiring potentially
> >    burdensome storage and/or processing requirements to guarantee
> >    immutability for a use case that does not require this strictness.
> >
> > That’s sensible, but can you include some text giving an example of a situation
> > where the preview might change?  Given that the messages themselves are
> > immutable, why would applying the same algorithm to the same text give
> > different results?
>
> We discussed this on the list in the past, but one example would be
> loss of cached preview data on the server and re-generation uses a
> newer algorithm version which produces slightly different text.
>
> The consensus was that we should not be making extraordinary
> efforts/costs to ensure this text never changes, where this text is not
> being held out as being the canonical view of the message contents in
> the first place.

That's fine.  So, as the first sentence of my comment says, can you
include some text to explain the situation?  I'm not looking for a
lot, just a sentence.  (If you think it's best not to, that's OK too:
this is a comment, not a discuss point).

Again, sorry for the delay in responding, and I'll keep up with the
discussion from here.

Barry