Re: 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