Re: [Jmap] Call for adoption draft-murchison-jmap-sieve-01

[Alexey Melnikov <[e-mail]>]

Hi,

On 31/07/2020 15:44, Bron Gondwana wrote:

> Hi All,
>
> As discussed in the meeting at IETF108, this is a formal call for 
> adoption for a document for managing sieve scripts via JMAP.  Please 
> send any comments on the adoption by August 14th (2 weeks from now).
>
> https://datatracker.ietf.org/doc/draft-murchison-jmap-sieve/

I support adopting this document and will work on it.


Some specific comments:

> Open Issues
>
>    o  How should doing /set{create} with an existing script name be
>       handled?  Should it fail or overwrite the existing script?  Should
>       the /set request include an 'overwrite' boolean argument?
RFC 5804 overwrites scripts by default, as long as they are valid. I 
would do the same here.

So maybe add boolean "nooverwrite" instead?

>
>    o  Should setting isActive==true on a script automatically deactivate
>       any other existing active script, or should the client have to do
>       so itself (as is currently documented)?
I think being able to activate the uploaded script in one operation 
would be handy. So yes, I agree with diactivating other scripts.
>
>    o  Do we want/need a SieveScript/copy method?
I am not sure this is needed. It is not like we support CATENATE for 
Sieve scripts ;-).
>    o  Do we want to leverage draft-ietf-jmap-quotas to query Sieve
>       script storage quotas?
Yes.
> 2.  Sieve Scripts
>
>    o  *content*: "String" The Sieve code in the script.  Note that any
>       double (") quote or backslash (\) characters appearing in the
>       script content MUST be escaped by prefixing them with a backslash
>       (\).
If this text is staying, it should explain that escaping is due to JSON 
rules. (Similar text when setting script)

Also, RFC 5804 has the following text:
  "A script of zero length SHOULD be disallowed."

So it is probably good to mention this in 2.2 and 2.3?

> 2.3.  SieveScript/validate
>
>    o  *errorDescription*: "String" A description of the error to show to
>       the user, or an empty string if the Sieve code is valid.
No strong preference, but should this be null when not set?

Best Regards,

Alexey