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

[Barry Leiba <[e-mail]>]

I think we're still in significant disagreement here; I'd like others
from the working group to comment, and see if that can move us in one
direction or the other.

> > > 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?
>
> Is that what a typical received message looks like?  To me, that looks like the edge case.

It's not the "typical" message, but I don't think it's an edge case
either.  I do often get messages where the only significant content is
in an image.  (I've tried to dissuade those responsible from sending
things that way, but they persist.)  So, no, I wouldn't call it an
"edge case" either.  And even if it were, that's not really the point;
see below.

> Seems that a server could figure out (through experience) when image
> preview data should be calculated or ignored.  Image size, MIME
> structure information, MIME order, etc. could all be used to reach some
> sort of 95% accuracy threshold.  Maybe that doesn't happen day 1 of
> implementation, but a competitive, reactive server implementation will
> work on this.
>
> The same issue exists for text previews, FWIW.  What about a text/plain
> + text/html alternative message, where text/plain is "Please click on
> this URL to view the text part", and the text/html part is empty text
> (it's a single image link).  A server can be programmed to be smart
> enough to ignore that part re: preview.
>
> As written, we allow a server to be given the latitude to figure these
> kind of issues out.  Closing down that opportunity because it might be
> a difficult logical problem isn't the right approach from my view.

I note that in your response you say "server" four times, at least
once per paragraph, and "client" never.  But my point (see above) was,
"But how would the client software know that, and, therefore, know
what to ask for?"  These are things a *client* is requesting; how does
the client know whether to request that the preview be preferentially
done on the image or on the text?  I contend that it doesn't, and
can't, and that, therefore, it's strange to expect it to ask, and
strange to say that the server has to take the client's "priority
decision" into account.

I'm still looking for a real use case where the *client* is the entity
that's better suited to asking for any specific action with respect to
a message preview.

> > 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.
>
> FUZZY is explicitly defined as text only output though, since that's generally mapping
> what clients already do.

Well, but saying, "That's the way it works now," isn't really the
point.  We need to be looking at how we *want* this to work going
forward, and I think that having the *server* decide what the best way
is to give a preview of a message is the right answer.  And if that
means that the server decides to make a preview from the text/plain
part, the text/html part, the application/pdf part, or the image/jpeg
part (perhaps using OCR on the image), then I think that's fine.
FUZZY is explicitly defined as text only, only because that's how
we've defined it so far.

> > > 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.
>
> Our UI client does "virtual attachment view", that shows graphical representations of all
> attachment data within messages within a mailbox, so PREVIEW is perfectly suited for
> that task.  (We currently have to do the preview conversion via a proprietary plugin.)

I don't understand this: this extension gives one preview for the
message, not separate previews for different message parts.  It looks
like you're talking about showing a graphic representation of the
message structure with each part having a preview.  Can you post a
screen capture of what you're talking about, showing how PREVIEW
helps?

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

This comment of mine still stands.  Please, EXTRA working group, join
the discussion.

Barry