Re: [imapext] AD review of draft-ietf-imapapnd-rfc2088bis-03
Alexey Melnikov <alexey.melnikov@isode.com> Sun, 06 March 2016 21:29 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 26F691B3A37 for <imapext@ietfa.amsl.com>; Sun, 6 Mar 2016 13:29:31 -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 bW3_NDJBD0G2 for <imapext@ietfa.amsl.com>; Sun, 6 Mar 2016 13:29:29 -0800 (PST)
Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 572B21B3A33 for <imapext@ietf.org>; Sun, 6 Mar 2016 13:29:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1457299768; d=isode.com; s=selector; i=@isode.com; bh=l7cUgFu2+7xRZ5kj3BgJF51K6XkFsthdzhP1QDuIinI=; 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=VHtOKGq0+Te4o5vDO9KWNZEevXL2oX3WtUxMszHT0AkMEMfsE7cACw/ghvU9xlireKkTiz tASuze6iESJJdneWyXd7QXZyvgql54dWXkB1FsHl/JsR7SH3k81Zo6KbbiMmYzQf1WZMUH 3KQRWG7Jx+e5i+EHwblTqHDzckrB3L0=;
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 <VtyhNwAHUZWT@waldorf.isode.com>; Sun, 6 Mar 2016 21:29:28 +0000
To: Barry Leiba <barryleiba@computer.org>
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> <CALaySJKUKD1zvzmto1DXZXUeB=nddUbpCeQBbtz-LmJYuZvWdg@mail.gmail.com>
From: Alexey Melnikov <alexey.melnikov@isode.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <56DCA131.4010603@isode.com>
Date: Sun, 06 Mar 2016 21:29:21 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
In-Reply-To: <CALaySJKUKD1zvzmto1DXZXUeB=nddUbpCeQBbtz-LmJYuZvWdg@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/8wgyvuAg18atX8r4lCN2NcAKOFc>
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:29:31 -0000
Hi Barry, On 05/03/2016 18:36, Barry Leiba wrote: >>>> 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? But you know that this particular problem is not really solvable. > 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. Oh, I think you misinterpreted what the text is trying to say: it doesn't recommend discarding the literal. Implementations that return BAD must still eat the data. But this sentence is saying that it is OK to say BAD immediately after observing a large literal, without waiting till the full command is received. > 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. This is not better than just sending BYE. > But then the advice isn't just to > send BAD -- it's the whole sequence, together. > > Get what I'm trying to say? > > b > > _______________________________________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/listinfo/imapext >
- [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