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

["Alexey Melnikov" <[e-mail]>]

Hi Barry,
Replying to your DISCUSS comments only:

On Mon, Apr 8, 2019, at 4:25 AM, Barry Leiba via Datatracker wrote:

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

For some reason I missed that multiple are allowed here. I think this is overcomplicated and the WG should probably re-review whether multiple should be allowed here.

(Adam raised a few comments on the same section. It needs more work.)

> — 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?  Also, as I noted in response to Meral’s Gen-ART
> review it would be good to be clear how encrypted messages should be handled in
> this regard.

Right.

> — Section 4.1 —
> 
>    The preview text MUST be treated as text/plain MIME data by the
>    client.
> 
> I think this requires a normative reference to RFC 2046.

Agreed.

> — Section 5.1 —
> 
> The way you have LAZY working isn’t really consistent with the IMAP protocol
> model.  In that model, the client would not have to ask for the preview twice,
> one with LAZY and one without.  Instead, with LAZY, the server would return
> FETCH PREVIEW responses when it could — perhaps some in the first set of FETCH
> responses, and some, where the PREVIEW part was missing before, in unsolicited
> FETCH responses when the preview became available.  That way, the server has
> the responsibility of setting off a separate task to generate the previews, and
> to send them to the client when it has them (at which point it either saves the
> for future FETCHes or doesn’t).
> 
> As it’s written here, the client has to open a separate IMAP session with the
> server and ask a second time for the previews it’s missing — a separate session
> to avoid blocking other action on the main session.  And if the server has spun
> off a task to preemptively generate them because the client asked once (a good
> practice, given the description here) it has to retain them for some indefinite
> period waiting for the client to ask again.
> 
> Why was this not done with the first mechanism?

I think you had a good exchange with Chris Newman on this.

> — Section 7 —
> 
> As was mentioned in Ben’s review, either the ABNF for “capability” is in error
> (it should not include “preview-mod-ext”) or the description needs to be
> significantly beefed up.  I’m guessing that the intent is that PREVIEW=
> capabilities include both algorithms and modifiers, that PREVIEW=FUZZY is
> required, that the presence of any preview algorithm implies PREVIEW=LAZY such
> that the latter not only need not be specified, but is not permitted to be.  So
> we might have “PREVIEW=FUZZY PREVIEW=FURRY PREVIEW=SLEEPY”, which would mean we
> support the algorithms FUZZY and FURRY, and the modifiers LAZY and SLEEPY.  Is
> that correct?

I think this is the intent. I agree that the document needs to be updated to clarify this.

> That seems somewhat obtuse to me, overloading the PREVIEW= capability and
> inviting confusion.
> 
> — 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.

I think this is a good idea.

Best Regards,
Alexey