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

[Stephan Bosch <[e-mail]>]

On 19/11/2020 15:15, Ken Murchison wrote:
> 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.

Well, I don't like piping potentially large data things through JSON 
very much. First, for JSON implementations that don't support streaming 
JSON string values, this means allocating large memory buffers to deal 
with uploading/downloading those. And yes, Sieve scripts can be quite 
large (e.g. vacation action with inline email with image attachment 
etc.). Second, the additional base64 or JSON-string-escape encoding 
effort does not sound too appealing for large data either.

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

I'd say both should be supported, as requested by client using the 
"properties" method field. This is similar to how Email object is 
structured.

Regards,

Stephan.