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

Stephan Bosch <> Thu, 19 November 2020 15:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF4323A0ABB for <>; Thu, 19 Nov 2020 07:43:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Status: No, score=-2.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1TWLb_wW67Bo for <>; Thu, 19 Nov 2020 07:43:55 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 524083A0A9A for <>; Thu, 19 Nov 2020 07:43:54 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Postfix) with ESMTPS id C22586A26A; Thu, 19 Nov 2020 16:43:52 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=201705; t=1605800632; bh=xxuCX+A163fYnHBG6sJz4fL1m1uaZc5Kabi/dKcfp14=; h=Subject:To:References:From:Date:In-Reply-To:From; b=mQPnNsOzQhMFs4Ie0fn4xxaFo9YMYSi934Xb8vyHNrW3jUujMUqnzWe9FHvZWcr/A v6HIsUJ/06k9tvlwmF36xJ7aW875Pf+DxbM+6yJNiCpiLczLX//K34lLpP77UfNpzr A2N4+JseDnAdo60zTAvjqfgk5EDs1h5xz4zkryGWze2XjaSTL+f8dfQU1V1jAkWlrj xFb4zeqqy/Ttv9w9FGuem9yBICNQn3+tCW4EX2KSiWXbH23qbImCauIQn9lg0lCDvb tmSf4Di3jZBfrPVnjJi224up+g7mieGo/hABdVPBDwCyHsZAhCKPiDgE8XPBA7mYEL mckpg+xCVEYtQ==
Received: from [] (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPSA id 85C123C002F; Thu, 19 Nov 2020 16:43:52 +0100 (CET)
To: Ken Murchison <>,
References: <> <> <>
From: Stephan Bosch <>
Message-ID: <>
Date: Thu, 19 Nov 2020 16:43:50 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.4.3
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [Jmap] I-D Action: draft-ietf-jmap-sieve-02.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: JSON Message Access Protocol <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Nov 2020 15:43:57 -0000

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