Re: [Extra] I-D Action: draft-ietf-extra-imap-messagelimit-03.txt

Thanks for the discussion, Arnt.

Comments inline.

- Phillip

> On Jun 12, 2023, at 2:41 AM, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> wrote:
> 
> Hi,
> 
> I suspect there are diverging assumptions here.
> 
> When I wrote RFC 5530, I asked around about what responses then-current servers sent, collated the lists, and synthesised the list in what's now RFC 5530. The list includes CANNOT and LIMIT. Those two are on the list because there are (unspecified) things some server CANNOT do, and (equally unspecified) LIMITs on the size of some operations or data structures.
> 
> I also seem to remember a couplf of Stack Overflow questions that implied that some servers would close the connectiion rather than parse a UID set with tens of thousands of commas. (The answer to which was "use the range syntax, x:y".)
> 
> I think Alexey shares my impression of the current servers do, but Philip does not.
> 
> In my view, this extension just announces limits without changing what the servers do. Extended and unextended client will not experience different server behaviour.

Correct, extended and unextended clients will experience the same server behavior from an extended server.

However, clients will experience different behavior between extended and unextended servers. Extended clients will understand the this difference of behavior.

Unextended clients will not. Unextended clients cannot distinguish between an extended and unextended server, and will therefore expect that servers will continue to behave in the same manner as they've always behaved. This is the case that I'm worried about.
> 
> Perhaps the best way forward is to add a MUST NOT paragraph:
> 
I'm not sure I fully understand this paragraph.

> "The server can infer whether the client uses this extension by observing the client's commands.

Again, why infer rather than explicitly communicate with an ENABLE?

> The server MUST NOT impose lower limits on a suppprting client than on other clients. Put differently, if code in a client worked in the past, then adding support for this extension MUST NOT break it due to lower server limits.

These two sentences seem to be saying different things? The first sentence seems to say that servers should not behave differently for extended and unextended clients. If so, why does the server need to infer whether a client uses this extension?

The second sentence says that the server must not break existing client implementations. Which is great, but what exactly does "break" mean here? And how does the first sentence lead to the desired outcome (non-breakage) of the second sentence?

> This extension simply permits a supporting client to know in advance whether a command will fail, avoid issuing such a command, and divide it into smaller parts if they want."
> 
> Maybe also two or three small examples showing how unextended clients receive CANNOT and/or LIMIT response codes.

This is interesting also. Is there a reason why a new response code was chosen rather than using the existing LIMIT?

Also, both CANNOT and LIMIT are, I believe, given with a NO response right now? I don't know if that's required, nor do I have any empirical data of how existing servers use them, but that's my understanding based on what I've seen and what the examples in RFC 5530 and others show.

So, in this case, are you proposing that we return NO [LIMIT] for commands other than COPY?

Between returning a set of partial results and OK vs. no results and NO, I can see how the partial results seem to be the more compatible approach. But again, I'm worried that that will break some expectations that existing clients have about an OK always meaning "all results".
> 
> Arnt
> 
> _______________________________________________
> Extra mailing list
> Extra@ietf.org
> https://www.ietf.org/mailman/listinfo/extra