Aaron Stone | 4 May 2009 23:24
Gravatar

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


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

On Tue, 14 Apr 2009 15:36:20 +0200, Arnt Gulbrandsen
<arnt <at> gulbrandsen.priv.no> 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  
(Continue reading)

Aaron Stone | 4 May 2009 23:24
Gravatar

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


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

On Sat, 11 Apr 2009 10:02:11 +0200, Stephan Bosch <stephan <at> rename-it.nl>
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 <stephan <at> rename-it.nl>
>> 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 
(Continue reading)

Internet-Drafts | 4 May 2009 23:30
Picon
Favicon

I-D Action:draft-ietf-sieve-include-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Sieve Mail Filtering Language Working Group of the IETF.

	Title           : Sieve Email Filtering: Include Extension
	Author(s)       : C. Daboo, A. Stone
	Filename        : draft-ietf-sieve-include-02.txt
	Pages           : 12
	Date            : 2009-05-04

The Sieve Email Filtering "include" extension permits users to
include one Sieve script inside another.  This can make managing
large scripts or multiple sets of scripts much easier, and allows a
site and its users to build up libraries of scripts.  Users are able
to include their own personal scripts or site-wide scripts.

Change History (to be removed prior to publication as an RFC)

Changes from ietf-01 to ietf-02:
a.  Require that script names must be constant strings, not subject

 to variable expansion.
b.  Try the phrase immediate script instead of current script.
c.  Clarify that "global 'varname'" and "global.varname" refer to the

 same variable.
d.  Drop the requirement the global keywords come after require and

 before anything else.

Changes from ietf-00 to ietf-01:
(Continue reading)

Aaron Stone | 5 May 2009 08:55
Gravatar

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


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

On Mon, 04 May 2009 14:24:51 -0700, Aaron Stone <aaron <at> serendipity.cx>
wrote:
> I'm posting draft-ietf-managesieve-02 that addresses these comments.
Thank
> you!
> 
> On Tue, 14 Apr 2009 15:36:20 +0200, Arnt Gulbrandsen
> <arnt <at> gulbrandsen.priv.no> 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?
(Continue reading)

Stephan Bosch | 5 May 2009 11:07
Picon

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


Hi Aaron,

Aaron Stone wrote:
> I'm posting draft-ietf-managesieve-02 that addresses these comments. Thank
> you!
> 
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 
(Continue reading)

Jeffrey Hutzelman | 5 May 2009 21:25
Picon
Favicon

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


--On Tuesday, May 05, 2009 11:07:59 AM +0200 Stephan Bosch 
<stephan <at> rename-it.nl> wrote:

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

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.

Aaron Stone | 5 May 2009 22:14
Gravatar

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


On Tue, 05 May 2009 15:25:17 -0400, Jeffrey Hutzelman <jhutz <at> cmu.edu>
wrote:
> --On Tuesday, May 05, 2009 11:07:59 AM +0200 Stephan Bosch 
> <stephan <at> rename-it.nl> wrote:
> 
>> 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.
> 
> 
> 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.

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

(Continue reading)

Jeffrey Hutzelman | 5 May 2009 22:47
Picon
Favicon

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


--On Tuesday, May 05, 2009 01:14:09 PM -0700 Aaron Stone 
<aaron <at> serendipity.cx> wrote:

>
> On Tue, 05 May 2009 15:25:17 -0400, Jeffrey Hutzelman <jhutz <at> cmu.edu>
> wrote:
>> --On Tuesday, May 05, 2009 11:07:59 AM +0200 Stephan Bosch
>> <stephan <at> rename-it.nl> wrote:
>>
>>> 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.
>>
>>
>> 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.
(Continue reading)

Aaron Stone | 5 May 2009 23:14
Gravatar

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


On Tue, 05 May 2009 16:47:11 -0400, Jeffrey Hutzelman <jhutz <at> cmu.edu>
wrote:
> --On Tuesday, May 05, 2009 01:14:09 PM -0700 Aaron Stone 
> <aaron <at> serendipity.cx> wrote:
> 
>>
>> On Tue, 05 May 2009 15:25:17 -0400, Jeffrey Hutzelman <jhutz <at> cmu.edu>
>> wrote:
>>> --On Tuesday, May 05, 2009 11:07:59 AM +0200 Stephan Bosch
>>> <stephan <at> rename-it.nl> wrote:
>>>
>>>> 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.
>>>
>>>
(Continue reading)

Stephan Bosch | 5 May 2009 23:28
Picon

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


Jeffrey Hutzelman schreef:
> 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".
> 
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.

(Continue reading)


Gmane