SIEVE WG minutes - Anaheim, Mar. 2010

Intro and document status update.

Discussion of EAI:
 o The EAI WG has dropped alternative address forms and downgrading within the
   network.
 o At this point, it is straightforward to put a UTF8 address in a sieve and
   test against a UTF8 address in a message.
 o Clients do need to be aware that this capability is present.
 o Sieve EAI document should address this for ManageSieve, ihave, requires.
 o Chris Newman volunteers to take a look at this in a few months.

Discussion of notary:
 o reviewers are needed, implementers please speak up.

Discussion of notify-sip:
 o needs RAI review, general review, implementation experience.
 o No consensus reached on whether to pursue Experimental or Standards Track.

Discussion of include:
 o needs some feedback, probably ready for last call.

Discussion of imap-sieve:
 o If a message is appended, and a sieve is executed during append, and the
   sieve deletes the message, does another client see the message? A uid is
   generated, what information is retrievable about it?
   Write an implementation considerations note, i.e., describe that an
   implementation can allow immediate expunge after uid allocation; document
   the ramifications of this.
 o A sieve could be used to implement a poor man's submit in an "outbox"
   folder, uh oh.
 o Flags extension assumes message begins with no flags, since the message is
   coming into the system for the first time. But in imap-sieve, the message
   will already have some flags.
 o Consensus that we need implementation experience; publish now,
   expect a rev after some time.

Discussion of external-lists:
 o Issue of URI vs. opaque strings comes up again. Consensus that URIs are
   good, and tag: scheme should be the mandatory-to-implement scheme in the
   base spec.
 o Consensus to discuss most common use case of "tag:<my address book>" (or
   however it ends up being spelled) should be reserved, possibly mandatory.
 o Semantics of http, ldap, etc. could be figured out by extension and/or
   by vendors.
 o Tag URIs may have associated display names for script-generating UIs,
   needs a ManageSieve extension to retrieve from the server. Can use
   ihave to test if a URI is valid, both that the scheme is supported and
   that the URI can be retrieved/queried.
 o Idea of exception handling came up. Noted that this would be a change
   to the language, not simply a new test or action.

Discussion of regex:
 o comparator interactions; in a nutshell: if a comparator is used together
   with the regex, we can normalize the text from the message, but need to
   figure out what to normalize in the regex.
 o For example, ascii-casemap maps the message text to uppercase, but then
   will cause a lowercase regex to fail to match.
 o Regex engines understand case-insensitive as a special parameter, so that
   could be done by the Sieve engine when it calls the regex engine.
 o But regex engines tend not to have a complete set of Unicode comparators,
   e.g. e-grave and E must match case insensitively in certain languages.
 o Possible solution: apply the comparator to the regex based on POSIX regex
   language knowledge of which characters are part of the pattern and which
   are specials.

Discussion of vacation-time, notify-presence, sieve-autoreply:
 o all look great, but need to be added to the charter in order to be WG
   documents.

Discussion of recharter:
 o will add new documents, move others to completed section.