Subject: I-D ACTION:draft-daboo-sieve-include-03.txt (fwd)

From: Cyrus Daboo <[email-masked]>
Date: Wed, 24 Aug 2005 19:52:59 -0400

Hi folks,
I have published a new version of the include draft. Note that this is NOT 
a working group item - its a personal submission. I am aware of at least 
two implementations of this (one complete, one in progress) and think it 
worth publishing at proposed status, though experimental might also be 
applicable. That's an open question for debate.

One other issue: how should include scripts interact with variables? Some 
questions to illustrate this problem:

1) Should a variable defined in a 'parent' script be available in 'child' 
(included) scripts?

2) Should a variable defined in a 'child' script be available in the 
'parent' script after the point of inclusion? And if so, should those 
variables be available to other 'child' scripts included after that point?

3) Should variables defined in a 'child' script only be local to that 
script?

Comments?

-- 
Cyrus Daboo

Subject: I-D ACTION:draft-daboo-sieve-include-03.txt
From: [email-masked]
To: [email-masked]
Date: Wed, 24 Aug 2005 15:50:01 -0400
List-Id: i-d-announce.ietf.org

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: SIEVE Email Filtering: Include Extension
	Author(s)	: C. Daboo
	Filename	: draft-daboo-sieve-include-03.txt
	Pages		: 11
	Date		: 2005-8-24
	
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, as well as
   supporting common 'libraries' of scripts.  Users are able to include
   their own personal scripts or site-wide scripts provided by the local
   SIEVE implementation.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-daboo-sieve-include-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-daboo-sieve-include-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-daboo-sieve-include-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/i-d-announce

---

From: "Aaron Stone" <[email-masked]>
Date: Thu, 25 Aug 2005 01:59:55 -0000

> 3) Should variables defined in a 'child' script only be local to that 

According to the changelog in the ietf-variables-06 draft, a clarification
was made that variables do span includes. I could not find where this was
specified in the document, however. It sounds like the open issue is being
left to the include draft to resolve ;-)

I program most frequently in C and in PHP. I can't think how we might
apply any of C's scoping rules because curly braced scopes do not exist in
Sieve. Everything is global. This rather reminds me of PHP, actually.

Applying a PHP-ish model, each file would have a totally clean namespace.
If you wanted a variable to cross both namespaces, you would declare it
Global. In the ietf-variables-06 draft, section 4.1, gives a list of
modifiers. How about a :global modifier?

set :global "a";
# Now ${a} in this script points to the same memory as ${a} everywhere.

But... both set is defined like this:
   Usage:    set [MODIFIER] [COMPARATOR] <name: string> <value: string>

So how about this:

set :global "a" "${a}"

Or perhaps:

set :import "a" "${a_from_my_parent}"
set :export "a_back_to_parent" "${a}"

Aaron

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 25 Aug 2005 17:16:42 +0200

> left to the include draft to resolve ;-)

this is the text which was added:

"All variables have global scope: they are visible until processing
stops."

I find this sufficiently clear to answer "yes" to all three of Cyrus'
questions, but then I wrote it :-)

> modifiers. How about a :global modifier?

that would be a no-op, but a :local modifier is definitely possible if
needed.
-- 
Kjetil T.

---

From: "Aaron Stone" <[email-masked]>
Date: Thu, 25 Aug 2005 15:30:05 -0000

> questions, but then I wrote it :-)

I wouldn't have gotten that on my own in a million years, neither in
implementing a Sieve interpreter nor in writing my own scripts. 

> that would be a no-op, but a :local modifier is definitely possible if

It would only be a no-op if the default namespace is the global namespace
;-) Unless you guys are already deeply along the path of a single
namespace, I believe a per-file namespace is less likely to cause
confusing results.

A :local modifier would do the trick. The text in the drafts should be
more explicit about there being a single global namespace for all scripts.

The very presence of a :global and/or :local modifier makes for an
explanation that will clarify things for implementors and end users alike.
On this point, what do folks think?

Aaron

---

From: "Nigel Swinson" <[email-masked]>
Date: Thu, 25 Aug 2005 17:02:17 +0100

> namespace, I believe a per-file namespace is less likely to cause

FWIW I totally agree.  I wonder if even though the variables spec puts it that way, it would be ok to interpret "Global" as "File scope" and add text to the include draft to permit this.  Indeed it's only with the include extension that the possibility of anything wider than File Scope exists.  I'm also a PHP user and I also think they've done a pretty good job with their :global specifer.

> more explicit about there being a single global namespace for all scripts.

I think a :local modifier is a bit of a waste... you'd likely only use it AFTER you'd spent ages debugging an awkward problem.  I'd much rather we helped them avoid the awkward problem in the first place and hence my support for a :superglobal type modifier.

Nigel

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 25 Aug 2005 23:45:10 +0200

> implementing a Sieve interpreter nor in writing my own scripts. 

okay, would you interpret that statement differently, or is it just
easily overlooked?

> > [:global] would be a no-op, but a :local modifier is definitely possible if
> > needed.
> 

I personally find a global namespace to be the less confusing option.
cutting the script into pieces and including those from a master file
shouldn't change its meaning, IMHO.  (you'll usually need to duplicate
require statements, though.)

> more explicit about there being a single global namespace for all scripts.

there is only one script, it just so happens that it may consist of more
than one file :-)

> On this point, what do folks think?

I don't think it is a very important point.  the scripts I see tend to
use a "stop" as soon as possible, and there is little need to keep state
across an include statement.  the risk of having your state trampled on
is small, especially since you'll tend to control all the script
components yourself.  indeed, I think it would be more common to use a
global variable set in the included file to return the result to the
calling file.
-- 
Kjetil T.

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Fri, 26 Aug 2005 00:16:17 +0200

the draft looks good.  a couple comments:

   SIEVE implementations MUST ensure that recursive includes are not
   possible. i.e. if script "A" includes script "B", and script "B"
   includes script "A" an error MUST be generated either when the script
   is uploaded to the SIEVE repository, or when the script is executed.

this can make uploading difficult, the uploader will have to resolve the
graph and upload in the right order.  I would prefer to change
"uploaded" to "activated".

      :global
         Indicates that the named script is stored in a site-wide SIEVE
         repository, accessible to all users of the SIEVE system.

to avoid possible confusion with scoping, I think ":system" is a better
name.  ":site" is another alternative.

typo section:

   Its convenient to be able to break SIEVE [1] scripts down into
   ===
   and a special 'vacation' script, the later being activated when the
                                        latter(?)
   via an includes in an existing script.  An error MUST be generated
          "include"
   when a missing included script is descovered during execution.  If
                                      =

-- 
Kjetil T.

---

From: "Aaron Stone" <[email-masked]>
Date: Thu, 25 Aug 2005 23:38:49 -0000

> okay, would you interpret that statement differently, or is it just

Both... it's only a single sentence, and a major issue. I think a section
entitled "Scope" at around 4.2 or 4.1.4 would be best. Also, when the
issue comes up the user or implementor will have the question, "Why does
my variable contain weird values after an include?" or "Why can't I access
a variable set in another file?" and the answer should be explicit to
those questions.

[snip]
> there is only one script, it just so happens that it may consist of more

Ok, but that doesn't change my position ;-)

:local would be like C's static applied to a variable in the file.

> global variable set in the included file to return the result to the

Include will allow more sites to create libraries of common scripts. These
scripts will want to keep most of their namespace clean and/or protected.
Prefixed on the variables might work, but a :local / :global mechanism
would make these protections more explicit.

Aaron

---

From: "Nigel Swinson" <[email-masked]>
Date: Fri, 26 Aug 2005 00:45:37 +0100

> there is only one script, it just so happens that it may consist of more

I can't help wondering if you are making a few assumptions:
- a single author wrote/maintain all the scripts
- all the scripts are quite small or
- all the scripts are sufficiently simple that they can be recalled as a whole

At one level aren't namespaces a tool for protecting you against pollution from some other part of a much larger or multi-authored script.  Other tools for breaking down larger scripts would include things like functions an files.  I'm nervous that by declaring that all variables must be more than just file-scope global that we create a problem for ourselves when/if scripts end up getting seriously large.  I recal seeing a script from one of my customers which was in excess of 64K!

Are there security concerns too.  Server Admin controls script A which includes script B which is controlled by an end-user.  The end user could declare a variable in script B that would alter the behaviour of the remainder of script A after the include?

Nigel