Subject: [sieve] Working group last call on draft-ietf-sieve-include

From: Barry Leiba <[email-masked]>
Date: Thu, 14 Jul 2011 10:45:35 -0400

The sieve-include doc looks ready to go.  Because Aaron and Cyrus are
both editors of this document, I'm playing doc shepherd and handling
chair duties related to the document.  And so here we start working
group last call on draft-ietf-sieve-include-10, which you can find
here: http://tools.ietf.org/html/draft-ietf-sieve-include-10

We've had good feedback on this, and I think it's solid.  Everyone,
please give it a last review and let us know whether you agree, or
whether you find anything that needs changing.  WGLC will end at the
end of July, just after the upcoming IETF meeting finishes.

Posts confirming that you've reviewed this version and agree that it's
ready are welcome.

Barry

---

From: Stephan Bosch <[email-masked]>
Date: Thu, 14 Jul 2011 17:13:22 +0200

> Posts confirming that you've reviewed this version and agree that it's

I've posted my final comments on the -10 version in the -07 thread a few 
days ago. Beyond those, I agree that it is ready to go.

Good work!

Regards,

Stephan.

---

From: Barry Leiba <[email-masked]>
Date: Thu, 14 Jul 2011 15:51:32 -0400

As I'm working on the shepherd writeup for this, I see that the
reference to RFC5429 isn't used, and it should be.  I suggest the
following changes:

At the bottom of page 6,
OLD
   Personal script "spam_tests"
NEW
   Personal script "spam_tests" (uses "reject" [RFC5429])

At the bottom of page 7,
OLD
   Site script "spam_tests"
NEW
   Site script "spam_tests" (uses "reject" [RFC5429])

Aaron, please put this in your working copy, but there's no need to
submit a new version unless there are other changes to make.  I'll
just put it into the writeup as a note, and the AD can enter it as an
RFC Editor note.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Thu, 14 Jul 2011 15:59:36 -0400

For the shepherd writeup, will folks please tell me if (1) you have
implemented sieve-include, at some version of the draft, or (2) you
intend to implement the final version.

Barry

---

From: Stephan Bosch <[email-masked]>
Date: Fri, 15 Jul 2011 00:41:35 +0200

> intend to implement the final version.

It's implemented for the Pigeonhole project for the Dovecot IMAP server:

http://pigeonhole.dovecot.org/

Latest draft version used is ietf-05 (currently except the ManageSieve 
requirements), with some backwards compatibility for the old 
import/export commands. I intend to upgrade to full RFC compliance once 
it is published.

Regards,

Stephan.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 18 Jul 2011 14:21:07 +0100

>Posts confirming that you've reviewed this version and agree that it's
I am mostly happy with this version, but I spotted several nits or minor 
errors:

2.  Conventions Used in This Document

   script execution
      an instance of a Sieve interpreter invoked for a given message
      delivery, starting with the user's active script and continuing
      through any included scripts until the message is delivered.

Pedantic comment: does "reject" or "discard" qualify as "message delivery"?

3.1.  General Considerations

   Sieve implementations MUST generate an error at execution time if an
   included script does not exist.

This is no longer true due to the addition of the :optional tag.

3.2.  Control Structure include

         Usage:   include *[PARAMETERS] <value: string>
                  PARAMETERS = LOCATION / :once / :optional
                  LOCATION = :personal / :global

   The "include" command takes an optional "location" parameter, an
   optional ":once" parameter, an optional ":optional" parameter, and a
   single string argument representing the name of the script to include
   for processing at that point.  It is RECOMMENDED that implementations
   restrict script names according to MANAGESIEVE [RFC5804] Section 1.7.

Did you mean Section 1.6 ("Script Names") instead of 1.7 ("Capabilities")?

Also, I think this requirement makes [RFC5804] Normative.

And finally, why is this not a MUST? Making a SHOULD level requirement 
seems a bit weak in this case.

4.  Security Considerations

   Sieve implementations MUST ensure that script names are checked for
   validity and proper permissions prior to inclusion, in order to
   prevent a malicious user from gaining acess to files accessible to

typo: access

   the mail server software that should not be accessible to the user.

5.1.  "include" Extension Registration

      Capability name: include
      Description:     adds the "include" command to execute other Sieve
                       scripts, and the "global" command and "global"
                       variables namespace to access variables shared
                       among included scripts.

The "return" action is not mentioned here.

---

From: Barry Leiba <[email-masked]>
Date: Mon, 18 Jul 2011 09:35:26 -0400

NEW
   an instance of a Sieve interpreter invoked for a given message
   delivery, starting with the user's active script and continuing
   through any included scripts until the final disposition of the
   message.

> This is no longer true due to the addition of the :optional tag.

NEW
   Sieve implementations MUST generate an error at execution
   time if an included script does not exist and the ":optional"
   parameter was not used.

> Also, I think this requirement makes [RFC5804] Normative.

I agree.

> seems a bit weak in this case.

I'd be happy with MUST.

Barry

---

From: Aaron Stone <[email-masked]>
Date: Mon, 18 Jul 2011 22:19:12 -0700

> Did you mean Section 1.6 ("Script Names") instead of 1.7 ("Capabilities")?

Probably was the right section in a draft version. Thanks for catching this.

> And finally, why is this not a MUST? Making a SHOULD level requirement seems
> a bit weak in this case.

s/RECOMMENDED/MUST/ ?

> _______________________________________________
> sieve mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sieve
>

---

From: Barry Leiba <[email-masked]>
Date: Tue, 19 Jul 2011 10:00:16 -0400

>> And finally, why is this not a MUST? Making a SHOULD level requirement seems

Well, not quite:

NEW
  Implementations MUST
  restrict script names according to MANAGESIEVE [RFC5804] Section 1.6.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Wed, 20 Jul 2011 09:29:55 -0400

We have last-call reviews and comments from Alexey, Stephan, and me.
Any others?  There's still a week and a half to review it.

Barry

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Wed, 20 Jul 2011 18:45:26 +0200

> Any others?  There's still a week and a half to review it.

It's OK. No substantial new issues since I reviewed.

I'm not entirely fond of the rules governing upload. If a is marked 
active and includes b, then I don't see why upload should treat a and b 
differently.

But that's a foo bar detail. In general the draft has about the right 
degree of verbosity, examples, etc: Good.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 21 Jul 2011 12:59:10 +0100

Arnt Gulbrandsen wrote:

> active and includes b, then I don't see why upload should treat a and 
> b differently.

I have to admit that that is something that bothered me a bit as well. 
However I can buy into an argument that a client which is going to 
upload multiple related scripts can either disable the active script, or 
upload it under a new name and then enable. (I am sure there are other 
reasonable choices.).

But this makes me wonder if we can add a new ManageSieve response code 
to detect include related errors?

---

From: Arnt Gulbrandsen <[email-masked]>
Date: Thu, 21 Jul 2011 14:02:10 +0200

> to detect include related errors?

If anything, then I think an "upload multiple" command. But I don't 
think it's worth botehring about.

Arnt

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 21 Jul 2011 13:06:18 +0100

> think it's worth botehring about.

I think this is overkill. I was thinking more about "this script is 
active and you have an include recursion error" response code, so that 
the client can disable the script, upload all pieces, reenable (or 
implement another strategy).

---

From: Barry Leiba <[email-masked]>
Date: Thu, 21 Jul 2011 08:17:04 -0400

>> If anything, then I think an "upload multiple" command. But I don't think
>> it's worth botehring about.
>
> I think this is overkill. I was thinking more about "this script is active
> and you have an include recursion error" response code, so that the client
> can disable the script, upload all pieces, reenable (or implement another
> strategy).

I think all of it's overkill: I think the real-world cases of complex
include dependencies will be far outliers.  Almost all includes will
be straightforward, and won't need anything complex to deal with them.

Barry