IETF 72, Dublin

Well, Dublin-ish. The IETF meeting was actually at Citywest, 30 minutes outside of Dublin. I guess that was great for the golfers, but I missed being in the city, and having the option of walking out and getting lunch and dinner. They provided dinner buses into Dublin, but that’s not the same as just walking down the street a block or three. It seems that Trinity College Dublin would have been a fine place to have the conference, and I’m sure there are other facilities that’d have worked as well.

Still, it was a good meeting. The facility we did have was somewhat expensive, but otherwise fine, and, of course, the meetings were productive and useful, as always. It was another full week (I had about two hours of free time the whole week, an hour or so each on Wednesday and Thursday), and managed to schedule the rest of the time, including meals, for work.

It’s too bad, someone pointed out, that it was the 72nd meeting, and not the 33rd — if it were the latter, we’d have heard the local presentations welcome us to the “torty-tord IETF”. As it was, we heard that there were almost torteen hundred attendees (or, one tousand tree hundred), so that was nice.

I’m going to keep the meeting summary on the short side this time, with just a few highlights, but it’ll still be a long post. If you want to read about the vacation days after the meeting, and see photos, look for my other post, to come tomorrow. If you’re really interested in this, click here to see the meeting summary.

apparea — Applications Area general session

Among the general announcements were that NFSv4 will probably be done in the Applications Area, and that there’d be a discussion of email standards status on Tuesday (of which I have a summary below). There was a presentation of two follow-ups from the Applications Area workshop in February — netappvlan and netappmodel — but with no ensuing discussion.

There was a brief discussion about FTP extensions. The points are that, while FTP seems quite mature, and not terribly ripe for extensions, it’s still big business and there are five documents that are out as Internet drafts, looking for standardization. Should these go through as individual submissions? Should we form a working group?

It looks like we’ll form a working group, and John Klensin and I have agreed to co-chair it. We expect it to be a short-lived and non-contentious group, and John and I agree that standards going through the group will require some real support behind them, and existing implementations as evidence that they’re real and worth moving forward.

dkim — Domain Keys Identified Mail

We had a quiet session at this meeting, and my co-chair, Stephen, wrote this succinct summary, which I’ll use here:

DKIM met Monday afternoon, 62 people attended.

The main goal of the meeting was to get the ADSP and Overview documents to the start of working group last call. Each had a couple of open issues at the start of the meeting that were discussed and resolved (modulo confirmation on the mailing list). The result was that a new revision of ADSP will be published this week. Working group last call on both documents will start at that point.

The deployment guide was briefly presented, and work on that continues.

A couple of proposals were made for new work that might require re-chartering. There was some, but not overwhelming, interest in pursuing these, but the group won’t have that discussion until after the two current documents are in the hands of the IESG.

idnabis — Internationalized Domain Names update

We had the usual minor issues discussion, but the most significant by far, taking most of the time in the two sessions, was in the “BiDi” (bi-directional text) document: how to deal with left-to-right text, such as numbers, dots, slashes, and the like, in otherwise right-to-left text, such as Hebrew and Arabic. We had a demonstration of what happens when such text is entered, and it’s not pretty. As someone typed “abc2.[Arabic-text].3def.com”, we watched the “.3” get turned around and moved, so it incorrectly appeared to be attached to the Arabic text. To be sure, this is a user-agent problem — the correct characters will be sent on the wire in the correct order — but it’s a very hard one to solve. There’s no resolution yet, but we have more information, and, as we say, “Our best people are working on it.”

We also had a discussion, which included at least one native speaker of Korean, about a request that we add another set of Korean characters to the list of characters forbidden in domain names.

eai — Email Address Internationalization

We had some discussion of EAI issues during a working dinner on Sunday, and came up with a recommended answer to the question of what to do about List-* header fields. I presented that answer in Monday’s EAI session: for List-ID, note that it is meant to be a machine-readable string, not a human-readable one, and should not be in UTF-8; for others, internationalize them by including multiple URIs, and downgrade by removing the UTF-8 version, leaving the non-UTF-8 versions for use after downgrade.

POP and IMAP are almost done, but there’s an issue about POP and downgrade — the document currently has uncertain language about how to downgrade a UTF-8 message if the client isn’t using UTF-8. In the event that an old client is being used to download the message, but that a newer client (perhaps after a software update) is later used against the same local message store, we agreed, after discussion, that it would be good to have a standard downgrade mechanism used, so there’s some hope that the new client can recover the original message. There was agreement to require the use of the standard EAI downgrade.

We decided to wave our hands around the issue of handling mailto URIs. It will eventually require its own document (a UTF-8-enabled mailto), and for now we’ll point out that mailto does not handle UTF-8 addresses, and that something to deal with that is forthcoming.

There was a report on some very successful experiments with the current EAI specs (including downgrade experiments). Many thanks to the organizations that participated in those. Notwithstanding that, it’s clear that the aggressive schedule that was suggested at IETF 71 isn’t realistic, and we’re setting up a new schedule for re-chartering to put the EAI specs on the standards track.

httpbis — HTTP update

There was a long issue list to get through here, and some issues have been harder than the chairs and authors thought they would be to get consensus on. I’m just including some brief notes here.

The next version of the drafts will include a new registry for messages, to parallel the one for status codes.

The formal grammar is being converted to ABNF, and that’s a lot of work to get right. There’s a particular trickiness with cleaning up LWSP, removing it from where it doesn’t belong, while being sure to leave it where it’s appropriate.

Internationalization is, as always, a sticky issue. Despite standard headers, HTTP implementations have done their own things with respect to internationalization, and it’s making it difficult to decide how to go here. There are questions about support of RFC 2047 encoding, internationalization of filenames in content-disposition headers, and such. There was quite some discussion on this.

There was a discussion of issues with the use of the message header registry in HTTP. The registry is for other uses and is shared by HTTP, and there’s concern about having information in the right place, making sure that implementors read everything necessary to get the implementation right, etc.

For more on internationalization, we came to the question of what character sets to allow in new header fields. The decision was to say that new header fields MUST only use US-ASCII, but that implementations SHOULD accept ISO-8859-1 (including UTF-8 as well, at this point, did not get acceptance).

We finished with a presentation and discussion about security requirements for HTTP, an item specifically out of scope for this first round through the working group, but something that might be added to a re-charter.

morg — Message Organization standards

The MORG BOF’s goal was to review a series of individual Internet drafts and ideas that all relate to searching, sorting, and organizing email messages using IMAP, and to consider forming a working group to bring these documents through the standards process.

The BOF chairs came in with a chunky set of drafts, most of them fairly immature, some of them with significant IMAP-community support already and some that are new items. We went through the drafts, got explanations of each, and discussed them — some in considerable detail.

As a result of the discussion, it seems clear that there are enough document authors, reviewers, and server implementors to get through this lot, and enough energy to easily support a working group. There was some concern, though, first brought up by John Klensin, that this could be another set of IMAP extensions that bloats IMAP, and that really isn’t in significant demand. The problem is that we don’t have much participation by client implementors.

Chris Newman supports the formation of a working group here, and I agree. Chris would like to see the chairs manage the work by assessing the implementation commitments, including commitments from client developers, and dropping items that don’t have commitments to implementation in clients. I also agree with that idea.

The “bloat” discussion led to a suggestion to consider “IMAP5”, which would start by removing features to create a minimal protocol with necessary function, making something that’s easier to implement and get right. Randy Gellens has already started a mailing list for that, and there’s been some initial discussion.

asrg — AntiSpam Research Group

There are two primary documents coming out of this research group so far, both dealing with DNS block-lists. The first, which describes how they work, has been reworked to go on the standards track (as an individual submission, since the IRTF can’t publish standards), rather than being an informational document. The second, recommending best practices in operating and managing a block list, still needs work, and will probably go out as a BCP.

We had some discussion about whether another document should be adopted by the ASRG — the decision was not to adopt it — and that discussion led into some talk about how to focus the ASRG on new research. I will discuss the ASRG at the CEAS conference in late August, and try to get more participation from the academic community into the ASRG (possibly recruiting an ASRG co-chair from that community).

vcarddav — VCard update and CardDAV

We had the usual document status update, and went over some open issues. One that seems simple, but that merited some discussion was that dates must currently be complete (day, month, year), but there are times when one doesn’t want them to be, or doesn’t know the full date (for birthdays, for example, one might just want day and month, but no year). We decided to use existing date syntax from the comparators RFC and adapt it for VCard.

The other significant discussion was on how to handle synchronization issues, especially with collision-detection in situations with multiple copies of the information (one on a host server, one on a laptop, and one on each of two or three mobile devices, for example). Included here is the discussion of unique IDs — whether to have per-property UIDs, whether to require persistence of UIDs, how to handle the situation where a particular device or data store can’t keep the UIDs persistently, and so on.

We also had a small discussion about internationalization questions, in light of EAI. I have a suspicion that we’ll encounter effects from EAI that we haven’t yet anticipated. In the end, I don’t think they’ll be serious, but we’ll have to deal with them.

sieve — Sieve mail filtering language

This was an uneventful session for a working group that’s wrapping up its old work and preparing to re-charter to add some new work — work that is itself close to being finished, actually. We went over document status, and there’s nothing notable to say about that. The most difficult document, which this working group is picking up from lemonade, was discussed there (see below).

We talked a little about possible issues that Sieve will have with EAI — most obviously, that it will likely make scripts more complex and ugly, as a script will have to handle multiple versions of the same email address. We expect to have a sieve-eai document in the new charter.

lemonade — Mail extensions for diverse service environments

We still had a full session of final discussion, despite having thought that we wouldn’t meet here at IETF 72, but this group is wrapping up. We made some decisions on the remaining issues, and agreed to move the last document (imap-sieve) to the Sieve working group.

We finished with an incomplete discussion of imap-sieve (we ran out of time), and we’ll continue that discussion on the Sieve mailing list. Ned Freed had brought up a series of thoughts about the extension, in an email message in May, and I’ve summarized that into eight main issues.

Email standards discussion

After our experience with getting RFC 2821 and RFC 2822 updated and through the process of progressing to Draft Standard, a few people thought it would be good to consider setting up a working group chartered to progress those documents to [full] Standard, and to move other Proposed Standard documents to Draft Standard. This dovetails with my idea of creating a long-standing working group for email standards maintenance, a topic that the IAB and IESG discussed in our joint meeting on Sunday.

We have consensus, energy from participants, and IESG support to create such a working group, and we now have a mailing list to discuss a proposed charter. I suggest that we do a three-stage approach:

• In the first stage, set out a list of Draft Standards to progress to Standard, and then re-charter for the next stage.
• In the second stage, set out a list of Proposed Standards to progress to Draft Standard, and then re-charter for the next stage.
• In the third stage, set out a list of work that needs to be done that might result in new Proposed Standards for email.
• Iterate on those three stages. When there’s no immediate work to do, go dormant and periodically review the situation, waking up and picking up work when there’s work to pick up.

Technical plenary

The technical topic at the plenary this time was operational experience with IPv6. We had a panel of five speakers, who talked about their experience with implementing and operating IPv6, and answered questions from the moderator and the attendees.

Internet Architecture Board

In addition to setting up and running the technical plenary panel, the IAB reported on its work as follows:

• Informational documents:
  • We published RFC 5218, “What Makes for a Successful Protocol”, to help provide guidance for protocol designers.
  • We have “Design Choices When Expanding DNS” almost ready for final submission, giving architectural guidance use those who would use DNS for new purposes.
  • Work is wrapping up on “Principles of Internet Host Configuration”, advising on architectural issues involved in configuring Internet hosts.
  • We have a new document, “On RFC Streams Headers and Boilerplates”, dealing with an administrative issue.
• At our IAB meeting in May, we began work on several Internet architectural projects, and two of them have made some progress since:
  • Evolution of the IP Model, looking at architectural problems caused by layer violations as assumptions leak into higher-layer protocols and applications about how the IP layer works.
  • Peer-to-Peer Architecture, covering architectural questions involved in peer-to-peer protocols and applications
• We have set up a process for assigning liaison shepherds from the IAB, to better manage the liaison relationships between the IETF and other organizations, such as ITU-T, OMA, and W3C.
• We set up some new liaison relationships and other inter-organizational work.
• We have proposed a new organization of the RFC Editor job, splitting it into four functional roles that give the flexibility of contracting and managing different roles separately.

Conference on Email and AntiSpam (CEAS) call for papers, deadline extended

The 2008 Conference on Email and Anti-Spam submission deadline is approaching, and has been extended by a week, to 10 April. If you have any work to report on in the area of Internet messaging abuse and its prevention — not limited to email spam; see the topic list in the CfP, below — please form it into a paper by next week, and submit it.

---

THE FIFTH CONFERENCE ON EMAIL AND ANTI-SPAM (CEAS 2008)

Thursday August 21 and Friday August 22, 2008
Microsoft Research Silicon Valley
Mountain View, California
<http://www.ceas.cc>

FINAL CALL FOR PAPERS
 

The Conference on Email and Anti-Spam (CEAS) invites the submission of papers for its fifth meeting. Papers are invited on all aspects of electronic communication including email, instant messaging, text messaging, and voice over internet protocol (VoIP). Topics of interest include novel applications of electronic messaging, abatement of abuses of electronic messaging, spam, spit (spam over internet telephony), spim (spam over instant messenger), phishing, identity theft via messaging, viruses, and spyware.

Paper submissions can be either research papers, extended abstracts, industry reports, or law and policy papers. Submissions from practitioners and vendors are encouraged. Papers will be selected by peer review for presentation at CEAS 2008. Papers will be reviewed based on their contribution to the literature.

SUGGESTED TOPICS:

• Message filtering, blocking, authentication
  • Machine learning
  • Natural language processing
  • Adversarial learning
  • Challenge-response
  • Payment schemes
  • Disposable addresses
  • Messaging protocols
  • Digital signatures
• Evaluation
  • Corpus and benchmark creation
  • Measures and methodologies
  • Comparative tests of methods or products
• Analysis
  • Economics of spam, spit, spim, phishing, etc.
  • Abuse tactics and patterns
  • Legitimate use patterns
  • Historical data
• Message organization and search
  • Advanced calendaring and scheduling
  • Automatic foldering
  • Automatic routing
  • Summarization
  • Search
• Systems and network issues
  • Performance & scalability
  • Reliability & security
  • Archival & retrieval
• User issues
  • User interfaces
  • Usability studies
  • Messaging in support of user activities
• Social issues
  • Deducing social networks
  • Costs and benefits of messaging use and abuse
  • Other social impacts
• Industry
  • Cooperation for stopping abuse
  • Messaging and abuse reporting standards
  • Interoperability
• Legal issues
  • Spam, spit, spim and phishing, etc.
  • Identity theft
  • Privacy
  • Freedom of speech
  • Digital rights management

KEY DATES:

• Submission deadline: April 10, 2008 (10:59pm UTC) — EXTENDED DATE
• Notification of acceptance: June 6, 2008.
• Final camera-ready version of papers: June 21, 2008
• Conference: August 21 and 22, 2008

REQUIREMENTS:

Papers may be of one of two types:

• Extended abstracts (up to 2 pages) may outline work in progress, exceptional papers published for different scientific communities, original research, or industry reports.
• Full papers (up to 10 pages). Work may not have been previously published in, or under consideration for publication in any other conference or journal.

Submissions must use the CEAS electronic system at https://cmt.research.microsoft.com/CEAS2008/. The style for submissions and final papers is a two-column, 8.5 by 11 inch format. See http://www.ceas.cc/2008/format.htm for details.

Papers will be reviewed by a committee of experts from academic and industrial research centers. Accepted papers will be made freely available on the web, and will be published on CD-ROM. Authors will retain copyright of their work.

CONTACT:

• The conference chair and co-chairs can be reached at information@ceas.cc

CEAS PRESIDENT:

• Gordon Cormack
  University of Waterloo
  http://plg.uwaterloo.ca/~gvcormac/

GENERAL CONFERENCE CHAIR:

• Aleksander Kolcz
  Microsoft Live Labs
  http://ir.iit.edu/~alek/

PROGRAM CO-CHAIRS:

• Andrej Bratko
  Jozef Stefan Institute
  http://ai.ijs.si/andrej/
   
• Barry Leiba
  IBM Research
  http://www.research.ibm.com/people/l/leiba/
   
• Tobias Scheffer
  Max Planck Institute for Computer Science
  http://www.mpi-inf.mpg.de/~scheffer/
   

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.

Applications Area Architecture Workshop

This is where I was for the past two days:

More on that here, when I've had time to summarize it.

IETF 70, Vancouver

As I said the other day, I’ve been at the 70th IETF meeting in Vancouver, BC, Canada. As usual, here’s my summary of the meeting, hidden below the “click here if you want to read the boring, geeky bits” link. I’m going to try to keep this shorter than usual. Some of the items will just be notes, rather than complete sentences. But it’s still pretty long.

Read the rest of the post...

Apparea — Applications Area general meeting

1. Announcement of Applications Area workshop, 11/12 Feb 2008.
2. Suggestion of Applications Area interoperability testing events — perhaps a full day of interop testing attached to an IETF meeting.
3. Request for a utf-8 advisor for the nfsv4 working group.
4. Brief discussion of question of identity-based encryption (IBE) and user authentication in email protocols. Issue will be discussed further by interested parties at the bar later.
5. Discussion of BCP 56 (RFC 3205): is this still the best current practice? Specifically, advice that new services should not reuse existing ports, contrasted with the use of http/80 for many non-web-browsing purposes. Conclusion: BCP 56 was meant to make sure people think about these things before they choose. It should stand, though maybe an update would be useful.
6. Presentation of a metadata format for files (see draft-garcia-sipping-file-*).
7. Presentations from netconf participants (Operations and Management Area) about a modeling language. One presentation using XML schemas. Second presentation of a homegrown modeling language called YANG. There was extensive discussion, and some heat. Ultimate question: “If we did a bof with YANG documents and other docs (XSD based), do people think we should do that?” Strong consensus in favour.

Sieve Mail Filtering Language

1. Document status: base doc is un-stuck (had been waiting for internationalization draft), and this frees a bunch of others.
2. Document status: body, notify, notify-mailto, notify-xmpp are in IESG processing.
3. Document status: edit header, mime loops, refuse/reject, regex are still being worked on.
4. Discussion of notify: have to sort out IANA registry issues. Decision to use RFC 2434, and refer to it.
5. Discussion of notify-mailto: Discussion of mail loop issues. Prefer to have a separate document, not from this WG, on mail loop detection and avoidance. Ackowledge that this doc will block on that. Discussion of using null MAIL FROM here. Discussion of not retaining Received headers in notification message.
6. Discussion of IMAP-Sieve (lemonade doc): Main issue is per-user scripts. Probably move to extension, probably leave the feature for delivery scripts, not IMAP-event scripts.
7. Brief discussion of other docs, no substantial issues.

Calsify — Calendaring and Scheduling Standards Simplification

1. 2445bis is in PROTO-shepherd review. One issue: is it OK to have RDATE < DTSTART ? Decision to take the issue back to the mailing list.
2. 2446bis (iTIP) issues discussion. Some small items.
3. Major discussion on RANGE parameter with day changes in recurring meetings.
4. Major discussion on SEQUENCE number — what its purpose is and how it’s used.

HTTPbis — HTTP updates

There were two HTTPbis sessions, but the second one conflicted with DKIM, so I missed it.

1. Presentation of HTTP history and lessons learned.
2. Charter review. Aiming to bring HTTP to “Draft Standard” status.
3. Discussion of the partitioning of the document into 8 parts.
4. Discussion of issues...
5. Loooooooooong discussion on ABNF conversion and logical whitespace (LWS) in ABNF for headers.
6. Some discussion of header-value internationalization. Decision: document reasonable RFC 2047 usage explicitly.
7. Brief discussion of character encoding defaults — existing language conflicts with MIME specifications. Noted that “guessing” is the best mechanism in practice, but someone pointed out that guessing wrong can cause problems that include security exposures.
8. Out of time, remaining items left for second session:
   • ETag in status messages
   • Clarify “requested variant”
   • Header line folding
   • Content negotiation for media types
   • Repeating single-value headers

IPR — Intellectual Property Rights

This session moved right along and ended early. The documents are essentially done, discussion wrapped up the remaining issues, and set us up for closing the working group. There were three proposals for new work; two were soundly rejected, the third had agreement that it should be pursued as an individual submission.

DKIM — Domain Keys Identified Mail

Tony Hansen and Murray Kucherawy presented the results of a DKIMinteroperability workshop that was recently held in the Dallas area.20 companies and organizations participated, and the interoperabilityresults were generally very good. A few minor issues were uncovered:edge conditions in the “relaxed” canonicalization algorithm, an ABNFerror, and similar things. We will submit errata to correct most ofthese issues, and add text to the “deployment” document for some others.

Jim Fenton presented a status update on the SSP draft, giving a reviewof recent changes and going over the open issues. Jim used quotes fromtwo “customers” early in his presentation, which prompted Dave Crockerto comment, and there was some significant discussion of theappropriateness of optimism in this regard, of some aspects of the SSPdraft that Dave considers wrong, and of Dave’s review of SSP, which he’dposted to the DKIM and Apps-Review mailing lists earlier that day. Further discussion of the review has been taken to the DKIM list (andthat discussion has already been quite active).

On the open issues: there was some discussion here and there, but a lotof discussion on one issue in particular: #1399: Clarify i= vs. SSP,“...need to provide the exact semantics in SSP of how a receiverdetermines whether a DKIM signature satisfies the SSP criteria or not.” The result of the discussion is that the chairs think we need one moreround, no more than a week, of discussion on the mailing list before wedetermine a closure for this issue.

We plan to start working-group last call after issue 1399 is closed andafter discussion has finished on Dave Crocker’s comments.

Doug Otis presented a (non-WG) draft, “DKIM Third-Party Authorizationfor Sender Signer Practices”.

Murray Kucherawy presented (non-WG) drafts dealing with passingauthentication results down the line (including all the way to the MUA). There was brief discussion about his draft for using an ESMTP extensionto pass the information, in order to reduce attacks against MUAs behindnon-compliant MTAs.

Tony Hansen presented a very drief status report (and call for reviews)on the Overview document and the new spin-off, Deployment andOperations.

EAI — Email Address Internationalization

1. UTF8headers doc:
   • Issue with specificatin of NO-WS_CTL. Decision to refer to 2822, note upcoming 2822bis.
   • Issue with normalization. Decision to refer to draft-klensin-net-utf8.
2. Core docs (UTF8headers, DSN, SMTPext) now ready to go to IESG.
3. Downgrade doc:
   • Issue with simple downgrade procedure. Decision that current section 8.1 is adequate.
   • Suggestion to split appendix A into a separate doc. Take discussion to the mailing list.
   • Needs review by people who have implemented it, then it’s ready for working-group last call.
4. IMAP and POP docs
   • Should we move “upgrading” — conversion up to UTF-8 — to clients, and remove it from here? Clients are better equipped to do whatever conversions are necessary, and clients know what they want. Also, conversion breaks message signatures. Consensus to remove, let clients do it.
   • Current IMAP draft uses lemonade “ENABLE” IMAP extension.
   • Switch POP to use UTF-8 “mode”, like IMAP, instead of duplicating commands? Decision: yes.
5. Discussion of whether “mailto” URL should be adopted now. Take to the mailing list.
6. Discussion of possible interoperability tests at one of the next IETF meetings.

lemonade — Enhancements to Internet email to Support Diverse Service Environments

1. Report on second interoperability event. Good results; things that were found broken at the first event have since been fixed.
2. Mostly covered document status and minor updates.
3. Some significant discussion on CONVERT, NOTIFY, and ENABLE.
4. Most of the discussion of ENABLE involved when it was allowed. Decision: only in authenticated, non-selected state.
5. Brief review of profile-bis status.

SAVI — Source Address Validation Improvements BOF

Problem statement: IP source addresses can be spoofed. Packet delivery is based only on destination addresses, to the spoofed traffic arrives, and hurts (attacks/threatens) the destination. It’d be nice to stop the spoofing, and existing solutions aren’t sufficient.

There are product solutions for ipv4, sold by Cisco and others, that work within a single switch. The working group wants something standard.

The trouble, as I see it, is that the charter is too limited:

Specifically, the group shall define solutions such that hosts attached to the same router cannot spoof each other’s addresses. The following assumptions apply:

• The WG considers only solutions on layer-3-aware Ethernet switches
• Two solutions are needed, one for IPv4 and another one for IPv6
• The IPv4 solution depends on tracking the DHCP traffic on a port
• The IPv6 solution depends on tracking the Neighbor Discovery and DHCP traffic on a port
• All address assignment mechanisms in IPv6 need to be supported, including stateless, stateful, privacy, and so on
• The solutions are turned on for host ports by configuration, and do not apply to routers

The WG recognizes anti-spoofing deployment efforts, motivation, and best practices development in various forums around the world (including RIPE). The WG is only chartered to deliver two specific solution components that such efforts could employ. The bigger questions are out of scope.

Normally, I would worry that a charter were too broad, but this just doesn’t seem to solve a problem that I think needs a standards-track IETF solution. Any company can already sell a switch with anti-spoofing technology in it. Another company can sell another, with different technology. There’s no issue of interoperability that I can see. The most I can see a need for is a BCP to tell hosts what to do to avoid running afoul of existing anti-spoofing techniques. If there’s a need for a WG to do that, OK (but I’m not convinced). But I really don’t see a standards-track issue here.

CSI — Cga & Send extensIons BOF

I have little to say about this. They have a solid idea of what they want to do, and a good plan for it. Almost everyone agreed that a working group should be chartered for it, they had some 20 or so people who said they’d be active participants, and 8 or 10 who said they’d be document authors. This seems ready to be chartered as a working group.

Peppermint — Provisioning Extensions in Peering Registries for Multimedia INTerconnection BOF

This one is decidedly less well baked, but they said that up front. They have good preliminary ideas about what they need, and used this session to bat it around in preparation for writing a draft charter. They seem to have succeeded in that, so we now have to see what the draft charter looks like.

CEAS 2007

I've just returned from the Conference on Email and AntiSpam (CEAS 2007), in Mountain View, CA. I've been on the program committee for the past two years (translation: I've been a paper-review slave), and have been asked to be program chair for next year (translaton: slave driver). We're trying to expand the scope of the conference, but more on that later. First, a summary of the highlights of this year's conference... this is only my opinion of the highlights, with no attempt to cover everything. For more about any of these, see the associated conference papers.

We started with Wietse Venema as the invited speaker. Wietse's the author of the email program Postfix, and he talked about the development of Postfix, including the reasons he did it and the things he learned from it. It was a good talk, and I'm not saying that only because he works upstairs from me.

Other talks of note:

Mark Dredze from University of Pennsylvania talked about the work he and his colleagues have done in cutting the overhead of analyzing email images for spamminess. Their method is basically to figure out the analysis techniques and features that will take too long for this image and eliminate them in favour of the ones that will be faster and work well enough, recognizing the characteristics of the images that lend the image to be more efficiently analyzed by certain algorithms.

Zhe Wang from Priceton University gave a complementary talk about improving efficiency of spam image analysis by separating out a set of “features” from the images, and then using the features to analyze the similarities among images. That allows them to do the analysis with a more limited set of features, streamlining the process.

Lisa Johansen of Penn State discussed a technique that's being used more and more, analyzing email to detect common social networks — in this case, communities with common interests.

Amad Thomason, of the company Six Apart, discussed blog spam, and the issues it raises.

Enrico Blanzeri of the University of Trento (Italy) discussed their experiments with coupling a nearest neighbour algorithm with a support vector machine filter to improve the effectiveness (and decrease the false-positive rate), but at a high computational cost (every message has a different neighbour set, requiring recomputation of the SVM).

Zulfikar Ramzen, of Symantec, gave us a rundown on trends in “phishing” messages in 2006.

Aaron Zinman, of the MIT Media Lab, talked about spam-related issues in social-networking sites such as MySpace, showing that it's much harder to put a black-or-white evaluation on things in that universe.

Vijay Balasubramaniyan of Georgia Tech presented a method of using social network techniques to establish “reputation” for voice-over-IP calls, and using the reputation to fend off potential spam in VoIP telephony.

Victoria Bellotti of the Palo Alto Research Center (PARC) showed us a system they're working on, called TV-ACTA — an activity-centered interface for task management, tying together email, meeting agendas, calendars, and associated files in one user interface that allows you to managed all the information associated with a task or project in one place.

Of course, I won't mention the wonderful talks by my colleague Rich Segal and me. We kicked butt.

On to next year:

We still have to find one or two more program co-chairs, and then look at how to expand the reach of the conference, getting more papers on different kinds of spam and malware, and on other, non-spam aspects of email. We're also looking at venues for 2008... it might actually not be on the west coast next year, woo-hoo!

IETF 69, Chicago

I've just spent the week at the 69th IETF meeting in Chicago. It was the best of weeks, it was the busiest of weeks. And here's a hint for those arranging meetings: regardless of the assurances the hotel gives you, do not believe that the fact that they're doing serious construction and renovations will not interfere with your meetings. A number of sessions were severely disrupted by the noise of jackhammers. The hotel kept promising that it would stop during the meeting hours, but at least through Wednesday it continued.

And I talked with a Chicago Tribune reporter on Thursday (as did the IETF chair and the IAB chair), and his article about the meeting came out in Friday's paper, on the front page, above the fold. Very cool. Here's the electronic version of the article. It's pretty good.

Anyway, here's my summary of the meeting, hidden below the “click here if you want to read the boring, geeky bits” link.

Read the rest of the post...

For me, the week started on Saturday, as the IETF management (the IESG and the IAB) spent the afternoon and evening with our counterparts from ITU-T, the standards body of the International Telecommunication Union. The goal was to meet them, to discuss some technical issues, and to set up a context for working together more effectively. I know that I made some personal contacts in the course of the day that'll be useful to the standards work that I (and those contacts) do, so the meetings served at least part of their purpose. Beyond that, time will tell.

On to the highlights of the standards sessions....

lemonade — Enhancements to Internet email to Support Diverse Service Environments

As usual, we had two busy, full lemonade sessions. We spent the time reviewing document status and updates, and discussing issues with the latest versions. We took a good chunk of the time — about the first hour with a presentation and discussion about the OMA Mobile Email (MEM) Enabler development status. That was followed by a brief discussion of CONVERT and a more extended discussion of NOTIFY, working on resolving a fairly long list of open issues with the document. There wasn't really serious contention, but a number of things needed to be batted around, so it was a good discussion. Streaming needed essentially no discussion.

We started the second session with about five minutes on Message Events, and then hit my IMAP-Sieve draft, which needed quite some time on the open issues (one of which was discussed in more detail in the Sieve session, summarized later). Issues:

• Should we allow transient Editheader functions, for use in prepping the message for Redirect? Resolution: This can be added later, as an extension, if we decide we really do need it.
• Should EXPUNGE be an IMAP-Sieve event? It currently is not. Problems: it introduces inconsistencies and difficult-to-explain (and difficult-to-understand) conditions. But it's not just theoretical; Alexey already has a need for it. No significant support for it in the room, though. Resolution: take it to the mailing list, put a two-week timeout on the discussion, and decide then. If there's no clear choice then, the default will be to consider it as an extension later. (I've already posted the question to the mailing list.)
• Is it clear enough that the meanings of some Sieve actions are different here than in the base Sieve spec, because the context is different? Resolution: current document text is OK.
• Should the references to optional features be normative (they are currently not). Argument: some of the references say things like, “if [action x] is supported, then [action x] is valid in this context,” and that strikes me as non-normative. Chris (Apps area AD) considers that to be in the “grey area”, and suggests taking the less risky path (from a process point of view) of making the references normative. So agreed.

We finished by discussing Profile-bis. Should we add Streaming? No, not a requirement for OMA, and not worth holding Profile-bis up for. Should we drop Idle in favour of Notify? No, already in Profile, so already supported, and essentially it comes “free” with support for Notify anyway. Should we add Quickstart? Needs implementations before deciding; leave it out for now. Some discussion of notifications ensued, with references to Friday's “Biff” BOF.

DKIM — Domain Keys Identified Mail

The meeting's goals were to move the Sender Signing Practices specification along, and to highlight the Overview document and bring the working group's focus to it. We started with a review of document status:

• DKIM base protocol specification is now RFC 4871.
• SSP requirements document is with the IESG, working out some last-call comments and an AD "discuss".

Jim gave a review of the SSP specification, the latest version of which has just been accepted as a working group document, draft-ietf-dkim-ssp-00. Jim covered the principal changes to the document since the last review, in Prague, and discussed three main items in detail:

• Issues involving DNS wildcards.
• The SSP lookup algorithm, as documented in the current spec.
• What SSP publishers can say, outlining, in particular, a new option called "strong", in addition to the original "strict" (if it stays, the name will change).

There was some discussion of the algorithm, but most of the discussion was about what can be stated, and what the relative meanings of "strict" and "strong" are. We considered the idea that we have developed statements that we think the signers will need, but we have to validate them with those who will benefit the most from signing and declaring signing practices. Dave and Phill agreed to interface with MAAWG and APWG, respectively, to try to get their opinions on this. Phill also stressed his opinion that SSP statements should be declarative, not imperative ("I am a financial institution," rather than, "I would like you to delete mail that appears to be from me that is suspicious.").

Tony presented the status of the DKIM Overview document, currently draft-ietf-dkim-overview-05, which has had a lot of work from its authors but which has had relatively little feedback from the working group. The discussion centered on the goals of the document, and strengthened the result from the Prague meeting: the document should be split into multiple ones, to better achieve its several goals. In particlar, there's normative text in the document now, which isn't appropriate for an informational document. Some of that will be resolved by changes to the text, but some may be resolved by splitting a BCP or standards-track document off from the informational portion. The authors will work on this, and we'll keep the ADs involved as we consider changes to the charter for this.

In the few minutes at the end, Murray led a brief discussion of his authentication-results draft, which the working group will follow, and will consider adding to its charter if we (and the ADs) decide it's appropriate.

Sieve — email filtering language

We had minor discussion of the base-spec update, Editheader, MIME Loops, Reject/Refuse, Environment, and iHave. The most significant discussion in Editheader involved what requirements we place on which headers should not be allowed to be changed, and which should be. That went on for a while, with arguments back and forth — the proposal is to say that Received headers MUST NOT be changeable, and that changes to other headers MAY be disallowed by local policy; the question is whether we should specify headers that MUST be changeable, so a script can be assured of something it can change. In the end, we decided that the text that's currently suggested is best.

We had a status update on Notify, and some discussion of Notify-Mailto and the inclusion of Auto-Submitted headers. Conclusion: I will change Notify-Mailto to have it define an RFC 3834 extension (and an IANA registry) with a “Sieve-Notify” value for Auto-Submitted. Appropriate text will go into the spec to define the inclusion and usage of that field.

There was a good deal of discussion on the changes to IMAP-Sieve, mostly focused on the Metadata changes. My changes have the metadata contain the name of a Sieve script; there was a suggestion (and some consensus) to also allow the metadata to contain the script itself — probably with a level of redirection, where the defined metadata entry gives the name of another metadata entry that contains the script. The main point of contention is the need to have more than one script active at once. Randy gave some good reasons for that, involving multiple clients each needing to have their own scripts active, and each being unable to interpret the scripts of the others. Randy will write text to implement what he's asking for.

We spent some time on External Lists, continuing the discussion from Prague about whether having URIs makes sense. We batted operational examples around, and considered the question of authentication to the targets of the URIs. We also discussed limiting Redirect, aiming to prevent misuse and fan-out attacks, but having the side-effect of eliminating the ability to use Sieve to implement a mailing list. This tied into the External Lists discussion too, considering the concept of getting an external list to which a message would be redirected to. We decided that while there are legitimate reasons to use more than one Redirect on a message, we do not want to position Sieve as a way of implementing mailing lists.

We briefly discussed an in-person interoperability event, and decided that it wasn't necessary: any interoperability testing for Sieve can just as well be done by network.

EAI — email address internationalization

There's not a lot I want to say about this. The session was devoted to discussion of the drafts, as usual, and the open issues that need to be resolved. It was a productive meeting, and the schedule for moving the drafts on in the process looks good.

The main thing I want to record here was an issue in the Downgrade specification, involving what happens to messages with DKIM signatures when the messages are downgraded. There was clear consensus that the document needs to point out the issue. But whether the document should make any suggestions about what to do to meliorate the issue (such as having the downgrader verify the DKIM signature and re-sign on its own behalf) wasn't clear. Chris, as Apps area AD, said that he thinks we have to say something about the interaction, but he isn't going to make a declaration of what that should be. Dave thought that this isn't the place to give DKIM implementation advice. I commented that I'd normally agree with that, but these are experimental specifications, and it would serve us well for them to suggest what experiments might be useful.

I think we decided to include some non-normative suggestions, and that any suggestions that involve DKIM will have to be reviewed by the DKIM working group.

SAAG — Security area open meeting

The SAAG meeting always starts with reports from all the security-area working groups, and then has some invited talks. There were two invited talks this time:

1. John Klensin presenting internationalization issues related to security.
2. Morris Dworkin, from NIST, presenting a proposed variant of the Galois Counter Mode, an authenticated encryption mechanism.

John talked about the problems that Internationalized Domain Names (IDNA) was meant to solve, the problems with the first version of IDNA (IDNA2003), and the changes in the update that's under development (IDNA-bis). There weren't any surprises in his presentation for anyone who's been following the work, and there really weren't any security-specific things in it, apart from occasional references to passwords (and the idea that internationalization problems might actually be beneficial for passwords). There was some discussion after the presentation, but, again, nothing especially notable and nothing really security-related.

The GCM presentation was a crypto-technical one, detailing a modification to an encryption algorithm intended to opimize it. I'm not a crypto expert, so I could follow the presentation somewhat, but only somewhat. After the description of the modification, its effects, and its performance, there were some questions and comments from the audience. The discussion involved tag truncation, key size, the speaker's point about “relaxation of IV validation”, and possible other variants of the algorithm (maybe better optimized than this). At the end, the Security area directors asked who in the room thought they could use this variant in their security protocols. No one raised a hand.

HTTP-bis BOF — Updating and advancing HTTP standards

The purpose of the BOF was to propose a working group — they had a proposed charter — to advance RFC 2616 to Draft Standard, along with associated considerations and updates. The principal associated issues were (1) the HTTP authentication mechanisms, (2) cookies (scope and domains), (3) HTTP caching (and association with "logout"), and (4) ETags (involving CalDAV/CardDAV issues).

There were presentations on each of those issues, some of which were a bit hard to follow because of a combination of jackhammers and quiet speakers. The bulk of the discussion then fell on the scope of the work — how much of the numbered stuff above should be included while updating and advancing RFC 2616. In particular: should the HTTP protocol update include the authentication/security issues. Consensus was that the security-related work should be separated, as those with the expertise in the protocol aren't the same as those with expertise about the security aspects.

There was also consensus to include cookies in the HTTPbis work.

It looks like the plans are fairly well baked, and the charter is pretty solid. There was also a good show of hands for people willing to do the work here. It seems that formation of a working group is mostly assured, and that's good.

APM BOF — Application Performance Metrics

The APM BOF's goal was to explain the need for coordination in the definition of performance metrics for higher-layer protocols (SIP was an example given), and to explore the interest in working on such definitions and to look at how to do it (directorate vs working group). Their problem statement points out that the people working on the protocols often do not have the expertise to define performance metrics, and that the documents addressing them do not get much attention (people would rather spend the effort on the protocol).

That sounded good. Unfortunately, once they got past that everything started raveling. The details were ill-defined, there were far more people there than the chairs expected and they asked questions for which the answers were inconclusive or unsatisfying. They proposed a set of options, with apparently no process guidance on how appropriate these options are:

1. Form an APM Directorate that would consult with and advise working groups on the development of APMs.
2. Form a long-running APM working group, which would wake up at appropriate times and develop the APMs in partnership with the protocol working groups.
3. Form a short-term APM working group, which would write a "BCP/framework RFC" and then “evolve” into (1) or (2).

In the end, the chairs had a series of questions that they didn't really have time to get to, which is just as well:

• Who thinks the IETF should work on developing performance metrics?
• How should we do it?: (1), (2), or (3), above, or none of the above.
• How should the choice picked in the the previous question operate?

They got many hands up for the formation of a long-running working group, but I'm sure the people “voting” didn't really know what they were suggesting, or what the process issues are with it. It was not an appropriate question to ask a group of BOF participants.

I think what needs to happen with this is that the organizers should work with the Ops area ADs to better define what they want to do and how they aim to do it, and set this up as a more concrete proposal that defines how it fits into the IETF process. If that happens, they might come back for another BOF that can better explain the result it wants to get, and how it'll be implemented.

vCard and CardDAV BOF

The goal of this BOF is to explore a working group to revise/update the vCard standards, and to define a protocol for storing vCards and moving them around. A number of issues with the current vCard definitions were highlighted, and some proposed updates reviewed:

• Issues:
  • Internationalization (using UTF-8).
  • There are currently too many combinations of parameters for things like TEL(ephone).
  • There's no way to indicate locale for address formats (local differences in the ordering of street address, for example).
  • There's no namespace for vendor extensions.
  • Properties need review — it's been nine years, and things have changed (for example, how many people specifically have car phones now?).
• Proposals:
  • Merge RFCs 2425/2426 into one document.
  • Merge current extensions into the document too.
  • Define a new MIME type, text/vcard, which defaults to UTF-8 data.
  • Clarify allowed parameter combinations.
  • Provide unique ID on each multi-occurring property to aid synchronization.
  • Geographic properties should be parameters on ADR, and add a MAP parameter (map program URI).
  • Define IANA process for registering vcard properties.
  • Define an XML variant of vCard syntax.

CardDAV defines vCard extensions to WebDAV, based on work done for CalDAV. Features:

• Defines a well-structured data model for storage of vCard data.
• Defines new reports for querying and retrieving vCard data efficiently.
• Defines a new collection type to represent an address book.
• Uses WebDAV ACLs for access control.

Cyrus is currently addressing mailing-list comments in the working CardDAV draft, then it's ready for last call (easily done, using CalDAV as a starting point). Next: work on synchronization and nofications (maybe reusing stuff from mail-store notifications work).

They covered considerations of using LDAP for vCard access, mainly looking at the differences between the vCard model and the LDAP model. They also noted that there's no standard LDAP schema for vCard information. Another issue is that vCards need write access (at least by the owner), and write access to LDAP databases by users is not common. Conclusion: LDAP is probably not good for vCards... but it's still probably worth defining a standard mapping. Should this be in scope for a working group formed here?

There seems to be enough demand for this work, and enough people to work on it. It seems to me that a working group is appropriate here.

IETF 68, Prague

The IETF meeting in Prague is over, and here's my usual meeting report. My apologies to most of you, who will skip the bulk of this entry.

I can't even tell you much about the city yet. This afternoon I'll start seeing some of it, apart from the little I've seen on the way to and from dinner — the photo to the right (click to enlarge) is of the municipal house, on the way to having dinner in a restaurant there. I get four full days, after today, and I'll be taking lots of pictures. So expect some to be posted here over the next few days if the hotel I'm moving to gives me Internet access. If not, please excuse the gap, and come back Wednesday when I'm home and posting again. Either way, see you soon.

As before, I've put the full meeting report off of this summary page, so click below if you want to see it.

Read the rest of this post...

apparea — Applications Area general meeting

The Applications Area has a new area director beginning with this meeting: Chris Newman is taking over Ted Hardie's slot. Thanks Ted; welcome Chris!

We reviewed the working groups that have finished their work and closed (like OPES, yay!), and those that are finishing up. Eric Burger talked about the Applications Area review team, volunteers to review documents when the authors ask for an apps area view of them. Then we had brief presentations on some BOFs coming up for the week, as well as some other work that needed some presentation/discussion.

In that last category, Ted and Chris asked me to present some upcoming work on a notifcation framework, which we'd like to start as an effort to build an email notification system around a common notification architecture that could be extended for other protocols and uses. After some discussion, we took a poll of the room and found a sufficient group of people who are interested in working on it.

sieve — email filtering language

We reviewed document status and discussed open issues with the documents. We spent about half of the time on two documents about notification (which will be part of the apps-area notification work, if that happens). Discussion was minimal for MIME loops, Date, Environment/Notary, and Ihave. Discussion of Metadata was mostly about the “:create” argument it adds to the “fileinto” action — I don't think it'll be very usable, since a script that tries to use it will fail completely if the extension isn't available. In the end we decieded to leave the option in.

Finally, there was significant discussion on Alexey Melnikov's proposal for externally stored lists. Alexey had planned to use a “list name” string, the meaning of which depends upon the implementation. I very strongly prefer using a URI, so that the script has a chance to be portable. There are certainly disadvantages to that, as well, so there was a good bit of discussion on it. We'll need to discuss this more on the mailing list.

We also had an after-hours session, where we talked about what we have to do in order to complete the interoperabili