Subject: Re: Questions and remarks on draft-ietf-sieve-include-01.txt

From: Aaron Stone <[email-masked]>
Date: Mon, 04 May 2009 14:24:51 -0700

I'm posting draft-ietf-managesieve-02 that addresses these comments. Thank
you!

On Tue, 14 Apr 2009 15:36:20 +0200, Arnt Gulbrandsen
<[email-masked]> wrote:
> Aaron Stone answers Stephan Bosch:
>>>  - Where the ManageSieve protocol specifies what characters are 
>>>  allowed for a script name, the include extension for the Sieve 
>>>  language does not. Would it be useful to adopt the same 
>>>  limitations? Especially things like '/' can cause problems.
>>
>> Good suggestion. I think this makes sense to give a consistent opinion 
>> on what script names should look like, but on the other hand, perhaps 
>> it's possible that someone isn't using ManageSieve but IS using 
>> include and might need to get at weird names? Do we care in that 
>> case?
> 
> If so, then they probably will use managesieve at some point anyway.
> 
>>>  - The global command is required to follow 'require' or another 
>>>  global command. I am worried what happens when other extensions 
>>>  have commands with similar requirements. Shouldn't we account for 
>>>  this eventuality?
>>
>> I don't like this restriction anyways. Any objection to lifting it?
> 
> (I don't feel qualified to have an opinion on this issue.)
> 
>>>  - The scope of the :once modifier could be a bit confusing. I am  
>>>  assuming it holds for the whole Sieve execution and not only for 
>>>  the identical include commands within the current script.
>>
>> Correct. Could you suggest how I might clarify that it's the whole 
>> execution? I feel like I'm missing the right word for being inside 
>> one file vs. being inside one delivery/execution instance.
> 
> I think that's enough of an issue that it's worth a whole sentence or
two.
> 
> I like precise words. But sometimes you can be as precise as you want, 
> and someone will read the text after being up half the night with the 
> crying baby and won't get it.
> 
> Or zero words perhaps. Why is :once justified? is "mandatory :once" or 
> ":once not supported" good enough?
> 
> Arnt

---

From: Aaron Stone <[email-masked]>
Date: Mon, 04 May 2009 14:24:41 -0700

On Sat, 11 Apr 2009 10:02:11 +0200, Stephan Bosch <[email-masked]>
wrote:
> Hi Aaron,
> 
> Aaron Stone wrote:
>> Thanks for your comments. I'd been preparing to send an email to the
list
>> announcing the changes and requesting feedback. You've touched on all
the
>> good points. So let's run with this thread!
>> 
>> On Sat, 11 Apr 2009 01:39:58 +0200, Stephan Bosch <[email-masked]>
>> wrote:
>>> First of all, I am very glad that the work on the specification is
being
>>>
>>> continued now. This week I quickly updated my implementation to match 
>>> the new specification. Merging import and export into a single global 
>>> command is a good choice. The use of a global variable namespace is
also
>>>
>>> a good idea (but I did not implement that yet).
>> 
>> I actually wonder if we should drop the global keyword and rely on
>> namespaces entirely.
> The global namespace has one disadvantage: it makes all global variable 
> names longer ('global.*'). Especially when a variable is used often in a 
> script, this may become tedious. Using the global command, it is 
> possible to pull global variables into the script namespace, which is 
> convenient in such situations. I guess it would be best to support both 
> methods of accessing global variables (and to even allow mixing these 
> freely).
> 
>>> - Where the ManageSieve protocol specifies what characters are allowed 
>>> for a script name, the include extension for the Sieve language does 
>>> not. Would it be useful to adopt the same limitations? Especially
things
>>>
>>> like '/' can cause problems.
>> 
on
>> what script names should look like, but on the other hand, perhaps it's
>> possible that someone isn't using ManageSieve but IS using include and
>> might need to get at weird names? Do we care in that case?
> You can also make it a recommendation. As long as implementers know that 
> there is some consensus about what a script name is supposed to be and 
> that script names should not be mapped directly to files for security 
> reasons.
> 
>>> - The global command is required to follow 'require' or another global 
>>> command. I am worried what happens when other extensions have commands 
>>> with similar requirements. Shouldn't we account for this eventuality? 
> Hmm, interesting suggestion. The main implication of this is that the 
> inclusion of global variables into the script namespace can become 
> conditional, i.e. when it is placed into an if statement. I don't know 
> whether this is desirable.
> 
> You could also state that the global command needs to be placed after 
> require commands or any command that also needs to be placed directly 
> below the require commands (choose better wording though). This implies 
> no ordering between the commands that follow the require section, 
> avoiding problems with future commands with similar needs.
> 
>>> - Are there any special security implications for using variables in
the
>>>
>>> value argument in the include command, i.e. to include a script 
>>> specified by a variable? Is that even (intended to be) allowed?
>> 
>> Oh, that's a good question. That'd be an easy vector for contamination
of
>> email contents into a filesystem request. Can we reasonably place such a
>> restriction, though? I'd hate to force implementations to special-case
>> their string expansions.
> Other extensions already have such limitations (e.g. notify) and the 
> variables extension explicitly states that future commands may choose 
> not to allow variables in some of their arguments (the so-called 
> constant string). However, I agree that we should not limit the 
> flexibility of the command more than necessary. Perhaps an explicit 
> mention in the Security Considerations section would suffice to cover 
> our bases.
> 
> On the other hand, one may argue how useful it is to use variables in 
> the include argument in the first place: there are a (known) limited 
> amount of scripts in the Sieve storage and making choices can be done 
> using if commands surrounding multiple alternative include commands.
> 
> People using variables could even make their scripts highly unreliable, 
> since include commands kill Sieve execution when the indicated script 
> does not exist. Perhaps in combination with an ':optional' modifier, 
> variables could be used to change the behavior of a script without 
> actually modifying it. For instance, when a script is added to the Sieve 
> store with a name that matches the sender address, it is included 
> automatically when a message from that person comes in. That sounds a 
> bit freaky though :)
> 
>>> assuming it holds for the whole Sieve execution and not only for the 
>>> identical include commands within the current script.
>> 
>> execution? I feel like I'm missing the right word for being inside one
>> file
>> vs. being inside one delivery/execution instance.
> I am still not sure what to do here. I guess it is also important to 
> mention that the scope of the :once modifier does not extend into the 
> other scripts of a multiscript sequence (and any scripts included by 
> those).. or does it? For this distinction it matters whether you call it 
> the 'whole Sieve execution', as this would include truly everything.
> 
> Regards,

---

From: Aaron Stone <[email-masked]>
Date: Mon, 04 May 2009 23:55:28 -0700

Of course I meant draft-ietf-sieve-INCLUDE-02. I added an informative
reference to managesieve, hence the copy-paste buffer error :)

---

From: Stephan Bosch <[email-masked]>
Date: Tue, 05 May 2009 11:07:59 +0200

Hi Aaron,

> I'm posting draft-ietf-managesieve-02 that addresses these comments. Thank
Ok, looks nice. I'll adjust my implementation as soon as I have some time.

However, as far as I can see, you did not address every issue yet:

- For the global command I would expect text stating that the variables 
extension is required when it is used.

- The scope of the :once modifier could be a bit confusing. I am 
assuming it holds for the whole Sieve execution and not only for the 
identical include commands within the current script. What is the 
interaction with multiscript in this case? I am still not sure what to 
do with this.

- The script examples have various small typos, syntax problems and 
missing require items.

Also, you completely lifted the global command's placement requirements. 
I am not fundamentally opposed to this, but this can make the inclusion 
of a global variable conditional, i.e. inside an if statement. Until I 
actually implement this I won't really know for sure whether there will 
be implementation issues.

And if the possibility for a conditional global command is desired, I 
would expect an explicit mention of this possibility somewhere in the 
command explanation. Now it could come to a surprise to the more naive 
implementer. This also implies that a global variable is not included 
into the local scope until after the first global command that specifies 
it.

Finally, I saw one new typo: Section 4, second paragraph, 'acess'.

Regards,

-- 
Stephan Bosch
[email-masked]

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 05 May 2009 15:25:17 -0400

> into the local scope until after the first global command that specifies

I would expect that a global command has effect only from the command to 
the end of the enclosing scope; as a result, a global inside a conditional 
has effect only on the conditional code, and never on something occurring 
after the conditional, regardless of whether the conditional is taken.

Alternately, a global command could be defined to apply to the entire file 
regardless of where it occurs.

---

From: Aaron Stone <[email-masked]>
Date: Tue, 05 May 2009 13:14:09 -0700

> after the conditional, regardless of whether the conditional is taken.

Would require variable scoping rules that follow the curly braces, but
we're doing it PHP / Python style in Sieve.

> regardless of where it occurs.

That presumes pre-parsing the script, which I don't want to sneakily make a
requirement of interpreters.

I went with this approach: the variable is local to the immediate script
until it is called global at some point later in the script. I flipped a
coin, and decided the local value would then overwrite the global value. I
could as easily see it go the other way, though. I can't think of any
particularly good examples from other languages that might apply here.
Feedback appreciated!

Aaron

---

From: Jeffrey Hutzelman <[email-masked]>
Date: Tue, 05 May 2009 16:47:11 -0400

--On Tuesday, May 05, 2009 01:14:09 PM -0700 Aaron Stone 
<[email-masked]> wrote:

> That presumes pre-parsing the script, which I don't want to sneakily make
> a requirement of interpreters.
>

Hrm.  OK, let's make it simple...

The global command is legal at any point in the script.  However, it must 
appear _and be executed_ before any use of the named variable(s). 
Otherwise, the results are undefined.

This means the question of what happens if you use a local variable and 
then call it global is up to the implementation.  So is the question of 
what happens if the global command appears in a conditional and that branch 
is not executed, and then the variable is used.

I think it gets us all the same implementation simplicity as requiring it 
to be "first", without painting ourselves into the corner of someday having 
multiple things that want to be "first".

-- Jeff

---

From: Aaron Stone <[email-masked]>
Date: Tue, 05 May 2009 14:14:00 -0700

> Otherwise, the results are undefined.

Or an error is thrown at runtime. I'm not a fan of this idea, but at least
it's definitive.

> multiple things that want to be "first".

Yuck, I don't like it when a language doesn't specify something like this,
especially knowing it is probably going to be implemented differently right
from the get-go.

Aaron

---

From: Stephan Bosch <[email-masked]>
Date: Tue, 05 May 2009 23:28:12 +0200

Jeffrey Hutzelman schreef:
> The global command is legal at any point in the script.  However, it 
> must appear _and be executed_ before any use of the named variable(s). 
> what happens if the global command appears in a conditional and that 
> branch is not executed, and then the variable is used.
> 
> I think it gets us all the same implementation simplicity as requiring 
> it to be "first", without painting ourselves into the corner of someday 
> having multiple things that want to be "first".
> 
Eeew, this is getting hairier by the minute :) I don't see any benefit 
for putting the global command anywhere else than the beginning of the 
script, so why don't we just get back to the original plan in a slightly 
modified manner:

"
A global command must be placed at top level directly after the require 
commands or any other command that has the same top level placement 
requirement.
"

And then more properly phrased of course.

Keep in mind that the problem I stated originally was only about 
interaction with other commands with similar placement requirements and 
not the flexibility of the global command in general.

Regards,

-- 
Stephan Bosch
[email-masked]