Subject: draft-ietf-sieve-3028bis-08.txt

From: Philip Guenther <[email-masked]>
Date: Tue, 25 Jul 2006 07:46:34 -0700

I've submitted draft-ietf-sieve-3028bis-08, whose change log reads:

   Changes from draft-ietf-sieve-3028bis-07.txt
    1. Improve description in the extension registrations
    2. Give IANA directions on how to massage existing registrations
       into the new form
    3. Added "Changes from RFC 3028" section
    4. Updated pages numbers in table of contents
    5. Permit non-UTF-8 octet sequences in comments
    6. It's an error to use conflicting or repeated tagged and optional
       arguments
    7. Update description of script encoding

That last item consisted of two larger changes plus some minor
tweaks, the large changes being:

1) in section 2.1, replace
----
   The language is represented in UTF-8, as specified in [UTF-8].

   Tokens in the US-ASCII range are considered case-insensitive.
----
   with 
----
   With the exceptions of strings and comments, the language is limited
   to US-ASCII characters.  Strings and comments may contain octets
   outside the US-ASCII range.  Specifically, they will normally be in
   UTF-8, as specified in [UTF-8].  NUL (US-ASCII 0) is never permitted
   in scripts, while CR and LF can only appear as the CRLF line ending.

   Tokens other than strings are considered case-insensitive.
----

2) in section 2.4.2 ("Strings"), add the following paragraph:
----
   As messages header data is converted to [UTF-8] for comparison (see
   section 2.7.2), most strings will use the UTF-8 encoding.  However,
   implementations MUST accept all strings that match the grammar in
   section 8.  The ability to use non-UTF-8 encoded strings matches
   existing practice and has proven to be useful both in tests for
   invalid data and in arguments containing raw MIME parts for extension
   actions that generate outgoing messages.
----
   That appears directly after the paragraph that starts "Non-printing
   characters..."

   (And yes, I've already changed "As messages header" to "As message
   header" for the next rev.  It's amazing how many times you can
   look right through a typo.)

Any comments on the above or the full text or do people feel this
is ready to be submitted to the IESG?

Philip Guenther

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Tue, 25 Jul 2006 18:17:42 +0200

>    Tokens other than strings are considered case-insensitive.

"normally" isn't good if you can't know if your script is normal or not.
I suggest you rephrase it as "Strings and comments may sometimes have a
different encoding than UTF-8, so for consistent behaviour across
implementations, it is recommended to avoid non US-ASCII".  (yes, tongue
is firmly in cheek.)

speaking of CRLF, I'd like a clarification of multi-line strings in
section 2.4.2 (some of its text duplicates the above, I'm not sure
that's good).  something like:

   Any CRLF before the final period are considered part of the string.

to make it a little more clear that implementations should NOT change
the CRLF into its local line delimiter sequence.

> is ready to be submitted to the IESG?

I don't like this at all.  keep it simple, force the scripts to be
encoded in UTF-8, it saves us a lot of grief and edge cases.  to be able
to express arbitrary octets, add an extension for \x -- I think someone
volunteered to write text?  if not, I'll be happy to.  note that the
contents of a string during execution is potentially arbitrary octets
(even NUL, as made clear in 2.7.2).

I'm afraid I didn't save the Jabber log from IETF-66, did anyone else?
it would be useful to post it here.
-- 
Kjetil T.

---

From: Michael Haardt <[email-masked]>
Date: Wed, 26 Jul 2006 12:41:00 +0200

> the CRLF into its local line delimiter sequence.

I second that.  Although obvious, once you think about it, it might
nevertheless save implementors some time.  CRLF line breaks in string
literals cause the string to contain CRLF, nothing else.

> (even NUL, as made clear in 2.7.2).

If a script contains arbitrary octets in string literals, UTF-8 aware text
processing tools will fail in decoding UTF-8.  Additionally, although
breaking a lot that way, Sieve still couldn't match NUL characters,
so we need an extension for matching truely arbitrary octets anyway.

I am not so sure something like \x is a good idea.  How should
a comparator working on UTF-8 characters (multibyte sequences) act
when it hits a string containing a code violation? How should "*" and
"?" work in that case? Right now, that can't happen.  Oops.  Actually,
it can, when "?"  matches a single octet of a multibyte sequence, using
an octet-comparator, and you build a new string from the matched part.

In past discussions, we spoke of a new match that could take a hex
string as argument, and agreed the first person needing it badly will
write the draft.  As well as matching raw headers, nobody did. :)

Michael