document status: 3028bis, body, editheader

To either head-off or prime the conversation for tomorrow...

draft-ietf-sieve-3028bis-06.txt
-------------------------------

The primary issue for the base-spec has been whether it's description
of matching is inline with that description in the collation doc,
draft-newman-i18n-comparator.  I _believe_ the current drafts are
in agreement on the details.  Either confirmation or corrections
from others are needed.

I've made one tweak for the next rev to the wording in section 2.7.1
regarding ':match' and the definition of 'character'; I had overlooked
an off-list comment at the turn of the year.  The paragraph now
reads:
   The ":matches" match type specifies a wildcard match using the
   characters "*" and "?"; the entire value must be matched.  "*"
   matches zero or more characters in the value and "?" matches a single
   character in the value, where the comparator that is used (see 2.7.3)
   defines what a character is.  For example, the comparators "i;octet"
   and "en;ascii-casemap" define a character to be a single octet so "?"
   will always match exactly one octet when one of those comparators is
   in use.  In contrast, the comparator "i;basic;uca=3.1.1;uv=3.2"
   defines a character to be any UTF-8 octet sequence encoding one
   Unicode character and thus "?" may match more than one octet.  "?"
   and "*" may be escaped as "\\?" and "\\*" in strings to match against
   themselves.  The first backslash escapes the second backslash;
   together, they escape the "*".  This is awkward, but it is
   commonplace in several programming languages that use globs and
   regular expressions.


As listed in the doc, the open issues are:
 1) is 'reject' going back in here as a "do the the best you can" action?
 2) should 3028bis recommend/require that fileinto map UTF-8 to mUTF-7
    when working with an IMAP store?

The latter thought actually came about from pondering the description
of fileinto after a suggestion that all the fileinto examples in
spec should use a consistent style of folder naming (e.g., always
using a prefix of "INBOX.").  I felt it better to leave the spec
mixed, if just to avoid the implication that a particular style was
meant to be mandated.  Indeed, I went ahead and inserted the text
in section 4.1:
   Implementations MAY place restrictions on
   folder names; use of an invalid folder name MAY be treated as an
   error or result in delivery to an implementation-defined folder.

Should it say more than this in either direction?  I pondered adding
text about mapping UTF-8 to mUTF-7 and a supporting example (the
the open issues entry), but it couldn't find a wording that didn't
feel like one step too far beyond the scope of sieve.


draft-ietf-sieve-body-03.txt
----------------------------

This had been blocked pending the settling of the comparator/charset
wording in the base spec.  Again, I believe it to be in agreement
but confirmation is needed.  At that point, this can be put into
the submission queue behind the 3028bis.


draft-ietf-sieve-editheader-04.txt
----------------------------------

This has been reading for submission for a while; I think the
write-up is even done.  This last rev was basically editorial.



Philip Guenther