S Moonesamy | 5 Feb 21:17 2016

WGLC for draft-ietf-imapapnd-rfc2088bis-02

Hello,

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
https://tools.ietf.org/html/draft-ietf-imapapnd-rfc2088bis-02

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

Regards,
S. Moonesamy (as imapapdb WG Chair)

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

internet-drafts | 5 Feb 13:31 2016
Picon

I-D Action: draft-ietf-imapapnd-rfc2088bis-02.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-02.txt
	Pages           : 7
	Date            : 2016-02-05

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
   of literals 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-02

(Continue reading)

Stu Brandt | 19 Jan 17:05 2016

IMAP Replace update (02)

Based on some discussion off list, draft-brandt-imap-replace-02 has been 
submitted. It attempts to add clarity around use cases where the 
selected mailbox and the mailbox specified as command argument could vary.

Here it is:
------------------------------------------------------------------------
Network Working Group                                          S. Brandt
Internet-Draft                                                       AOL
Intended status: Standards Track                        January 19, 2016
Expires: July 22, 2016

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

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/.
(Continue reading)

S Moonesamy | 10 Jan 18:23 2016

Re: Kathleen Moriarty's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT)

Hi Barry,
At 09:18 10-01-2016, Barry Leiba wrote:
>Yes: the first sentence says that this extension is about cooperative
>clients.  The second sentence says that it does nothing with respect
>to abusive clients, and that servers still have to deal with that.
>Are you saying that you think that's unclear and needs a few more
>words?

Sorry, I should have been clear.  I explained what I understood on 
reading the text and concluded that it is fine.  I don't think that 
more words are needed.

Regards,
S. Moonesamy 

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

S Moonesamy | 10 Jan 16:45 2016

Re: Kathleen Moriarty's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT)

Hi Barry,
At 14:27 09-01-2016, Barry Leiba wrote:
>Great; thanks.  I'd like to hear from a couple of others to make sure
>it's OK with a few more people.  Alexey, SM, can the two of you weigh
>in?

The first sentence in Section 6 
(draft-ietf-imapapnd-appendlimit-extension-10) mentions that the 
extention does not introduce new security concerns.  The second 
sentence is about  clients which exhibit abusive behaviour.

The text looks fine.

Regards,
S. Moonesamy  

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

Ben Campbell | 7 Jan 00:15 2016

Ben Campbell's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT)

Ben Campbell has entered the following ballot position for
draft-ietf-imapapnd-appendlimit-extension-08: 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extension/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

- section 2, last paragraph:

It was not obvious to me if "An IMAP client SHOULD be able to parse both
formats. " meant both STATUS and LIST, or both global and per-mailbox. I
assume the former.

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

Kathleen Moriarty | 6 Jan 02:28 2016
Picon

Kathleen Moriarty's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT)

Kathleen Moriarty has entered the following ballot position for
draft-ietf-imapapnd-appendlimit-extension-08: 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extension/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks for your work on this extension, it seems useful, I just have a
few comments that can be left to the editors and AD to handle if I
disappear for maternity leave.  

I think the security considerations section could be a bit more clear on
the actual risks with this extension.  I think the flow of the section
can be improved to make these risks a bit more clear.

First, this extension lets you find out the limit for either the server
or individual mailboxes, so shouldn't the first part of the description
focus on a possible DoS filling up those resources?

I'm not sure why there is a focus on "without this extension".
(Continue reading)

S Moonesamy | 5 Jan 23:33 2016

Re: OPS-DIR review of draft-ietf-imapapnd-appendlimit-extension-08

Hi Sarah,
At 10:58 04-01-2016, Sarah Banks wrote:
>The document is ready with a minor nit/comment.

Thanks for the review.

>This draft discusses an extension to IMAP, where a server can use 
>APPENDLIMIT to communicate to the client the maximum mail upload 
>size, via several commands (status, list, capability). The document 
>cites a particularly useful use case, of mobile devices and resource 
>contention. I found the document fairly well written, and I have a 
>single comment:
>
>Section 3.1 - is the should in "should issue a STATUS 
>command"  normative? It reads as if it could be...

The "should" in the above is not normative.  The usage of a RFC 2119 
"SHOULD" in the sentence would be incorrect as there isn't any other 
way to get the desired Section 3.1 "STATUS response".

>Authors, thanks for making me research "hone in" versus "home in" 
>(ala section 6). :)

I'll credit Barry for that. :-)

Regards,
S. Moonesamy (as document shepherd) 

_______________________________________________
imapext mailing list
(Continue reading)

Alissa Cooper | 5 Jan 20:10 2016
Picon

Alissa Cooper's No Objection on draft-ietf-imapapnd-appendlimit-extension-08: (with COMMENT)

Alissa Cooper has entered the following ballot position for
draft-ietf-imapapnd-appendlimit-extension-08: 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-imapapnd-appendlimit-extension/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

It's unusual to see author names without first initials in the document
header. Not sure if that was intentional but seems like it should be
fixed (assuming the authors have both first names and surnames).

= Section 2 =

"In this case the client SHOULD get an APPENDLIMIT value by issuing a
   STATUS or LIST command.

   An IMAP client SHOULD be able to parse both formats.  By looking at
   the upload size advertised by the IMAP server, a client MUST NOT try
   to APPEND mail more than the advertised limit."

(Continue reading)

S Moonesamy | 31 Dec 22:47 2015

Re: SecDir review of draft-ietf-imapapnd-appendlimit-extension

Hi Paul,
At 13:36 31-12-2015, Paul Wouters wrote:
>This document is Ready
>
>The document describes an IMAP extension to convey a limit size for
>appending to a mailbox. This prevents situations where the clients
>upload data only to have it rejected by the server. The security
>considerations are therefor limited in scope, as it is more of an
>optimization. The only item mentioned in the section is that an
>attacker that knows the limit could optimize their attack by sending
>better matching sized payloads for a denial-of-service attack, and
>servers should disconnect such clients as abusive. I believe that
>it correctly covers any new security risks that could arise from this
>document's specification. And that this issue is very minor compared
>to other DOS attacks possible by malicious clients that can successfully
>authenticate against the IMAP server.

Thanks for the review.

As a note for the authors, there isn't any issue.

Regards,
S. Moonesamy (as document shepherd) 

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

(Continue reading)

internet-drafts | 29 Dec 17:12 2015
Picon

I-D Action: draft-ietf-imapapnd-appendlimit-extension-08.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           : The IMAP APPENDLIMIT Extension
        Authors         : Jayantheesh S B
                          Narendra Singh Bisht
	Filename        : draft-ietf-imapapnd-appendlimit-extension-08.txt
	Pages           : 7
	Date            : 2015-12-29

Abstract:
   This document defines an extension to the IMAP service whereby a
   server can inform the client about maximum message upload sizes,
   allowing the client to avoid sending APPEND commands that will fail
   because the messages are too large.

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

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

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-imapapnd-appendlimit-extension-08

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
(Continue reading)


Gmane