Re: [imapext] AD review of draft-ietf-imapapnd-rfc2088bis-03
Alexey Melnikov <alexey.melnikov@isode.com> Sun, 06 March 2016 21:22 UTC
Return-Path: <alexey.melnikov@isode.com>
X-Original-To: imapext@ietfa.amsl.com
Delivered-To: imapext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 026981B3A10 for <imapext@ietfa.amsl.com>; Sun, 6 Mar 2016 13:22:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.002
X-Spam-Level:
X-Spam-Status: No, score=-2.002 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 o0zmUkF_Bf26 for <imapext@ietfa.amsl.com>; Sun, 6 Mar 2016 13:22:04 -0800 (PST)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 888341B3A0F for <imapext@ietf.org>; Sun, 6 Mar 2016 13:22:04 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1457299323; d=isode.com; s=selector; i=@isode.com; bh=npgzPU0mlJSKE8dpnXMBsh/koY78FSUT9fd4S24rusA=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=uZxOVVZbev91juxh+tEAi48M7Xjm7TD3i6L3WCkgknknOTCEhQdiZtx/miIwukmWufuAy0 VOqLmCX/HL35kfthVMHiLhNYpLLSbOIBcBHdrhKTmTZHzv8m4wixWf0I3haY+QTDFs8FP1 UQXMCvT0j2bldvnSjVSUQGeV7rzRcOY=;
Received: from [192.168.0.5] (cpc5-nmal20-2-0-cust24.19-2.cable.virginm.net [92.234.84.25]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id <VtyfegAHUaCJ@waldorf.isode.com>; Sun, 6 Mar 2016 21:22:03 +0000
To: Barry Leiba <barryleiba@computer.org>
References: <CALaySJJxkYW+w1wY7NNH73P5qXoxutYz2VeM4E23BG0U_U5p5g@mail.gmail.com>
From: Alexey Melnikov <alexey.melnikov@isode.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <56DC9F67.7020805@isode.com>
Date: Sun, 06 Mar 2016 21:21:43 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
In-Reply-To: <CALaySJJxkYW+w1wY7NNH73P5qXoxutYz2VeM4E23BG0U_U5p5g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"
Content-transfer-encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/imapext/I0t32DlyJMo5WVQ9ZwaqJrpw_DQ>
Cc: "imapext@ietf.org" <imapext@ietf.org>
Subject: Re: [imapext] AD review of draft-ietf-imapapnd-rfc2088bis-03
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IMAP extensions <imapext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/imapext>, <mailto:imapext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/imapext/>
List-Post: <mailto:imapext@ietf.org>
List-Help: <mailto:imapext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imapext>, <mailto:imapext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Mar 2016 21:22:06 -0000
Hi Barry, I've applied most of the comments (thank you!). Regarding the two remaining issues: On 04/03/2016 23:03, Barry Leiba wrote: > Here's my review of draft-ietf-imapapnd-rfc2088bis-03. Much of this > is editorial, but there are a couple of substantive things here. > In bullet 1: > > (The server is allowed to send the tagged BAD/NO response before > reading the whole non-synchronizing literal.) > > Substantive: Shouldn't that be "the server is not allowed" (missing "not")? I reply to this in a separate email. > > -- Section 5 -- > Substantive: Shouldn't references to "APPEND" be removed from here, > since we re-spun LITERAL- as applying to all commands? Also, the last > sentence doesn't really make sense. In order to reject the command > with BAD and TOOBIG, the server has to read (and discard) the literal > -- that is, it's already processing according to bullet 1 in Section > 4. I fixed the problem you stated in the last sentence, see below. > So: > > OLD > The "LITERAL-" extension is almost identical to "LITERAL+", with one > exception: when "LITERAL-" is advertised, non-synchronizing literals > used in any command MUST NOT be larger than 4096 bytes. Any literal > larger than 4096 bytes MUST be sent as an RFC 3501 synchronizing > literal. A "LITERAL-" compliant server that encounters a non- > synchronizing literal in APPEND larger than 4096 bytes MUST reject > such APPEND command with a tagged BAD response that contains the > TOOBIG response code [RFC4469]. It then MAY proceed as described in > Section 4. > > NEW > The "LITERAL-" extension is almost identical to "LITERAL+", with one > exception: when "LITERAL-" is advertised, non-synchronizing literals > used in any command MUST NOT be larger than 4096 bytes. Any literal > larger than 4096 bytes MUST be sent as an RFC 3501 synchronizing > literal. A "LITERAL-" compliant server that encounters a non- > synchronizing literal larger than 4096 bytes MUST read (and discard) > the literal, and then reject the command with a tagged BAD response > that contains the TOOBIG response code [RFC4469]. > > END Unfortunately TOOBIG is defined as: 4.2. TOOBIG Response The TOOBIG response code is returned if the resulting message will exceed the 4-GB IMAP message limit. This might happen, for example, if the client specifies 3 URLs for 2-GB messages. Note that even if the server doesn't return TOOBIG, it still has to be defensive against misbehaving or malicious clients that try to construct a message over the 4-GB limit. The server may also wish to return the TOOBIG response code if the resulting message exceeds a server- specific message size limit. So this is really APPEND specific. And I think having a response code is important to debugging and problem diagnostic. So I initially rewrote the last sentence as: A "LITERAL-" compliant server that encounters a non-synchronizing literal larger than 4096 bytes MUST read (and discard) the literal, and then reject the command with a tagged BAD response. If responding to an APPEND command, the tagged BAD response that contains the TOOBIG response code <xref target="RFC4469"/>. However, I realized that the server should still be allowed to return BYE and disconnect. So my final version is: A "LITERAL-" compliant server that encounters a non-synchronizing literal larger than 4096 bytes proceeds as described in Section 4. If responding to an APPEND command, the tagged BAD response MUST contains the TOOBIG response code [RFC4469]. If responding with untagged BYE response, it SHOULD include the TOOBIG response code.
- [imapext] AD review of draft-ietf-imapapnd-rfc208… Barry Leiba
- Re: [imapext] AD review of draft-ietf-imapapnd-rf… Barry Leiba
- Re: [imapext] AD review of draft-ietf-imapapnd-rf… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-rf… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-rf… Barry Leiba
- Re: [imapext] AD review of draft-ietf-imapapnd-rf… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-rf… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-rf… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-rf… Barry Leiba