Re: [imapext] AD review of draft-ietf-imapapnd-rfc2088bis-03
Barry Leiba <barryleiba@computer.org> Sat, 05 March 2016 16:19 UTC
Return-Path: <barryleiba@gmail.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 49DF31A90DC for <imapext@ietfa.amsl.com>; Sat, 5 Mar 2016 08:19:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Level:
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
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 6lUlBtd27ypO for <imapext@ietfa.amsl.com>; Sat, 5 Mar 2016 08:19:03 -0800 (PST)
Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC3811A9095 for <imapext@ietf.org>; Sat, 5 Mar 2016 08:19:02 -0800 (PST)
Received: by mail-io0-x22c.google.com with SMTP id n190so92434844iof.0 for <imapext@ietf.org>; Sat, 05 Mar 2016 08:19:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc; bh=O84HxKdhcjp+y4NOvd5ryn4LsFBvZskEhKRvN9IYeqs=; b=VzrgyYbqLkdg3+Y1QvVMaHm6zfwgzvfg0IoUFFl1L8sf7inqgYTjKeQNpPirPZs6Gi Czzjtx6Dp4f2NMvGZ3kBl/T7L8MCs7awvyB8tkPy9bEZ+PLe2+uGIinRb61lcTppzzhh 0g6FlrAd7TMylkdVBwDqGMhGMW8nEryuTJUNe4bm1aCcfJiZyVmnejBBjtVZ47cbuFhI GUsMaaPy0qbmCZADr/EfejysZ3kos+u1WPH5+WtcLZZH94JWOCo4n2lIFR96d77oH4Zy ICDIAFOspU+WsuPtLBqQEzhiNNpu/Xh86wI43h5VMhNPBrp/BJirv5VeGIHxN/14TYIv MeSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to:cc; bh=O84HxKdhcjp+y4NOvd5ryn4LsFBvZskEhKRvN9IYeqs=; b=OPgiL6+Cbbsus2i2ghdpkxrN91rlaP7oVVEQZ9+edPFHGhewSKGLasGfkYHubJZsU3 FGjJ35ybmqhQjqJ5xTlxomETNBVFIp58GReEbHZj/1ZaIdtIFEH2erQcB0bS5GJbUk2j OUgDs+lf7e7Pg7ZeEiWm38XpmAMQQ4voxbmKaBZwk94RZ79W0oj1qPDiA73VoLvXCnFs BnpUSOpzngq55JFqd+LqZH/1mlM5FMs+WOQEm1MRrKjnBw8jXXbjvAWFjrhdSD051pZ2 iObCIJT7xezZU0LyT1XmyQ1y0vgeywQP2nMk0tRsgrxfaZTkPYpUqmvEnYZiJ2RJPgyt Rhcw==
X-Gm-Message-State: AD7BkJLVVUW9ZFtufva/aajbMFPFfjmRT5EmLVCd2fq2zX/8A4EJ9xAf7vcgX/IwKlNkEcP89t9dGSFF0W4srA==
MIME-Version: 1.0
X-Received: by 10.107.131.206 with SMTP id n75mr13096291ioi.189.1457194742242; Sat, 05 Mar 2016 08:19:02 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.36.59.133 with HTTP; Sat, 5 Mar 2016 08:19:01 -0800 (PST)
In-Reply-To: <1011FF8D-99AC-491F-A12A-B3DBAD55FAE9@fastmail.fm>
References: <CALaySJJxkYW+w1wY7NNH73P5qXoxutYz2VeM4E23BG0U_U5p5g@mail.gmail.com> <1011FF8D-99AC-491F-A12A-B3DBAD55FAE9@fastmail.fm>
Date: Sat, 05 Mar 2016 11:19:01 -0500
X-Google-Sender-Auth: pn6ApiLNagfuQQN40XJcuBefuVQ
Message-ID: <CALaySJLL2F=vmQvJXmm_miCveXhNiQRgLLDEir8K54RLU6VcFA@mail.gmail.com>
From: Barry Leiba <barryleiba@computer.org>
To: Alexey Melnikov <aamelnikov@fastmail.fm>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <http://mailarchive.ietf.org/arch/msg/imapext/DF3UYBFXMNOKDHd3KCHXlUikKNw>
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: Sat, 05 Mar 2016 16:19:04 -0000
>> There are only two choices, and in no one's reckoning does two count >> as "several". > > I thought several was any number other than 1. This is just for fun now, because it really doesn't matter either way: Well, dictionary.reference.com says... 1. being more than two but fewer than many in number or kind: several ways of doing it. In general, if you said "Barry has several Furbies," and it turned out I had two, no one would say you were wrong, but many might accuse you of exaggerating. (In fact, I have no Furbies <https://en.wikipedia.org/wiki/Furby>; sorry.) >> 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")? > > No, the sentence is correct as written. Some servers send BAD right after > observing the non-synchronising literal prefix and that is Ok. Hm, but then I think the sentence is meaningless. The server still has to read and discard the literal, so whether it sends the BAD before or after it does that hardly matters. What are you really trying to say with that parenthetical that's useful? >> -- Section 5 -- >> Substantive: Shouldn't references to "APPEND" be removed from here, >> since we re-spun LITERAL- as applying to all commands? > > I double check, but I prefer to keep it. Really? Why. My understanding was that the working group agreed that the 4K limitation on LITERAL- applies to all literals, not just those in APPEND commands. So why should this text explicitly talk about APPEND? >> 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. ... >> 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]. > > Hmm. Or it can close the connection. I will try to reword, as your text > seems to imply that that is the only option. I'll look forward to your rewording. Barry
- [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