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

["Rob Wilton (rwilton)" <[e-mail]>]

I've cleared my discuss.

Thanks for the update.

Rob


> -----Original Message-----
> From: iesg <[e-mail]> On Behalf Of Barry Leiba
> Sent: 02 October 2020 16:02
> To: Rob Wilton (rwilton) <[e-mail]>
> Cc: [e-mail]; [e-mail]; Bron
> Gondwana <[e-mail]>; Arnt Gulbrandsen
> <[e-mail]>; The IESG <[e-mail]>; extra-
> [e-mail]; Michael Slusarz <michael.slusarz=40open-
> [e-mail]>
> Subject: Re: [EXT] Re: [Extra] Robert Wilton's Discuss on draft-ietf-
> extra-imap-fetch-preview-09: (with DISCUSS and COMMENT)
> 
> 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=40open-
> [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