Re: [imapext] AD review of draft-ietf-imapapnd-rfc2088bis-03

Barry Leiba <barryleiba@computer.org> Sat, 05 March 2016 18:36 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 82E181B355F for <imapext@ietfa.amsl.com>; Sat, 5 Mar 2016 10:36:30 -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 x7Ux-ElIKvir for <imapext@ietfa.amsl.com>; Sat, 5 Mar 2016 10:36:29 -0800 (PST)
Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (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 3808E1B355B for <imapext@ietf.org>; Sat, 5 Mar 2016 10:36:29 -0800 (PST)
Received: by mail-io0-x236.google.com with SMTP id l127so94272057iof.3 for <imapext@ietf.org>; Sat, 05 Mar 2016 10:36:29 -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=7nDqD6e/f2c4VJedUPd6iWIdme3mL53Jvb2etD3xssg=; b=L8V4qoWrXiUsKjw9IlYDAciCcDJOzyKbyBPm/FIrRU64LORd76Da3LOY9TrgjMUSoM Wep+8/36SFpUlnH9KVK/SwNTeu/6/Zo+SmJlhpfJGGFvlGqmG6lf8gDNaVWPDPH5KoNy YA8StQ11wvP0Eh3zQp5YZ3hfuhIkvstIctJXPFfoEo/AtWGi6vEt4YS001NUMURZn8cG XYeiKZ66ZZRcm6YSpSFIFev0kZ1JxcHMgGt4wNFXA9qGue1MrWEoQ9UsePDqCztolPeg CuBLxenrZ0Mvm/E3NOMbuUcbd8LniLHkUA8ouJKTwkk2T60Z5aVkeHxp3TwbSZ08byk1 rtww==
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=7nDqD6e/f2c4VJedUPd6iWIdme3mL53Jvb2etD3xssg=; b=E/5Ss3XgAkuXJQA5Veq8E9hia82gw0qV9RWa9KFgzLziDrZJtXGwH+1qEHCVL4bmcv xSWzY/hJs4RqtrGSdYHalCNEckKvwVzIBGU7ZRfMW6le6REuixsKJKAwOHwgcrHA1fpW Bco+28QNGxkRbKO8HKJh982RFop1EcdsA06SJCSqcKio3XXS78q+BFYsMXCyjClVEKmz /gbMV/de0TiaPxonI0KRiVRn5Aq4wep8Y4bHgYa8LoYt/UzbSBFkWu2Mz0ju6i8ykJhR kMc1htsfPaC7B8HhRS4okS8UIb6lT7xigD/JTmUv9CEA3IZxRHfRGXDBBrypwDn7ZpBm MVGg==
X-Gm-Message-State: AD7BkJLKDUckUhwh3wuURpkTvlCbCj18a3L9zM853oD2oCRK4jdXKEyaGhEykENKGRDftOA3HM+NAAAyMYWGVg==
MIME-Version: 1.0
X-Received: by 10.107.131.206 with SMTP id n75mr13493181ioi.189.1457202988657; Sat, 05 Mar 2016 10:36:28 -0800 (PST)
Sender: barryleiba@gmail.com
Received: by 10.36.59.133 with HTTP; Sat, 5 Mar 2016 10:36:28 -0800 (PST)
In-Reply-To: <72D2AFD9-EC8A-4358-BCD3-528829E53FB5@fastmail.fm>
References: <CALaySJJxkYW+w1wY7NNH73P5qXoxutYz2VeM4E23BG0U_U5p5g@mail.gmail.com> <1011FF8D-99AC-491F-A12A-B3DBAD55FAE9@fastmail.fm> <CALaySJLL2F=vmQvJXmm_miCveXhNiQRgLLDEir8K54RLU6VcFA@mail.gmail.com> <587132AF-8DDE-46ED-A37E-A8E7A28352F6@fastmail.fm> <72D2AFD9-EC8A-4358-BCD3-528829E53FB5@fastmail.fm>
Date: Sat, 05 Mar 2016 13:36:28 -0500
X-Google-Sender-Auth: miSdJUYLuP_Ljra7d7nylBajKcE
Message-ID: <CALaySJKUKD1zvzmto1DXZXUeB=nddUbpCeQBbtz-LmJYuZvWdg@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/Xb-sYwyOQ5aKl3dkivnY75OUAoQ>
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 18:36:30 -0000

>>> 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?
>>
>> This is a valuable implementation advice.
>
> This also potentially affects how client implementations are coded.

I don't agree that it's valuable as written, as I don't think it says
enough to be useful.  Consider a non-expert implementor, who codes
like this:

- Read up to CRLF
- See "{666666+}" at the end
- Send BAD
- Now what?  Read the next command?  That won't work, because the
client already sent the literal.  Close the socket?  With or without
sending untagged BYE first?  And why would you want to close the
socket when you've already said BAD to the command itself?  Are we
advising servers to kick off clients that have protocol errors?  And
then what if the client just reconnects?  Kick it off again?

Rather than having a cryptic parenthetical, if you want to give useful
implementation advice it'd be better to give real advice about the
options that are reasonable, and what the pros and cons are.  And I
personally (just opinion here) don't think that sending BAD before
discarding the literal is something implementors should be advised to
do, even if some implementations happen to do it... unless one can
articulate what advantages it gives to the server or to the client.

If your argument is that sending BAD and then immediately closing the
socket (or sending BAD, then BYE, then closing the socket), without
bothering the read the literal... saves the server work and resources,
then maybe it's reasonable advice.  But then the advice isn't just to
send BAD -- it's the whole sequence, together.

Get what I'm trying to say?

b