Thank you Kenneth for addressing my comments. The changes are Ok for me. Best Regards, Ines.
On Tue, Feb 6, 2024 at 6:58 PM Ken Murchison <mu...@fastmail.com> wrote: > Hi Ines, > > Thanks for the detailed review. I used you input to produce draft -18. > Comments inline. > > > On 2/2/24 3:42 PM, Ines Robles via Datatracker wrote: > > Reviewer: Ines Robles > > Review result: Ready with Nits > > > > I am the assigned Gen-ART reviewer for this draft. The General Area > > Review Team (Gen-ART) reviews all IETF documents being processed > > by the IESG for the IETF Chair. Please treat these comments just > > like any other last call comments. > > > > For more information, please see the FAQ at > > > > <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. > > > > Document: draft-ietf-jmap-sieve-17 > > Reviewer: Ines Robles > > Review Date: 2024-02-02 > > IETF LC End Date: 2024-02-01 > > IESG Telechat date: Not scheduled for a telechat > > > > Summary: > > > > The document specifies a data model for managing Sieve scripts using > JMAP, a > > protocol for synchronizing data such as email between clients and > servers. The > > model also includes details about server capabilities, script properties, > > activation, and validation processes. The document is well written. I > have > > minor comments/questions below. > > > > Major issues: None > > > > Minor issues: None > > > > Nits/editorial comments: > > > > 1- Section 1: "...however the functionality offered over the two > protocols may > > differ" > > > > It would be nice to clarify How the protocols may differ, for example, > what > > about: "While both JMAP and ManageSieve provide mechanisms for managing > Sieve > > scripts on a server, the range of features and operations available may > vary > > between the two protocols. This could affect how scripts are created, > edited, > > or executed, depending on which protocol is used." or something like > that. What > > do you think? > > I've removed the sentence about differing functionality, and broken out > a separate section discussing of the only functional difference between > the two protocols. > > > > 2- Section 1.3.1: "This represents support..." --> Perhaps: "The > > urn:ietf:params:jmap:sieve capability object represents support..." ? > > Done. > > > > 3- Section 2.2: "...This method provides similar functionality to the > > PUTSCRIPT, DELETESCRIPT, RENAMESCRIPT, and SETACTIVE commands in > [RFC5804]." > > > > It would be nice to clarify a bit in which aspects are > similar/dissimilar, for > > example, what about: "This method provides similar functionality to the > > PUTSCRIPT, DELETESCRIPT, RENAMESCRIPT, and SETACTIVE commands in > [RFC5804]. > > Similar functionality here means that, though the protocols differ, the > JMAP > > method achieves the same end goals (e.g. managing Sieve scripts by > allowing > > their creation, deletion, renaming, and activation)" Is this correct? > What do > > you think? > > > I've changed all instances of "similar functionality" to "equivalent > functionality" which I believe is more accurate and doesn't require > having to explain any differences. > > -- > Kenneth Murchison > Senior Software Developer > Fastmail US LLC > >
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
