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

[Barry Leiba <[e-mail]>]

Ping... to both Michael and the EXTRA working group as a whole: Can we
keep this discussion moving and get this document resolved, please?

Thanks,
Barry

On Sun, Jun 2, 2019 at 5:33 PM Barry Leiba <[e-mail]> wrote:
>
> 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