Subject: I-D ACTION:draft-ietf-sieve-variables-04.txt

From: [email-masked]
Date: Fri, 15 Jul 2005 10:50:01 -0400

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 Mail Filtering Language: Variables Extension
	Author(s)	: K. Homme
	Filename	: draft-ietf-sieve-variables-04.txt
	Pages		: 16
	Date		: 2005-7-15
	
In advanced filtering rule sets, it is useful to keep state or
   configuration details across rules.  This extension changes the
   interpretation of strings, adds an action to store data in variables,
   and supplies a new test so that the value of a string can be
   examined.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sieve-variables-04.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-ietf-sieve-variables-04.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-ietf-sieve-variables-04.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.

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Sat, 16 Jul 2005 16:09:36 +0200

> http://www.ietf.org/internet-drafts/draft-ietf-sieve-variables-04.txt

the changes are:

* added :quotewildcard and :quoteregex mofiefiers to SET.
* added this paragraph to security considerations:

        Since values stored by SET exceeding implementation limits are
        silently truncated, it's not appropriate to store large
        structures with security implications in variables.

I did not remove the text about interaction with regex yet.  I feel the
text belongs in the variables draft, so if it is procedurally possible,
I prefer it stays there rather than move into the regex draft.
-- 
Kjetil T.

---

From: Ned Freed <[email-masked]>
Date: Wed, 20 Jul 2005 10:51:42 -0700 (PDT)

> * added :quotewildcard and :quoteregex mofiefiers to SET.

Basic idea looks good, however, a couple of typos have crept in. First, the
syntax at the begining of 4.1 fails to list the two new modifiers. Second, the
plain text draft now says:

4.1.2.1.  Modifier ":quotewildcard"

   Every character with special meaning for :matches ("*", "?" and " is
   prefixed with "

4.1.2.2.  Modifier ":quoteregex"

   Every character with special meaning for :regex (".", "*", "?" etc.)
   is prefixed with "

I assume you meant '"\"' and not '"'. Looks like you need to apply some quoting
to the draft source...

The lack of a full list of regex specials is a bit awkward here, but I
guess I can live with it.

Finally, the section ends with "Using two or more modifiers of the same
precedence is a syntax error.". This isn't quite right: These aren't syntax
errors. How about saying "It is an error to use two or more modifiers of the
same precedence in a single SET operation" or something similar.

> I prefer it stays there rather than move into the regex draft.

I also would like to keep the text here if possible.

				Ned

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 20 Jul 2005 21:15:10 +0200

On Wed, 2005-07-20 at 10:51 -0700, Ned Freed wrote:
> syntax at the beginning of 4.1 fails to list the two new modifiers.

doh!  thanks.

> Second, the plain text draft now says:
> 

doh! it was supposed to say:

        Every character with special meaning for :matches ("*", "?" and
        "\") is prefixed with "\" in the expansion.

> I assume you meant '"\"' and not '"'. Looks like you need to apply some quoting

yeah, I always forget that \ must be written \e in roff.

> guess I can live with it.

there is no ABNF in [REGEX] to refer to, and a full list will be prone
to inaccuracies.  not that I expect any changes to the syntax allowed by
it, but ...

> same precedence in a single SET operation" or something similar.

thanks.  I used "command" rather than "operation" to avoid using new
terminology.

I also downgraded refering to an unknown namespace to just an "error"
rather than a "syntax error".

> I also would like to keep the text here if possible.

I guess we'll decide this in Paris?
-- 
Kjetil T.

---

From: Philip Guenther <[email-masked]>
Date: Wed, 20 Jul 2005 14:54:50 -0700

>On Wed, 2005-07-20 at 10:51 -0700, Ned Freed wrote:
...
>> I assume you meant '"\"' and not '"'. Looks like you need to apply
>> some quoting to the draft source...
>

That would be an argument for moving :quoteregex to the regex draft.  I
don't see any wording that limits support for :quotaregex to when the
regex extension is also required, so even implementations that don't
support regex will need to support :quoteregex.  To me, that means that
this document needs to specify exactly what its behavior is.  (Yeah, you
could make [REGEX] a normative reference, but ... ick.)

(Hmm, what if the regex extension is revised to support not just the
normal ("extended") POSIX regexps but also the old "basic" regexps?  The
quoting rules for the two are different.  (Basic regexps are _not_ a
subset of extended regexps for functionality, though the GNU
implementations have blurred that fact by extending them both.))

Anyway, if :quoteregex isn't moved, then the minimal list of characters
that are escaped by :quoteregex is:

\ . [ ^ $ ( ) { * + ? |

On an unrelated point, the [SIEVE] reference needs to be changed to the
replacement I-D to dodge the "no side-effects in tests" restriction.

Philip Guenther

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 21 Jul 2005 00:28:45 +0200

On Wed, 2005-07-20 at 14:54 -0700, Philip Guenther wrote:
> support regex will need to support :quoteregex.

ouch, you're right.  suggestion:

Modifier ":quoteregex"

        Every character with special meaning for :regex (".", "*", "?"
        etc.) is prefixed with "\" in the expansion.  This modifier is
        only available when the "regex" extension is in effect.

> To me, that means that

:quoteregex specifically works for :regex (and the added sentence above
locks the behavioural description to [REGEX]), if an :basicregex is
introduced, there will be no quoting modifier for it.

> that are escaped by :quoteregex is:

that's just too ugly a duplication of specification.  if we need to add
that, I'd rather split out the :regex bits.

> replacement I-D to dodge the "no side-effects in tests" restriction.

well, 3028bis must be published first, anyway, so I'll update the
reference when its done?
-- 
Kjetil T.

---

From: Ned Freed <[email-masked]>
Date: Wed, 20 Jul 2005 16:00:05 -0700 (PDT)

>         only available when the "regex" extension is in effect.

Seems reasonable.

> well, 3028bis must be published first, anyway, so I'll update the

Might as well update it now as it is likely that the variables draft
will be approved before 3028bis comes out as an RFC. The RFC Editor
understands how to handle such dependencies and will update the
reference for you.

I have one additional suggestion. Thinking about it, I don't like the name
choices here. Specifically, ":quotewildcard" refers to the characters being 
quoted and not the context they are being quoted for, while ":quoteregex"
refers to the context they are being quoted for and not the characters being
quoted. How about changing ":quotewildcard" to ":quotematches" so both
names refer to the context?

				Ned

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 21 Jul 2005 01:52:52 +0200

> understands how to handle such dependencies and will update the

okay, but I don't know what such a reference should look like.  my best
guess:

[SIEVE]
Guenther, P., "Sieve: An Email Filtering Language", Work in Progress

> names refer to the context?

:quotematches was the original suggested name, and it seems logical in
tandem with :quoteregex, but it sounds awfully misleading on its own.

   SET :quotematches "address" "[${1}]"

it's tempting to think that the modifier will only affect the match
variable, IMHO.

the argument to :regex _is_ a "regexp"
the argument to :matches isn't a "match", that's the result, but it
_contains_ wildcards.

one alternative is :quotepattern, but I don't think that's any
clearer. :quotematchespattern is too long...

-- 
Kjetil T.

---

From: Alexey Melnikov <[email-masked]>
Date: Thu, 21 Jul 2005 14:52:28 +0100

Philip Guenther wrote:

>That would be an argument for moving :quoteregex to the regex draft.
>
I agree.

 >I don't see any wording that limits support for :quotaregex to when the

Right, I don't think this should be required for a bare "variables" 
implementation.

 >To me, that means that this document needs to specify exactly what its 
behavior is.  (Yeah, you
 >could make [REGEX] a normative reference, but ... ick.)

To me ":quoteregex" as written says that REGEX is a normative reference.

I want to repeat and maybe rephrase something I've said to Kjetil 
off-list: I don't think the variables draft should depend on documents 
that might take undetermined amount of time to complete.

Alexey

-- 
Alexey Melnikov
__________________________________________
Isode M-Box Message Store developer
http://www.isode.com/products/m-box.html

IETF standard related pages:
http://www.melnikov.ca/mel/devel/Links.html

Personal Home Page: http://www.melnikov.ca
__________________________________________

---

From: Ned Freed <[email-masked]>
Date: Sat, 23 Jul 2005 18:42:26 -0700 (PDT)

> Guenther, P., "Sieve: An Email Filtering Language", Work in Progress

I prefer to have the draft name and date in there, so the ones I have look like
this:

   [I-D.ietf-sieve-3028bis]
              Philip, P. and T. Tim, "Sieve: An Email Filtering
              Language", draft-ietf-sieve-3028bis-04 (work in progress),
              July 2005, <http://www.ietf.org/internet-drafts/
              draft-ietf-sieve-3028bis-04.txt>.

   [I-D.ietf-sieve-variables]
              Homme, K., "Sieve Mail Filtering Language: Variables
              Extension", draft-ietf-sieve-variables-04 (work in
              progress), July 2005, <http://www.ietf.org/
              internet-drafts/draft-ietf-sieve-variables-04.txt>.

In case anyone cares, the way to get this output from xml2rfc is with
something like:

<reference anchor='I-D.ietf-sieve-3028bis'
           target='http://www.ietf.org/internet-drafts/draft-ietf-sieve-3028bis-04.txt'>
<front>
<title>Sieve: An Email Filtering Language</title>
<author initials='P' surname='Philip' fullname='Guenther'>
    <organization>Sendmail, Inc.</organization>
</author>
<author initials='T' surname='Tim' fullname='Showalter'>
    <organization/>
</author>
<date month='July' day='18' year='2005' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-sieve-3028bis-04' />
</reference>

<reference anchor='I-D.ietf-sieve-variables'
           target='http://www.ietf.org/internet-drafts/draft-ietf-sieve-variables-04.txt'>
<front>
<title>Sieve Mail Filtering Language: Variables Extension</title>
<author initials='K' surname='Homme' fullname='Kjetil Homme'>
    <organization>University of Oslo</organization>
</author>
<date month='July' day='15' year='2005' />
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-sieve-variables-04' />
</reference>

On a side note, I'm seeing an increasing tendency to try and avoid referencing
internet-drafts even in cases where such a reference is clearly appropriate,
and I cannot say I like it. While I understand the desire to avoid unnecessary
document dependencies in the RFC Editor queue, IMO the risk of the wrong
reference slipping into the final document far outweighs the delays
dependencies can cause. If there's a problem where documents are blocked
unnecessarily even after dependencies - and I've seen some indications that
such a problem does in fact exist - we need to deal with that problem rather
than gloss over it in this way.

> it's tempting to think that the modifier will only affect the match

Not to me, but since it appears to be to others I'll let this one drop.

				Ned

---

From: Philip Guenther <[email-masked]>
Date: Sat, 23 Jul 2005 20:03:10 -0700

Ned Freed <[email-masked]> writes:
...
...
>I prefer to have the draft name and date in there, so the ones I have
>look like this:
>
>   [I-D.ietf-sieve-3028bis]

Umm, please make that:
   [I-D.ietf-sieve-3028bis]
              Guenther, P. and T. Showalter, "Sieve: An Email Filtering
              Language", draft-ietf-sieve-3028bis-04 (work in progress),
              July 2005, <http://www.ietf.org/internet-drafts/
              draft-ietf-sieve-3028bis-04.txt>.

As for the XML, the surname attribute should have the author's family
name, not his or her personal (given) name.  I would assume that the
fullname attribute should contain both personal and family name, in
whatever order is appropriate for the author's culture, but that's just
a guess.

Philip Guenther

---

From: Ned Freed <[email-masked]>
Date: Sat, 23 Jul 2005 20:34:17 -0700 (PDT)

>               draft-ietf-sieve-3028bis-04.txt>.

Sorry about that; pure carelesness on my part. Fixed now.

> whatever order is appropriate for the author's culture, but that's just

That's correct.

				Ned

---

From: "Mark E. Mallett" <[email-masked]>
Date: Mon, 25 Jul 2005 15:37:45 -0400

[ attaching this comment to a random message in the thread..]

>         only available when the "regex" extension is in effect.

Do we want to more specifically say something like "Ensures that "
[ ...every character with special meaning is prefixed with "\" ... ],
i.e. if a character is already quoted, we don't want another quote
character to be added (otherwise the quoted character would become
unquoted, a literal quote character would be added, etc).

Ditto for :quotewildcard

BTW, I also prefer ":quotematches" to ":quotewildcard" so that the
keyword is more reflective of the match-type name.

mm

---

From: Philip Guenther <[email-masked]>
Date: Mon, 25 Jul 2005 13:42:11 -0700

>unquoted, a literal quote character would be added, etc).

No!  :quotewildcard/:quoteregex must escape any backslash characters
that are already present so that the resulting pattern or regexp
will match them literally.  For example, the wildcard pattern for
matching the literal text
	foo\*bar
is
	foo\\\*bar
and _not_
	foo\*bar

Ergo, something like
	set :quotawildcard "b" text:
	foo\*bar
	.
must have the same result as
	set "b" text:
	foo\\\*bar
	.

(I used a multiline literal to avoid confusing the issue with the
extra round of backslash escaping that quoted-strings under go.)

Philip Guenther

---

From: Ned Freed <[email-masked]>
Date: Mon, 25 Jul 2005 13:56:11 -0700 (PDT)

> character to be added

Absolutely not. We want all characters quoted, including quoting
characters. If you don't do this a literal sequence like "\*" ends
up matching a "*", not "\*" as it should. We want "\*" to become
"\\\*" so it matches "\*".

> (otherwise the quoted character would become

That's not what happens. See above.

				Ned

---

From: "Mark E. Mallett" <[email-masked]>
Date: Mon, 25 Jul 2005 17:25:03 -0400

On Mon, Jul 25, 2005 at 01:42:11PM -0700, Philip Guenther wrote:
> will match them literally.

Right.  Check.  A slip of the brain.

mm