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

From: [email-masked]
Date: Mon, 02 Nov 2020 03:35:07 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the JSON Mail Access Protocol WG of the IETF.

        Title           : JMAP for Sieve Scripts
        Author          : Kenneth Murchison
	Filename        : draft-ietf-jmap-sieve-02.txt
	Pages           : 25
	Date            : 2020-11-02

Abstract:
   This document specifies a data model for managing Sieve scripts on a
   server using JMAP.

Open Issues

   o  Should we introduce an "isIncluded" or "isInUse" filter/sort
      condition for the /query method to locate scripts which are
      included by others?

   o  Do we need any (rate) limits for /test?

   o  Should ":fcc" and associated arguments (e.g., ":flags",
      ":create":, etc) reported in the /test response be in their own
      "fcc" sub-object rather than listed inline with the rest of the
      arguments for the action?

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-jmap-sieve/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-jmap-sieve-02
https://datatracker.ietf.org/doc/html/draft-ietf-jmap-sieve-02

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-sieve-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Stephan Bosch <[email-masked]>
Date: Thu, 19 Nov 2020 14:01:34 +0100

> https://www.ietf.org/rfcdiff?url2=draft-ietf-jmap-sieve-02

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.

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?

Regards,

Stephan.

---

From: Ned Freed <[email-masked]>
Date: Thu, 19 Nov 2020 05:17:01 -0800 (PST)

I think there's a more fundamental question we need to ask here: Is the
managesieve model the right one for handling sieves in JMAP?

By "managesieve model" I'm referring to the underlying data model where
there are multiple named sieves and one active sieve.

My specific concern is interoperability between clients that fully support this
model and clients that don't. A client that doesn't want to offer the ability
to have multiple sieves is likely going to just present the active script and
let you mess with it. Things can get interesting if another client that does
support multiple scripts comes along and switches to another script.

Of course there are ways of handling this, some requiring protocol/server
changes and others requiring extra vigilance on the part of clients. But before
we start exploring those - and given the ratio of single script to multiscript
clients I've seen I don't really think we have a choice - I think we need to
ask if multiscript facilities are something we want.

				Ned

P.S. I speak as someone who has implemented managesieve server side without any
real difficulty, and forsee no difficulty doing the same in JMAP. This is all
about client needs.

---

From: Ken Murchison <[email-masked]>
Date: Thu, 19 Nov 2020 09:15:55 -0500

Hi Stephan,

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

---

From: Ken Murchison <[email-masked]>
Date: Thu, 19 Nov 2020 09:26:37 -0500

Hi Ned,

> ask if multiscript facilities are something we want.

Don't we have the same single-script/multi-script client issue with 
managesieve?

Or perhaps I'm not fully understanding your concern.

A separate question that comes to mind, is do we want JMAP Sieve servers 
to be able to only support a single script?  I guess in this case, the 
server could simply have a single script with id "singleton" which can 
only be updated and (de)activated.  Any attempt to create another script 
or destroy the existing one would fail with a "singleton" error.

---

From: Ned Freed <[email-masked]>
Date: Thu, 19 Nov 2020 06:54:42 -0800 (PST)

> Don't we have the same single-script/multi-script client issue with

Yes. That's kind of the point.

> or destroy the existing one would fail with a "singleton" error.

Indeed. It seems like we're asking a lot of clients here. And if the past is
any indication, we're likely to be disappointed by what we get.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Thu, 19 Nov 2020 06:58:29 -0800 (PST)

> roundtrip of having to first upload the script in a separate request.

Is sieve updating something clients do often enough that it warrants 
roundtrip optimization?

				Ned

---

From: Ken Murchison <[email-masked]>
Date: Thu, 19 Nov 2020 10:06:44 -0500

> any indication, we're likely to be disappointed by what we get.

So, its sounds like you're making an argument that JMAP Sieve should 
always operate on a singleton.  Am I correct?

Obviously, this takes the Sieve "include" extension of the table.

---

From: Ken Murchison <[email-masked]>
Date: Thu, 19 Nov 2020 10:07:43 -0500

> Is sieve updating something clients do often enough that it warrants 

Perhaps not, but Blob/set provides a way around it anyways.

---

From: Stephan Bosch <[email-masked]>
Date: Thu, 19 Nov 2020 16:43:50 +0100

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

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

---

From: Ned Freed <[email-masked]>
Date: Thu, 19 Nov 2020 07:34:32 -0800 (PST)

> always operate on a singleton.  Am I correct?

No, not really. I'm saying that the managesieve model has issues that
warrant serious consideration before we adopt it in a different context.

The single sieve model is the obvious alternative, but it may not be the only
one. Since none of this is especially difficult server-side, I would like to
hear from client devleopers what sort of model they would prefer. Or if
the multisieve model is what they really want, have them say that.

> Obviously, this takes the Sieve "include" extension of the table.

No, not really. It just means you'd have to use some other means of resolving
the includes.

(Not that I'd mind. I think include is a botch.)

				Ned

---

From: Ken Murchison <[email-masked]>
Date: Thu, 19 Nov 2020 10:49:50 -0500

> No, not really. It just means you'd have to use some other means of 

A user would have no way of managing their own included scripts, but 
they could still include system-wide global scripts in their own single 
script if desired.

---

From: Ned Freed <[email-masked]>
Date: Thu, 19 Nov 2020 09:19:28 -0800 (PST)

> they could still include system-wide global scripts in their own single

Or you could include the ability to have (and manage) named scripts strictly
for use with include, and have one fixed script that's always the active one.

At first blush I actually like this model a lot. Enough that I may have to
revise my opinion of include.

				Ned