Re: [Extra] Adam Roach's No Objection on draft-ietf-extra-imap-fetch-preview-03: (with COMMENT)

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

Hi Adam,
Thank you for your comments:

On Mon, Apr 8, 2019, at 9:38 PM, Adam Roach via Datatracker wrote:

> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks to everyone who has worked on this document. I have a handful of comments
> that should be considered prior to publication.
> 
> ---------------------------------------------------------------------------
> 
> §3.1:
> 
> >  These algorithms MUST be one
> >  of the algorithms identified as supported in the PREVIEW capability
> >  responses.
> 
> This is confusing, as "algorithms" and "one of" don't make sense with each
> other. Is it meant to say something like "...MUST be a subset of the
> algorithms..."?
> 
> ---------------------------------------------------------------------------
> 
> §3.1:
> 
> >  If a client requests an algorithm that is unsupported,
> >  the server MUST return a tagged BAD response.
> 
> This appear to be underspecified, or at least nonintuitive. As written,
> it seems to say that an algorithm list of (known-1, known-2, unknown, known-3)
> would be considered invalid, even though there are plenty of supported,
> requested algorithms that could be used. Is this actually intended to be an
> error? If so, please make it explicit, as it's pretty counterintuitive.
> 
> (As an aside: it's also unnecessarily fragile from an interop perspective, so I
> would suggest that this is not the desired behavior: I believe you want to
> return an error only when *none* of the requested algorithms are supported).

I think this section is a mess. If we want to allow for multiple algorithms here, then, as you point out, handling of error cases need to be described. This will be fixed.

> ---------------------------------------------------------------------------
> 
> §6, example 5:
> 
> >    C: E1 CAPABILITY
> >    S: * CAPABILITY IMAP4rev1 PREVIEW=FUZZY SEARCHRES
> >    S: E1 OK Capability command completed.
> >    [...a mailbox is SELECTed...]
> >    C: E2 SEARCH RETURN (SAVE) FROM "FOO"
> >    C: E3 FETCH $ (UID PREVIEW (LAZY=FUZZY))
> 
> This example shows the use of a modifier ("LAZY") with an algorithm; however,
> this modifier doesn't appear to be advertised by the server in its CAPABILITY
> line. If I understand how this is supposed to work (looking at the definitions
> in section 7), I would have expected:
> 
>      S: * CAPABILITY IMAP4rev1 PREVIEW=FUZZY PREVIEW=LAZY SEARCHRES
> 
> I'll note that this syntax effectively places algorithms and modifiers in the
> same namespace, although IANA doesn't seem to be given any explicit
> instructions about this. 

Right, Barry has DISCUSS on this point.

> I think this needs to be cleaned up prior to
> publication.  I would make this last point a DISCUSS, except that it appears
> to be covered by Benjamin's DISCUSS already.