Thanks, Alexey. Here's a first stab at text for that last item; I
propose moving Section 3.5 to a new section and doing this:
NEW
4. Interoperability Considerations
4.1. Effects of MESSAGELIMIT/SAVELIMIT extensions on non compliant
clients
(as is from 3.5)
4.2. Maintaining Compatibility
It is important to understand that the above effects essentially
abandon existing clients with respect to operation on large mailboxes.
Suppose, for example, that a user is accessing a large and active
mailing list via IMAP — the mailing list gets on the order of 1500
posts per week. When the user returns from a week-long vacation and
catches up on the mailing list, the user’s client will be fetching
information about 1500 messages. If the server has a MESSAGELIMIT of
1000, that will fail; the client will not understand why, will not be
prepared to recover from the situation, and will act as if it is
interacting with a broken server.
In order to give clients time to implement this extension, servers
should not be strict about applying the MESSAGELIMIT at first. One
possible approach is to advertise a MESSAGELIMIT but not enforce it at
all for a while. Clients that understand this extension will comply,
reducing load on the server, but clients that do not understand the
limit will continue to work in all situations.
Another approach, perhaps phased in later, is to advertise one limit
but to treat it as a soft limit and to begin enforcement at a higher,
unadvertised hard limit. In the above example, perhaps the server
might advertise 1000 but actually enforce a limit of 10,000. Again,
clients that understand MESSAGELIMIT will comply with the limit of
1000, but other clients will still interoperate up to the higher
threshold.
Attempts to go beyond the advertised limit can be logged so that
client understanding of MESSAGELIMIT can be tracked. If
implementation and deployment of this extension becomes common, it may
at some point be acceptable to strictly enforce the advertised limit
and to accept that the remaining clients will, indeed, no longer work
properly with mailboxes above that limit.
END
(And then renumber the subsequent sections, of course.)
Have at it...
Barry
On Wed, Apr 3, 2024 at 9:41 AM Alexey Melnikov
<alexey.melnikov@xxxxxxxxx> wrote:
>
> Hi Barry,
>
> To close the loop:
>
> On 13/03/2024 19:42, Barry Leiba via Datatracker 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.
>
> We have briefly discussed this in the EXTRA WG meeting in Brisbane and agreed that if there are no unexpected side effects of this, then I will make EXPUNGE and UID EXPUNGE behave in the same way, i.e. with no limit applying to them.
>
> — 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.
>
> I will clarify this.
>
> 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?
>
> MULTIAPPEND APPEND is actually atomic (as per the MULTIAPPEND spec), i.e. it can't partially fail. But I will spell this out in more details.
>
> — 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.
>
> In Brisbane we agreed that two of us will wordsmith some text allowing soft limit.
>
> Best Regards,
>
> Alexey
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
