Draft minutes from Vancouver
2005-11-23 13:19:04
Hi folks,
Below are the draft minutes I've produced from the Jabber logs. (Thanks
to Tony Hansen for scribing in Jabber!) Please send any comments on
correctness/completeness. Editorial comments are welcome as well.
=========
The meeting has started with a quick review of documents ready for IESG
writeup (or nearly ready). The vacation extension has two minor
outstanding issues: clarification on how hash should be constructed when
some tagged arguments like :subject are omitted; default auto reply
subject when the original message had no subject.
Scott Hollenbeck has asked what was the resolution on "multiple executed
vacation actions in a script". Alexey has replied that after a long
discussion on the mailing list there was no change in the behaviour of
the vacation action.
Spamtest, imap flags, relational extensions are ready for IESG writeup.
Edit header needs to say something about stripping leading/trailing
spaces, but it is done otherwise. Barry has mentioned that the
relational draft got bounced by Internet Draft editor, resubmitted.
The body draft is waiting for resolution on comparators in the base
document, but otherwise is done. Once comparator issues are addressed,
the body can be revised in a couple of days.
IESG has raised a discuss comment on Sieve variables: ":lower" and
":upper" were underspecified, the vague text about using comparators is
not good enough to implement. Two ways to solve the issue:
a). just say that :lower and :upper only affect US-ASCII subset, other
characters are not affected;
b). do stringprep like approach (full Unicode).
Several people are in favour of US-ASCII-only approach, which is
perceived to be quicker and will satisfy IESG. 6 people in the room are
in favour of US-ASCII-only approach, plus some more in jabber. No people
objecting. Need to confirm the decision on the mailing list.
Alexey has expressed his desire to get resolution on comparators by the
end of November.
There are several open issues with the base document:
1). ABNF for match types (done)
2). Matching uses glob characters, but is not fully specified in the
document. Need to clarify that matching depends on substring operation
of collation.
3). Base spec and variables: Clarify that when matching is done then
pieces of the original value are returned in match variables, not the
result of applying the selected comparator.
4). Stripping leading/trailing whitespaces in the relational draft -
text needs to be moved to the base spec.
Short discussion about Barry's proposal to string leading/trailing
whitespaces any time a header field is touched. No objections from
people who've seen the new text (Alexey, Philip). Barry will send the
text to the mailing list.
Philip has promised a new revision of base document by November 18th.
Alexey has talked about the notification draft. Received many comments,
much more than expected :-). Separate documents will be created for
different Sieve notification methods.
Alexey & Barry will co-edit the main notification document. Barry &
Michael will co-edit SMTP notification draft. Alexey will do XMPP, but
need a co-editor. Peter Saint-Andre has agreed to co-edit. No editor for
SMS notifications, but Stephane might be working on the drafts.
Discussion about SMS has followed: what does it mean to implement SMS
notifications, what kind of payload is used (do we need multiple
different ones?), what kind of parameters are needed, how payload is
generated and delivered, etc. Ray Cromwell has mentioned that there are
a lot of requests to limit number of SMS generated per day, in order to
limit cost. Discussion on whether URIs are the best way to specify
notification methods and whether a generic Lemonade notification method
should be defined. Discussion on complexity of different SMS gateways -
different gateways need different parameters, in most cases users of
Sieve scripts wouldn't care about such parameters. Consensus from the
group that it is too premature to discuss details until we see a first
revision of the SMS notification draft.
A detailed discussion about current issues in the base Sieve
Notifications document has followed. Alexey has presented open issues.
1) Many people have requested to remove "denotify", it will be removed
in the next revision, as there were no requests to keep it.
2) Comments from Jabber that "mailto" should be a mandatory to implement
notification method, as Sieve engines already able to send mail.
3) Need a way to extract textual message body. Kjetil's suggestion will
not work, as "body" extension explicitly prohibits setting variables on
body test. Barry has mentioned that we need the ability to send the
whole body as well as first starting bytes.
Alexey has asked Philip if "body" can be changed to relax the
restriction? Philip said "no", "body" is already widely deployed. If
body extraction is only useful for Sieve notification, we can add it to
the Sieve notifications document. Otherwise we need a separate
extension. Decision to bring the issue to the mailing list.
4) Can notification method parameter be optional (i.e. if not present -
use site specific default. If no default - noop)?
Barry: keep it optional; if there is no default - "notify" action is a
noop. No objections from the room.
5) What should happen if an unrecognized notification method is
specified in the "notify" action? Error or ignored?
Alexey: scripts can't have "require" statements for notification
methods, because a notification method can be specified as a variable,
who's value can be obtained from an external service.
Do we need to add a test "if a notification method is available"? One
use case is when notification method is stored as an IMAP server
annotation. Agreement to add the test.
<>Once the room has agreed to add the test for available notification
methods, the room has reached the agreement to make an unrecognised
notification method an error.
Cyrus (in Jabber) suggested to add ManageSieve protocol capability to
advertise supported notification methods. The room agrees.
Cyrus suggested Sieve presence extension, so notification types can be
customized based on presence and time of day. (The latter is already
possible using Ned's time extension).
6) Add :from to the "notify" action? It is useful for all envisioned
notification mechanisms, but it might not be generally useful. However a
notification method is free to ignore the parameter. No objection from
the room.
7) Ned (in Jabber) is bringing another issue: URI formats need URI
"percent encoding" for different values, inserting variables into an URI
will not work. He would like to avoid options, but can't see a way to do
without them.
8) Do we want to allow suppression of identical notifications?
Greg: the answer might depend on whether we need to provide
confidentiality. No consensus was reached, so the discussion should
continue of the mailing list.
Discussion about status of refuse/reject. Most people don't know the
difference between MDNs, DSNs and protocol-level-refusal. Would script
writer really care? Consensus from the room that script writers wouldn't
care, so refuse and reject can be merged into a single action
("reject"). Confirm the decision on the mailing list.
Cyrus has pointed out that sysadmins care about protocol-level refusals
versa DSNs, however the draft is already recommending protocol level
refusals whenever possible.
Cyrus said that non-ascii text in the reject action can't be sent as a
protocol level refusal. Ned added that if non-ascii text results in
DSNs, sysadmins will disallow users to use the reject action. The draft
needs more work in this area.
Alexey and Philip will discuss if it make sense to put the new reject
back into the base Sieve document.
WG has covered the main agenda items. Barry will publish a new
individual submission that describes how Sieve can be executed in IMAP
store on different events, such as flag changes, message deletion, etc.
He believes that this will require a small extension to Sieve and a
detailed description on how this would work on IMAP side.
Discussion of the main documents has concluded, so the room has
discussed other Sieve related issues.
<>Nobody wanted to talk about index or include extensions.
<>
Cyrus will address scoping issue and he hopes that this is going to be
independent of the variables draft, i.e. it will be an extension to
variables.
<>Philip has promised a new revision of the base document on November 18th.
Dave Cridland (in jabber) has asked about outcome of the comparator
discussion. Philip did a quick review of the discussion that happened
during the IMAPEXT meeting few days earlier. Match type is built on
comparator's substring matching. <?> matches a single character as
defined by the comparator (e.g. octet or sequence of UTF-8 octets
corresponding to a single Unicode character).
Alexey has asked the WG and IMAPEXT chairs if the collation (comparator)
draft should be done in the Sieve WG, as it is moving much faster than
IMAPEXT. The answer was no, as most people are participating in both
working groups. Chairs of both WGs should nag authors of the collation
draft to move it forward quicker.
<>
<>Variables need to be updated to say that matching with glob characters
returns pieces of the original string, i.e. before any comparator was
applied. Alexey wants to send the variables document back to IESG asap.
Regards,
Alexey
<Prev in Thread] |
Current Thread |
[Next in Thread>
|
- Draft minutes from Vancouver,
Alexey Melnikov <=
|
|
|