Re: The IMAP APPENDLIMIT Extension - version 04

All,

Can you please share your views regarding the below item to come to a consensus?

1.  APPENDLIMIT value should be UINT32_MAX or UINT64_MAX ?

2.  APPENDLIMIT value in SELECT/STATUS response: Whether APPENDLIMIT is needed in both SELECT and STATUS response? 

Please share your thoughts.

Regards,
Jay

-----Original Message-----
From: Alexey Melnikov [mailto:[email protected]] 
Sent: Monday, March 09, 2015 8:00 AM
To: Michael M Slusarz; [email protected]
Subject: Re: [imapext] The IMAP APPENDLIMIT Extension - version 04

Hi,
After thinking more about this topic (I might have changed my position on a few minor issues):

On 06/03/2015 21:27, Michael M Slusarz wrote:
> Quoting Chris Newman <[email protected]>:
>
>> Q for list: If the server has a message larger than UINT32_MAX in the 
>> store and a client tries to fetch it, should the server just go ahead 
>> and violate the base-spec's UINT32_MAX limit or should the data be 
>> NIL unless the client uses ENABLE to tell the server it accepts 
>> larger-than-uint32-max literals on messages? If this extension fixes 
>> that base spec limitation in addition to enabling better client 
>> diagnostics for overlarge messages, I think that's cool.
>
> I agree that the max limit should be extended.  However, it doesn't 
> seem like the APPENDLIMIT document is the (best) place to do that 
> since burying a change in a document devoted to APPEND behavior that 
> affects a general IMAP limit, e.g. changing FETCH behavior, doesn't 
> seem to be the model of clarity.
I agree.
>
>> Having two different ways to access a per-folder limit is a violation 
>> of good protocol design practices. Specifically 3.1 and 3.2 provide 
>> two ways to access the same appendlimit. I believe the document would 
>> be improved by the removal of section 3.1. Some problems with the 
>> current two-mechanism proposal:
>
> +1.  This is what I had written about previously.
Not really a violation, because the data is the same whether returned by STATUS or SELECT
>> * Which limit will the client use if the two limits are different?
>> * Should a client SELECT a mailbox before doing an APPEND? This is 
>> not required by the base spec and is less efficient. The presence of 
>> section 3.1 implies a client should do this. I do not think a client 
>> should do this.
>> Removing section
>> 3.1 removes this issue as a problem.
>
> More important... this may be a non-trivial value to calculate for the 
> server.
(Depending on how accurate a server might want to make this information. 
This is a quality of implementation issue.)
>
>> * The addition of APPENDLIMIT as a response to SELECT even for 
>> clients that don't understand it penalizes all clients with 
>> unnecessary network traffic.
>> While it's not a big response by itself, we're starting to get a 
>> death-of-1000-cuts problem with SELECT responses, so unless it's 
>> really important (and in most cases I think the capability is good 
>> enough) I'd rather not add that extra traffic (and potential battery 
>> life cost on mobile devices).
>
> To me the most common use case for APPEND is sent-mail saving. 
> Generally this will occur in one of two situations:
>
> 1.) Replying/Forwarding to an existing message. In these cases, it is 
> likely that at the time of sending that the client will still be in 
> the same mailbox - most people tend to write a message in one sitting 
> so they won't change their mailbox - and this mailbox will NOT be the 
> sent-mail mailbox.
> 2.) Composing a New Message. The client IMAP connection may be in 
> either a selected or non-selected state depending on their previous 
> actions in the client UI, but odds are high that they are unlikely to 
> be in the Sent mailbox.
>
> In either of these cases it is going to be a MUCH less expensive 
> operation to grab the APPENDLIMIT with a STATUS(-like) call followed 
> by an APPEND rather than SELECTing the mailbox and then APPENDing.
> Not only will the client code have to do the normal state 
> initalization of opening a mailbox, which probably isn't necessary 
> from a UI perspective since the user doesn't care about the 
> contents/status of the sent-mail mailbox, but this initialization 
> could involve other delays if the server is doing things like 
> on-demand new message tasks within that mailbox (e.g. header caching, 
> search indexing).
>
> TLDR: APPENDs to a sent mail mailbox are the most common real-world 
> APPEND action, and these APPENDs rarely occur when in selected state 
> within the sent mail mailbox.
Ok, I don't have a strong preference one way or another, but I find your argument convincing and I can live without APPENDLIMIT be returned on SELECT.
>> * The document does not state if the APPENDLIMIT response is a 
>> MUST/SHOULD/MAY.
>> If it's a MAY, my server implementation won't send it, in which case 
>> why is it in the spec? If it's a SHOULD, I'll include a product 
>> option so admins can disable it. If it's a MUST, I object to 
>> advancing the proposal.
>
> Agree.  It can be argued that this would actually make things slightly 
> slower for the vast majority of clients, with no (or microscopic) gain 
> to APPENDLIMIT aware clients.
Right.

  [snip]


_______________________________________________
imapext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/imapext