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?