[Top] [All Lists]

Sieve WG Chicago meeting minutes

2007-08-29 11:42:33
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 


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

[14:49:47] <cyrus_daboo> Document is ready for IESG

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

[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 
[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 
[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
[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>
[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 
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.
<Prev in Thread] Current Thread [Next in Thread>
  • Sieve WG Chicago meeting minutes, Alexey Melnikov <=