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

[Alexey Melnikov <[e-mail]>]

Hi Phillip,

> On 25 May 2023, at 23:10, Phillip Tao 
> <ptao=[e-mail]> wrote:
>
> What is the expected outcome for clients which do not support this 
> extension? The Introduction states:
>
> > This extension is compatible with both IMAP4rev1 [RFC3501] and 
> IMAP4rev2 [RFC9051].
>
> But "always return NO" seems like a very loose definition of "compatible".
You have a point, but this only relates to COPY/UID COPY command.
> I can't think of any similar IMAP extensions in the past which 
> radically alters server behavior without having the client explicitly 
> opting in to it (either by using new commands/new command parameters, 
> or by requiring an ENABLE).
This is true. What this is trying to say is that this extension can be 
advertised by both IMAP4rev1 and IMAP4rev2 servers.
> Clients may not be able to adopt this extension for some time, and 
> some clients may never adopt it (either due to an explicit decision 
> not to, or due to that client or client version no longer being 
> actively maintained). Those clients will therefore be unable to 
> communicate successfully with any server which has implemented this 
> extension.

I don't think what you are describing above is completely correct. I 
think what would happen with clients that don't specially handle this 
extension would encounter one of the following (let's assume that the 
server advertises MESSAGELIMIT=N):

1) If a specific mailbox is smaller than N, then the client would never 
observe MESSAGELIMIT response code, so it would not be affected.

2) If a specific mailbox is larger than N, then the client would be 
limited to operating on at most N messages at a time. For example SEARCH 
and FETCH will return N most recent messages in the specified range.

The client would also be unable to copy more than N messages at a time. 
(But a client using MOVE will be able to move at most N messages.)

Does this help?

Several notes in relation to this:

1) If N is small, this would make life very interesting for clients. I 
think the document should recommend which values are reasonable for 
servers to pick.

2) I think some explanation along the lines of what I explained above 
should be added to the document to make it clearer what the intent is 
for casual readers.


> I see that version 1 of this draft did require an ENABLE, but that was 
> subsequently removed in version 2. From the mailing list archive, it 
> seems like there may have been some discussion in person at IETF 115 
> which led to this, but unfortunately the reasoning was not captured in 
> the mailing list. Can you shed more light on why the newer versions 
> have moved away from requiring an explicit ENABLE?

Basically MESSAGELIMIT conveys a server limitation. There is no way for 
clients to opt out of it, so using ENABLE doesn't work. And the idea 
here is to make sure that clients using 1:* in various IMAP commands 
still need to be subject to the server limit.

When a server returns the MESSAGELIMIT capability, clients can at least 
discover the server limitation.

Best Regards,

Alexey

>
> - Phillip
>
>> On May 17, 2023, at 5:45 AM, Alexey Melnikov 
>> <[e-mail]> wrote:
>>
>> Hi all,
>>
>> On 17/05/2023 13:42,[e-mail]:
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories. This Internet-Draft is a work item of the Email 
>>> mailstore and
>>> eXtensions To Revise or Amend (EXTRA) WG of the IETF.
>>>
>>>    Title           : IMAP MESSAGELIMIT Extension
>>>    Authors         : Alexey Melnikov
>>>                      Arun Prakash Achuthan
>>>                      Vikram Nagulakonda
>>>                      Luis Alves
>>>    Filename        : draft-ietf-extra-imap-messagelimit-03.txt
>>>    Pages           : 9
>>>    Date            : 2023-05-17
>>>
>>> Abstract:
>>>    The MESSAGELIMIT extension of the Internet Message Access Protocol
>>>    (RFC 3501/RFC 9051) allows servers to announce a limit on the number
>>>    of messages that can be processed in a single
>>>    FETCH/SEARCH/STORE/COPY/MOVE command.  This helps servers to control
>>>    resource usage when performing various IMAP operations.
>>
>> This version addes UIDAFTER and UIDBEFORE SEARCH keys.
>>
>> If people are happy with their inclusion, I think this is ready for WGLC.
>>
>> Best Regards,
>>
>> Alexey
>>
>> _______________________________________________
>> Extra mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/extra
>