[sieve] Draft minutes from IETF 77

[Aaron Stone <[e-mail]>]

>From chat logs here:
http://www.ietf.org/jabber/logs/sieve/2010-03-24.txt
Please let me know if i missed or misunderstood anything.


SIEVE WG minutes - Anaheim, Mar. 2010

Intro and document status update.

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

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

Discussion of notify-sip: needs RAI review, general review,
implementation experience.

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

Discussion of imap-sieve: 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? A sieve could be used to implement a poor
man's submit in an "outbox" folder, uh oh. 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. Consensus that we need implementation experience;
publish now, expect a rev after some time.

Discussion of external-lists: 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. Semantics of http,
ldap, etc. could be figured out by extension and/or by vendors. 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.

Discussion of regex: 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. For example, ascii-casemap maps the message text to uppercase,
but then will cause a lowercase regex to fail to match. Regex engines
understand case-insensitive as a special parameter, so that could be
done by the Sieve engine when it calls the regex engine. 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.
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: all
look great, but need to be added to the charter in order to be WG
documents.

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


Cheers,
Aaron