Aaron Stone wrote:
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.
Thanks Aaron. Some additions below:
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.
Please record that Chris Newman has volunteered to look at this in a few
months ;-).
Discussion of notary: reviewers are needed, implementers please speak up.
Discussion of notify-sip: needs RAI review, general review,
implementation experience.
Are we happy to go Experimental with this, or do people prefer Standard
Track?
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?
I think we agreed to add some implementation considerations on this, for
example to describe that an implementation can allow immediate expunge after
UID allocation, and document ramafications of this.
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.
+ I think we agreed to reserve a URI (tag:<something>) for a user's personal
addressbook that everybody should implement.
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.
We briefly talked about an exception handling extension. Probably worth
mentioning here.
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