Re: [Jmap] I-D Action: draft-ietf-jmap-sieve-02.txt

[Ken Murchison <[e-mail]>]

Hi Stephan,


On 11/19/20 8:01 AM, Stephan Bosch wrote:
>
> First, I think this now misses a nice way to upload/download raw Sieve 
> scripts (i.e. without JSON string escaping). As said earlier in this 
> mailing list, using the blob upload/download facility would be better 
> and it is more consistent with jmap:mail in my opinion.


The reason that we chose to provide the content as an argument to /set, 
/validate, and /test (unless using scriptId) is to avoid the extra 
roundtrip of having to first upload the script in a separate request.

That said, a client could leverage 
https://tools.ietf.org/html/draft-gondwana-jmap-blob-01 
<https://tools.ietf.org/html/draft-gondwana-jmap-blob-01> to avoid the 
extra roundtrip, but I will note that in order to avoid JSON string 
escaping, the script would have to be base64-encoded.

I have no strong opinion either way on how the script content gets 
supplied for the /set method.  I'll leave that up to others to hash out.


What do you envision would be returned by /get?  The script content, or 
a blobId that would have to be subsequently fetched?


>
> Second, I remember RFC 5784 (https://tools.ietf.org/html/rfc5784). 
> That is an effort to map the Sieve language grammar to XML. We could 
> (optionally of course) do the same in this extension using JSON rather 
> than XML and make it easier for clients to evaluate, display, and 
> manipulate Sieve scripts without the need to write a Sieve 
> parser/generator. This could be a "content:as(json)" field, or 
> something like that. Or is that just too complex?


If someone wants come up with a design for a JSON object to represent 
Sieve, we could certainly consider it.  Again, I have no strong opinion.

-- 
Kenneth Murchison
Senior Software Developer
Fastmail US LLC