[secdir] [new-work] WG Review: IMAP APPEND Extensions (imapapnd)

The IESG <iesg@ietf.org> Fri, 12 June 2015 16:07 UTC

Return-Path: <new-work-bounces@ietf.org>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 527441A7007; Fri, 12 Jun 2015 09:07:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1434125226; bh=S6l/yl4MZ9nuAj6fuDboLfX/9N/S/A3JFE52Rw/+xG0=; h=MIME-Version:From:To:Message-ID:Date:Subject:Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: Content-Type:Content-Transfer-Encoding:Sender; b=H1jmOH0fhZpXoy83WphsjGY4v1aKQZfst2JyZcRMrPsgW/p1zwXbj25Gi7EUHqhp7 4ADMUE6fLaIqjV4cs+QUHiZIT8CSnlklvlnhLXl+J3F3k5t6A67m63mHzrqPhMM/OR Eo9bAHxCq0qwnUWRwlNvUHlME4za5FEN59FTLu9E=
X-Original-To: new-work@ietfa.amsl.com
Delivered-To: new-work@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C23D1A6F30; Fri, 12 Jun 2015 09:07:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xIxWUj3l3JoZ; Fri, 12 Jun 2015 09:07:02 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E45031A1BFA; Fri, 12 Jun 2015 09:06:49 -0700 (PDT)
MIME-Version: 1.0
From: The IESG <iesg@ietf.org>
To: <new-work@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.3.p2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150612160649.18953.62329.idtracker@ietfa.amsl.com>
Date: Fri, 12 Jun 2015 09:06:49 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/new-work/zti76PktxTE-5JA_6eR9UIFIA40>
X-BeenThere: new-work@ietf.org
X-Mailman-Version: 2.1.15
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: new-work-bounces@ietf.org
Sender: "new-work" <new-work-bounces@ietf.org>
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/fh-Km8H35sX0y0gHc1lc2lKPS4M>
X-Mailman-Approved-At: Fri, 12 Jun 2015 09:11:49 -0700
Subject: [secdir] [new-work] WG Review: IMAP APPEND Extensions (imapapnd)
X-BeenThere: secdir@ietf.org
Reply-To: iesg@ietf.org
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jun 2015 16:07:06 -0000

A new IETF working group has been proposed in the Applications and
Real-Time Area. The IESG has not made any determination yet. The
following draft charter was submitted, and is provided for informational
purposes only. Please send your comments to the IESG mailing list (iesg
at ietf.org) by 2015-06-22.

IMAP APPEND Extensions (imapapnd)
------------------------------------------------
Current Status: Proposed WG

Assigned Area Director:
  Barry Leiba <barryleiba@computer.org>;

Mailing list
  Address: imapext@ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/imapext
  Archive: https://www.ietf.org/mail-archive/web/imapext/

Charter:

The Internet Message Access Protocol (IMAP), defined in RFC 3501,
specifies a protocol for transferring email messages between a server
that implements a message store, and a client. It also includes commands
for manipulating the message store -- creating, deleting, and renaming
mailboxes, adding a message to a mailbox, and copying messages from one
mailbox to another.

IMAP (RFC 3501) contains the "literal" syntactic construct for
transferring blocks of data. Sending an IMAP literal string entails
first sending the length of the string, waiting for a response that
accepts a string of that length, then sending the string itself.
This complicates client implementations and resulted in definition
of the "LITERAL+" IMAP extension (RFC 2088), which specifies an
alternative
type of literal string that does not require an extra network round trip
(the length and data are sent together). While this extension is quite
commonly supported by servers, some implementations have it disabled
because there is no good way for clients to know whether a server can
accept big messages.

The IMAP APPEND Extensions (imapapnd) working group will produce two
related Standards Track specifications, which are targeted at improving
the current situation:

* The first is based on draft-jayantheesh-imap-appendlimit-extension,
and defines a way for servers to announce an APPEND limit for a
particular
server or a particular mailbox.

* The second is based on draft-melnikov-rfc2088bis, and describes
implementation choices for servers supporting the LITERAL+ extension,
as well as defining a new "LITERAL-" extension that has similar
properties but provides a mechanism allowing servers to avoid
denials of service by malicious or naive IMAP clients.

As part of the protocol development, implementation experience on both
the client and server side is highly desirable, so that the actual
operational value of this extension can be assessed. The working group
will document the results of this experience on the working group wiki.

No other IMAP extension work is in scope for this working group.

Milestones:


_______________________________________________
new-work mailing list
new-work@ietf.org
https://www.ietf.org/mailman/listinfo/new-work