Re: [sieve] Draft minutes from IETF 77

[Alexey Melnikov <[e-mail]>]

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
>  
>