Subject: 3028bis status

From: Philip Guenther <[email-masked]>
Date: Mon, 10 Jul 2006 05:10:28 -0700

I finally got rev -07 posted in late June.  Changes from rev -06:
  1. Tweak wording of how :matches uses character definition
     of comparator
  2. Add security consideration regarding "redirect" as a notification
     method
  3. fileinto SHOULD reencode; mention IMAP's mUTF-7
  4. en;ascii-casemap is gone; switch back to i;ascii-casemap
  5. Permit non-UTF-8 octet sequences in strings
  6. Sort grammar non-terminals
  7. Syntactically invalid addresses don't match :localpart or :domain
  8. The null return-path has empty address parts
  9. Treat comparator result of "undefined" the same as "no-match"
  10. Envelope sender on redirects is implementation defined
  11. Change IANA registration template

The last open items are:
  a) figuring out exactly what to put in for IANA so they can update all
     the registry entries
  b) what's up with that UTF-8 thing anyway?

For (a), I just dropped by the IANA table and ran the question by them and 
the response was to simply state in the IANA considerations section the 
procedure that they should use to bring the old registrations in line with 
the new registration requirements.  For the new "Description" field, the 
fields will be left empty and we should just poke registrants to submit a 
description via email.  I'll roll in text for that to the next revision.

(b) is the continuation of change #5 above.  That was in response to Ned's 
observation that you need to be able to put text in other character sets 
into strings for things like vacation's :mime option.  E.g., usability may 
demand a site returning vacation responses in some ISO-8859-* charset.

The change I made, based on the mumbling in I heard in the audio recording 
of the meeting, effectively requires sieve implementations to handle such 
scripts by making it part of the grammar of legal scripts.  Scripts are 
still required to use valid UTF-8 in comments, but strings are fair game. 
The description of sieve as respresented in UTF-8 (section 2.1 and 
elsewhere) needs to be dropped or amended.  Other programs that parse 
sieve scripts (<cough> GUIs <cough>) are affected by this of course, but 
they really had to face it before.

Philip Guenther

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Mon, 10 Jul 2006 15:28:59 +0200

>   5. Permit non-UTF-8 octet sequences in strings

in strings yes, but not in scripts.  agreed?  non-UTF-8 must be encoded
in whatever manner is available.

> demand a site returning vacation responses in some ISO-8859-* charset.

sure, but the script doesn't need to contain ISO 8859-* octet values.
-- 
Kjetil T.

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 12 Jul 2006 00:49:41 +0200

> The last open items are:

sorry, I want to add a small open item, a change in section 6,
Extensibility:

   Extensions MUST state how they interact with constraints defined in
   section 2.10, e.g., whether they cancel the implicit keep, and which
   actions they are compatible and incompatible with.
 + An extension MUST NOT change the behavior of the "require" control
 + command.

(CAN NOT would sound better, but that's not in [KEYWORDS] :-)

reference to original suggestion:
http://thread.gmane.org/gmane.ietf.mta-filters/2030/focus=2037

-- 
Kjetil T.

---

From: Ned Freed <[email-masked]>
Date: Tue, 11 Jul 2006 17:34:23 -0700 (PDT)

> http://thread.gmane.org/gmane.ietf.mta-filters/2030/focus=2037

I think this is OK, but do note that require "variables" changes
the semantics of subsequent strings. I don't want to have text that
forbids this or comparable extensions that modify semantics in some way.

				Ned

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Wed, 12 Jul 2006 03:10:51 +0200

> the semantics of subsequent strings.

yes, except for the arguments to "require", see the last sentence in the
introduction:

1.  Introduction

   This is an extension to the Sieve language defined by [SIEVE].  It
   adds support for storing and referencing named data.  The mechanisms
   detailed in this document will only apply to Sieve scripts that
   include a require clause for the "variables" extension.  The require
   clauses themselves are not affected by this extension.

> I don't want to have text that

sorry -- do you want to allow an extension which changes "require"
semantics or not?

-- 
Kjetil T.