Alexey Melnikov | 26 Jul 16:53 2015

Review of draft-ietf-imapapnd-appendlimit-extension-00

Hi,
SM asked me to review the document, so I reread everything for the first
time in a couple of months. Here are my comments:

> 2. APPENDLIMIT Extension
> 
> An IMAP server that supports APPENDLIMIT advertises this by including
> the word APPENDLIMIT in its capability list.  IMAP server shall publish
> the supported mail upload size as part of CAPABILITY response.

As per the recent discussion, the above text should be amended to make
it clear that both "APPENDLIMIT" and "APPENDLIMIT=<value>" can be
advertised. As traditionally IMAP uses exact match for capabilities,
"APPENDLIMIT=..." is not going to work for a client that looks for exact
match with "APPENDLIMIT".

> The
> advertised upload limit is common across the mailboxes, but client
> can still issue SELECT/EXAMINE or LIST command to get the mailbox
> specific upload limit set by the IMAP server.  In this case,
> APPENDLIMIT value obtained as part of SELECT/EXAMINE or LIST command
> takes precedence over the value returned as part of CAPABILITY
> response.

 [snip]

> 3. Mailbox specific APPENDLIMIT
> 
> IMAP server can still have mailbox specific APPENDLIMIT restriction,
> which may not be advertised as part of CAPABILITY response.  In this
(Continue reading)

internet-drafts | 26 Jul 16:23 2015
Picon

I-D Action: draft-ietf-imapapnd-rfc2088bis-00.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IMAP APPEND Extensions Working Group of the IETF.

        Title           : IMAP4 non-synchronizing literals
        Author          : Alexey Melnikov
	Filename        : draft-ietf-imapapnd-rfc2088bis-00.txt
	Pages           : 7
	Date            : 2015-07-26

Abstract:
   The Internet Message Access Protocol (RFC 3501) contains the
   "literal" syntactic construct for communicating strings.  When
   sending a literal from client to server, IMAP requires the client to
   wait for the server to send a command continuation request between
   sending the octet count and the string data.  This document specifies
   an alternate form of literal which does not require this network
   round trip.

   This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-.
   The former allows the alternate form of literals in all IMAP command.
   The latter is the same as LITERAL+, but disallow the alternate form
   in IMAP APPEND, unless they are 4096 bytes or less.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-imapapnd-rfc2088bis/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-imapapnd-rfc2088bis-00

(Continue reading)

Jayantheesh S B | 23 Jul 21:05 2015

Re: Review for first draft for draft-ietf-imapapnd-appendlimit-extension

HI Jamie,
 
Thanks for reviewing the document again.
 
Please find my response.
 
Regards,
Jay
---------- Forwarded message ----------
From: Jamie Nicolson <nicolson <at> google.com>
Date: Thu, Jul 23, 2015 at 1:41 PM
Subject: Re: [imapext] Review for first draft for draft-ietf-imapapnd-appendlimit-extension
Cc: "imapext <at> ietf.org" <imapext <at> ietf.org>, "Jayantheesh S.B"
 
 
Thanks Jay. A few comments.
 
Section 3.2: This section seems to imply that the extended list syntax for STATUS APPENDLIMIT must be supported by any server that advertises the APPENDLIMIT capability, regardless of whether it supports LIST-EXTENDED and LIST-STATUS. I think we should clarify that this section will only apply to servers that support LIST-EXTENDED, LIST-STATUS, and APPENDLIMIT. Supporting the new syntax might be non-trivial, and will be wasted work for servers that don't support per-mailbox limits (see below).
 
[Jay] When server does not support the mailbox specific limit, then capability response is enough for the client to know the limit.
 
SELECT and LIST response is needed only when server supports mailbox specific limit. It is not mandatory for the server to implement LIST STATUS, LIST-EXTENDED to get the mailbox specific limit.
 
“Note that a server implementing this extension, is syntactically compatible with
RFC 5819, however support for RFC 5258 or RFC 5819 is not required,
when implementing this extension.”
 
Mailbox-specific appendlimits: Our server will have a single appendlimit for all mailboxes, so we don't need the per-mailbox limits. However, the only way for a client to determine this will be to issue a SELECT or extended LIST on the target mailbox and note the absence of a per-mailbox appendlimit response. SELECT is expensive, and not all servers support extended list. Is there a way we could annotate the APPENDLIMIT capability to indicate that per-mailbox limits are not supported, so clients needn't bother querying them? It could be something as simple as adding a magic atom-char like '+' or
'!':
 
APPENDLIMIT=25000000!   ; system-wide append limit is 25000000,
applies to all mailboxes
 
[Jay] In Section 2, its mentioned that, when an IMAP server does not support the mailbox specific limit (Google server case), then as part of capability response, supported limit value can be published. But, if the server supports mailbox specific limit, then APPENDLIMIT value will be omitted as part of Capability response. It will send only APPENDLIMIT string in the capability, then client can always get the mailbox specific limit as part of SELECT, LIST response.
 
“The following example, demonstrates the APPENDLIMIT capability with
mailbox limit.
 
C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev1 ID APPENDLIMIT=257890
S: t1 OK foo
 
If APPENDLIMIT value is omitted in CAPABILITY response, then client
SHOULD issue SELECT/EXAMINE or LIST command to get the mailbox specific
limit set by the server.  New response code APPENDLIMIT is added to get
the mailbox specific limit.  Refer section 5 for response code syntax.
 
The following example demonstrates, its usage.
 
C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev1 ID APPENDLIMIT
S: t1 OK foo
 
C: t2 SELECT INBOX
S: * 172 EXISTS
S: * OK [APPENDLIMIT 257890] Maximum upload limit
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: t2 OK [READ-WRITE] SELECT completed”
 
Kindly let us know, if this answers your question. Please revert back for any clarification.
 
Regards,
Jay
 
On Mon, Jul 20, 2015 at 3:29 PM, Naren <narendrasingh.bisht <at> gmail.com> wrote:
>
> Hello Working Group,
>
> We have published the first draft for draft-ietf-imapapnd-appendlimit-extension.
>
> Please review the draft and drop your comments.
>
> ion/
>
> --
> Thanks & Regards
> -Naren
>
> _______________________________________________
> imapext mailing list
>
 
_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
Naren | 21 Jul 00:29 2015
Picon

Review for first draft for draft-ietf-imapapnd-appendlimit-extension

Hello Working Group,

We have published the first draft for draft-ietf-imapapnd-appendlimit-extension.

Please review the draft and drop your comments.


-- 
Thanks & Regards
-Naren
_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
S Moonesamy | 20 Jul 13:29 2015

Re: Imapapnd WG editor for draft-ietf-imapapnd-rfc2088bis

Hello,

Alexey will be the document editor for draft-ietf-imapapnd-rfc2088bis 
which is the second draft on our WG Charter.  The first and second 
drafts will be posted soon.  I suggest giving priority to the first draft.

Regards,
S. Moonesamy (as imapapdb WG Chair)

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext

S Moonesamy | 20 Jul 13:18 2015

Re: Imapapnd WG editor for draft-ietf-imapapnd-appendlimit-extension

Hello,

Jay and Naren will be the document editors for 
draft-ietf-imapapnd-appendlimit-extension which is the first draft on 
our WG Charter.  I would appreciate if you could help them by 
reviewing the draft once it is available.

Regards,
S. Moonesamy (as imapapdb WG Chair)

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext

Stu Brandt | 20 Jul 12:57 2015

IMAP Replace update

Based on discussion at IETF93, draft-brandt-imap-replace-01 has been 
submitted. The primary changes are a relaxing of the atomicity 
requirement and more information on the combination of REPLACE with 
CATENATE.  Feedback is certainly welcomed.

Here it is:

------------------------------------------------------------------------

Network Working Group                                          S. Brandt
Internet-Draft                                                       AOL
Intended status: Standards Track                           July 20, 2015
Expires: January 21, 2016

                          IMAP REPLACE Extension
                       draft-brandt-imap-replace-01

Abstract

    This document defines an IMAP extension which can be used to replace
    an existing message in a message store with a new message.  Message
    replacement is a common operation for clients that automatically save
    drafts or notes as a user composes them.

Status of This Memo

    This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is at http://datatracker.ietf.org/drafts/current/.

    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."

    This Internet-Draft will expire on January 21, 2016.

Copyright Notice

    Copyright (c) 2015 IETF Trust and the persons identified as the
    document authors.  All rights reserved.

    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
    carefully, as they describe your rights and restrictions with respect
    to this document.  Code Components extracted from this document must
    include Simplified BSD License text as described in Section 4.e of
    the Trust Legal Provisions and are provided without warranty as
    described in the Simplified BSD License.

Brandt                  Expires January 21, 2016                [Page 1]

Internet-Draft           IMAP REPLACE Extension                July 2015

Table of Contents

    1.  Conventions Used in This Document . . . . . . . . . . . . . .   2
    2.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   2
    3.  REPLACE and UID REPLACE . . . . . . . . . . . . . . . . . . .   3
      3.1.  Advertising Support for REPLACE . . . . . . . . . . . . .   3
      3.2.  REPLACE Command . . . . . . . . . . . . . . . . . . . . .   3
      3.3.  UID REPLACE Command . . . . . . . . . . . . . . . . . . .   4
      3.4.  Semantics of REPLACE and UID REPLACE  . . . . . . . . . .   4
      3.5.  IMAP State Diagram Impacts  . . . . . . . . . . . . . . .   5
    4.  Interaction with other extensions . . . . . . . . . . . . . .   5
      4.1.  RFC 4314, ACL . . . . . . . . . . . . . . . . . . . . . .   5
      4.2.  RFC 4469, CATENATE  . . . . . . . . . . . . . . . . . . .   6
      4.3.  RFC 4315, UIDPLUS . . . . . . . . . . . . . . . . . . . .   8
      4.4.  RFC 6785, IMAP Events in Sieve  . . . . . . . . . . . . .   8
      4.5.  RFC 7162, CONDSTORE/QRESYNC . . . . . . . . . . . . . . .   8
    5.  Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . .   8
    6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
    7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
    8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   9
    9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   9
      9.1.  Normative References  . . . . . . . . . . . . . . . . . .   9
      9.2.  Informative References  . . . . . . . . . . . . . . . . .  10
    Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Conventions Used in This Document

    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    document are to be interpreted as described in [RFC2119].

    Formal syntax is defined by [RFC5234].

    Example lines prefaced by "C:" are sent by the client and ones
    prefaced by "S:" by the server.

2.  Overview

    This document defines an IMAP [RFC3501] extension to facilitate
    replacing an existing message with a new one.  This is accomplished
    by defining a new REPLACE command and extending the UID command to
    allow UID REPLACE.

    Since there is no replace function in the base IMAP specification,
    clients have instead had to use a combination of three separate
    commands issued in serial fashion; APPEND, STORE, EXPUNGE.
    Pipelining of these three commands is not recommended since failure

Brandt                  Expires January 21, 2016                [Page 2]

Internet-Draft           IMAP REPLACE Extension                July 2015

    of any individual command should prevent subsequent commands from
    being executed lest the original message version be lost.

    Because of the non-atomic nature of the existing sequence,
    interruptions can leave messages in intermediate states which can be
    seen and acted upon by other clients.  Such interruptions can also
    strand older revisions of messages, thereby forcing the user to
    manually clean up multiple revisions of the same message in order to
    avoid wasteful quota consumption.  Additionally, the existing
    sequence can fail on APPEND due to an over-quota condition even
    though the subsequent STORE/EXPUNGE would free up enough space for
    the newly revised message.  And finally, server efficiencies may be
    possible with a single logical message replacement operation as
    compared to the existing APPEND/STORE/EXPUNGE sequence.

    In its simplest form, the REPLACE command is a single-command
    encapsulation of APPEND, STORE +flags \DELETED and UID EXPUNGE for a
    message, except that it avoids any of the quota implications or
    intermediate states associated with the 3 command sequence.  In
    handling a REPLACE command, a server MUST NOT generate a response
    code for the STORE +flags \DELETED portion of the sequence.
    Additionally, servers supporting the REPLACE command MUST NOT infer
    any inheritance of content, flags, or annotations from the message
    being replaced.  Finally, the replaced and replacing messages SHOULD
    NOT be present in the mailbox at the same time.

3.  REPLACE and UID REPLACE

3.1.  Advertising Support for REPLACE

    Servers that implement the REPLACE extension will return "REPLACE" as
    one of the supported capabilities in the CAPABILITY command response.

3.2.  REPLACE Command

    Arguments:  message sequence number
                mailbox name
                OPTIONAL flag parenthesized list
                OPTIONAL date/time string
                message literal

    Responses: no specific responses for this command

    Result:     OK - replace completed
                NO - replace error; can't remove specified message
                     or can't add new message content
                BAD - command unknown or arguments invalid

Brandt                  Expires January 21, 2016                [Page 3]

Internet-Draft           IMAP REPLACE Extension                July 2015

    Example:
      C: A003 REPLACE 4 Drafts (\Seen \Draft) {312}
      S: + Ready for literal data
      C: Date: Thu, 1 Jan 2015 00:05:00 -0500 (EST)
      C: From: Fritz Schmidt <fritz.ze <at> example.org>
      C: Subject: happy new year !!
      C: To: miss.mitzy <at> example.org
      C: Message-Id: <B238822388-0100000 <at> example.org>
      C: MIME-Version: 1.0
      C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
      C:
      C: Just saw the best fireworks show. Wish you were here.
      C:
      S: * 4 EXPUNGE
      S: A003 OK [APPENDUID 1 2000] Replace completed

3.3.  UID REPLACE Command

    This extends the first form of the UID command (see [RFC3501]
    Section 6.4.8) to add the REPLACE command defined above as a valid
    argument.  This form of REPLACE uses a UID rather than sequence
    number as its first parameter.

    Example:
      C: A004 UID REPLACE 2000 Drafts (\Seen \Draft) {350}
      S: + Ready for literal data
      C: Date: Thu, 1 Jan 2015 00:06:00 -0500 (EST)
      C: From: Fritz Schmidt <fritz.ze <at> example.org>
      C: Subject: happy new year !!
      C: To: miss.mitzy <at> example.org
      C: Message-Id: <B238822389-0100000 <at> example.org>
      C: MIME-Version: 1.0
      C: Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
      C:
      C: Just saw the best fireworks show. Wish you were here.
      C: Hopefully next year you can join us.
      C:
      S: * 4 EXPUNGE
      S: A004 OK [APPENDUID 1 2001] Replace completed

3.4.  Semantics of REPLACE and UID REPLACE

    The REPLACE and UID REPLACE commands take five arguments: a message
    identifier, a named mailbox, an optional parenthesized flag list, an
    optional message date/time string, and a message literal.  The
    message literal will be appended to the named mailbox, and the
    message specified by the message identifier will be removed from the

Brandt                  Expires January 21, 2016                [Page 4]

Internet-Draft           IMAP REPLACE Extension                July 2015

    selected mailbox.  These operations will appear to the client as a
    single action.  This has the same effect as the following sequence:

       1. APPEND
       2. [UID] STORE +FLAGS.SILENT \DELETED
       3. UID EXPUNGE

    In the cited sequence, the quota implications of the APPEND are
    evaluated within the context of the pending EXPUNGE so that only the
    net quota consumption is considered.  Additionally, the EXPUNGE
    portion of the sequence only applies to the specified message, not
    all messages flagged as \Deleted.

    Although the effect of REPLACE is identical to the steps above, the
    semantics are not identical; similar to MOVE [RFC6851], the
    intermediate states produced do not occur, and the response codes are
    different.  In particular, the response codes for EXPUNGE and APPEND
    will be returned while those for the STORE operation MUST NOT be
    generated.

    When an error occurs while processing REPLACE or UID REPLACE, the
    server MUST NOT leave the selected mailbox in an inconsistent state;
    any untagged EXPUNGE response MUST NOT be sent until all actions are
    successfully completed.

    Because of the similarity of REPLACE to APPEND, extensions that
    affect APPEND affect REPLACE in the same way.  Response codes such
    TRYCREATE (see [RFC3501] Section 6.3.11), as well as those defined by
    extensions, are sent as appropriate.  See Section 4 for more
    information about how REPLACE interacts with other IMAP extensions.

3.5.  IMAP State Diagram Impacts

    Unlike the APPEND command which is valid in the authenticated state,
    the REPLACE and UID REPLACE commands MUST only be valid in the
    selected state.  This difference from APPEND is necessary since
    REPLACE operates on message sequence numbers.

4.  Interaction with other extensions

    This section describes how REPLACE interacts with some other IMAP
    extensions.

4.1.  RFC 4314, ACL

    The ACL rights [RFC4314] required for UID REPLACE are the union of
    the ACL rights required for UID STORE and UID EXPUNGE in the current
    mailbox, and APPEND in the target mailbox.

Brandt                  Expires January 21, 2016                [Page 5]

Internet-Draft           IMAP REPLACE Extension                July 2015

4.2.  RFC 4469, CATENATE

    Servers supporting both REPLACE and CATENATE [RFC4469] MUST support
    the addtional append-data and resp-text-code elements defined the
    Formal Syntax section of RFC4469 in conjunction with the REPLACE
    command.  When combined with CATENATE, REPLACE can become a quite
    efficient way for message manipulation.

Brandt                  Expires January 21, 2016                [Page 6]

Internet-Draft           IMAP REPLACE Extension                July 2015

    Example:

      User composes message and attaches photo
      ----------------------------------------
      C: A010 APPEND Drafts (\Seen \Draft) {1201534}
      S: + Ready for literal data
      C: Date: Thu, 1 Jan 2015 00:10:00 -0500 (EST)
      C: From: Fritz Schmidt <fritz.ze <at> example.org>
      C: Message-ID: <B238822388-0100003 <at> example.org>
      C: MIME-Version: 1.0
      C: Content-Type: multipart/mixed;
      C:         boundary="------------030305060306060609050804"
      C:
      C: --------------030305060306060609050804
      C: Content-Type: text/plain; charset=utf-8; format=flowed
      C: Content-Transfer-Encoding: 7bit
      C:
      C: Here is picture from the fireworks
      C:
      C: Yours...
      C: Fritz
      C:
      C: --------------030305060306060609050804
      C: Content-Type: image/jpeg;
      C:         name="Fireworks.jpg"
      C: Content-Transfer-Encoding: base64
      C: Content-Disposition: attachment;
      C:         filename="Fireworks.jpg"
      C:
        <large base64 encoded part goes here>
      C:
      C: --------------030305060306060609050804--
      S: A010 OK [APPENDUID 1 3002] APPEND complete

      User completes message with To: and Subject: fields
      ---------------------------------------------------
      C: A011 UID REPLACE 3002 Drafts CATENATE (TEXT {71}
      S: + Ready for literal data
      C: To: Mitzy <miss.mitzy <at> example.org>
      C: Subject: My view of the fireworks
      C:  URL "/Drafts/;UID=3002")
      S: * 5 EXISTS
      S: * 4 EXPUNGE
      S: A011 OK [APPENDUID 1 3003] REPLACE completed

Brandt                  Expires January 21, 2016                [Page 7]

Internet-Draft           IMAP REPLACE Extension                July 2015

4.3.  RFC 4315, UIDPLUS

    Servers supporting both REPLACE and UIDPLUS [RFC4315] SHOULD send
    APPENDUID in response to a UID REPLACE command.  For additional
    information see section 3 of RFC4315.  Servers implementing REPLACE
    and UIDPLUS are also advised to send the APPENDUID response code in
    an untagged OK before sending the EXPUNGE or replaced responses.
    (Sending the APPENDUID in the tagged OK, as described in the UIDPLUS
    specification means that the client first receives an EXPUNGE for a
    message and afterwards APPENDUID for the new message.  It can be
    unnecessarily difficult to process that sequence usefully.)

4.4.  RFC 6785, IMAP Events in Sieve

    REPLACE applies to IMAP events in Sieve [RFC6785] in the same way
    that APPEND does.  Therefore, REPLACE can cause a Sieve script to be
    invoked with the imap.cause set to "APPEND".  Because the
    intermediate state of STORE +FLAGS.SILENT \DELETED is not exposed by
    REPLACE, no action will be taken that results in a imap.cause of
    FLAG.

4.5.  RFC 7162, CONDSTORE/QRESYNC

    Servers implementing both REPLACE and CONDSTORE/QRESYNC [RFC7162]
    MUST treat the message being replaced as if it were being removed
    with a UID EXPUNGE command.  Sections 3.2.9 and 3.2.10 of RFC 7162
    are particularly relevant for this condition.

5.  Formal Syntax

    The following syntax specification uses the Augmented Backus-Naur
    Form (ABNF) notation as specified in [RFC5234].  [RFC3501] defines
    the non-terminals "capability","command-select", "mailbox", and "seq-
    number".  [RFC4466] defines the non-terminal "append-message".

    Except as noted otherwise, all alphabetic characters are case-
    insensitive.  The use of upper or lower case characters to define
    token strings is for editorial clarity only.  Implementations MUST
    accept these strings in a case-insensitive fashion.

    capability     =/ "REPLACE"

    command-select =/ replace
    replace        = "REPLACE" SP seq-number SP mailbox append-message
    uid            = "UID" SP (copy / fetch/ search / store / move /
                               replace)

Brandt                  Expires January 21, 2016                [Page 8]

Internet-Draft           IMAP REPLACE Extension                July 2015

6.  Security Considerations

    This document is believed to add no security problems beyond those
    that may already exist with the base IMAP specificaiton.

7.  IANA Considerations

    The IANA is requested to add REPLACE to the "IMAP 4 Capabilities"
    registry, http://www.iana.org/assignments/imap4-capabilities.

8.  Acknowledgements

    The author would like to thank the participants of IMAPEXT with
    particular thanks to Arnt Gulbrandsen, Alexey Melkinov, and Chris
    Newman for their specific contributions.

9.  References

9.1.  Normative References

    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/
               RFC2119, March 1997,
               <http://www.rfc-editor.org/info/rfc2119>.

    [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
               4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003,
               <http://www.rfc-editor.org/info/rfc3501>.

    [RFC4314]  Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
               RFC 4314, DOI 10.17487/RFC4314, December 2005,
               <http://www.rfc-editor.org/info/rfc4314>.

    [RFC4315]  Crispin, M., "Internet Message Access Protocol (IMAP) -
               UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315,
               December 2005, <http://www.rfc-editor.org/info/rfc4315>.

    [RFC4466]  Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
               ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006,
               <http://www.rfc-editor.org/info/rfc4466>.

    [RFC4469]  Resnick, P., "Internet Message Access Protocol (IMAP)
               CATENATE Extension", RFC 4469, DOI 10.17487/RFC4469, April
               2006, <http://www.rfc-editor.org/info/rfc4469>.

Brandt                  Expires January 21, 2016                [Page 9]

Internet-Draft           IMAP REPLACE Extension                July 2015

    [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
               Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/
               RFC5234, January 2008,
               <http://www.rfc-editor.org/info/rfc5234>.

    [RFC6785]  Leiba, B., "Support for Internet Message Access Protocol
               (IMAP) Events in Sieve", RFC 6785, DOI 10.17487/RFC6785,
               November 2012, <http://www.rfc-editor.org/info/rfc6785>.

    [RFC7162]  Melnikov, A. and D. Cridland, "IMAP Extensions: Quick Flag
               Changes Resynchronization (CONDSTORE) and Quick Mailbox
               Resynchronization (QRESYNC)", RFC 7162, DOI 10.17487/
               RFC7162, May 2014,
               <http://www.rfc-editor.org/info/rfc7162>.

9.2.  Informative References

    [RFC6851]  Gulbrandsen, A. and N. Freed, Ed., "Internet Message
               Access Protocol (IMAP) - MOVE Extension", RFC 6851, DOI
               10.17487/RFC6851, January 2013,
               <http://www.rfc-editor.org/info/rfc6851>.

Author's Address

    Stuart Brandt
    AOL
    43623 Preddy Ct
    Ashburn, VA  20147
    USA

    Email: stujenerin <at> aol.com

Brandt                  Expires January 21, 2016               [Page 10]

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext

IETF Secretariat | 16 Jul 13:46 2015
Picon

Milestones changed for imapapnd WG

Changed milestone "Submit IMAP APPENDLIMIT Extension draft to the IESG
(Proposed Standard)", set state to active from review, accepting new
milestone.

Changed milestone "Submit IMAP4 non-synchronizing literals draft to
the IESG (Proposed Standard)", set state to active from review,
accepting new milestone.

URL: https://datatracker.ietf.org/wg/imapapnd/charter/

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext

S Moonesamy | 16 Jul 12:07 2015

Re: imapapdb milestones

Hello,

Thanks to everyone who provided feedback on the milestones.  I'll go 
with Alexey's suggestion [1] as the working group is okay with that:

   First draft  - August 2015
   Second Draft - September 2015

Regards,
S. Moonesamy (as imapapdb WG Chair)

1. http://www.ietf.org/mail-archive/web/imapext/current/msg05505.html

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext

Jayantheesh S B | 15 Jul 22:19 2015

The IMAP APPENDLIMIT Extension - version 05

Dear SM,

 

Please find the latest version (05) of the draft attached.

 

Kindly consider this version of the document for next level review.

 

Regards,

Jay

INTERNET-DRAFT                                           Jayantheesh S B 
Intended status: Standards Track                                 Samsung
Expires: December 2015                              Narendra Singh Bisht
                                                                 Samsung
                                                           July 15, 2015

                      The IMAP APPENDLIMIT Extension
                draft-jayantheesh-imap-appendlimit-extension-05

Abstract

This memo defines an extension to the IMAP service whereby a server can
advertise its capability, to support maximum mail upload size using
CAPABILITY, SELECT/EXAMINE and LIST command.

Status of this Memo

This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. This document may not be modified, and
derivative works of it may not be created, except to publish it as an
RFC and to translate it into languages other than English.

Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups.  Note that other groups
may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html

This Internet-Draft will expire on December, 2015.

Copyright Notice

Copyright (c) 2014 IETF Trust and the persons identified as the
document authors.  All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document.  Please review these documents carefully,
as they describe your rights and restrictions with respect to this
document.

Jayantheesh & Narendra     Expires December, 2015             [Page 1]

Internet-Draft               IMAP APPENDLIMIT                July 2015

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
     1.1. Conventions and Terminology . . . . . . . . . .  . . . . .   2
   2. APPENDLIMIT Extension . . . . . . . . . . . . . . . . . . . . .  2
   3. Mailbox specific APPENDLIMIT . . . . . . . . . . . . . . . . . . 3
     3.1. SELECT response . . . . . . . . . . . . . . . . . . . . . .  4
     3.2. LIST response . . . . . . . . . . . . . . . . . . . . . . .  4
   4. APPEND response . . . . . . . . . . . . . . . . . . . . . . . .  5
   5. Formal syntax . . . . . . . . . . . . . . . . . . . . . . . . .  5
   6. Security Considerations  . . . . . . . . . . . . . . . . . . . . 6
   7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  6
   8. References . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
    8.1 Normative References . . . . . . . . . . . . . . . . . . . . . 6
    8.2 Informative References . . . . . . . . . . . . . . . . . . . . 7
   9. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . .  7
   10. Author's Address . .. . . . . . . . . . . . . . . . . . . . . . 7

1. Introduction

Several IMAP server have limitation for mail upload size which is not
published to the email client.  When email client APPEND a mail with
huge attachments, it fails due to size restriction set by the IMAP
server.  This results in unnecessary resource usage.  Especially in the 
mobile device environment, appending mail with huge attachment consumes
device resources like device battery power and mobile data.

The IMAP APPENDLIMIT extension provides an ability to advertise maximum
upload size allowed by the IMAP server, so that email client knows the
size limitation beforehand.

1.1. Conventions and Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119.

Example lines prefaced by "C:" are sent by the client and ones prefaced
by "S:" by the server.  The five characters [...] means that something
has been elided.

2. APPENDLIMIT Extension

An IMAP server that supports APPENDLIMIT advertises this by including
the word APPENDLIMIT in its capability list.  IMAP server shall publish
the supported mail upload size as part of CAPABILITY response.  The

Jayantheesh & Narendra     Expires December, 2015            [Page 2]

Internet-Draft               IMAP APPENDLIMIT               July 2015

advertised upload limit is common across the mailboxes, but client
can still issue SELECT/EXAMINE or LIST command to get the mailbox
specific upload limit set by the IMAP server.  In this case,
APPENDLIMIT value obtained as part of SELECT/EXAMINE or LIST command
takes precedence over the value returned as part of CAPABILITY
response.

The following example, demonstrates the APPENDLIMIT capability with
mailbox limit.

C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev1 ID APPENDLIMIT=257890
S: t1 OK foo

If APPENDLIMIT value is omitted in CAPABILITY response, then client
SHOULD issue SELECT/EXAMINE or LIST command to get the mailbox specific
limit set by the server.  New response code APPENDLIMIT is added to get
the mailbox specific limit.  Refer section 5 for response code syntax.

The following example demonstrates, its usage.

C: t1 CAPABILITY
S: * CAPABILITY IMAP4rev1 ID APPENDLIMIT
S: t1 OK foo

C: t2 SELECT INBOX
S: * 172 EXISTS
S: * OK [APPENDLIMIT 257890] Maximum upload limit
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Deleted \Seen \*)] Limited
S: t2 OK [READ-WRITE] SELECT completed

By looking at the upload size restriction set by the IMAP server, client
MUST not try to upload mail more than advertised limit in the APPEND
command. 

3. Mailbox specific APPENDLIMIT

IMAP server can still have mailbox specific APPENDLIMIT restriction,
which may not be advertised as part of CAPABILITY response.  In this
case, client can issue SELECT/EXAMINE command to get the per mailbox
specific limit set by the server.  Similarly, if client wish to know
the mailbox specific limit in authenticated state, can be done by
issuing the LIST command in combination with STATUS command.

Jayantheesh & Narendra     Expires December, 2015            [Page 3]

Internet-Draft               IMAP APPENDLIMIT               July 2015

3.1 SELECT response

Client can get the per mailbox append limit by issuing the SELECT/
EXAMINE command.  APPENDLIMIT size to this mailbox is obtained as part
of untagged OK response.  In this case, this APPENDLIMIT value will
supersede the value received as part of CAPABILITY response.  If no
per-mailbox APPENDLIMIT is specified for a folder, but the server did
specify a common APPENDLIMIT in the CAPABILITY response, then the
common APPENDLIMIT applies to that folder.

C: t2 SELECT INBOX
S: * 172 EXISTS
S: * OK [APPENDLIMIT 257890] Maximum upload limit
S: [...]
S: t2 OK [READ-WRITE] SELECT completed

In the above example, APPENDLIMIT represents the maximum upload size for
this mailbox.

OK [APPENDLIMIT <n>] Maximum upload limit for this mailbox, in bytes.
                     Refer to section 5 for more information.  If this
                     is missing, the client can always honour the
                     value received as part of CAPABILITY response.

3.2 LIST response

IMAP client can get the mailbox specific APPENDLIMIT in authenticated
state, where it do not need to issue SELECT/EXAMINE command.  LIST
command in combination with STATUS command can be issued to get the per
mailbox specific APPENDLIMIT set by the server.  Refer RFC 5819 for the
usage of LIST command in combination with STATUS command.  Note that a
server implementing this extension, is syntactically compatible with
RFC 5819, however support for RFC 5258 or RFC 5819 is not required,
when implementing this extension.

The following example demonstrates, its usage.

C: t1 LIST "" % RETURN (STATUS (APPENDLIMIT))
S: * LIST () "."  "INBOX"
S: * STATUS "INBOX" (APPENDLIMIT 257890)
S: t1 OK List completed.

New attribute APPENDLIMIT is added to get the limit set by the server
for this mailbox as part of STATUS command.  The STATUS response occurs
as a result of an STATUS command.  It returns the mailbox name that

Jayantheesh & Narendra     Expires December, 2015            [Page 4]

Internet-Draft               IMAP APPENDLIMIT               July 2015

matches the STATUS specification and the requested mailbox status
information.  IMAP server should recognize an extra "RETURN (STATUS
 (APPENDLIMIT))" at the end of a LIST command and emit an extra STATUS
response for each matching mailbox.  Refer to section 5 for the syntax.

Invoking STATUS command with APPENDLIMIT is also acceptable.  Below
example demonstrates, its usage.

C: t1 STATUS INBOX (APPENDLIMIT)
S: * STATUS INBOX (APPENDLIMIT 257890)
S: t1 OK STATUS completed

4. APPEND response

If client uploads a mail which exceeds the maximum upload size set
to that mailbox, then server SHALL reject the APPEND command with a
tagged TOOBIG response code.  Refer RFC 4469 Section (4) for various
APPEND response codes and its handling.

Client can avoid use of LITERAL+, when maximum upload size
supported by the IMAP server is unknown. 

5. Formal syntax

The following syntax specification uses the Augmented Backus-Naur
Form (ABNF) notation as specified in [RFC5234] including the core
rules in Appendix B.1.  [RFC3501] defines the non-terminals
"capability", "resp-text-code" and "status-att".
Except as noted otherwise, all alphabetic characters are case-
insensitive.  The use of upper or lower case characters to define
token strings is for editorial clarity only.  Implementations MUST
accept these strings in a case-insensitive fashion.

appendlimit-cap = "APPENDLIMIT" ["=" append-limit-value]
capability /= appendlimit-cap

appendlimit-respcode = "APPENDLIMIT" SP append-limit-value
resp-text-code /= appendlimit-respcode

append-limit-value = 1*DIGIT
                     ; Unsigned 64-bit integer
                     ; (0 <= n < 18,446,744,073,709,551,615)

appendlimit-status-att = "APPENDLIMIT"
status-att /=appendlimit-status-att

A number indicating the fixed maximum message size in bytes that the
server will accept.  APPENDLIMIT=0 indicates the server SHALL not
Jayantheesh & Narendra     Expires December, 2015            [Page 5]

Internet-Draft               IMAP APPENDLIMIT               July 2015

accept APPEND command due to size restriction.  The syntax of the
parameter follows the augmented BNF notation of [RFC5234].  If this
capability is omitted, no information is conveyed about the server's
fixed maximum mail upload size.

6. Security Consideration

It is believed that this extension doesn't add any new security
considerations that are not already present in the base IMAP
protocol [RFC3501].

7. IANA Considerations

The IANA is requested to add APPENDLIMIT to the IMAP4 Capabilities
Registry.  [[Note to RFC-editor: please remove the following before
publication: This registration should take place at the following
location: http://www.iana.org/assignments/imap4-capabilities]]

8. References

8.1 Normative References

The following documents contain definitions or specifications that
are necessary to understand this document properly

[RFC2119]  Bradner, "Key words for use in RFCs to Indicate
           Requirement Levels", RFC 2119, Harvard University, March
           1997.

[RFC3501]  Crispin, "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1",
           University of Washington, March 2003

[RFC5234]  Crocker, Overell, "Augmented BNF for Syntax
           Specifications: ABNF", RFC 5234, Brandenburg
           Internetworking, Demon Internet Ltd, January 2008

[RFC5322]  P. Resnick, Ed, "Internet Message Format", RFC 5322,
           Qualcomm Incorporated, October 2008

[RFC2088]  J. Myers, Carnegie Mellon, "IMAP4 non-synchronizing
           literals",  January 1997
		   
[RFC4469]  P. Resnick, "Internet Message Access Protocol (IMAP)
           CATENATE Extension",  April 2006
		   
[RFC5819]  A. Melnikov, T. Sirainen, "IMAP4 Extension for Returning
           STATUS Information in Extended LIST",  March 2010
		   
Jayantheesh & Narendra     Expires August, 2015               [Page 6]

Internet-Draft               IMAP APPENDLIMIT                July 2015

[RFC5258]  A. Melnikov, B. Leiba, "Internet Message Access Protocol
           version 4 - LIST Command Extensions",  March 2010
		   
8. 2 Informative References

The following documents describe related protocols:

[RFC2087]  Myers, J., "IMAP4 QUOTA extension", RFC 2087,
           January 1997

[RFC7377]  B. Leiba, A. Melnikov, "IMAP4 Multimailbox SEARCH
           Extension", RFC 7377, October 2014

9. Acknowledgement

Thanks to Alexey Melnikov, Dave Cridland, Adrien de Croy,
Michael M Slusarz, Timo Sirainen, Chris Newman,
Pete Maclean, Jamie Nicolson, Stu Brandt, Bron Gondwana,
Arnt Gulbrandsen, Cyrus Daboo, Jan Kundrát, Brandon Long
and Barry Leiba for providing valuable comments. 

10. Author's Address

Jayantheesh S B
Samsung Telecommunications America,
685 US Highway 202/206,
Bridgewater, NJ 08807.
USA
Email: jayantheesh.sb <at> gmail.com

Narendra Singh Bisht
Samsung Telecommunications America,
685 US Highway 202/206,
Bridgewater, NJ 08807.
USA
Email: narendrasingh.bisht <at> gmail.com

Jayantheesh & Narendra     Expires December, 2015             [Page 7]
_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext
S Moonesamy | 27 Jun 00:20 2015

imapapdb milestones

Hello,

The Working Group Charter for IMAP APPEND Extensions (imapapnd) is at 
https://datatracker.ietf.org/wg/imapapnd/charter/  The working group 
has to deliver two Standards Track specifications to the IESG.  The 
first step is set the milestones for the 
draft-jayantheesh-imap-appendlimit-extension and 
draft-melnikov-rfc2088bis.  Could the working group participants 
please suggest a date for each of the two drafts?  I would like to 
have the milestones settled by 30 June so that the working group can 
proceed with the technical discussions about the two drafts.

If you have any questions about the work of the working group please 
feel free to raise them on the mailing list [1].  You can also email 
me if you find that easier.

Regards,
S. Moonesamy (as imapapdb WG Chair)

1. https://www.ietf.org/mailman/listinfo/imapext

_______________________________________________
imapext mailing list
imapext <at> ietf.org
https://www.ietf.org/mailman/listinfo/imapext


Gmane