[Top] [All Lists]

Draft minutes for the Sieve WG meeting in San Diego

2006-12-02 11:46:42

Disclaimer: I've created the minutes from the Jabber logs, filling in missing pieces from my [failing] memory. I haven't listened to the audio recording.
So, please report anything missing or inaccurate.

Thanks to Chris Newman for scribing in Jabber.

The meeting has started with chairs reviewing status of WG documents. 6 specs are in RFC editor queue blocked on 3028bis. IETF LC for 3028bis has completed, some comments from Eric Rescorla (Security Area review) were received. There is also an ongoing discussion on an extension for escaping arbitrary octets in Sieve scripts.

1). Is the base Sieve language Turing complete?
Eric Rescorla's review said that loops can occur in the mail system.
Does that count?

Matthew (remotely): Standards/techniques already limit loops. Don't think we should pretend those don't exist. Ned: need to mention redirect can cause mail loops, but don't want to go into a lot of detail about it. Philip/Ned: Our intention of Sieve is that it is not Turing complete. Although it's may be possible to create something Turing complete with certain types of mail loops, that does not change the intention. Agreement that the intention should be clearly stated in the 3028bis document.

Next topic: Sieve Reject/Refuse

Had design team (Randy, Philip, Chris and Alexey) discussion; Alexey summarizes outcome: there are use cases where you want to reject over protocol if at all possible and lose UTF-8 if necessary, and there are use cases where preservation of UTF-8 is paramount. Want to go back to two actions: original reject which does MDNs and preserves UTF-8, the other is ereject which tries to reject over protocol.

Randy argued that having 2 separate actions is less confusing to users then having an action and a parameter that modifies the behavior.
Room consensus two go with two separate actions.

Matthew: I think having the reject work the way it currently does (as in RFC) is a horrible idea. Any objections to having "reject" do the new way (over protocol), and "oreject" do the old way? (OldReject) Chris doesn't want the behavior of existing reject change, due to deployments in certain regions, like Japan. Japanese customers use non-ASCII and they wouldn't like behavior change.
Chris also suggests to provide automatic migration from old reject.
Randy: concerned that users read MDNs but not DSNs or protocol rejects. Uncomfortable changing the behavior of the existing command. Matthew: I still want to change the default, common behavior. That was the main point of the entire effort of creating the new draft. Chris: When it comes to changing the behavior of an existing standard, there must be rough consensus to change behavior; absent consensus the published behavior should stand.

Poll: who currently implement Sieve reject (as described in RFC 3028):
8 hands raised
Poll: how many can change there implementations to do protocol level refusal: The same 8 hands raised. However this still doesn't guaranty that there would be no bounce.

Chairs asked local and remote participants to hum for 3 questions:
Q1: Keep reject as MDN.
Q2: New action for protocol level rejection or MDN
Q3: (optional) Allow reject to do protocol level rejection if ASCII only text is supplied.

Q1: who would disagree with keeping reject as is?
(Several people hummed in agreement. Matthew disagreed in Jabber. No people disagreed in the room)
Room rough consensus for keeping reject action as MDN.

Q2: Any hums against adding a new action for protocol level reject?
Nobody in the room objected to adding a new action for "protocol level rejection or MDN".
Room rough consensus for adding the new action.

Q3: Allow implementations to do protocol level "reject" if text doesn't require downgrade? (Wishy-washy in favor, no opposed. The hum was not as strong as on the first 2 questions) Room rough consensus for allowing the reject action to do protocol level rejection (MAY do protocol level rejection).

Alexey: Matthew and I will do a new update by December.

Next topic: "MIME Loops" document. New revision got published: draft-ietf-sieve-mime-loop-01.txt.
Major changes: header/address/exists tests now has a new :mime parameter.
Things to be done to the document: fixed various errors in examples, better explanation of nesting, IANA registration for Original-* header fields,

Q: Should we require that implementations verify that replaced/enclosed parts are valid 2822/Mime?
Ned: The vacation document doesn't prescribe this for "vacation :mime".
A: Leave as a quality of implementation issue.

Chris (regarding traversing MIME structure): implementation can descend into parts they understand, but MUST descend into multipart/* and message/rfc822, and SHOULD NOT descend into text/rfc822-headers.

Chris: it would be nice to be able to parse DSN reports (message/delivery-status) in Sieve. A: DSN information is located in the body of message/delivery-status, and thus this is not a task of the MIME loops document. A separate Sieve extension can be written to address this.

Next topic: Sieve notify extension

Open issues:
1) :importance - is it a transport thing (i.e. to be used to send the notification faster/slower), or just a flag on the notification?

Barry: can be either, depending on a mechanism

2) Mandatory to implement notification method? Will IESG require one?

The subsequent discussion lead the room to the question about why the notification method can be optional.

Barry: I think IBM implementation is guilty, as we had a default mechanism that would do different things depending on presence.

Subsequent discussion resulted in the feeling that nobody actually likes having a default notification method, because it can change when replacing one Sieve implementation with another. This will surprise users.

Consensus: make the :method parameter to notify action required

3) Can default behavior in the absence of the :message parameter be notification mechanism specific?

Room consensus: Yes, implementations already do that, besides the formatting of :message is mechanism specific anyway.

4) Restrict :priority to just three levels?

A: We've previously agreed to have 3 numeric levels, let's not change the decision. More levels can be added if needed.

5) IANA registry for :options needs some discussion.

Room consensus: Still no desire to do IANA registration, as there are no options registered so far.

6) Changing name of the extension

There were some significant changes between the current draft and the one deployed by Sendmail and CMU. Ned: I think we can detect which version is used by parsing parameters to the Notify action Philip: The principle for Sieve extensions is that _if_ an implementation accepts the 'require's that the script contains, _then_ the script will be executed with the expected behavior. That rule basically means that we can't use the same name for the revision of notify.

Room consensus to change the name of the extension.

7) The room also discussed how loop detection should be done for notify.

Philip has volunteered to work on text for loop detection for notify.
Barry wants a loop prevention mechanism that works across notification mechanisms in some way. He will try to work on text.

Alexey: Barry and I will do a new update by December.

Other topics:
RegEx - lack of progress. If no more progress by this meeting, it should be dropped. So we're thinking about dropping it from our charter
Aaron: What is holding up the RegEx?
Philip: RegEx needs careful thinking about how regular expressions interact with comparators

Chairs: When we update the milestones, we will put the RegEx as the very last deliverable, maybe it will get done.

Sieve Date extension
Ned: one comment was to change the part parameter from positional to tagged. nobody else in favor, will drop that issue. New draft adds one more test type to get back an RFC822 format.

ManageSIEVE - no update

IMAP Sieve - no update
Lemonade WG depends on it.
Barry - work on IMAP Sieve and Sieve environment.
Alexey: Ned is also looking at doing Sieve environment extension and ihave extension, so Barry and Ned need to coordinate.

Discussion of standards dependency and issue on taking Sieve base and extensions to Draft Standard. Proposal to move 2821/2822 to Draft, perhaps on a variance because they're better than 821/822 which are Full Standards.

<Prev in Thread] Current Thread [Next in Thread>
  • Draft minutes for the Sieve WG meeting in San Diego, Alexey Melnikov <=