Subject: Dallas meeting notes

From: Alexey Melnikov <[email-masked]>
Date: Thu, 06 Apr 2006 11:51:14 +0100

Hi folks,
Here are the draft notes from the Dallas meeting. Please send me any 
corrections.

(Thanks to Chris Newman for scribing in Jabber. I’ve made some editorial 
changes to the jabber log, in particular I’ve
reordered some logs so that discussion appears right after the
corresponding open issue)

============
Agenda slide

Cyrus: priority is base spec revision

Chairs: Any other issues for agenda?

Moving on to WG status slide

Approved: vacation, variables, relational update. All documents blocked
on 3028bis, which in its turn blocked on comparators.

Completed: spamtest update, IMAP flags, edit header. Will be sent to our
new AD (Lisa) shortly.

Minor issues: body (interaction with reject?)*//*

Others: 3028bis, subaddress, date, loop, notifications, refuse, regex

Cyrus presents spamtest-bis draft.

Review comment: should we keep both scales (1-10 and percentage) or have
only one scale?

Alexey: want to keep both, as spamtestplus is not yet deployed. Will
re-evaluate when moving document to Draft standard,

Ned: we've implemented the percentage model

Date draft status: no progress, as Ned didn’t have time to update it.

Ned: two issues: need to add day of week, use modified julian day. Will
add both.

Now is a good time to send any additional issues to Ned.

Ned: hopes to have new revision of spec by March 31st.

Alexey: Should this be a WG draft? Personally in favor.

Ken talks about subaddress draft.

Last remaining issue: how flexible should address parsing/splitting be?

Ken: need a concrete example

Alexey: will email Ken with example

Ned: fine line between subaddress type stuff, but no for VERP or other
encoding mechanisms

Ned: want to let it work with any local subaddressing conventions (not
just prefix/suffix), no matter how obscure.

Chris: EAI WG will use punycode form of local parts, subaddress can help
with decoding them.

Ken talks about regexp draft.

Open issues: what to do with localization/internationalization?

Ken: the document needs work, in particular some feedback from Ned.

The milestone for regex will be pushed out.

Alexey talks about reject/refuse draft.

Open issues: how to deal with non-ASCII reason when not possible via SMTP.

Cyrus: EAI WG isn't going to i18n SMTP error messages in present plan

Alexey: can revive old draft for SMTP i18n error messages

Ned/Chris: good idea.

Cyrus: case where this will fail if move script from one environment to
another which changes the

nature of the refuse handling.

Alexey: can't know in advance if rejection text contains non-ASCII – the
script might be using variables.

Open issue 2: reject interaction with editheader? Edit header requires
bounce of edited text. Is that too strong?

Ned: this makes us nervous. Perhaps we should do the opposite.

Barry: concur

Straw poll: who is in favor of changing editheader to say that reject
SHOULD/MUST return original?

Rough consensus to return original message

Question: SHOULD vs. MUST?

Barry: would rather have MUST. Generally doesn't like SHOULD.

Dave Cridland (remotely): concur

Barry: should note about making changes via editheader and then bouncing
due to match caused by the change.

Open issue 3: vacation text on i18n implies that might be useful to add
:mime tag for case where DSN/MDN is generated.

Question: Good idea, bad idea, don't care?

Room: silence

Ned: Easy to implement, but hasn't seen much use of :mime tag in vacation.

Alexey: Will not add :mime to reject until somebody really wants it.
This can be added as an extension later on anyway.

Alexey: will post message to mailing list asking for feedback.

Tony talks about MIME Loops draft.

Open issue 1: how to deal with nested loops?

Open issue 2: shorthand to get to MIME type/subtype was a suggestion.

Cyrus: would like examples other than spam/virus

Cyrus: ability to extract part for notification -- e.g. to extract
calendar part

Ned: has usual objection to the way MIME tests are done. But the draft
does not have way to do address tests or MIME header existence test.

Philip (remotely): a mimeparameter test would be useful in some cases too

Ned: do like way draft separates do the test from ability to modify the
body (the latter might be difficult to implement for Sun).

Ned: agrees about mime parameter

Alexey/Barry talk about Sieve Notifications Draft

Open issue 1: need way to extract message body, as body extension
specifically disallows extraction with variables extension.

Cyrus: overlaps with loop comment about extracting body part

Barry: might want way to extract first text part

Ned: extraction of textual data from message is very sticky. Issue with
using notifications to extract information from classified to
unclassified net.

Open issue 2: should we push the question of error recover to the
individual methods?

Alexey: should add section describing requirements on notification
methods. That would be a requirement for that section.

Barry: not a bad idea

No objection from the room

Open issue 3: priority vs. importance?

Philip: so it's a transport thing, not a contents thing?

Barry: Field means how important is it that the notification be
delivered and be delivered quicker or slower / more or less intrusive

Barry: how we change the name and specify what to do with it?

Alexey: also an issue with how many levels.

Barry: thinks high / medium / low is sufficient.

Ned: thinks 3 priorities is fine. Cautionary tale about X.400 priorities
and broken timeouts for high priority messages.

Open issue 4: script can generate multiple notifications. Add text about
suppression of identical notifications, or is this too mechanism specific?

Alexey: I now think this is too mechanism specific

Open issue 5: should there be mandatory to implement (mailto:)? We say
there must be a default mechanism.

Barry: believes we should not mandate a specific mechanism.

Barry: asks Lisa directly.

Ned: issues with notification with entire message attached causing loops
and bouncing. Need cautionary text: don't use this as a crappy form of
redirect.

Cyrus: do you want message extraction as another option?

Ned: conflicting requirements from customers. Some want it disabled
forever. Others insist on the feature.

Barry: On redirect: keeping a semantic difference between redirect and
notify.

Ned: agrees. there are times when redirect is the wrong tool and notify
should be used.

Alexey: anything for the base spec about redirect/notify?

Barry: perhaps warning to avoid misuse of redirect. something brief.

Moving on to the second slide on Sieve Notifications. The slide contains
authors "todo" list:

ToDo 1: need to bring back and update old example using denotify. We are
not reviving denotify, but examples are useful.

ToDo 2: change tagged :method to the positional parameter. Already broke
backwards compatibility so might as well do this.

Philip: can we please change the extension name in this case.

Barry: yes.

ToDo 3: Add :from to the "notify" action

Barry talks about mailto notification draft:

Barry: got really little comment on the list

Barry: will wait for notify 03 before iterating mailto and others

Cyrus presents 3028bis issues:

3028bis-06 version has been released (also -08 version of comparator draft)

Cyrus: anyone read both drafts and interaction between the two?

Alexey: not enough people in room have reviewed.

Barry: will read and comment on the list.

Open issues with base spec:

Open issue 1: merge reject back in with textual changes to permit MDNs
and protocol level rejection?

Cyrus: suggest we don't do that.

Open issue 2: map UTF-8 to mUTF-7 when working with an IMAP store?

Philip: for bullet 2: any comments on Michael Haardt's suggested text?
continue on list...

Ned: doesn't think requirement in this area is appropriate as mUTF-7 is
only a "convention" in the IMAP base spec. However it's important to
point out mUTF-7 as a convention.

Ned: SHOULD map to appropriate naming scheme. BTW, the one for IMAP is
mUTF-7.

Alexey: Ned's agreeing with what Alexey posted on mailing list.

Open issue 3: IANA template not precisely defined.

Cyrus: bringing up base spec on his display

Cyrus: current registration has "capability name", "capability keyword",
"capability arguments"

Cyrus: odd because a capability might be defining a test, new
parameters, etc.

Philip: the published extensions in other RFCs ignore the "arguments"
field and always set the name and keyword to the same

Philip: we've always set name == keyword

Barry: Capability Name is what we call it. Capability keyword is what we
put in requires

Barry: not sure what "capability arguments" is.

Alexey: arguments doesn't make sense with multiple commands, etc.

Ned: suggests list of new tests and actions in place of capability arguments

Chris: suggest just removing arguments

Cyrus: we may need to register language tokens to avoid collisions

Dave Cridland: Something for Cyrus: Actions can be claimed by two
capabilities. Generally when they're backwards compatible updates.

Ned: just leave this to the editor

Ned: as long as you're backed up by an RFC which says what to do IANA
will do it. So we can just clean up the registry.

Alexey talks about ManageSIEVE protocol draft:

Make this a WG item?

Seems like Lemonade needs it, even thought it is still not clear what
state of this draft is in lemonade WG. But getting close for it to be
done and needs more reviews.

Alexey: volunteered Barry to review.

Barry: wants to add this to the WG.

Ned: will need charter revision to do this.

Ned: agrees OK to add this to charter.

Lisa: managesieve sounds pretty useful.

Cyrus: charter updates need to go through full IESG?

Alexey: need to push base spec before adding Manage Sieve to the charter.

Q: How many people will implement manage sieve?

Dave Cridland: I've vaguely planned on doing the ACAP Sieve stuff at
some point, just because I can.

A: one wavy hand in room + Dave Cridland, Alexey.

Q: How many people in the room do something else?

A: one implementation (Sun’s implementation store pieces of Sieve
scripts in LDAP)

Ned: fine for per-user, but not fine when scope broader.

Ned: we would just put manage Sieve front-end on LDAP.

Philip: we store scripts in LDAP with a provided GUI

Alexandros Vellis (remotely): I find ManageSieve essential in that it
provides a) capability keywords b) syntax checking

Rob: Regardless of what lemonade ends up doing, this is probably
desirable, I'm not convinced that extensions to managesieve are the
right thing for lemonade's problems though

Cyrus: show of hands for manage sieve as WG item?

A couple of hands and nobody opposed.

Cyrus: will add date as well at the same time.

Alexey: will push out base first, however.

Randy: The ACAP Sieve dataset provided syntax checking too ;-)

Cyrus talks about his "include" draft:

Open issue 1: are variables global to all scripts or local to script?

Cyrus: punting on issue, no comments on scoping in draft.

Cyrus: is "implementation dependent" OK?

Poll: who interested in include?

Two hands

Ned: given our methodology to store Sieve, we can't implement include in
a meaningful way. Likes idea, but we can't get there.

Chris: Store Sieve scripts in mailbox annotations, define URL for
ANNOTATEMORE :-).

Open issue 2: interaction with variables (variable scope)

Open issue 3: scope of require statements

Jeffrey: all scripts are self contained, so they must have all necessary
require statements just for themselves.

Philip: an included script can defined a set of "functions" (currently
there is no such construct in Sieve)

Jeffrey: useful case for something that's not a useful sieve script in
it's own right. But it doesn't have to fail the require test.

Barry: each script needs to be syntactically valid on its own.

Barry: don't require "require" for the outer script when including the
inner script.

<Many>: no need for the included (inner) script to include require from
the including (outer) script or vice versa

Dave Cridland: Could one use:

require "include:some-file"

To ensure that the requires are checkable easily?

Cyrus: what do we want to do with this draft now?

Cyrus: may be more interest in near future than we have right now.

Cyrus: propose keeping this as individual submission for now, but see
where we are in a couple months.

[room: nodding heads]

Next topic: exception handling &optional "require"

Q: do we need some form of exception handling in SIEVE?

Q: should there be a test for the presence of extensions?

Alexey: if reject action fails because UTF-8 is not allowed, do we want
to catch that and do something else?

Barry: we had discussion about environment tests.

Ned: Yes, we had agreed Barry would write draft to add environment tests.

Barry: yes there should be test for presence of tests.

Jeffrey: thinks that the two bullets are very different issues.

Jeffrey: the problem with test for presence of extension is they add new
syntax to language.

Ned: No. Key design feature of Sieve is that extensions don't change syntax.

Alexey: … at least so far

Jeffrey: not clear we need exception handling. We have exception
handling today: if there's a runtime error processing stops.

Ned: hard for our implementation, but still in favor of proposal for
feature tests. But exception handling makes Ned very nervous, would
prefer we avoid that.

Cyrus: alternative to exception handling: would like error reporting
(e.g. if scripts fails, send notification to …)

Ned: that's a very limited form of exception handling.

Jeffrey: if sufficiently limited, it's OK

Barry: is that really an interoperability issue? Or can we leave that to
the implementation. Do we really have to standardize that?

Philip: who gets to control error reporting – the admin or the user?

Ned: do you just send an error to the user?

Barry: nods.

Ned: that's what we do too.

Philip: ours is similar with options to tweak where the email gets sent

Cyrus: do you have a tracing feature?

Ned: not yet. Majority of errors so far are syntax errors.

Barry: just put the line of the sieve script which failed.

Barry: maybe we should just put advice in the spec or leave it up to the
implementation.

Jeffrey: SHOULD as long as we're not specific about what the
notification is.

Randy: My Sieve implementation has tracing, but only admin can control.
It's great for my own use but would suck for casual users. Never had
time to update it.

Alexey: something we forgot. What is the state of "envelope auth" document?

Ned: not written yet.

Barry: do we want it in base spec or environment?

Ned/Philip: don't put it in the base spec. Put it in environment spec.

Barry: will roll this into environment draft.

Barry: are we going to add environment draft to the WG?

Cyrus: publish individual submission and if it's before the anticipated
charter change, we'll go from there.

Cyrus/Alexey talking about updating Sieve WG milestones.

Are new dates reasonable? Need feedback from document authors.

Cyrus: 3028bis for May. What's up for comparator?

Alexey: Comparator has been through 4 week last call, but several major
comments. One revision done fixed several comments, but add few more.

Lisa: Comparator will be last called in imapext.

Lisa: agreed to shephard document.

Ned: Mark Davis's comments ran to 10 pages on this.

Lisa: might not be ready to shephard this until it's been through more
comments. But it's an important document.

Alexey: do you want to push this to somebody else to shephard the
document? I am willing to do that.

Lisa: thought IMAPEXT agreed to take document and therefore shephard it.

Jeffrey: somebody, not the document editor, needs to make sure issues
are addressed.

Lisa: any volunteers for doing a sanity check?

Alexey: reluctantly volunteering for this.

Ned: will try to take a look at it.

Cyrus: do we want another last call on 3028bis

Lisa: anyone want another WG last call for 3028bis?

Room: no

Cyrus: regexp draft to june

Cyrus: subaddress done

Cyrus: imapflags, will go to IESG this month

Cyrus: push refuse to July? Uncomfortable doing this because it was
originally part of the base spec.

Alexey: would rather beat milestone

Cyrus: Jul/Jun regexp, loop, notification action

Philip: MIME loop in June seems quick to me

Jeffrey: given that not-loop part of loop extension has lot of issues,
Phillip's point sounds right.

Cyrus: Ok, will push loop to august

Cyrus: may still have i18n issues with regexp, but see how it goes.

Cyrus: 3028bis interop report. Want to move to draft. Need to start work
in aug timeframe.

Jeffrey: how much work has been done on interoperability report for
Sieve? If two implementations never talk to each other, how does this work?

Jeffrey: thinks August is ambitious

Barry: clear what it means, not clear how to determine success.

Barry: can take script from one server to another and "it will do same
thing", but that's not quite right.

Ned: interop testing: we have had previous examples of strangeness in
this area, so we can expect some leeway. Example is ABNF document. IESG
wouldn't make it BCP, but did accept report that all ABNF features were
used in multiple drafts.

Ned: thinks this is a case to request an exception to the normative
reference rule to 2822 when moving to draft.

Cyrus: comparator draft?

Ned: that one we have to wait for.

Barry: what is process for moving 2821/2822 to draft?

Ned: go whack Pete regarding 2822.

Cyrus: may need work to shephard comparator moving to draft as part of
Sieve interop.

Cyrus: what impact of EAI on Sieve?

Philip: we should all be attending EAI and thinking about it

Jeffrey: going to be a while before EAI is something we need to refer to
from a standards document.

Philip: we'll be going for full standard

Ned: it's a conundrum if EAI is going experimental.

Chris: create EAI Sieve extension (Ned agrees)

Jeffrey: there is an issue with downgraded EAI addresses

Cyrus: how IDN aware is Sieve?

---

From: Michael Haardt <[email-masked]>
Date: Thu, 6 Apr 2006 13:54:40 +0200

Thanks for the log! It sounds all very reasonable, but I have one

> Barry: will roll this into environment draft.

I agree not to put it in the base spec, but it would help me a great deal
to have to it as an extension on its own, independent of other extensions.

In case you plan to let it have its own require word "envelope-auth"
and just describe it together with other things that have their own
require word, too: That's of course fine with me.

Michael

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 18 Apr 2006 19:49:41 +0100

>to have to it as an extension on its own, independent of other extensions.
Speaking as an individual: I agree.

>require word, too: That's of course fine with me.
Agree as well.