Re: [sieve] Draft minutes from IETF 77

[Aaron Stone <[e-mail]>]

Thanks, minutes posted:
http://www.ietf.org/proceedings/10mar/minutes/sieve.txt

On Wed, Mar 31, 2010 at 12:58 AM, Alexey Melnikov
<[e-mail]> wrote:
> 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
>>
>
>