Re: [Gen-art] [Jmap] Genart last call review of draft-ietf-jmap-sieve-17

[Ines Robles <[e-mail]>]

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 <[e-mail]> 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
>
>