Re: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06
"Adrien de Croy" <adrien@qbik.com> Fri, 11 December 2015 10:45 UTC
Return-Path: <adrien@qbik.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 C71151A8788; Fri, 11 Dec 2015 02:45:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level:
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 1t6Pg6Fcwwy0; Fri, 11 Dec 2015 02:45:28 -0800 (PST)
Received: from smtp.qbik.com (smtp.qbik.com [122.56.26.1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 479371A1A8F; Fri, 11 Dec 2015 02:45:27 -0800 (PST)
Received: From [192.168.1.146] (unverified [192.168.1.146]) by SMTP Server [192.168.1.3] (WinGate SMTP Receiver v8.5.4 (Build 4854)) with SMTP id <0000593247@smtp.qbik.com>; Fri, 11 Dec 2015 23:45:25 +1300
From: Adrien de Croy <adrien@qbik.com>
To: Barry Leiba <barryleiba@computer.org>, Narendra Bisht <ns.bisht@sta.samsung.com>
Date: Fri, 11 Dec 2015 10:45:25 +0000
Message-Id: <eme8fe9e99-d1fd-4ad0-88f3-65aad425c998@bodybag>
In-Reply-To: <CALaySJK=5nkmF2K0Vt7mgg2honoX9iYS4yhgu+giDjKyDoR0GQ@mail.gmail.com>
User-Agent: eM_Client/6.0.23421.0
Mime-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <http://mailarchive.ietf.org/arch/msg/imapext/5nhXND7dvUNFXuzzJF9V9uPduYQ>
Cc: "draft-ietf-imapapnd-appendlimit-extension@ietf.org" <draft-ietf-imapapnd-appendlimit-extension@ietf.org>, "imapext@ietf.org" <imapext@ietf.org>
Subject: Re: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06
X-BeenThere: imapext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: Adrien de Croy <adrien@qbik.com>
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: Fri, 11 Dec 2015 10:45:30 -0000
------ Original Message ------ From: "Barry Leiba" <barryleiba@computer.org> >> -- Section 4 -- >> >> "Client can avoid use of LITERAL+ [RFC2088], when maximum upload size >> supported by the IMAP server is unknown." >> >> What? >> Don't you mean "The client SHOULD avoid"? I'd even use this as an >>opportunity >> to make it firmer, and say "The client MUST avoid". No? >> If not, why not? >> >> [Naren] We will change it to a MUST > >Hold off on this, because there's still discussion based on Adrian's >message in another thread... which I'll bring back here: > >On Tue, Dec 8, 2015 at 4:31 PM, Adrien de Croy <adrien@qbik.com> wrote: >> >> The proposal that a client MUST avoid LITERAL+/NSLs presumes there is >>a >> limit when in fact there may actually not be one. Of course there is >>always >> a finite limit, but there may be no policy limit. In fact we don't >>plan to >> implement the limit as we've never had a request for it and don't see >>a need >> to deny authenticated users from appending a mail (and see some >>dangers in >> that). >> >> I think MAY works in that it proposes a strategy, and doesn't confuse >>issues >> with servers that already implement LITERAL+ but not a limit. >>Otherwise you >> may be placing a new requirement on old software to police the new >>MUST, or >> implementing the limit places addition requirements to alter >>behaviour of >> LITERAL+ support to enforce this which IMO over-complicates it. > >But the point of the use of LITERAL+ with APPEND isn't just about this >spec and overall limits -- it's about whether we should use LITERAL+ >with APPEND *at all*. There are other reasons that any particular >APPEND might fail, and one point of using literals (and *never* >allowing quoted strings, for example) is exactly to give the server a >chance to say "NO" to the APPEND *before* the message data is shipped >over. Using LITERAL+ for APPEND data violates that. OK fair point, the extra round trip for APPEND only isn't that big a deal. Do we need to ad an addenda to LITERAL+ then? > >It was always the intent of LITERAL+ that it be used as a way to >eliminate the extra round trip on short strings, where the OK from the >server isn't necessary -- such as for username and password at login, >or for mailbox names in various places (including the mailbox name in >an APPEND command. > >My point here is that we now have an opportunity to stress this: that >it's not a generally good idea to use LITERAL+ for the message data in >an APPEND command, because it doesn't give the server the opportunity >to say, "OK, yes, go ahead and send me the message." > >I'm absolutely willing to accept that "MUST NOT" use LITERAL+ for that >is too strong. But I'm still going to hold out for "SHOULD NOT", and >would like to continue the discussion of why you disapprove. Happy with the SHOULD NOT. Adrien
- [imapext] AD review of draft-ietf-imapapnd-append… Barry Leiba
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba
- [imapext] Referencing RFC 2088 (was: AD review of… S Moonesamy
- Re: [imapext] Referencing RFC 2088 Alexey Melnikov
- Re: [imapext] Referencing RFC 2088 (was: AD revie… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Narendra Bisht
- Re: [imapext] Referencing RFC 2088 S Moonesamy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] Referencing RFC 2088 (was: AD revie… Naren
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… S Moonesamy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Naren
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… S Moonesamy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Naren
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… S Moonesamy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… S Moonesamy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… S Moonesamy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Stu Brandt
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Stu Brandt
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Arnt Gulbrandsen
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Dave Cridland
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Dave Cridland
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Arnt Gulbrandsen
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Bron Gondwana
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Narendra Bisht
- Re: [imapext] AD review draft-ietf-imapapnd-appen… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba
- Re: [imapext] AD review draft-ietf-imapapnd-appen… Stu Brandt
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review draft-ietf-imapapnd-appen… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review draft-ietf-imapapnd-appen… S Moonesamy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Adrien de Croy
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review draft-ietf-imapapnd-appen… Dave Cridland
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Alexey Melnikov
- Re: [imapext] AD review draft-ietf-imapapnd-appen… Alexey Melnikov
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Jayantheesh S B
- Re: [imapext] AD review of draft-ietf-imapapnd-ap… Barry Leiba