Draft minutes for the Sieve WG meeting in San Diego

[Alexey Melnikov <[e-mail]>]

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.