Subject: Re: Draft for script 'include' capability

From: Marc Mutz <[email-masked]>
Date: Wed, 7 May 2003 18:06:18 +0200

Hi!

I think that the draft should forbid recursion in the description of the 
include action, where it talks about policy limits on nesting depth. I 
don't see the point in having it the Security Considerations section. 
I'd also make it explicit that a script MUST NOT include itself:

    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
+   possible. e.g. if script "A" includes script "B", and script "B"
+   includes script "A" or a script includes itself an error MUST be
+   generated either when the
    script is uploaded to the SIEVE repository, or when the script is
    executed.  If such an error is detected whilst processing a SIEVE
    script, an implicit "keep" action MUST be executed to prevent loss
    of any messages.

Just for fun, here's a fact() "function" implemented with "variables" 
and "include" (with only include-self allowed) :-)

--usage--
if header :matches "X-SPAM-LEVEL" "*" {
  set "arg" "${1}";
}
include "fact";
addheader "X-SPAM-FACULTY-OF-LEVEL" "${fact}";
--end usage--

--script fact--
require [ "variables", "include" ];

# returns in ${fact} the faculty of ${arg} (expressed as the length of
# the string: "#####" = 5, "foo" = 3, etc. ${fact} is a "real" integer

if anyof( string "${arg}" "", string :matches "${arg}" "?" ) {
  set "arg" "#";  # 0! = 1! = 1
  set "fact" "1";
  return;
} else {
  # return arg * fact( arg - 1 )
  set "arg1" "${arg}";
  # --arg
  if string :matches "?*" "${arg}"; {
    set "arg" ${2};
  }
  # arg = fact( arg )
  include "fact";
  # result = arg1 * arg
  set "arg2" "${arg}";
  include "multiply";
  set "arg" "${result}";
  set :length "fact" "${arg};
  return;
}
--end script fact--

--script multiply--
require [ "variables", "include" ];

# returns a string in ${result} that contains ${arg1} * ${arg2} times
# the hash # character:

if string "${arg1}" "" {
  set "result" "";
} elsif string :matches "${arg1}" "?" ) {
  set "result" "${arg2}";
} else {
  # --arg1:
  if string :matches "?*" "${arg1}" {
    set "arg1" "${2}";
  }
  include "multiply";
  # arg1 * arg2 == ( arg1 - 1 ) * arg2 + arg2
  set "result" "${result}${arg2}"
}
--end script multiply--

On Monday 14 April 2003 05:20, Kjetil Torgrim Homme wrote:
<snip>
> another issue is case-sensitivity for filenames.  this is glossed
> over in fileinto as well, but I think it should be stated explicitly.
> something like:
>
>     The filename is case sensitive.  An implementation MAY refuse to
>     allow two files whose names only differ in case.
>
> actually, this should go into the Managesieve draft as well.

I'd prefer to leave that up to the implementation since it touches on OS 
or even filesystem/database dependence.

Marc

-- 
If free-software authors lose the right to disclaim all warranties and
find themselves getting sued over the performance of the programs
they've written, they'll stop contributing free software to the world.
 -- Bruce Perens: Open Sources: Voices from the Open Source Revolution

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: 09 May 2003 14:13:16 +0200

[Marc Mutz]:
>
>   I think that the draft should forbid recursion in the description
>   of the include action, where it talks about policy limits on
>   nesting depth. I don't see the point in having it the Security
>   Considerations section.  I'd also make it explicit that a script
>   MUST NOT include itself:

spoilsport!  how am I going to do Towers of Hanoi in Sieve now?

oh well, I guess I must support your suggestion...

>   [nifty code snipped]

I'm glad to see :length being put to good use :-)

> I'd prefer to leave that up to the implementation since it touches
> on OS or even filesystem/database dependence.

that's my point.  if we don't say anything, the script generator must
assume the lowest common denominator, which is case-sensitive (Unix)
and upper-case (DOS and others).  perhaps even more restrictions must
be put in place (allowable characters, length).  passing the work of
finding this lowest common denominator on the script writer is wrong,
I think the draft needs to put in some ground rules for what
implementations _must_ support.

-- 
Kjetil T.