[Extra] Artart last call review of draft-ietf-extra-imap-messagelimit-08
Barry Leiba via Datatracker <noreply@ietf.org> Wed, 13 March 2024 19:42 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: extra@ietf.org
Delivered-To: extra@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B527C1D6DB1; Wed, 13 Mar 2024 12:42:33 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba via Datatracker <noreply@ietf.org>
To: art@ietf.org
Cc: draft-ietf-extra-imap-messagelimit.all@ietf.org, extra@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 12.8.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <171035895300.20900.11505557380537520896@ietfa.amsl.com>
Reply-To: Barry Leiba <barryleiba@computer.org>
Date: Wed, 13 Mar 2024 12:42:33 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/extra/8hWT-xJJ01ueAsupOjF3WeYJBrw>
Subject: [Extra] Artart last call review of draft-ietf-extra-imap-messagelimit-08
X-BeenThere: extra@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Email mailstore and eXtensions To Revise or Amend <extra.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/extra>, <mailto:extra-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/extra/>
List-Post: <mailto:extra@ietf.org>
List-Help: <mailto:extra-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/extra>, <mailto:extra-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Mar 2024 19:42:33 -0000
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.
- [Extra] Artart last call review of draft-ietf-ext… Barry Leiba via Datatracker
- Re: [Extra] Artart last call review of draft-ietf… Murray S. Kucherawy
- Re: [Extra] Artart last call review of draft-ietf… Alexey Melnikov
- Re: [Extra] [Last-Call] Artart last call review o… Alexey Melnikov
- Re: [Extra] [Last-Call] Artart last call review o… Barry Leiba