Hi folks,
Here are the tentative minutes for the Montreal meeting. I've created
them from Jabber logs.
Please send me any corrections withing one week.
Thanks!
Alexey
===============================
Thanks to Kurt Zeilenga for scribing in Jabber.
The WG meeting started with agenda bashing. No changes were requested
from people in the room or in jabber. Chairs noted that editors for the
Regex draft are not in the room and there were no update to the draft,
so no need to spend 20 minutes on it.
Document status:
IMAP flags got approved in May, but got stuck in "Approved announcement
to be sent" state, ADs need to investigate.
Subaddress bis just got approved.
Spamtest - another update recently, minor comments from Aaron to be
addressed and will be sent to IESG.
Editheader - one more change is needed regarding interaction with reject.
Body - minor issues to address.
Base spec - very few issues remain, but still stuck waiting for
comparators (draft-newman-i18n-comparator-XX.txt) to be done.
Remaining issues:
1). Need to clarify what redirect means in term of formatting the
message. Need to check what RFC 2822 says.
2). Changes to IANA consideration section (removed Name, added
Description): Philip talked to IANA, they said they need exact
instructions on how to update the registry. Documents that are already
approved will be updated during AUTH48 state, but chairs and authors
need to remember to do that.
3). Allowing arbitrary octets in Sieve scripts (e.g. as in vacation
:mime text, which can contain any character sets). Sieve doesn't have
any escaping mechanisms.
Options:
- ignore the problem (its not an issue in practice).
- revert ABNF for Sieve scripts to allow for arbitrary 8bit data, not
just UTF-8.
- create new syntax elements. This would mean updating the vacation
extension, which is already approved for publication.
Ned: we can't require users to enter quoted printable text in vacation
:mime.
Philip suggested to revert to the original syntax (currently only UTF-8
is allowed), as in RFC 3028.
Kjetil (in jabber) commented that it is too bad that we can't trust
Sieve scripts to be be in UTF-8. The intent of the document was quite
clear: everything is in Unicode.
Philip: multiple character sets are bad for GUIs, also parsing is
problematic (parser needs to know what action/test it is parsing, in
order to interpret it correctly).
Ned (in jabber): I dislike both options, but reverting the ABNF seems
like the least problematic one. I want to allow for non-UTF8 in quoted
strings, so that one can match any binary data in RFC 2822 header fields.
Ned/Kjetil: it would be nice to have an escape mechanism in the base spec.
Jeff/Kjetil: how does the script writer now which Unicode characters to
type in in order to produce a script that tests for specific octet values.
Jeff: If the user is restricted to UTF-8, she can't produce arbitrary
octet values.
Barry: Need to separate the UI issue from the protocol issue.
Philip: will revert the ABNF.
Many: string escape mechanism seems like a good idea. Ned has
volunteered to write one. Philip will help out. Jeff suggested to use
\nnn or \xXX syntax.
4). Alexey reviewed draft-newman-i18n-comparator-12.txt regarding
compatibility with Sieve. The comparator document seems to be Ok,
request for others to independently verify this.
MIME loops: Cyrus presenting. Cyrus apologized for missing the
submission deadline.
Current list of open issues:
1). Depth of nested for_every_part - proposed solution is make it an
implementation defined value.
2). The draft is missing ability to test full content type (e.g.
text/plain, as opposed to separately testing "text" and "plain" - could
have been extracted from different parts). Also no way to test for
parameters.
Suggestion to have: :type, :subtype, :contenttype, :param
3). Allow address and exists tests on included RFC822 parts.
Proposed syntax:
- header :mime
- address :mime
- exists :mime
Cyrus: WG consensus appears to allowing nesting but have a
implementation defined depth.
Some discussion on whether it is possible to test MIME headers. Also
some confusion on how exactly looping works and whether embedded
message/rfc822 is another element of the message tree or not.
EAI WG might chose MIME encapsulation, in which case it might be useful
to test headers of the encapsulated RFC822 message.
Lisa: wouldn't there be always de-encapsulation before Sieve is invoked?
Chris suggests to ignore EAI encapsulation at the moment, because it
might not be the chosen solution. But Sieve WG should give feedback to EAI.
People agree that this might be the case, but there are other uses for
nested RFC822 messages (like message forwarding).
Consensus seems to be in favor of allowing any headers to be access from
Sieve. Needs to be verified on the mailing list.
Ted warns people that some message/* are not easy to handle, as they
have specific parsing logic. E.g. you won't see message/sipfrag
enclosing a message/cpim, with message/rfc822 in the middle very often.
So no need to require access to them in Sieve.
Chris: The ability to test the headers in text/rfc822-header part of a
DSN with header-only return would be interesting.
Cyrus: Yes, it would, but this is a body test.
Philip: it would be nice to do a header test on the body.
Cyrus: design team.
Regex:
Alexey: There was no progress on the document for some time, should we
drop it from out charter?
Kjetil thinks that it is important.
Poll of implementations that do regex: CMU (and derivatives) + Ned has
half completed implementation.
Alexey: the main issue was choosing a regex standard to use: POSIX?
Perl? Unicode? ...
Ned will try to do an update next week, or will pass it to somebody else.
Consensus to push the milestone for Regex out, maybe it gets done later.
Reject/refuse draft: 3 remaining issues, 2 of them related:
1). Issue # 1: The current text says that "reject SHOULD be incompatible
with other actions". Some people want to relax it to MAY (e.g. use
reject + fileinto in order to save a copy for rejected message for later
analysis), others think that this violates SMTP semantics: message is
either delivered or bounced, never both.
Jeff: Why should two actions ever be artificially declared incompatible?
Sure, reject/refuse should suppress the default keep. Reject shouldn't
be incompatible with fileinto, and it shouldn't be incompatible with keep.
Kjetil: MUST be incompatible, as per RFC 2821, section 4.2.5
Barry generally dislikes SHOULD, we end up in a mess like this.
No clear consensus to change SHOULD to MUST or to MAY. Suggestion how to
proceed:
a). Leave SHOULD in the document.
b). Add explanatory text detailing why SHOULD is here. This will help
implementers to decide when to conform or violate the SHOULD.
c). List incompatible extensions explicitly, there is no reason why some
actions like setflag/addflag/removeflag (IMAP flags) should be
incompatible with reject. Besides, it is difficult (pointless?) to put
such an open ended restriction on all future extensions.
Some fun side conversation about another reject-like action that is
compatible with other action. Suggestions are "reject-more" and "punt".
Alexey will poll people on the mailing list regarding new action which
is compatible with fileinto/redirect.
2). Issue # 2 (related to # 1): should reject just cancel all other
actions, instead of causing runtime error (suggestion from Barry).
The issue was not discussed at the meeting.
3). Issue #3: Non-ascii text in reject string?
4 choices:
-Strip UTF-8 from string (or replace it with an ascii character, e.g. '?')
-Force sending of DSN
-Send an implementation defined ascii string
-Runtime error
Alexey: Suggestion not to use runtime error, people seem to agree that
runtime errors are bad.
Many: DSNs are generally considered bad as well.
William: 5th choice: have an extra parameter with string only in ascii.
Kjetil doesn't think that having 2 strings, one in ascii is confusing
Chris Newman (in jabber): 6th choice: include URL with contains encoded
UTF-8 :-)
?: Let's not have 2 strings, this is hard to represent meaningfully in UI.
?: Also, still need to check that the extra string is still in ascii
(and this can be hard due to use of variables).
Consensus of the room not to consider choice # 5.
Barry: prefers #3 (send implementation defined string), maybe #1 (strip
UTF-8)
Kurt: stripping is evil (use of a replacement character would be
slightly better).
Kjetil: would like to reuse of RFC 2047 encoded-words, but that is an
SMTP extension, so off-topic for the Sieve WG.
Chris: A clever implementation could stuff the reject text into a public
http URL and include generic error with the http URL for details. I
wouldn't want to forbid such an implementation, but neither is it
reasonable to require that.
Consensus of the room to go with option # 3. Will be double checked on
the mailing list.
Notifications:
New revision draft-ietf-sieve-notify-03 (Alexey&Barry).
Open issues/ToDo:
- Rename :priority to :importance. There was a consensus to change this
during the last meeting, but Alexey missed it. Editors will update the
document
- Change :options to be multiple ':option <name: string> string/number'?
The current syntax is too flexible and is also incorrect (e.g. no place
for option name).
- What is the initial list of :options? IANA registry?
- Method registry? (Can include options).
Alexey: do we want to do an IANA registry now (there are no options so
far) or later when the first one is needed?
Many: do the IANA registry now, don't be lazy.
Chris gives an example for options: :option "alarm" "audio".
Kjetil: generic options valid for all methods should be explicit :keywords.
Some options would be method specific, but some might be generic, so
options registry should be separate from method registry. Consensus to
create the two registries in the document.
XMPP notifications:
- Is it OK to have normative references to JEP (Jabber Extension Proposal)?
Some discussion between room and ADs about normative references to JEP
documents followed. There is no document describing interaction with
Jabber Software Foundation (owner of JEP series). The IETF requirement
is that documents are stable and publicly accessible. Ted suggested not
to worry about this and assume that normative references to JEPs are Ok.
Date/index extension: Ned has published a new draft, addressed all know
issues.
Alexey: Ned, can you please LC the draft?
ManageSieve:
Alexey: There is no need to wait for the Lemonade WG to decide if they
want to use ManageSieve or not. ManageSieve is generally useful.
Cyrus: The main issue with ManageSieve is interaction with Include (next
topic).
Include:
Alexey asked the room: "who have read the draft"? A few hands raised.
Alexey: my only issue is relative order of import/export statements -
should be arbitrary. Otherwise Ok with the document.
Kjetil: the base spec might define a "preamble" section which can only
contain require, then include can specify that import/export only goes
in that header.
Jeff: I asked why "import" should be _immediately_ after require, as
opposed to merely after.
Cyrus: imports should be in one place.
Kjetil: "global" means you can see variables from parent, even though
you may not want to.
Kjetil: "export" is only global to the current script, and children.
Kjetil: I'm not sure if we need the restriction that imported variables
can't be re-exported.
More discussion about how to do variable import/export. No consensus, so
need to discuss on the mailing list.