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

[Michael Slusarz <[e-mail]>]

Adam,

Thanks for your comments.  Discussion below.

> On April 8, 2019 at 2:38 PM Adam Roach via Datatracker <[e-mail]> wrote:
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> §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..."?

Noted that the topic of multiple algorithm selection is being discussed in Barry's DISCUSS.

That being said, if multiple algorithm support is decided to be kept, what about changing this to:

"All algorithms specified in the list MUST be identified as being supported by the server by appearing in a PREVIEW capability response." (or "PREVIEW= capability response" maybe?)

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

See Barry's DISCUSS response.  Agreed that error handling is not specified adequately in current text.

To mirror duplicate algorithm language, how about: "Unsupported algorithms in the list MUST be ignored. If the list contains no supported algorithms, the server MUST return a tagged BAD response to the FETCH command."

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

This has been discussed in several other places already.  I am proposing removing priority modifier extensions, which would address this concern.

michael