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