Re: [Extra] Artart last call review of draft-ietf-extra-imap-messagelimit-08

["Murray S. Kucherawy" <[e-mail]>]

Hi,

Any reply to the ARTART review?

-MSK

On Wed, Mar 13, 2024 at 3:43 PM Barry Leiba via Datatracker <
[e-mail]> wrote:

> Reviewer: Barry Leiba
> Review result: Ready with Issues
>
> General comment:  It seems very odd for this to apply to EXPUNGE.  First,
> the
> overhead in expunging is low.  Second, the client has no control over the
> number of messages that will be expunged, as it just has to do with which
> messages happen to have the /Deleted flag set on the server, and having a
> limit
> on UID EXPUNGE and not on EXPUNGE would be strange and hard to justify.
>
> — Section 3.1 —
>
>    If a server implementation doesn't allow more than <N> messages to be
>    operated on by a single COPY/UID COPY command, it MUST fail the
>    command by returning a tagged NO response with the MESSAGELIMIT
>    response code defined below.
>
> I think this needs to be clearer that the entire command is failed and that
> *no* messages are copied.  It should not just rely on the example later in
> the
> section to convey that.
>
>    When IMAP MULTIAPPEND [RFC3502] extension is also supported by the
>    server, the message limit also applies to the APPEND command.
>
> Is that really all you want to say about using this with APPEND?  I think
> that
> leaves it underspecified.  How is a partial result handled?  Tagged OK with
> partial result?  Tagged NO with complete failure of the command?  And how
> about
> including an example?
>
> — Section 3.5 —
>
> You are now making it permissible for servers to break compatibility with
> clients that don’t support this new extension; that seems troubling.  I
> understand that possibly servers are already doing that, but it seems bad
> to
> define an extension that says it’s OK… basically, if you implement this
> extension, you are abandoning older clients.
>
> It would seem better to have the section talk about the i portance of
> maintaining compatibility with clients that don’t support this extension,
> and
> raise the possibility of abandoning compatibility only if it’s absolutely
> necessary.
>
> For example, one might suggest tolerance of the situation to some extent,
> allowing older clients to exceed the message limit to a point in order to
> stay
> compatible, but recognizing the need to stop when it’s excessive.  Maybe
> if the
> limit is 1000 you still accept up to 5000 from a non-compliant client
> before
> you give up, or something like that.
>
> This is especially true for flag searches, for which much greater
> tolerance is
> probably acceptable.  Maybe true for STORE as well.
>
>
>