Re: The IMAP APPENDLIMIT Extension - version 04

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.

> 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.

> * 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.

> * 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.

> * 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.

> I'm also curious, does anyone intend to implement different  
> per-mailbox append
> limits? If nobody speaks up, then perhaps we should just remove all  
> of section
> 3.

To me it seems like a fairly common use case that public and/or shared  
namespaces might have a different append "quota" than a private  
namespace.  At least enough of a possibility that it makes sense to  
allow different per mailbox limits.

Earlier it has been mentioned that QUOTA might also change the value.   
There's been discussion of whether this should change/factor into the  
APPENDLIMIT value returned.  If it doesn't, and thus APPENDLIMIT does  
not necessarily reflect the actual value of the current append limit  
on the server, I continue to question how useful APPENDLIMIT would be  
as compared with the current solution of doing a non-LITERAL+ APPEND.

Speaking of this latter option ... discussion of it is completely  
absent from the APPENDLIMIT draft.  At a minimum, the APPENDLIMIT  
draft needs to make clear that the extension only really effects  
behavior when using the combination of APPEND + LITERAL+.  There has  
never been an issue with sending unnecessary data if just using  
APPEND.  I think a discussion, or at least a prominent reference to  
RFC 4549 [4.2.2.3], is necessary to make this distinction clear.

Part of me is wondering whether APPENDLIMIT is even worth it and if  
the better solution is instead that use of APPEND w/LITERAL+ should be  
explicitly discouraged in the LITERAL+ update that Alexey has been  
working on.

> One suggestion for the list to discuss; should we allow the limit to be
> expressed in terms of Megabytes or Gigabytes via a suffix? Thus we'd have:
>
> append-limit-value = 1*DIGIT ["G" / "M"]
>                      ; M = Megabyte (* 1,000,000)
>                      ; G = Gigabyte (* 1,000,000,000)
>                      ; Unsigned 63-bit integer after multiplier
>                      ; (1 <= n <= 9,223,372,036,854,775,807).
>
> Not much additional code and makes the protocol both more concise and human
> readable. Just a suggestion (we have some product config options like this).

The append limit value is being machine parsed, and this doesn't save  
that much in terms of transfer bandwidth, so I don't see much benefit  
in this.

michael

___________________________________
Michael Slusarz [[email protected]]

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