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

From: "Bron Gondwana" <[email-masked]>
Date: Sat, 01 Aug 2020 00:44:57 +1000

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/

Cheers,

Bron.

--
  Bron Gondwana, CEO, Fastmail Pty Ltd
  [email-masked]

---

From: Ken Murchison <[email-masked]>
Date: Fri, 31 Jul 2020 11:47:32 -0400

I'm obviously in favor of adopting.

On 7/31/20 10:44 AM, 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).
>

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 31 Jul 2020 18:16:58 +0100

Hi,

> 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