Minutes from the Prague IETF meeting

[Alexey Melnikov <[e-mail]>]

And at the very last moment Alexey submits minutes...
Enjoy!
===========
Thank you to Dave Cridland for being the Jabber scribe this time.

Alexey was the only co-chair present this time. He briefly talked about
status of different documents (see slides). About half WG docs are in 
RFC ed queue.
Collation document got published as RFC 4790, thanks to Arnt.
Base spec was submitted for IESG review.

Philip promised to update Sieve body one more time before sending it to 
IESG for publication.
Editheader - need to resolve handling of mail loops.
Alexey/Cyrus think that notify extension is basically ready, but needs 
reviews and feedback on changes.
Mailto notification is in WGLC, has some open issues, but not much feedback.
Refuse/Reject: Alexey has been too busy recently for an update.

The WG briefly talked about Editheader interaction with redirect/reject. 
Philip replied
in jabber that the new text doesn't affect reject, which still requires 
to return the original
headers, as per another paragraph in the document. And he basically 
agrees with other comments
and will do another revision of the draft before sending it to IESG.

Alexey talked about recent changes to Notify. No comments or objections 
were received,
so Alexey & Barry think that the document is done.

TODO: Dave Cridland & Randy Gellens to do a full review of notify.


Barry has presented the Mailto notification draft. He talked about open 
issues:

1. URI Parameter conflicts with other notify parameters: Do notify 
parameter Override the URI parameters,
   is it an Error or something else?

 Barry likes "Error".
 Alexey & Michael prefer Override. Alexey is thinking of external URIs 
being pulled in (perhaps from IMAP METADATA).
 Barry thinks that Ned might have useful opinion.

 Philip: I suppose a script can code itself defensively to test the URI 
before it uses it. Possible, but ugly.
 Later he added that there were no practical way to test the contents of 
a URI using just ":matches",
 one needed regexps to break them down.

 TODO: Ask Ned for opinion. Unless more people say there opinion, the 
Override option will prevail.

2. Undesirable URI params: what do we do if a URI specifies unsafe headers?

 Barry slightly prefer ignoring bad headers.
 Ted saying the mailto scheme RFC is pretty limited on these points, so 
Sieve advice and mailto RFC advice
 would probably be different.

3. Message origin: does the notification message come from the original 
"RCPT TO", or from the notification system?

 Alexey pointed out a suggestion to make it an option.
 Pete asked what the From is for and whether we were going to reply to 
these messages.

 Philip: if the notification system can autoprocess bounces, then it 
belongs in the envelope MAIL FROM
 Maybe always is better, to block the loop possibility.

 Dave Cridland: not clear why worry about "from" for notifications: are 
they to send msgs *to* a user, not necessarily
 be *from* anyone in particular.

 Philip/Pete: The important 'from' here is the envelope from. IMHO, the 
env-from should *never* be the original.

 No clear consensus on this issue in the room.

4. Body excerpts: "is Barry being silly" for wanting this?

 Alexey commented that the Sieve Notify used to have body extraction 
action, which was removed.
 But it will move to MIME-loops, so he thinks that this is still useful.
 Dave Crocker said that there was a long history of an excerpt being 
useful. But it's tricky to get it perfect.
 Randy was discussing whether the spec ought to say more than "this is a 
good idea", or should we stipulate
 down to the last octet.
 Barry likes the idea of vague specification, with a view that 
mime-loops and body extraction to a variable
 would provide a strictly specified method for doing this.
 Randy: I'm concerned that if we try and standardize it we end up with a 
sprintf format for how the script
 specifies how much of the body to use and how it appears. Since that 
prospect is so scary I urge us to
 instead say "engine may do this if it wants, it is helpful"
 Barry commented that this automatic vague excerpt could be the default.

 TODO: verify consensus for "vague description of body excerpts" in the 
document.


Tony has presented the updated MIME loops document:

Open issues:

1. Should enclose throw away modifications?

 Philip: I think enclose should honor changes. Anyone using enclose to 
create bounces should be shot.
 Aaron: why would we *not* want to honor changes?
 Ted says we can always get unmodified behavior by structuring the 
script carefully (As in not doing
 any modifications).

 Consensus to use the modified version.

2. Should we synthesize Date and From headers to reflect the current 
user and time?

 Philip: Is there text that can be stolen from the submission spec? It's 
kinda like a submission,
 the creation of a full message from a partial one...

 Alexey prefer synthesized: the original are still in the enclosed part. 
Sometimes it is useful
 to see when the message was created and when it was enclosed.

 Note from the room about synthesizing new message id.

 Kjetil and Tony were discussing syntax for extracting key/value pairs 
from variables). Everybody
 else except Philip don't have a clue about the discussion, because 
people haven't read the most recent
 message from Kjetil on the mailing list.

 Philip: Kjetil's idea is cute, but they're not much better than simply 
using a comma separated list,
 partly because there's no way to quote the value properly when adding it.
 You can put quotes around it, but that won't handle embedded quotes or 
backslashes
 Regexps would be as good (or better), but you can't do the extraction 
with just :matches.
 Time for that SQL access extension.

General comment from Alexey (as a co-chair): the list of open issues 
that Tony presented
differs from the one from the latest San Diego IETF, and the issues were 
not addressed.
Tony agrees to review the San Diego list.

Alexey: Assuming all issues are resolved, MIME loops will be last called 
in a couple of weeks.


Alexey briefly talked about Ned's individual Date-Index Draft.
The document has no major issues now, Alexey to shepherd to IESG.

Alexey has briefly talked about Ned's Environment & Notary (DSN) extension.
Barry/Alexey: the two extensions don't belong to the same document.
TODO: Ask Ned to split the draft into 2.

Next Alexey presented his draft on "Accessing IMAP per-mailbox 
annotations from Sieve".
Alexey described features of the extension:
1). Ability to test for mailbox existence
2). Ability to create mailbox on fileinto. Without the new :create tag 
fileinto creates mailboxes
    in some implementations, but doesn't in others.

    Some short discussion about Sendmail implementation: it still treats 
:create as an optional request,
    which is arguably a bug. Sendmail implements Sieve in SMTP server, 
so fileinto turns into
    +detail email address, thus the mailbox creation request might not 
be honored.

Alexey talked about an example: an annotation can be used to turn 
vacation autoreply on or off.

Open issues:

1). Do we want access to server annotations? - Alexey thinks "yes"

 Chris pointed out that testing server annotations and testing 
environment are basically the same thing.
 Barry agreed. Barry commented that there is no namespace-like thing in 
Environment that might support this.

 TODO: Talk to Ned about namespaces in Environment.

2). Do we want access to LIST-EXTENDED data? ACLs? - Alexey thinks 
"maybe" on LIST-EXTENDED data.

 Philip threatened to lose the breakfast he just ate.



Alexey presented a new (not yet written) draft on "Externally stored lists".
The basic idea is to be able to store lists of users or email addresses 
in SQL/LDAP/ACAP/...
Such lists can be updated externally, without the need to update Sieve 
script.
The proposal is to extend redirect action and header/envelope tests to 
reference externally
stored lists.

 Barry showed his Sieve script. It has many email addresses hardcoded, 
so he would like
 to have such an extension.

 Randy said that maybe an external list reference should be via URLs. 
(The proposal as described
 had list labels as opaque UTF-8 strings, e.g. "blacklist")
 Philip agrees.
 Philip: hmm, how about using imap: URLs to access annotations/metadata 
in IMAP?

 Aaron: so, :list "string" is probably a bad name because its confusable 
with :param ["string", "list"].
 And, this would be cool together with variable namespaces: ${external:name}

 Kjetil suggests that this probably doesn't scale too well, for example 
if the list contains
 ten thousands of addresses (like an enterprise address book). Kjetil 
suggests a comparator which
 takes a URI on one side.
 Alexey: Sure, testing membership in big lists can be optimized (e.g. 
use LDAP search).
 This is an implementation detail.

 Randy pointed out that we needed to handle updates, and the LDAP server 
going down.

 Pete says there are email clients which already have addressbook 
interaction in filtering.

 Aaron: I'm in favor of some kind of managesieve extension to maintain 
the external lists.

 Randy said that the extension should also cover management of mailing 
lists.
 (Alexey didn't like the idea)
 Randy: It's a generalization of Eudora's 'intersects address book' 
test, and
 'add to address book entry' action.
 Aaron: Automatically adding inbound/outbound addresses to the address book?

 Kjetil: with "include" in Sieve, it wouldn't be that much of a 
difference to
 upload a new list using ManageSieve. But I want it to use your *real* 
address
 book which is already stored in LDAP or whatever. Also, duplicating 
lists is not good.

 A huge discussion started on whether the identifier for a list has to 
be an opaque string or
 an URI:
  Alexey: I don't like URIs in this case. I don't want to force users to 
write LDAP URIs,
  they are just too complex. The whole point of the extension is to make 
this easier for users.
  In LDAP case users don't need to know the base DN for search, search 
criteria (e.g. which object
  classes), etc.

  Philip: who says the user will be writing the URI? won't the MUA be 
generating the URI to match
  the URI it uses for the address book?

  Pete suggested that the "mylist" can be a relative reference, so the 
script engine uses
  a base URI to resolve it to an absolute URI.

  Alexey thinks that this would not work with LDAP, for example.

  Barry likes the notion of a magical URI for "Your data".

  Kurt thinks it's all too complex.

  Pete says "Thou shalt support URIs", but "Thou may support arbitrary 
tokens".

  Philip: one catch with URIs is that they all have distinct quoting 
requirements for various fields.
  Given an arbitrary string, generating an LDAP URI that searches for 
entries that have a particular
  attribute with that value is non-trivial.
  Randy agrees.
  Philip: have to apply both the LDAP filter escaping *and* the URL 
escaping, in that order.


And finally Alexey talked about ManageSIEVE draft.
One update since last IETF, mostly bugfixes. NOTIFY capability text 
moved here.

Open Issues:

1. Reference implementation doesn't implement non synchronizing literals.

So the spec will be updated to match the real world.

2.  Suggestion from Arnt: Remove anonymous script verification mode.

 Any objections?

 Kjetil: Means the UA doesn't have to store the password for syntax 
checking.
 Alexey: But clients already cache passwords, at least while they are 
running.

 Aaron notes that different users can have different capabilities granted to
 them, so it is important to authenticate properly.

 TODO: Consensus to remove the text.

3. IANA registry for response codes

 Dave Cridland: Could reuse 
http://www.iana.org/assignments/acap-registrations for response codes.


Alexey talked about WG milestones. There was a proposal to update them, 
but the WG is already
1 month behind on the updated ones.

Other business: Alexey wants to talk about Sieve interop on Tuesday or 
Wednesday.
Alexey instructs WG members to drink Czech beer.
The meeting has ended.