Subject: SIEVE lunch summary

From: Cyrus Daboo <[email-masked]>
Date: Wed, 12 Nov 2003 21:11:02 -0600

Summary of SIEVE Lunch, IETF 58, Minneapolis 17-Nov-2003

Present in person: Cyrus, Rob, Chris, Phillip, Madan, Randy
Present on Jabber: Ned, Alexey, Ken, Arnt

current docs: <http://www.cyrusoft.com/sieve/documents.html>
jabber log: 
<http://www.xmpp.org/ietf-logs/[email-masked]/2003-11-12.txt>

I have summarised comments for each draft in their own section, even though 
the discussion of some of them was interleaved due to jabber lag and some 
of us taking a break to eat.

Discussion on existing drafts:

imapflags: some implementations exist. Should we last call? Not yet, its 
tied to variables very tightly and thus cannot proceed until variables is 
nailed down. Should name be changed because of recent incompatible changes? 
Final suggestion for new name: imap4flags.

vacation: new from address option proposed. Question is how to deal with 
MIME encoding. Suggestion: server MUST support utf-8 encoding of non-ascii 
from parameter, and MAY support encoding in some other appropriate 
character set. Client MAY do MIME encoding itself. Ned wanted alignment 
with Keith Moore's auto-responder draft: resent headers must be tested as 
well as regular to/cc/bcc.

variables: consensus that it is important to complete this asap. Cyrus has 
a new date draft (out soon - see below) that may overlap with date 
variables. Should date items be removed from variables: yes - lets pare 
variables down to the essentials. Date stuff can go in Cyrus' draft if it 
makes sense. Ned has partial draft on date tests - will send to Cyrus. Wait 
to see date draft before deciding exactly what to do.

regex: i18n problems - two solutions (1) ignore for now using 
case-insensitive ascii and octet-stream comparators, (2) wait for Chris 
Newman's comparator draft. Discussion on evil regex tests & utf-8 took 
place. Should we opt to publish as experimental and gloss over i18n issues? 
Rough consensus. Use reference to unicode technical spec in the draft. OK - 
lets rev the current draft and punt the i18n issue to the list.

managesieve: need to clean up - refs to latest sasl work, id nits, 
references etc. URL scheme and sasl profile name need to be changed to 
managesieve. STARTTLS issue with virtual hosts: can be done as extension. 
Ned will re-post his issues to the list. Rob will endeavour to get Tim to 
do a new draft asap, or will take over the job himself.

notify: draft is currently expired. Need to get it updated. Some 
implementations, e.g. sms messages. Rob will again prompt Tim for an update 
or take over himself.

body: Jutta will have an update out shortly. Will do list last call on that.

spamtest: in IESG last call right now.

include: how to deal with missing scripts? Error at runtime seems to be 
consensus. Need way to list global scripts in managesieve - Chris: allowing 
users to see the contents of global scripts is bad - could cause legal 
problems. Include will define managesieve extension for listing available 
global scripts only. It would be useful to have a managesieve extension to 
check a script against a supplied message to see errors or results - Randy 
volunteered to work on a draft.

multiscript: need more review of this document. Punt to list.

editheader: one 'hacked' implementation. Punt to list for further review.

copy: Consensus was to list last call it.

Discussion on new drafts:

Cyrus will submit mime header test draft in the next few days.

Cyrus will submit date test draft in the next few days.

Cyrus has report/trace draft in the works. Proposal: to allow users to turn 
on logging/tracing of actions on filtered messages. Two possible outcomes 
(1) addition of headers with trace info, (2) dsn with trace info sent to 
email address or fileinto'd a specific mailbox. Chris suggested just use 
(2). Hidden headers are bad. Ned has a similar capture extension - actually 
not the same. Any interest in also writing up capture - general 
indifference on that point.

Other issues:

fileinto + auto-create mailbox behaviour: consensus that the default 
behaviour is up to the implementation, but we need specific options to 
explicitly turn on or off auto-create as required by client. Not sure 
whether this was proposed in a draft before - possibly not. Phil will bring 
this to Jutta's attention.

-- 
Cyrus Daboo

---

From: Kjetil Torgrim Homme <[email-masked]>
Date: Thu, 13 Nov 2003 16:45:50 +0100

> to see date draft before deciding exactly what to do.

ACK.  will have time to do a new version of draft next week.

-- 
Kjetil T.