Re: [Jmap] Roman Danyliw's No Objection on draft-ietf-jmap-sieve-20: (with COMMENT)

[Roman Danyliw <[e-mail]>]

Hi Ken!

Thanks for these proposed edits. They address my feedback.

Roman

> -----Original Message-----
> From: iesg <[e-mail]> On Behalf Of Ken Murchison
> Sent: Thursday, April 4, 2024 10:43 AM
> To: Roman Danyliw <[e-mail]>; The IESG <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]
> Subject: Re: Roman Danyliw's No Objection on draft-ietf-jmap-sieve-20: (with
> COMMENT)
> 
> Warning: External Sender - do not click links or open attachments unless you
> recognize the sender and know the content is safe.
> 
> 
> Hi Roman,
> 
> Thanks for the review.  Responses inline.
> 
> 
> On 4/2/24 9:09 PM, Roman Danyliw via Datatracker wrote:
> > Roman Danyliw has entered the following ballot position for
> > draft-ietf-jmap-sieve-20: No Objection
> >
> > When responding, please keep the subject line intact and reply to all
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> > Please refer to
> > https://www.ietf.org/about/groups/iesg/statements/handling-ballot-posi
> > tions/ for more information about how to handle DISCUSS and COMMENT
> > positions.
> >
> >
> > The document, along with other ballot positions, can be found here:
> > https://datatracker.ietf.org/doc/draft-ietf-jmap-sieve/
> >
> >
> >
> > ----------------------------------------------------------------------
> > COMMENT:
> > ----------------------------------------------------------------------
> >
> > Thank you to Ines Robles for the GENART review.
> >
> > ** Section 1.2.1
> >
> >        The maximum length, in (UTF-8) octets, allowed for the name of a
> >        SieveScript.  For compatibility with ManageSieve, this MUST be at
> >        least 512 (up to 128 Unicode characters).
> >
> > What’s a “(UTF-8) octet” as opposed to just a “octet”?
> 
> 
> I removed "(UTF-8)" since all of JMAP is UTF-8.
> 
> 
> > ** Section 2.1
> >        For
> >        compatibility with ManageSieve, servers MUST reject names that
> >        contain control characters
> >
> > What is the definition of “control characters”?  Recommend either
> > citing Section 1.6 of RFC5804 or repeating the guidance here.
> 
> 
> I have listed the prohibited characters per your suggestion.
> 
> 
> > ** Section 2.4
> >        If the id is either illegal or nonexistent, it MUST be ignored and
> >        the currently active SieveScript (if any) will remain as such.
> >
> > Is an “illegal” id the same as “invalid”?  That might be clearer.
> 
> 
> I changed "illegal" to "invalid" as suggested.
> 
> 
> > ** Section 2.6 and 5.  The SieveScript validation would appear to
> > require the serve to parse and validate the provided SieveScript.
> > Section 5 cites the security considerations of RFC5804 and RFC8620.
> > The latter has Section 8.4 which discusses the considerations for JSON
> > processing.  Is there an equivalent for a Sieve script (which is not JSON).
> 
> 
> I added the following paragraph:
> 
>        Additionally, implementations MUST treat Sieve script content
>        as untrusted data.  As such, script parsers MUST fail gracefully
>        in the face of syntactically invalid or malicious content and
>        MUST be prepared to deal with resource exhaustion (E.g.,
>        allocation of enormous strings, lists, or command blocks).
> 
> --
> Kenneth Murchison
> Senior Software Developer
> Fastmail US LLC