Re: WGLC for draft-ietf-imapapnd-rfc2088bis-02
Jamie Nicolson <[email protected]> Tue, 1 Mar 2016 16:42:07 -0800
| Newsgroups | gmane.ietf.imapext |
|---|---|
| Message-ID | <CACU8CfSNcW9AvOO4eMVH1Rnp0YnH0pAZMvrvP24fWKZRTA7JXw@mail.gmail.com> |
--===============4491792238697091627== Content-Type: multipart/alternative; boundary=001a113f943c8be769052d062820 --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 <[email protected]> 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:[email protected]] On Behalf Of S Moonesamy > Sent: Friday, February 05, 2016 3:17 PM > To: [email protected] > 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 [email protected] mailing list. > > Regards, > S. Moonesamy (as imapapdb WG Chair) > > _______________________________________________ > imapext mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/imapext > > _______________________________________________ > imapext mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/imapext > --001a113f943c8be769052d062820 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>The content looks good. I assembled some grammatical = nits.</div><div><br></div><div>Throughout the document:</div><div><ul><li>&= quot;non synchronizing" -> "non-synchronizing". I think t= he hyphen is more grammatically correct and is used in RFC 2088.</li><li>&q= uot;that" vs "which" (<a href=3D"https://www.google.com/sear= ch?q=3Dwhich+that">https://www.google.com/search?q=3Dwhich+that</a>). Speci= fic issues called out below.</li></ul></div>Abstract:=C2=A0<div><ul><li>&qu= ot;...alternate form of literal <b style=3D"background-color:rgb(255,255,25= 5)">which</b> does not require..." -> "...alternate form of li= teral <b style=3D"background-color:rgb(255,255,255)">that</b> does not requ= ire..."</li><li>"...in all IMAP command." -> "...in = all IMAP command<b>s</b>."<br></li><li>"...but disallow the alter= nate..." -> "...but disallow<b>s</b> the alternate"</li><= li>consider just writing "LITERAL+" and "LITERAL-" inst= ead of "the former" and "the latter"</li></ul><div>Sect= ion 1:</div></div><div><ul><li>"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 <b>as<= /b> an alternate form of literal..." or "The non-synchronizing li= teral is an alternate form of literal..."?</li><li>"...any IMAP s= erver implementation <b>which</b> returns..." -> "...any IMAP = server implementation <b>that</b> returns..."</li></ul>Section 3:</div= ><div><ul><li>"difficilt" -> "difficult"</li><li>&qu= ot;...used by a client <b>which</b> is too big..." -> "...used= by a client <b>that</b> is too big..."</li><li>"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..."</li><li>"non optimal -&= gt; "non-optimal"</li><li>"...if the literal size is big.&qu= ot; could be more concisely written "...if the literal is large."= <br></li><li>"Send <b>the</b> untagged BYE response..." -> &qu= ot;Send <b>an</b> untagged BYE response..."</li><li>"Some server = implementations impose limits on literal..." ->=C2=A0"Some ser= ver implementations impose limits on literal<b>s</b>..."</li><li>"= ;...in order <b>to protect from</b> Denial Of Service attacks..." ->= ;=C2=A0"...in order <b>to protect themselves from</b> Denial Of Servic= e attacks..." or better "...in order<b> to defend against</b> Den= ial Of Service attacks..." You could also get rid of "in order&qu= ot;.</li></ul>Section 4:</div><div><ul><li>""LITERAL-" exten= sion is almost..." ->=C2=A0"<b>The</b>=C2=A0"LITERAL-&quo= t; extension is almost..."</li><li>"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."</li><li>"A "LITERAL-" compliant = server <b>which</b> encounters a <b>non synchronizing</b> 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 <b>that</b> encounters a <b>non-s= ynchronizing</b> literal in APPEND larger than 4096 bytes MUST reject such = APPEND command with a tagged BAD response that contains <b>the</b> TOOBIG r= esponse code [RFC4469]."</li></ul>Section 7:</div><div><ul><li>".= ..creation of "LITERAL-" extension..." ->=C2=A0"...c= reation of <b>the</b> "LITERAL-" extension..."<br></li></ul>= </div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Th= u, Feb 25, 2016 at 8:32 AM, Jayantheesh S B <span dir=3D"ltr"><<a href= =3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>= ></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0= 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">All,<br> <br> Kindly share your review comments for this draft (This Working Group Last C= all will end on Saturday 20th February)<br> <br> Regards,<br> Jay<br> <span class=3D"im HOEnZb">-----Original Message-----<br> From: imapext [mailto:<a href=3D"mailto:[email protected]">imapext-b= [email protected]</a>] On Behalf Of S Moonesamy<br> Sent: Friday, February 05, 2016 3:17 PM<br> To: <a href=3D"mailto:[email protected]">[email protected]</a><br> Subject: [imapext] WGLC for draft-ietf-imapapnd-rfc2088bis-02<br> <br> </span><div class=3D"HOEnZb"><div class=3D"h5">Hello,<br> <br> 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<br> <a href=3D"https://tools.ietf.org/html/draft-ietf-imapapnd-rfc2088bis-02" r= el=3D"noreferrer" target=3D"_blank">https://tools.ietf.org/html/draft-ietf-= imapapnd-rfc2088bis-02</a><br> <br> This Working Group Last Call will end on Saturday 20th February.=C2=A0 Plea= se review the I-D and send comments to the <a href=3D"mailto:[email protected]= rg">[email protected]</a> mailing list.<br> <br> Regards,<br> S. Moonesamy (as imapapdb WG Chair)<br> <br> _______________________________________________<br> imapext mailing list<br> <a href=3D"mailto:[email protected]">[email protected]</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/imapext" rel=3D"noreferrer= " target=3D"_blank">https://www.ietf.org/mailman/listinfo/imapext</a><br> <br> _______________________________________________<br> imapext mailing list<br> <a href=3D"mailto:[email protected]">[email protected]</a><br> <a href=3D"https://www.ietf.org/mailman/listinfo/imapext" rel=3D"noreferrer= " target=3D"_blank">https://www.ietf.org/mailman/listinfo/imapext</a><br> </div></div></blockquote></div><br></div> --001a113f943c8be769052d062820-- --===============4491792238697091627== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ imapext mailing list [email protected] https://www.ietf.org/mailman/listinfo/imapext --===============4491792238697091627==--