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

[Ken Murchison <[e-mail]>]

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-positions/
> 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