IETF 71, Philadelphia

Once again, it’s been IETF meeting time, which means that today’s post is long and geeky, describing the meeting sessions in way more detail than makes sense, and causing my readers to wonder how I got this way. But I have to write this up anyway, and so I post it here.

First, a bit about the venue: Philadelphia. That made it very convenient for me, as it’s only an hour and a half from New York by train, and that’s a pleasant way to travel. And the meeting hotel was a reasonable walk from the train station, as well. There were lots of good places to eat in the area. And, contrary to the case for the two previous meetings, the construction that was going on in the meeting hotel did not affect the conference.

Perhaps the best part of having the meeting in Philadelphia was that the Tuesday evening social event, one of the rare breaks in the hectic pace of the week, was held at the wonderful Philadelphia Museum of Art, making it the best social since the Paris meeting in 2005, when we went to the Musée d’Orsay. Good food, great art, and a nice place to socialize. And they have a Frida Kahlo exhibit there now, which, along with their permanent collection of impressionist and modern art, made it a good evening for art.

And now, I know I’m back in New York. As soon as I got out of the train station in New York City, I overheard someone talking on his mobile phone:

You know what? We’re having a Korea day. You should come.

Yeah, that’s right, a Korea day.

No, no, not the country! We’re lookin’ to hire people!

Read the long, geeky bit...

Sieve Mail Filtering Language (sieve)

Document status: several working group specifications, including the base spec, Variables, Vacation, Relational, IMAPflags, Subaddress, and Spamtest, have been approved as Proposed Standards. Huzzah! In addition, Notify and Notify-XMPP are in the RFC Editor queue. The remaining active working-group documents — Notify-Mailto, Body, Editheader, MIMEloop, and Refuse/Reject — are mostly done and should be wrapped up soon. We just have to revive RegEx and get that revised and finished.

That leaves the working group with two tasks. One is to decide whether to do the work needed to move the base spec (now RFC 5228) to Draft Standard status. We spent some time (continuing a conversation that some of us had had at lunch) discussing how to do an interoperability report for something like Sieve, which isn’t a client/server protocol (for which interoperability evaluations are common and well known). It’s clear that some of us would like to move it along the standards track, while others aren’t sure it’s worth the time spent.

The other task is to decide whether to re-charter and accept six other Sieve extensions — currently individually submitted drafts — as working group products. The extensions in question are IMAPext-metadata, Environment, iHave, in-XML, Date-Index, and Notify-SIP. There was clear consensus to adopt at least most of this set if we decide to re-charter, and the consensus in the room was to do so. We have to check on the mailing list to make sure we still have enough active interest to get enough work and review effort for this.

Domain Keys Identified Mail (dkim)

The main goal of the meeting was to discuss and close issues on the Author Signing Policy document and move toward working group last call on that document.

The meeting opened with a review of the informational documents, “DKIM Service Overview” and “DKIM Service Deployment”. The former is mostly done, but for some editorial comments. Working group last call on the content started at the close of the meeting, and will end on 24 March. The latter is still under development. The authors solicited reviews and contributions from those developing software for DKIM, deploying it, or operating mail systems with it. A participant who works for an email marketing company, had comments about the timing of the documents, and the importance of having some early advice on the deployment of signing practices. Tony Hansen met with a few people after the meeting.

The bulk of the meeting was then spent going through the open issues on the signing practices document, now called “Author Signing Practices” (“Author” replacing “Sender”, and there was some discussion on the name, with this working group chair preferring “From Domain”, shortened to “FroDo”). Jim Fenton discussed the history of the recent changes (which involved a significant restructuring of the document, a restructuring that resolved a number of issues), and then divided the open issues into three groups, roughly “easy”, “medium”, and “hard” — more specifically, “We should close these,” “These might be ready to close,” and “These probably need more discussion.”

The result of the issue run-through and discussion related to the latest (-03) draft was that, pending confirmation on the mailing list, we can close all but two of the “easy” issues, all but two of the “medium” ones, and all but one of the “hard” issues (but see below).

Most of the “hard” discussion was on issue 1519, user vs domain granularity of signing practices. Consensus was to leave it at domain granularity only, leaving any extension to user granularity for a protocol extension. We’ll leave this issue open for two weeks, to allow further discussion.

Some issues remaining open:
1519 — user vs domain granularity of signing practices
1535 — clarify need for domain existence check in the decision tree (step 2)
1543 — remove [FWS]; there’s a significant move to keep it, just for consistency with the base spec
1547 — require existence of MX records; leave open awaiting follow-up from Peter Koch
1550 — the name of the document (remains open briefly); there’s still disagreement on “Author”

In addition, Phillip Hallam-Baker agreed to review the security considerations and add any appropriate text about security threats. Peter Koch will post a message to the list about his concerns about DNS queries (which may open a new issue). And we will open a new issue to replace 1520, which will address only the name of the “Discardable” feature — there’s significant dislike of the name, but it’s not clear that we’ll find a better one. This issue will be open for two weeks only, to avoid having it turn into an interminable discussion.

VCard and CardDAV (vcarddav)

This working group is just getting started, and this was its first meeting. We started off in a pretty large room, with very few in attendance, but we were soon moved to another room, and gave our large room to a group that was overflowing the smaller one.

The task at this meeting was to review the documents that are proposed as working group documents, to bash them a bit, and to decide whether we want to use them as starting points for the working group. Bashing was done, and there was quite a bit of discussion, and both of the documents were accepted:

1. Update to the vCard specs: there was some discussion of the new properties that are being added, and the extensibility that’s now in the spec. Synchronization and property IDs need a lot more discussion — in short, if each property has a unique ID, it makes collation and synchronization of properties much easier, but it makes vCards uglier (not so much of a worry) and much larger (perhaps a greater problem).
2. CardDAV protocol: this is an extension to WebDAV, modelled along the line of CalDAV, to be used for storing and updating vCard data on a server. The author reviewed the protocol, and an early implementor gave an implementation report.

There was also a presentation and discussion of comments by OMA. The comments involve OMA DS (formerly SyncML), what problems they’ve had with vCard, and how the vcarddav work can help.

Calendaring and Scheduling Standards Simplification (calsify)

This working group is in its final stages, wrapping things up. We’re on final updates to iTIP (about to be submitted to the IESG after another revision) and iCalendar (a new draft has to be submitted, since the old one has recently expired). iMIP will be sent through as an individual submission, and the chairs do not expect to have the working group meet at IETF 72.

Cyrus went through the open issues on iTIP, along with his proposed resolutions, and we approved those. We also resolved one that Cyrus presented options for, which created an action item for Bernard, on iCalendar. And that was it for this meeting.

Anti-Spam Research Group (asrg)

The ASRG has been around for several years, and has been pretty much dormant for some time. This meeting was an attempt to kick it back into action by reviewing the documents that the group had been working on, in their various stages of completion — and in their various stages of neglect.

DNSBL mechanics is mostly complete, and is the only one that’s still an active draft (though it’s just expiring now, so even it needs to be revived). It’s meant to document the way DNS block lists (DNSBLs) work, at a protocol level. It does not discuss how they’re administered and makes no judgments about whether they’re good or bad. This document has been approved by the ASRG, and needs to be pushed through the publication process. Alexey Melnikov volunteered to work on that.

DNSBL best practices is a draft that’s been expired for a while (draft-irtf-asrg-dnsbl-bcp) and needs to be revived. It’s current editor (who was not at the meeting) intends to get back to it, and Tony Hansen volunteered to co-edit, to make sure it gets moving. This is the document where issues about administration and implementation quality will go, and we had some discussion about the split between the previous document and this one. The IRTF chair also pointed out that IRTF documents can’t be published as “best current practices” (BCP) documents without the sponsorship of an appropriate Area Director, so it will be best to get the ADs involved soon.

“Assessment of Anti-spam Techniques” is a moribund document, and it’s not clear whether it really serves a useful purpose — despite its title, it’s actually more of a meta-specification, of how to assess, rather than being an actual assessment. J.D. Falk agreed to review the document, and talk with the author about reviving it or dropping it.

“Taxonomy of Anti-spam Techniques” is a section of the ASRG wiki in which John Levine has tried to list and describe the various anti-spam techniques, with the intent of turning it into a research group document. There was quite a bit of discussion of the document, much of it involving whether it even makes sense to do this, and what the list really means. In the end, a number of people volunteered to fill in the descriptions on the wiki, and we’ll look at it in about two months to see whether there’s enough there to make an Internet draft out of it.

Enhancements to Internet email to Support Diverse Service Environments (lemonade)

Lemonade met twice this week, taking care of document-prep business in the first session, and intending to have an extended discussion with OMA representatives on Friday, running through lunch and into Friday afternoon, with the goal of filling in the mapping between OMA requirements and lemonade work. But since the logistics weren’t worked out before the IETF meeting, the OMA folks weren’t there and we just held the Friday session as a normal working group meeting, reviewing the OMA requirements without the benefit of OMA representatives to discuss them with.

Document status:

Context

wrapping up, needs final draft

Notify

short issues list remaining, mostly done

Convert

minor changes, ready to go

IMAP-Sieve

done, waiting for working group last call notice

Streaming

some open issues, one more set of changes to be made

URLfetch-Binary

working group last call ended, need to fix ABNF/example mismatch, Alexey proposing new ABNF for bodypartstructure

Notifications Architecture

ready for working group last call

Profile-bis

reviewed content, will issue revision and last call on that

We then set last-call dates (with a bit of pushing from me when the chair wanted to put it off, citing no calendar handy), all finishing by early May. So if we hold to the schedule, all existing working group documents should be in to the IESG by mid-May.

Friday’s meeting became a bit tedious, as we went through the list of OMA requirements. Alexey had done the hard work, of setting them out in a table and making the first pass at working group applicability, response, and remarks for each. We reviewed and tweaked what he did, and filled in the gaps in his initial work. In quite a few cases, we weren’t sure what the requirement really meant, which is why we’d wanted OMA people there. In each of those cases we made a best guess, and will ask OMA to clarify their requirement.

Email Address Internationalization (eai)

Document status:

Downgrade

mostly ready for working group last call. Open issue: should UTF8 version of some headers be removed by downgrade?

IMAP

final work, then working group last call

POP

major change since last time: UTF8 mode change added (must precede authentication). Open issue: how to specify downgrade for non-UTF8 client. There was quite a bit of discussion of that, specifically about whether it should refer to the working group’s “Downgrade” spec, and whether the reference should be “MUST”, “SHOULD”, or some sort of “might consider”. Clear consensus against MUST, but divided otherwise; take to the mailing list.

IRIs for mailto

much discussion, take to list. We might need a new URI scheme instead of trying to use mailto:.

Mailing-List

ties into mailto, particularly in the list-* headers. Otherwise done.

Scenarios

should we drop it? John Klensin suggested merging it with a future update to Framework, which also serves to delay the decision. Consensus in favour of that.

Next question: should we adopt draft-dainow-eai-email-clients and draft-fujiwara-eai-downgraded-display as working group documents. Consensus to do so, but the timing on publication isn’t certain.

Finally, on re-chartering to develop standards-track versions of the experimental specifications: Harald (chair) asked whether we can test, find problems, fix the problems, and have standards-track documents ready by the end of 2008? I thought that was too optimistic. John suggested that it’s worth taking that as a goal, and using it to push us to get the work done. Consensus was in favour of setting the aggressive dates.

Extensible Supply-chain Discovery Service (esds) BOF

This is a proposal to develop a standardized system and protocol for identifying and tracking physical objects in a supply chain. The organizers have a good handle on what they need to accomplish, and I think they understand the difficulty involved, particularly in areas such as scaling and access control. In particular, the access control issues will be nasty: it involves complex database retrieval, distribution, and merging, all done under access control rules that can be constantly changing as an item moves along the chain. Some suppliers might own their items all the way through to the final delivery, while in other cases a manufacturer (say, of an electronic part) may give up access to tracking an item when it moves to the next stage (information about what I do with the part I bought from you might be quite proprietary).

There was a detailed presentation of the problems and the concepts, and much discussion about it. In the end, there was wide consensus (and no objection) that it’s suitable to do this work in the IETF. There was also a sufficient group of people willing to do the work. But there was also broad consensus that they’re not ready to start a working group yet: that things have to be nailed down more before they can take that step.

Internationalized Domain Name (idn) BOF

This is aimed at updating the IDN standards that were passed in 2003, having found problems with them since. John Klensin reviewed the problem background in some detail, and gave an overview of the current documents. Much of the discussion was about a major change that involves a complex algorithm to decide whether a Unicode code-point is allowed (the 2003 standards use an exclusion list, so that all code-points are allowed except for the excluded ones). This will cause a number — allegedly, a small number — of currently registered domain names to be invalid, and they will have to change. It’s not clear what agreement we have from the registrars on this. There was also quite some discussion on the handling of direction-neutral characters (such as numbers) in right-to-left text, and the like.

In any case, “some of our best people are working on it,” the charter is pretty much ready, and this very much needs to be done. There will be whirlpools and sea monsters along the way.

Provisioning Extensions in Peering Registries for Multimedia INTerconnection (peppermint) BOF

The main point here is to set up a protocol for doing provisioning across administrative domains. The goal of the BOF was to show that there’s a problem here that needs to be fixed, that the problem is within the IETF scope and that it can be fixed, and that there are enough people “ready, willing, and able” to fix it within a reasonable time.

They sensibly suggest reusing work done in the enum and speermint working groups. The draft charter also suggests reusing work from RFC 4114, but there seems resistance to locking the group into that, and there was consensus to remove it.

Jon Peterson, one of the responsible Area Directors, suggested looking at breaking the work down into modules, to avoid biting off more than they can chew. Indeed, there’s too much here and it’s not clear that the group knows how to do it all or where to go with it.

They are absolutely not ready to adopt a charter yet, and I think the ADs, Jon and Cullen, will need to work closely with them to get a reasonable charter... and then will have to select the working group chairs carefully. It is clear, going back to the initial questions, that they do have a problem that needs to be fixed, that the IETF is the right place to do the work, and that they have a reasonable set of people who want to work on it. They don’t know how to fix it yet. It’s up to the ADs to make sure the next steps are taken with that in mind.