IETF 67, San Diego

I attended the 67th IETF meeting this week, in San Diego. The photo to the right was taken from my hotel room (slogan: "The only thing we overlook is the marina."). The meeting hotel is the one that's horizontal in the center of the photo.

General comments

The weather was great and the food was expensive, but that's what we've come to expect for the San Diego meetings. The pilot of my flight out there thought he was Seinfeld or something, and did little humour routines on the way up and on the way down. On the way down he pointed out the view of San Diego and the sun, and said, "For those of you who aren't from here: yes, it is always like this." As to the food issue, the IETF provided a shuttle bus to the downtown area, which gave us more dinner options than we have on Harbor Island, where the meetings are. That helps a lot!

Logistics in general were excellent. The wireless network worked flawlessly for me and everyone I talked with (though I did hear of a complaint or two). The cookies were good, and plentiful (and that's sort of an inside joke). The only thing I often wonder about is why they sweep off with the breakfast stuff right at the stroke of 9:00 (and here they didn't delay by even a minute). I know they have to clean up, but can't it wait, as long as there's food still out there? They could certainly leave one or two coffee/tea stations out. It would be especially nice to be able to duck out of the 9-to-11:30 session for another cup of tea at 10:00, and at some of the meetings one can. Not here.

Since this is a very long post and probably won't interest everyone, I've put the meeting report, full of technical details and IETF process stuff, off of this summary page.

Read the rest of this post...

Applications Area general meeting

1. Kurt Zeilenga presented a summary of upcoming and suggested future work on directory standards.
2. John Klensin presented an update on work on internationalized domain names. Not surprisingly there are a number of issues with the characters allowed by the IDN specifications.
3. Eliot Lear presented an assessment of what needs to be fixed in the IANA port-number assignments. The current assignment list is significantly obsolete, and the process for registering new ports is arguably broken. Eliot suggests using DNS SRV records instead of port-number assignment, where that makes sense... and there was a lot of discussion on that point.
4. Harald Alvestrand presented a summary of the work in the Email Address Internationalization working group. The work will lead, at least at first, to an experimental (not standards-track) protocol that will extend SMTP. The major difficulty will be handling "downgrades", when a message must be sent through a system that doesn't understand the EAI extensions.
5. Alexey Melnikov gave a brief review of the work in other email-related working groups: IMAP Extensions, Sieve, and Lemonade. I added a few words about DKIM to Alexey's summary.
6. Iko Keesmaat presented a proposal for URIs for television broadcasts. Issues that came up in discussion largely centered on localization vs URI uniqueness, and the conflict between human-readability (usability) and URI uniqueness. In the end, there's skepticism about whether the IETF is the right place to do work in this area. As Paul Hoffman pointed out, some companies stand to make a lot of money if this is done right; if those companies haven't already done it, it's likely to be too hard, and certainly beyond the expertise of the IETF.

Calendaring and scheduling standards simplification (calsify)

The bulk of the time here was spent going over the open issues with the protocol specifications, and considering simplification of RRULES, which handle repeating events. The RRULES discussion was interesting, in that it points out some unnecessary — and effectively unusable — complexity in the rules. In the end, the consensus was to simplify the rules in dealing with the cases in question.

Perhaps more interesting, though, was a side discussion I had with a colleague at the end of the session. Calsify is an attempt to update and simplify the previous work done in the "calsched" working group years ago, without throwing the calsched work away completely. It's succeeding in that, but it might not have been the best choice. A major restructuring might have been better, using a single master server for each calendar entry, and defining retrieval of information and distribution of updates to involve that server. That would greatly simplify many of the marginal situations that are giving calsify a lot of headaches.

Sieve mail filtering language

Here, too, the discussion was on the document status and the resolution of some outstanding issues in them. Most of the discussion was routine, but there were two significant changes to previous decisions:

1. Reject/Refuse will be split back into two actions, rather than the one action they were merged back to. Chris Newman points out that merging them and requiring the merged version not to send Message Delivery Notifications (MDNs) will cause implementations to work differently, which will annoy some customers — especially those in Asia, who depend upon non-ASCII messages in the MDNs. At the same time, Matthew Elvey strongly objects to allowing MDNs always. So we're back to two versions:
   • The "old" reject action will send MDNs if the rejection message contains non-ASCII characters, and may choose to use a protocol-level rejection (or an MDN) if the message is ASCII-only.
   • The "new" action (name undecided) will never send MDNs, and will not allow non-ASCII text.
2. Notifications had allowed an unspecified notification mechanism. That would result in an implementation-specific default mechanism. It took us a while to remember why we did that, because on further discussion no one liked it — it will cause unexpected results if, for example, a service-provider changed Sieve implementations and a user's script used this feature. It turned out that it was actually a decision made based on an implementation of mine, which used the ":importance" value and user presence information to decide on the notification mechanism.

   We decided that it's better to require that the mechanism be specified, and to have a new extension define a presence-based mechanism choice

Domain Keys Identified Mail (dkim)

This was my session to chair. We went over the open issues with the "sender signing policy requirements" document. A major meta-issue there, which we discussed for a while, is what to do with the document, ultimately: should it become an informational RFC, or should it just live as a draft document, guiding the development of the signing policy specification(s), and then expire? After a surprising amount of discussion on that point, we got a "hum" from the room marginally in favour of making it an informational RFC.

Next, three participants presented their proposals for specific details of a signing policy specification. We limited discussion during the presentations, and had an open-mike period afterward. Phillip Hallam-Baker's presentation offered a mix-and-match set of three independent aspects, and it was well received. It seems likely that at least some parts of his proposal will become part of the final specification.

Tony Hansen reviewed the status of the DKIM Overview document, and we got another "hum" from the room about preference to put the document out soon, to aid implementations of the DKIM base, with a possible second version later, covering subsequent topics... or to publish the overview document only after the working group completes (or largely completes) the rest of its work. The consensus was again not overwhelming, and was marginally in favour of publishing a first version now.

Paul Hoffman presented a brief overview of a reputation protocol, Vouch By Reference, that's being experimented with by the Domain Assurance Council, an organization he runs.

Finally, we revised the SSP milestone, deciding to set a new date of July '07 for a final SSP spec, and to add a new milestone for February for the working group's acceptance of an SSP spec as a working group document.

Enhancements to Internet email to support diverse service environments (lemonade)

We reviewed document status, listing completed documents (RFCs, in RFC editor queue, in/finished IETF last call), ready-to-go documents (in/finished/ready for working-group last call), and docments that need to be discussed. Then Eric gave a brief report of the October interoperability testing in London. Many things worked well, and the test highlighted some clarifications that are needed in some of the specifications — some fairly minor issues in URLAUTH, URLMECH, and CONDSTORE that were discussed later.

IMAP Notify extension: will give the IMAP client the choice of what types of events to be notified about; allows search critera (notifications only on matching documents) and mailbox patterns (monitoring multiple mailboxes); allows the client to define fetch options to be automatically returned with the notification (saves an extra explicit request by the client). There was some discussion that a client could ask for too much, and there needs to be advice to make sure the implementers know what they're asking for. Servers should also be allowed to limit what they're willing to give (maximum number of mailboxes, for instance).

IMAP URL update: There was much discussion of the meanings of certain relative URLs, and the interaction between certain characters in mailbox names and the URLs. We seem to be reaching consensus on limitations on relative URLs for the next draft.

"Profile-bis" vs "Profile-ter": There was discussion about whether it makes sense to have another ("ter") iteration on the profile, and whether that will confuse things in the OMA. Dorothy Gellert, who's working with OMA, says it will. Getting the notifications specs in there is key for the OMA.

Contents of Profile-bis: Alexey Melnikov proposed adding four items to Profile-bis, and we discussed those at length, particularly SMTP compression (again) and SMTP checkpoint/restart. Consensus not to add either of those, but to add SASL-IR and in-band notifications. There's also the question of whether we should remove binary MIME, and that question will go to the mailing list.

Quick Resync: This has a co-dependency on EXPUNGED, and will be discussed in the IMAP extensions meeting; the result is that EXPUNGED will be merged into QRESYNC.

There was an extensive presentation and discussion on issues with notifications, which is a key point for the OMA, as well as for lemonade directly. Ray Cromwell made a detailed presentation, which led into a pre-arranged lunch meeting. I'll talk about the presentation and the lunch meeting separately.

Intellectual Property Rights (ipr)

Most of the discussion here involved "outbound rights" — the rights the IETF grants others in the use of IETF-approved documents. The room showed strong consensus to always allow citations and translations, and to allow unlimited use and modification of code components of IETF documents. There was also strong consensus on a process for granting expanded rights as necessary. Important note here: the IETF is limited by "inbound rights" on what it can grant in outbound rights. Also, this applies to "IETF contributions", and not to individual submissions.

For "inbound rights", there was discussion about RFCs with "no derivative works" restrictions. There was strong consensus in the room, after the discussion, to allow "no derivative works" documents; I dissented, and Brian Carpenter asked why. I gave a vague answer — that I don't think products of the IETF should be restricted in that way — and was asked to write up a more robust answer for the mailing list.

Notification lunch BOF

In the second lemonade session, Ray presented a list of desirable properties for notifications, including these:

• Initiated by the server
• Support both in-band and out-of-band mechanisms
• Support filtering, for event selection
• Filters may be named, discovered, and managed by clients
• Events must include "new message arrival" at least
• Notification data shows which filter triggered the event
• Tolerant of delay & loss / graceful degradation

There's existing notification work in a number of working groups, and there are a number of documents that deal with some aspect of notification, including these:

• Lemonade server-to-client
• Lemonade server-to-server
• CONTEXT
• IMAP IDLE
• VFOLDER
• MSG-EVENTS
• Sieve Notify
• SNAP
• ...and others...

What we need is to simplify and unify things, to provide a common framework for notifications. Ray presented several more slides talking about notification requirements and status, and that led into this lunch meeting, arranged by Applications Area Director Lisa Dusseault.

The IETF has tried to do general notification work before, and it didn't work out, but perhaps an attempt with narrower scope can produce the sort of extensible framework we need, which other groups can extend to fit their requirements. We'll form a group to try that out, by starting with a jabber chat and a mailing list, and propose a BOF for the Prague IETF meeting. Philip Guenther and I will lead that, at least through the BOF, and we'll specifically invite people with experience with notification issues.

Email Address Internationalization (eai)

We discussed document status and issues...

Framework: The issues list was accepted, the editor will update the document and put out another revision.

UTF8SMTP: There was extensive discussion of issues with internationalization of DSNs. It's needed because we have to be able to bounce messages to UTF8 addresses, and end users and administrators often need to see localized (UTF8) error text. A number of issues related to this were sorted through.

Headers and downgrade: Not surprisingly, once again the bulk of the discussion was about a few details of what to do when UTF8 addresses have to be downgraded because the message is passing through a non-EAI-tolerant relay. We decided to go with the "<utf8@utf8 <ascii@ascii>>" syntax to represent the alternative address, and to remove the UTF8SMTP marker header. There was discussion of how to deal with UTF8 in MIME parameters, with the decision to allow it, but uncertainty about how to downgrade it. The current best suggestion is to use RFC2047 encoding, though use of that isn't legal in this context. More discussion for the mailing list. We decided to store downgraded addresses in the message headers, but only to preserve the address mapping, and we decided — wisely — not to worry about breaking DKIM signatures if an EAI message has to be downgraded.

The longest discussion here was about what to do when there's a recipient whose address must be downgraded but there's no alternative address to deliver to. Going into the discussion the thought was to bounce the message, and a number of speakers supported that. But a few of us didn't, and we eventually convinced the group that bouncing isn't a good idea. The issue still isn't finally resolved; more discussion on the mailing list.

Other minor points, briefly:
POP: no open issues
IMAP: waiting for other conclusions first
Mailing lists: new editor?
Mailto URI: wait
Forward as attachment: out of scope

Internet Message Access Protocol extensions (imapext)

We discussed document status and issues, presented here as brief notes.

ANNOTATE: Experimental now... move to standards track?
Outcome: Leave as is.

I18N: What's left? Few have reviewed it.
Outcome: Working Group review within two weeks.

ANNOTATEMORE: Review needed before last call
Issue: Exact match on SEARCH would help, but that point is broader than just this document.
Q: Should we have multivalued attributes? A: Use a string list!

EXPUNGED: [My too-brief notes caused me to get this a bit confused; thanks to Alexey for unconfusing it.]
EXPUNGED depends on CONDSTORE. There can be unexpected results if the client only supports CONDSTORE and not EXPUNGED, on a server that supports both.
Outcome: Add text to warn clients to do both to avoid spurious resync problems. Merge this into lemonade QRESYNC, as a feature.
Issue: What to do if modseq is too old for server?
Outcome: After long discussion, decided that server will return the full list, since it can't limit it as the client has asked.
Issue: EXPUNGED response is now VANISHED; should we rename the REPORTEXPUNGES fetch option to VANISHED also?
Outcome: Yes.

QUOTA: Status update, no issue discussion.

Other notes...

I didn't find anything interesting in the plenary sessions to report. In particular, there was an IAB workshop on unwanted traffic, about which there was an overlong and undergood presentation at the technical plenary, complete with bad clip art and an unnecessary and ineffective tag-team presentation style. Near the end of the presentation, Sam Hartman, one of the Security Area Directors, made a comment at a floor mike: He couldn't understand, he said, how such a good workshop could result in such a boring presentation.