Re: The IMAP APPENDLIMIT Extension - version 04

>1.  APPENDLIMIT value should be UINT32_MAX or UINT64_MAX ?

UINT64_MAX

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

I don't feel strongly about this but, considering the recent 
arguments on the matter, I lean toward having it only in STATUS.

Pete Maclean

>and STATUS response?
At 03:47 PM 3/18/2015, Jayantheesh S B wrote:
>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

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