IESG Secretary | 19 May 15:41 2016

WG Action: Conclusion of IMAP APPEND Extensions (imapapnd)

The IMAP APPEND Extensions (imapapnd) working group in the Applications 
and Real-Time Area has successfully completed all of its milestones and 
is now concluded. The IESG contact persons are Alexey Melnikov and Ben 

The mailing list will remain open.

imapext mailing list
imapext <at>

S Moonesamy | 18 May 19:06 2016

IMAPapnd Working Group shutdown

Hi Alexey,

The IMAPapnd has completed the work on the two items which it was 
chartered to work on with the publication of RFC 7888 and RFC 
7889.  I suggest shutting down the IMAPapnd working group.

I'll take this opportunity to thank both Barry Leiba and you as Area 
Directors.  I would also like to thank Jay and Naren as authors of 
RFC 7889.  This work would not have been possible without the effort 
of the IMAPapnd Working Group participants who reviewed the two documents.

S. Moonesamy (as imapapdb WG Chair)

imapext mailing list
imapext <at>

Suresh Krishnan | 21 Apr 02:01 2016

Suresh Krishnan's No Objection on draft-ietf-imapapnd-rfc2088bis-04

Suresh Krishnan has entered the following ballot position for
draft-ietf-imapapnd-rfc2088bis-04: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:

There are no remarks associated with this position.

imapext mailing list
imapext <at>

S Moonesamy | 19 Mar 22:05 2016

Re: OPS-DIR review of draft-ietf-imapapnd-rfc2088bis-04

Hi Mahesh,
At 10:56 19-03-2016, Mahesh Jethanandani wrote:
>I have reviewed this document as part of the Operational 
>directorate's ongoing effort to


>Document reviewed:

Thanks for the review.

S. Moonesamy (as document shepherd) 

imapext mailing list
imapext <at>

IETF Secretariat | 16 Mar 20:08 2016

Milestones changed for imapapnd WG

Changed milestone "Submit IMAP APPENDLIMIT Extension draft to the IESG
(Proposed Standard)", resolved as "Done".

Changed milestone "Submit IMAP4 non-synchronizing literals draft to
the IESG (Proposed Standard)", resolved as "Done".


imapext mailing list
imapext <at>

Alexey Melnikov | 6 Mar 22:35 2016

Re: New Version Notification for draft-ietf-imapapnd-rfc2088bis-04.txt

On 06/03/2016 21:32, internet-drafts <at> wrote:

> URL:  
> Status:
> Htmlized:
> Diff: 

All issues addressed by Barry are addressed, except for the last one
which we are still discussing. I post another version if any further
changes would be agreed upon.

imapext mailing list
imapext <at>

Barry Leiba | 5 Mar 00:03 2016

AD review of draft-ietf-imapapnd-rfc2088bis-03

Here's my review of draft-ietf-imapapnd-rfc2088bis-03.  Much of this
is editorial, but there are a couple of substantive things here.

-- Introduction --

"(RFC 3501)" should be a citation, "[RFC3501]".  (And then you can
remove the citation at the beginning of Section 3, if you like (or
leave it, if you prefer).)

-- Section 3 --

   If the server does
   not advertise either of the above capabilities, the client must use
   synchronizing literals instead.

Minor point, but I'd word this like this (because I find "instead" to
be a bit inapt):

   If the server does
   not advertise either of the above capabilities, the client can only
   use synchronizing literals.

   The protocol receiver of an IMAP server must check the end of every
   received line

That "must" should probably be "MUST".

We probably should also take this opportunity to fix a bit of
(Continue reading)

S Moonesamy | 2 Mar 16:26 2016

IPR disclosure - draft-ietf-imapapnd-rfc2088bis-03

Hi Alexey,

As you are the document author for draft-ietf-imapapnd-rfc2088bis-03, 
can each of you confirm that any and all appropriate IPR disclosures 
required for full conformance with the provisions of BCP 78 and BCP 
79 have already been filed?

S. Moonesamy (as document shepherd)

imapext mailing list
imapext <at>

internet-drafts | 2 Mar 15:11 2016

I-D Action: draft-ietf-imapapnd-rfc2088bis-03.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 of the IETF.

        Title           : IMAP4 non-synchronizing literals
        Author          : Alexey Melnikov
	Filename        : draft-ietf-imapapnd-rfc2088bis-03.txt
	Pages           : 8
	Date            : 2016-03-02

   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 that does not require this network round

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

   This document obsoletes RFC 2088.

The IETF datatracker status page for this draft is:

There's also a htmlized version available at:
(Continue reading)

S Moonesamy | 2 Mar 07:38 2016

Review of draft-ietf-imapapnd-rfc2088bis-02

Hi Alexey,

I reviewed draft-ietf-imapapnd-rfc2088bis-02 [1].

In Section 1:

   "The non-synchronizing literal is added an alternate form of literal,
    and may appear in communication from client to server instead of the
    IMAP [RFC3501] form of literal."

I found the sentence unclear (is added an alternate form ...).  The 
second paragraph in the Abstract is clear and I understood what the 
document specifies.

   "The non-synchronizing literal is distinguished from the original
    synchronizing literal by having a plus ('+') between the octet count
    and the closing brace ('}').  The server does not generate a command
    continuation request in response to a non-synchronizing literal, and
    clients are not required to wait before sending the octets of a non-
    synchronizing literal."

The above describes the "non-synchronizing literal".  The previous 
describes the usage of the "non-synchronizing literal".  I suggest 
describing the "non-synchronizing literal" and explain how it may be 
used after that.

In Section 1:

   "The non-synchronizing literal form MUST NOT be sent from server
    to client."
(Continue reading)

S Moonesamy | 5 Feb 21:17 2016

WGLC for draft-ietf-imapapnd-rfc2088bis-02


This message starts a Working Group Last Call for "IMAP4 
non-synchronizing literals" (draft-ietf-imapapnd-rfc2088bis-02).  The 
I-D can be accessed at

This Working Group Last Call will end on Saturday 20th 
February.  Please review the I-D and send comments to the 
imapext <at> mailing list.

S. Moonesamy (as imapapdb WG Chair)

imapext mailing list
imapext <at>