Chairs apologies for being so late with this...
3028bis (base spec): blocked on Cullen's DISCUSS. Need to try to catch Cullen
during the IETF week to discuss
his issue.
Notify Mailto draft:
[14:18:01] <cyrus_daboo> discussion of auto-submitted in notify mailto and
whether we need strong text about preventing loops.
[14:20:22] <aaronstone> (agree that notification messages should not trigger
notifications)
Editheader:
[14:28:22] <cyrus_daboo> new draft addressing issues: some comments from Ned
were addressed.
[14:28:45] <cyrus_daboo> We has a Sieve lunch yesterday. From the lunch we came
up with some better restrictions
on deletion of "trace" headers
[14:29:53] <aaronstone> so we'd write a discrete whitelist of headers?
[14:29:59] <cyrus_daboo> Issue as to whether there is a list of specific
headers that can always be changed/removed.
[14:31:10] <cyrus_daboo> X- headers should not be specifically called out.
[14:32:52] <cyrus_daboo> Chris: some headers (general class) should be editable.
[14:34:28] <cyrus_daboo> So, must permit changes to Subject, security
consideration about changes to "trace" headers,
then implementation note about being wise to allow changing classification
headers.
[14:35:38] <cyrus_daboo> Barry wants clarification of slide bullet points.
[14:36:06] <cyrus_daboo> Is deletion of received forbidden no matter what local
policy is?
[14:36:08] <cyrus_daboo> Yes.
[14:36:58] <cyrus_daboo> Randy wants more detail on the language for
implementation note.
Not happy with the current proposal.
[14:37:48] <aaronstone> MUST allow: Subject. MUST NOT allow: Received. SHOULD
allow: everything else, because
we like editing headers. MAY disallow: anything else for site policy.
[14:38:59] <cyrus_daboo> Kurt - aren't there other reasons (e.g. privacy)?
[14:41:29] <cyrus_daboo> Part of the problem is the precision in noting which
headers are trace or not.
[14:43:19] <randy> 2821/2822 identify trace headers: received and return-path
[14:44:06] <aaronstone> oh right - return-path. that'd be an evil one to modify.
[14:46:07] <cyrus_daboo> Jeff: is it only up to local policy to define this or
can the Sieve implementation
dictate that policy?
[14:46:16] <guenther> randy: it's not a closed set
[14:47:41] <cyrus_daboo> Pete: policy may dictate that nothing can be changed
so why not leave it all to local policy.
[14:47:57] <aaronstone> If the script cannot depend on at least one field, then
it kills the poor-man's variables
possibility... so what?
Notify:
[14:49:47] <cyrus_daboo> Document is ready for IESG
Reject/refuse:
[14:50:56] <barryleiba(_at_)gmail(_dot_)com> Aaron Stone will co-edit the
document and move it along.
[14:51:10] <barryleiba(_at_)gmail(_dot_)com> Two changes needed, per IETF67
consensus:
[14:51:23] <barryleiba(_at_)gmail(_dot_)com> 1. two actions: reject, ereject.
[14:51:32] <barryleiba(_at_)gmail(_dot_)com> 2. add more details on MDN/DSSN
[14:52:03] <aaronstone> I have my asbestos Inbox filter turned on, so I'm ready
for the flood of comments
from everyone about what else this should go into refuse-reject :-)
MIME loops:
[14:52:31] <cyrus_daboo> Remember its not just MIME loops anymore - a whole
bunch of other MIME related things
[14:53:04] <cyrus_daboo> biggest change was pulling extract_text action out of
the notify
[14:53:15] <cyrus_daboo> IANA considerations greatly expanded
[14:53:21] <cyrus_daboo> other minor tweaks
[14:54:05] <cyrus_daboo> discussion of extract_text: suggestion to extend body
to do the same
[14:56:46] <cyrus_daboo> issue: does text about how to find the first text part
need to be more detailed?
[14:58:22] <cyrus_daboo> Will do last call and comments on those can be
included then.
[14:59:03] <cyrus_daboo> extract_text returns empty string if not used in the
context of an iterator
[14:59:23] <cyrus_daboo> Philip wants an error instead
[14:59:48] <cyrus_daboo> Jeff: compile time error not runtime
[15:00:03] <cyrus_daboo> Alexey: boundary is somewhat grey between runtime and
compile time errors
[15:00:55] <cyrus_daboo> Jeff: do the "find the first part" logic as the logic
of the loop itself
Ned's Date: ready for last call. Alexey will shepherd.
Ned's iHave: more review please
Ned's Notary: new drafts - more review please.
Alexey's IMAP METADATA:
[15:06:04] <cyrus_daboo> Who is planning on implementing this?
[15:07:03] <cyrus_daboo> Extension includes tests for existence and :create
option for fileinto.
[15:07:33] <cyrus_daboo> Open issue: server annotations
[15:07:44] <cyrus_daboo> List-extended?
[15:08:20] <cyrus_daboo> Probably not now can be done as another extension later
Alexey's External Lists:
[15:09:43] <cyrus_daboo> Now allows URLs as well as user tokens as list
identifiers
[15:11:02] <cyrus_daboo> issues:
[15:11:14] <cyrus_daboo> how to handle server outage? runtime error?
[15:11:30] <aaronstone> clearly we need a try/catch at runtime.
[15:13:13] <aaronstone> i'm just reading this for the first time, and yes, an
entire mailing list could be implemented.
If you could write to the external list from sieve, then you can even handle
the maintenance addresses like
list-subscribe, list-remove.
[15:14:23] <aaronstone> What is a "real mailing list"? It's a program written
in some language that re-sends messages
to a list of addresses.
[15:21:23] <aaronstone> on the issue of LDAP result paging, i brought this up
in prague: we don't want the ":list foo"
to be evaluated strictly and result in a huge stringlist. rather, we would
want the action to accept the :list foo
and lazy evaluate it inside the action handler.
[15:21:24] <jhutz> sure, but is it really necessary to extend Sieve to the
point where it can be used to write mailing
list software? There are plenty of mailing list pakages out there today, none
of which are written in sieve.
[15:21:41] <barryleiba(_at_)gmail(_dot_)com> It's not just for mailing lists.
[15:21:57] <barryleiba(_at_)gmail(_dot_)com> There are lots of good reasons a
Sieve script should be able to access my "address book".
[15:22:10] <barryleiba(_at_)gmail(_dot_)com> Now, where might my address book
reside?
[15:22:46] <jhutz> Barry, I think some of the other use cases you and Philip
have presented are compelling.
I just don't think "implement mailing lists" is.
[15:23:02] <jhutz> Actually, I'm curious as to where your address book resides.
[15:24:26] <aaronstone> I'm tempted to write a mailing list manager in Sieve
now just to see what it looks like.
It would need basically every major extension - editheader, date tests,
variables, etc. per the ietf "running code"
mantra, let's see what it looks like before we pass judgment. and yes, i do
think its the most pedantic use case.
As barry points out, there are lots of very reasonable use cases that are not
crazy at all.
[15:29:12] <jhutz> I don't think a sieve-based mailing list manager would be
very useful operationally. However,
it certainly would excercise a lot of the language features and extensions,
and that alone might make it a worthwhile
endeavor.
[15:29:43] <randy> (You don't really need editheader if you want to do an
smtp-expn style list)
[15:30:02] <barryleiba(_at_)gmail(_dot_)com> I agree with Jeff... While I can
come up with some limited good uses of Sieve to fan out
messages, I don't think we should design Sieve to support mailing list usage
in general.
Barry's IMAP Sieve:
[15:36:38] <aaronstone> would we be comfortable lifting the restriction against
running multiple scripts if there were
some document explaining what happens? I recall this being something that has
been discussed before and several
implementations _do_ currently use more than one script run at different
stages of message delivery.
[15:37:43] <aaronstone> this is good -- it gives a transition path away from
ManageSieve towards script management
via metadata.
[15:38:07] <jhutz> Where is that restriction expressed?
[15:38:36] <aaronstone> Barry just said it out loud, that it's in the new
IMAP-Sieve draft.
[15:40:01] <jhutz> ... and now I can't find the draft :-(
[15:40:38] <aaronstone>
http://www.ietf.org/internet-drafts/draft-ietf-lemonade-imap-sieve-03.txt
[15:49:29] <randy> My point is that if clients are generating the scripts, if
there is only one script per mailbox,
then clients will stomp all over each others' scripts
[15:49:36] <aaronstone> ok, sounds good, and an important point that we don't
cause the lemonade people to throttle us.
[15:50:03] <randy> If we allow /client/<client-id> as an extra metadata entry
under /IMAPSieve/Script, then each client
can add its own script
[15:50:25] <randy> These subsequent scripts would be prohibited from doing
operations such as Reject and FileInto
[15:51:09] <guenther> 1) if you have two phones, do they use the same client-id
or different ones?
[15:53:43] <guenther> 2) if different, and one died, what would delete the
scripts for the dead client?
[15:53:52] <randy> Depends on how the phone's client is written. Assuming it
creates a script based on local user
configuration, I'd say each client needs its own id
[15:55:13] <randy> Don't know how best to reap scripts for dead clients, but
there are possible solutions based
on age of last change and so forth
[15:55:59] <randy> But without per-client scripts, it's unclear how these
scripts get created or used. It seems
to be a per-user thing that can't be per-client
[15:56:10] <randy> Any client will stomp on the script for others
Other business:
Q: Sieve face-to-face interop in Greece this fall (hosted by University of
Athens)?
A: Mostly silence in response
Q: Is online interop better?
A: People are more entusiastic about that, but still not clear how much support
this idea has.
[15:53:32] <aaronstone> I'd definitely be at an online interop, and possibly at
an in person.
[15:54:03] <aaronstone> I think this actually grows into a question of creating
a basic interop script test suite.
[15:54:13] <aaronstone> oh, that's what Barry and Arnt have talked about.
[15:54:22] <aaronstone> huge +1 from me.