IETF65, day 3 (Wednesday)

Lemonade, part 2

Continuing from Monday, the second lemonade session began with the OMA response to the liaison report. There was extensive discussion about the list of mandatory conversions (draft-ietf-lemonade-convert). We then continued with the status and issues discussions on other documents. My notes on the items I paid particular attention to follow.

Reconnect:

• Discussion of state saved by the server.
• Do we need "logout (preserve)" to explicitly retain state (as opposed to just shutting down the connection)?
• Do we need a "delete session" command?

Object-level encryption:

• Presentation of the proposal.
• Question of whether it's a bad idea to develop our own crypto protocol.
• Need to talk with the Security Area advisor.

Firewall traversal:

• draft-ietf-lemonade-firewall-binding
• Chair clarifies that this should not have been made a working group doc.
• Discussion of the wisdom of doing this; attempts to bypass firewalls will be met with stricter firewalls.
• Rework document, focus on the real issues it's addressing, then review.

Charter review and next steps:

• 11 drafts to be updated by 3 April (comment: Yow! That's a lot).
• New draft on content streaming due by 10 April.

IMAP Extensions

This group is almost done with its work. It's lost a working group chair (she's an Area Director now), but the remaining chair expects to close out the work without needing a new co-chair. We covered the status on the last few work items.

Charter review and next steps:

• 11 drafts to be updated by 3 April (comment: Yow! That's a lot).
• New draft on content streaming due by 10 April.

List Extensions:

• Issue with text saying that servers MAY ignore request for child info; if they do, clients will get it empirically anyway, and it'll probably cost the server more. Editors will change text.
• Issue with text saying that servers might not be able to do SUBSCRIBED and CHILDREN together. The concern is that there might be other "difficult" combinations, and what should we do about that? This is related to the above, with the same resolution: kill it.
• Suggestion to split section 3 into overview / selection options / return options. Editors will consider, but not at the expense of resetting working-group last call.
• Suggestion that we clarify that clients must deal with information's being wrong, because of changes that happened after the LIST command was done. Response is that this is always the case and always has been, and text is not needed. Editors will remove the existing text that prompted this.
• We mention access permissions, but don't reference the ACL spec. Response is that we talk about the concept of access permissions, intentionally not talking about the specific mechanism. No change needed.

Comparators:

• Change en;ascii-casemap back to i;ascii-casemap.
• Discussion of pipelining selection of comparator. Issue is that it causes an extra round trip otherwise. Sometimes you can't pipeline, but often you can. OK, no change.
• Quite a bit of other assorted comparator discussion....

Annotate:

• Concern that there aren't enough implementations to be sure that we're doing this right.
• Will go through as "experimental", not standards track yet.
• Text will make it clear that "experimental" in this case does not mean "beware of implementing", but, rather, "please implement and add your experience to the pool."
• Discussion of sizes of annotations.

AnnotateMore:

• Needs a better name. Suggestion is "metadata". No resolution.
• Definitely standards track; lemonade needs it.
• Discussion of retrieving folder annotations through extended LIST, rather than GETANNOTATION command. If we do this, issue remains of getting sevrer annotations. I'm not sure we resolved this.

EAI issues:

• Discussion about dealing with UTF-8.
• Decision to finish the imapext work, and deal with EAI in another group.

DKIM, part 2

We started the second DKIM session by finishing the review of the base-spec issues with the few we hadn't gotten to on Monday. We briefly discussed splitting the base document (specifically to remove references to retrieving DNS records, but there may be other things that make sense to split out), and deferred some longer discussion to the mailing list.

Jim Fenton then introduced the signing policy/practices proposal and issues; after the base document, we'll be attacking this in earnest. The name is still in flux, with some thinking that "policy" is not the right term, others thinking that "practices" isn't either. We were pointed to some work called DDDS that's been introduced in the speermint working group, which might help us with the work (not with the naming), so we'll have a look at that.

Tony Hansen introduced the DKIM Overview document that he's gotten Phillip and Dave to work on with him. The idea is that this document contain informative text to explain history and decisions that it doesn't make sense to put in the normative documents. There was discussion of what should go in here: some would like to have all informative text moved here, while others point out that implementors often don't read auxiliary documents, and everything should stay in the base doc. There's also the issue of how this dovetails with the DKIM Best Practices document that the AntiSpam Research Group is planning to do, and John Levine will work with Tony to sort that out.

Doug Otis presented his proposal about opaque IDs and signing roles. There was only a little discussion because time was tight. There were comments that this would require a lot of DNS querying, and that it might be more interesting theoretically than practically.

Tony briefly talked about a test message corpus that's available for implementors to use to test their implementations.

Administrative Plenary

Nah, I'm not going to talk a lot about this. The gist of it was an avertisement by the host company, followed by reports from folks like the RFC editor and the IAOC chair. Then we had a short talk about the effort to update the Tao of the IETF, a report from the nomination committee, and some "thank you" comments and other such to/from some who are leaving IETF management. Finally, on the open mike, the first topic to come up was... that food runs out too quickly during the breaks. "Where are my cookies?"