Subject: Working Group Last Call: draft-ietf-sieve-imapflags-01.txt

From: Cyrus Daboo <[email-masked]>
Date: Wed, 14 Sep 2005 07:01:36 -0700

I would like to draw your attention to the following draft:

<http://www.ietf.org/internet-drafts/draft-ietf-sieve-imapflags-01.txt>

A two week working group last call of this document starts today on 
September 14th 2005 and ends on September 27th 2005 at 6 pm EST.

Please review this document and send issues to the list or direct to the 
author(s).

NB If you do review this document, but have no issues or comments, please 
send both co-chairs (or the list) an email to indicate you have looked at 
it. This will allow the chairs to gauge the scope of reviews of this 
document to aid in our determination on whether to send it to the IESG. 
Thanks.

--
Cyrus Daboo
SIEVE WG Co-chair

---

From: Dave Cridland <[email-masked]>
Date: Wed, 14 Sep 2005 16:18:26 +0100

> <http://www.ietf.org/internet-drafts/draft-ietf-sieve-imapflags-01.txt>

1) I did find the use of the phrase "internal variable" somewhat 
confusing - this may simply be my own stupidity, but I feel that the 
first usage of "the internal variable" would be more readable if 
changed to "an internal flag list". Similarly, subsequent uses could 
be changed to "the internal flag list". I consider this a purely 
editorial change.

2) Section 5, para 2 states: "If the :flags tagged argument is not 
specified, "keep" or "fileinto" will not set any flag [...]". This 
appears to be in contradiction to Section 3, which states that where 
:flags is not supplied, the internal flag list will be used. I 
consider this a purely editorial change.

3) Section 4: hasflag appears to require a list of variable names. 
This would mean there is no method for testing the presence of a flag 
in the internal flag list. I consider this a minor technical change.

Dave.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 21 Sep 2005 16:02:17 +0100

> be changed to "the internal flag list". I consider this a purely 

But it is a variable. If an implementation supports both "variables" and 
"imap4flags", the internal variable can still be accessed.

Do other people find this confusing?

> consider this a purely editorial change.

Good catch, fixed.

> in the internal flag list. I consider this a minor technical change.

Good point.
I've made the list of variables in hasflag optional and added:
   If the list of variables is omitted, value of the internal variable is
   used instead.

---

From: Philip Guenther <[email-masked]>
Date: Thu, 22 Sep 2005 19:02:35 -0700

In section 1, I suggest changing
   Sieve interpreters that don't support integration with IMAP SHOULD
   ignore this extension.
to
   This extension is only appropriate for sieve interpreters that
   support integration with IMAP.
(What does it mean for an interpreter to 'ignore' an extension?)

Why is the [Variables] reference mixed cased instead of being
[VARIABLES]?

I'm not sure it's clear that the "variables" extension is 'present' if
and only if it has actually been used with "require".  (You can't use
the explicit variable name parameters if the "variables" extension is
supported by the implementation but has not been enabled with
"require".)  Perhaps the wording of the last paragraph of section 1
could be tweaked to avoid that ambiguity?

The ignoring of extra spaces in flag lists should include leading and
trailing spaces.  Should tabs and CRLF pairs also be ignored?  That
would let applications use multiline literals:
	addflag "flagvar" text:
	\deleted \answered
	.

I think the third sentence of section 3.2 should be flipped around, if
just to avoid "MAY NOT" (while "MAY" is an RFC 2119 keyword, "MAY NOT"
isn't!).  Indeed, I would give the implementation even more leeways,
ala:
   The addflag action MAY alter the flag list in any way that leaves the
   its semantics as a set of case-insensitive words unaltered.  For
   example, it may reorder the flags, alter the case of the letters in
   them, or add or remove duplicates or extraneous spaces.  Scripts
   SHOULD NOT make assumptions about the ordering of flags in lists or
   the preservation of their case.

Hmm, written like that, that chunk probably belongs in section 3 and not
3.2, especially when generallized to cover "setflag" and "removeflag" as
well.

The above also obsoletes the second paragraph of section 6 ("A script
interpreter..."), which seemed oddly placed to me anyway.

The third paragraph of section 4 regarding "hasflag" and reordering
makes no sense to me.  "hasflag" must split the supplied list of flag
and then iterate across it, but since it returns true if *any* of the
flags are present, the relative order of the flags doesn't matter, no?

There's no way to test whether a variable contains _only_ certain flags,
but I don't think that's needed either.

The two sample implementations of "addflag" should be next to each
other.

The sample "removeflag" implementation in section 6 is incorrect, as it
will only remove a single occurence of the given flag.  (Even if
"addflag" performs duplicate elimination, "removeflag" must still handle
multiple occurences as the user may have altered the variable directly
with "set".)

Philip Guenther

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 23 Sep 2005 12:01:23 +0100

Thanks Philip. I am answering to part of your comments and will get to 
the rest later on.

>Why is the [Variables] reference mixed cased instead of being
Changed.

>trailing spaces.
Ok, section 2.1, the middle of the third paragraph now reads:

   However spaces MUST be always allowed. Multiple
   spaces between flag names MUST be treated as a single space character,
   leading and trailing spaces MUST be ignored.

>Should tabs and CRLF pairs also be ignored?
>
No :-).

>That
[...]

>flags are present, the relative order of the flags doesn't matter, no?
You are right. The paragraph should be deleted.

>but I don't think that's needed either.
I don't think this is needed, as different flags are independent.

---

From: Alexey Melnikov <[email-masked]>
Date: Mon, 26 Sep 2005 15:45:17 +0100

>could be tweaked to avoid that ambiguity?
Yes. I've updated the last paragraph of section 1 to read:

   The "imap4flags" extension can be used with or without the "variables"
   extension [VARIABLES]. When the "variables" extension is enabled in
   a script using <require "variables">, the script can use explicit
   variable names in setflag/addflag/removeflag actions. See also section
   3 for more details. When the "variables" extension is not enabled
   the explicit variable name parameter to setflag/addflag/removeflag
   MUST NOT be used and MUST cause an error according to [SIEVE].

---

From: "Aaron Stone" <[email-masked]>
Date: Mon, 26 Sep 2005 23:54:52 -0000

On Mon, Sep 26, 2005, Alexey Melnikov <[email-masked]> said:
> ...  When the "variables" extension is not enabled

I've noticed that a lot of the Sieve specs say to generate errors at
"compile" time and I'm just wondering if there's a list of compile-time
and run-time errors that are listed as MUST, SHOULD or MAY. I'm also
wondering if someone's got a good solution to the Halting Problem? I've
been working at it for a while and it seems to be unsolvable...

Aaron

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 27 Sep 2005 10:50:15 +0100

Aaron Stone wrote:

>and run-time errors that are listed as MUST, SHOULD or MAY.
>
I think all errors are MUST. Otherwise scripts are not really portable.

Whether an error is catched at runtime or compile time - it depends on 
an implementation. Some implementations bytecompile Sieve, some 
implementations interpret it.