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

[Barry Leiba <[e-mail]>]

Hi, Rob.
Please check version -10, which removes the "and that won't change later" text.

Thanks,
Barry

On Thu, Sep 24, 2020 at 5:09 AM Rob Wilton (rwilton) <[e-mail]> wrote:
>
> In case it helps reach a quicker resolution, one solution could be to delete the clause “and that decision won’t change later”:
>
>
>
> I.e. old:
>
>
>
>    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. ...
>
>
>
> New:
>
>    It is possible that the server has determined that no meaningful
>
>    preview text can be generated for a particular message. ...
>
>
>
> Full paragraph (new):
>
>    It is possible that the server has determined that no meaningful
>
>    preview text can be generated for a particular message.  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.)
>
>
>
> Regards,
> Rob
>
>
>
>
>
> From: Michael Slusarz <michael.slusarz=[e-mail]>
> Sent: 24 September 2020 07:30
> To: Arnt Gulbrandsen <[e-mail]>; Rob Wilton (rwilton) <[e-mail]>
> Cc: Barry Leiba <[e-mail]>; [e-mail]; Bron Gondwana <[e-mail]>; The IESG <[e-mail]>; [e-mail]; [e-mail]
> Subject: Re: [EXT] Re: [Extra] Robert Wilton's Discuss on draft-ietf-extra-imap-fetch-preview-09: (with DISCUSS and COMMENT)
>
>
>
> The case study we are analysing is expected to be rare.
>
>
>
> Real world: a server handling large amounts of incoming mail is going to deal with preview generation at delivery, rather than display. Any delays at delivery are not normally apparent to the end user. For a server supporting this extension, preview data will exist in almost every access, so generation issues will be irrelevant purposes of UX.
>
>
>
> If a client is worried about the tiny fraction of requests where a preview can not be generated by the server, that client can have code to fallback to attempting to generating the preview itself (I.e. the current behavior for many clients). The situation of a single email where a preview cannot be generated is going to be interpreted by the end user as an exception... And the lack of preview has no bearing on whether an end user can view the full contents of the message.
>
>
>
> michael
>
> On 09/23/2020 2:47 PM Arnt Gulbrandsen <[e-mail]> wrote:
>
>
>
>
>
> On Wednesday 23 September 2020 22:18:47 CEST, Rob Wilton (rwilton) wrote:
>
> It states what to do for the case that the server both (i)
>
> cannot generate the preview AND (ii) this is not a transient
>
> error.
>
> IMAP doesn't report transient errors (which is perhaps wrong, but that's
>
> how it is). The server has no way to report transient errors for the other
>
> dozen or more FETCH items. Why makes this one different?
>
>
>
> IMO, the document shouldn't mention transient errors at all, since they're
>
> alien to IMAP and orthogonal to this extension.
>
>
>
> Arnt