Return-Path: 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 0FCA01B441B for ; Tue, 1 Mar 2016 16:42:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.384 X-Spam-Level: X-Spam-Status: No, score=-1.384 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.006, 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 IBZrTKb_DmyI for ; Tue, 1 Mar 2016 16:42:38 -0800 (PST) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (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 981761A1A99 for ; Tue, 1 Mar 2016 16:42:37 -0800 (PST) Received: by mail-io0-x235.google.com with SMTP id l127so242631294iof.3 for ; Tue, 01 Mar 2016 16:42:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OXs35iFZjR7XX/9JKpaT9opooQqK/64D/DMYr/1zFtw=; b=ITXGfwwrBZPpRPn2j+n0vI4L3/fLza+WWLYxYWvAA6tsorghwp77GvyPVa2tu+y6e2 evnIvFhhqmOTwSP/5NPJWZuoDSRyBAlLoIR1na1HONGt3Z+DVEBeb2SVX7r7YdA1Qd9U FjMEHAIvBmflz2TvNi3so0MZP7acQWOC7pbCFhEo9SMMUY+eTS6F1YYb2VDPnCXCXRkT I+O49NfDCG7o0Ined9zQsUaE6ttkDjRv/xQW4S2WDxclhMb+NoKMSsMd+9FNpcTChPzb CG4lpkQcwbwg7rMK4Lbir7ogmcTUL1DjR3/rbg16qt5dCz8VMldBkulq9uzrzWT7QNyV fmVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OXs35iFZjR7XX/9JKpaT9opooQqK/64D/DMYr/1zFtw=; b=KJXEVhnv7ZPD7J92Bk/LX4BGPKZFiy4evIXfuZ0k8jHAvcXfTLzSe/WnTtG6Svv8LZ Fl6G5uUjGL371yRiLbBF+Lxe1laSTjDO9DCyECg/FhaQB11sBrmRna76p5Fl98IwBwc6 IqxZ31bmNQTQ9htdFxG1WmcKKS+raMB0MSZKCRHVsPANTVUYlSflLQGHBEoN45a4Qg1A T1Goqd2VrJvTNo3fK7ly3qYsAA+bQtyZgOJf/CL079DRWP2IMgbSiaTmbmUdfTgBnG8V tFxrrwY+LlK8kl6w2oyBKy1dtIb/WeWd6qeR0cKCQSd6UnGYZNqjSLJYFxUUEa4r1PZw AeOg== X-Gm-Message-State: AG10YORXaZKJUljwRMnijScGN7lYJnciy449PjkdjX5Aa3Db79SXVfltMMTBVpTMulxB9ehA4HUVY/R6TtA07nMv X-Received: by 10.107.129.89 with SMTP id c86mr28884928iod.102.1456879356845; Tue, 01 Mar 2016 16:42:36 -0800 (PST) MIME-Version: 1.0 Received: by 10.64.62.194 with HTTP; Tue, 1 Mar 2016 16:42:07 -0800 (PST) In-Reply-To: <32efdefdc1d847ae9c7c74323b77f914@SEAMBX01.sea.samsung.com> References: <6.2.5.6.2.20160205121329.102a7f38@elandnews.com> <32efdefdc1d847ae9c7c74323b77f914@SEAMBX01.sea.samsung.com> From: Jamie Nicolson Date: Tue, 1 Mar 2016 16:42:07 -0800 Message-ID: To: Jayantheesh S B Content-Type: multipart/alternative; boundary=001a113f943c8be769052d062820 Archived-At: Cc: S Moonesamy , "imapext@ietf.org" Subject: Re: [imapext] WGLC for draft-ietf-imapapnd-rfc2088bis-02 X-BeenThere: imapext@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IMAP extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2016 00:42:41 -0000 --001a113f943c8be769052d062820 Content-Type: text/plain; charset=UTF-8 The content looks good. I assembled some grammatical nits. Throughout the document: - "non synchronizing" -> "non-synchronizing". I think the hyphen is more grammatically correct and is used in RFC 2088. - "that" vs "which" (https://www.google.com/search?q=which+that). Specific issues called out below. Abstract: - "...alternate form of literal *which* does not require..." -> "...alternate form of literal *that* does not require..." - "...in all IMAP command." -> "...in all IMAP command*s*." - "...but disallow the alternate..." -> "...but disallow*s* the alternate" - consider just writing "LITERAL+" and "LITERAL-" instead of "the former" and "the latter" Section 1: - "The non-synchronizing literal is added an alternate form of literal..." This sentence doesn't quite parse. Should it read, "The non-synchronizing literal is added *as* an alternate form of literal..." or "The non-synchronizing literal is an alternate form of literal..."? - "...any IMAP server implementation *which* returns..." -> "...any IMAP server implementation *that* returns..." Section 3: - "difficilt" -> "difficult" - "...used by a client *which* is too big..." -> "...used by a client *that* is too big..." - "When a non synchronizing literal is used by a client which is too big for the server to accept..." -> "When a client uses a non-synchronizing literal that is too big for the server to accept..." - "non optimal -> "non-optimal" - "...if the literal size is big." could be more concisely written "...if the literal is large." - "Send *the* untagged BYE response..." -> "Send *an* untagged BYE response..." - "Some server implementations impose limits on literal..." -> "Some server implementations impose limits on literal*s*..." - "...in order *to protect from* Denial Of Service attacks..." -> "...in order *to protect themselves from* Denial Of Service attacks..." or better "...in order* to defend against* Denial Of Service attacks..." You could also get rid of "in order". Section 4: - ""LITERAL-" extension is almost..." -> "*The* "LITERAL-" extension is almost..." - "When any literal is larger than 4096, RFC 3501 synchronizing literals MUST be used instead." How about, "Any literal larger than 4096 bytes MUST be sent as an RFC 3501 synchronizing literal." - "A "LITERAL-" compliant server *which* encounters a *non synchronizing* literal in APPEND larger than 4096 bytes MUST reject such APPEND command with a tagged BAD response that contains TOOBIG response code [RFC4469]." -> "A "LITERAL-" compliant server *that* encounters a *non-synchronizing* literal in APPEND larger than 4096 bytes MUST reject such APPEND command with a tagged BAD response that contains *the* TOOBIG response code [RFC4469]." Section 7: - "...creation of "LITERAL-" extension..." -> "...creation of *the* "LITERAL-" extension..." On Thu, Feb 25, 2016 at 8:32 AM, Jayantheesh S B wrote: > All, > > Kindly share your review comments for this draft (This Working Group Last > Call will end on Saturday 20th February) > > Regards, > Jay > -----Original Message----- > From: imapext [mailto:imapext-bounces@ietf.org] On Behalf Of S Moonesamy > Sent: Friday, February 05, 2016 3:17 PM > To: imapext@ietf.org > Subject: [imapext] WGLC for draft-ietf-imapapnd-rfc2088bis-02 > > Hello, > > This message starts a Working Group Last Call for "IMAP4 non-synchronizing > literals" (draft-ietf-imapapnd-rfc2088bis-02). The I-D can be accessed at > https://tools.ietf.org/html/draft-ietf-imapapnd-rfc2088bis-02 > > This Working Group Last Call will end on Saturday 20th February. Please > review the I-D and send comments to the imapext@ietf.org mailing list. > > Regards, > S. Moonesamy (as imapapdb WG Chair) > > _______________________________________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/listinfo/imapext > > _______________________________________________ > imapext mailing list > imapext@ietf.org > https://www.ietf.org/mailman/listinfo/imapext > --001a113f943c8be769052d062820 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
The content looks good. I assembled some grammatical = nits.

Throughout the document:
  • &= quot;non synchronizing" -> "non-synchronizing". I think t= he hyphen is more grammatically correct and is used in RFC 2088.
  • &q= uot;that" vs "which" (https://www.google.com/search?q=3Dwhich+that). Speci= fic issues called out below.
Abstract:=C2=A0
  • &qu= ot;...alternate form of literal which does not require..." -> "...alternate form of li= teral that does not requ= ire..."
  • "...in all IMAP command." -> "...in = all IMAP commands."
  • "...but disallow the alter= nate..." -> "...but disallows the alternate"
    • <= li>consider just writing "LITERAL+" and "LITERAL-" inst= ead of "the former" and "the latter"
Sect= ion 1:
  • "The non-synchronizing literal is added= an alternate form of literal..." This sentence doesn't quite pars= e. Should it read, "The=C2=A0non-synchronizing literal is added as<= /b> an alternate form of literal..." or "The non-synchronizing li= teral is an alternate form of literal..."?
  • "...any IMAP s= erver implementation which returns..." -> "...any IMAP = server implementation that returns..."
Section 3:
  • "difficilt" -> "difficult"
  • &qu= ot;...used by a client which is too big..." -> "...used= by a client that is too big..."
  • "When a non synch= ronizing literal is used by a client which is too big for the server to acc= ept..." -> "When a client uses a non-synchronizing literal tha= t is too big for the server to accept..."
  • "non optimal -&= gt; "non-optimal"
  • "...if the literal size is big.&qu= ot; could be more concisely written "...if the literal is large."=
  • "Send the untagged BYE response..." -> &qu= ot;Send an untagged BYE response..."
  • "Some server = implementations impose limits on literal..." ->=C2=A0"Some ser= ver implementations impose limits on literals..."
  • "= ;...in order to protect from Denial Of Service attacks..." ->= ;=C2=A0"...in order to protect themselves from Denial Of Servic= e attacks..." or better "...in order to defend against Den= ial Of Service attacks..." You could also get rid of "in order&qu= ot;.
Section 4:
  • ""LITERAL-" exten= sion is almost..." ->=C2=A0"The=C2=A0"LITERAL-&quo= t; extension is almost..."
  • "When any literal is larger th= an 4096, RFC 3501 synchronizing literals MUST be used instead." How ab= out, "Any literal larger than 4096 bytes MUST be sent as an RFC 3501 s= ynchronizing literal."
  • "A "LITERAL-" compliant = server which encounters a non synchronizing literal in APPEND= larger than 4096 bytes MUST reject such APPEND command with a tagged BAD r= esponse that contains TOOBIG response code [RFC4469]." ->=C2=A0&quo= t;A "LITERAL-" compliant server that encounters a non-s= ynchronizing literal in APPEND larger than 4096 bytes MUST reject such = APPEND command with a tagged BAD response that contains the TOOBIG r= esponse code [RFC4469]."
Section 7:
  • ".= ..creation of "LITERAL-" extension..." ->=C2=A0"...c= reation of the "LITERAL-" extension..."
=

On Th= u, Feb 25, 2016 at 8:32 AM, Jayantheesh S B <j.sb@sea.samsung.com= > wrote:
All,

Kindly share your review comments for this draft (This Working Group Last C= all will end on Saturday 20th February)

Regards,
Jay
-----Original Message-----
From: imapext [mailto:imapext-b= ounces@ietf.org] On Behalf Of S Moonesamy
Sent: Friday, February 05, 2016 3:17 PM
To: imapext@ietf.org
Subject: [imapext] WGLC for draft-ietf-imapapnd-rfc2088bis-02

Hello,

This message starts a Working Group Last Call for "IMAP4 non-synchroni= zing literals" (draft-ietf-imapapnd-rfc2088bis-02).=C2=A0 The I-D can = be accessed at
https://tools.ietf.org/html/draft-ietf-= imapapnd-rfc2088bis-02

This Working Group Last Call will end on Saturday 20th February.=C2=A0 Plea= se review the I-D and send comments to the imapext@ietf.org mailing list.

Regards,
S. Moonesamy (as imapapdb WG Chair)

_______________________________________________
imapext mailing list
imapext@ietf.org
https://www.ietf.org/mailman/listinfo/imapext

_______________________________________________
imapext mailing list
imapext@ietf.org
https://www.ietf.org/mailman/listinfo/imapext

--001a113f943c8be769052d062820--