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.