Re: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06
"Adrien de Croy" <adrien@qbik.com> Fri, 11 December 2015 10:56 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 8ECE51A885A; Fri, 11 Dec 2015 02:56:29 -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 0QC2FotJqc5Y; Fri, 11 Dec 2015 02:56:27 -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 20EE71A87D2; Fri, 11 Dec 2015 02:56:26 -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 <0000593255@smtp.qbik.com>; Fri, 11 Dec 2015 23:56:24 +1300
From: Adrien de Croy <adrien@qbik.com>
To: Adrien de Croy <adrien@qbik.com>, Barry Leiba <barryleiba@computer.org>, Narendra Bisht <ns.bisht@sta.samsung.com>
Date: Fri, 11 Dec 2015 10:56:24 +0000
Message-Id: <em5a18e557-86b5-4a28-ac22-4cd4a153cb46@bodybag>
In-Reply-To: <eme8fe9e99-d1fd-4ad0-88f3-65aad425c998@bodybag>
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/UO2k6Qk5eFJGllNo9kzhCO2ZvE4>
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:56:29 -0000
p.s. it seems pretty common to use LITERAL+ on APPEND, Thunderbird and iOS clients do it. eM Client does not. No data on others. Adrien ------ Original Message ------ From: "Adrien de Croy" <adrien@qbik.com> To: "Barry Leiba" <barryleiba@computer.org>; "Narendra Bisht" <ns.bisht@sta.samsung.com> Cc: "draft-ietf-imapapnd-appendlimit-extension@ietf.org" <draft-ietf-imapapnd-appendlimit-extension@ietf.org>; "imapext@ietf.org" <imapext@ietf.org> Sent: 11/12/2015 11:45:25 p.m. Subject: Re: [imapext] AD review of draft-ietf-imapapnd-appendlimit-extension-06 > > >------ 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 mailing list >imapext@ietf.org >https://www.ietf.org/mailman/listinfo/imapext
- [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