Tuesday, March 21, 2006

.

IETF65, day 1 (Monday)

My blogs this week will be about the Internet Engineering Task Force meeting this week in Dallas. The conference started off with a bang, with a long string of thunderstorms that caused delayed and cancelled flights in, and severe flooding here. Many attendees couldn't get to their hotels, as the roads in the area were impassible — some under several feet of water. Still, the Sunday evening reception happened, and by this morning we had bright, sunny weather, and the waters had receded. Doves were sighted.

Each day this week, I'll be posting brief notes on the IETF sessions from that day. For my readers who aren't interested in that: come back on Saturday for more of the other stuff.

Applications Area General Session

The meeting started with introduction of the new Applications Area Director, Lisa Dusseault, and a layout of the division of work between the two ADs. Then, as usual, was a quick review of some new Working Groups and BOF sessions. The remaining time was mostly divided among four topics:

  • CRISP Internet Routing Registry Proposal; a proposal presentation was given, with little discussion following.
  • FTP Internationalization; this mostly amounted to a discussion of whether a third transfer option should be considered (binary, ascii, and "something else"), or whether we should just go back to the idea that FTP transfers "blobs", and just use binary always (lots of issues of linends there).
  • Distributed Multimodal Synchronization Protocol; a proposal presentation was given, with little discussion following.
  • Discussion of the question of what problem DIX (Digital Identity eXchange) is trying to solve. The discussion introduced some use cases, and the main result was to repeat the statement at the beginning of the discussion: that this is actually one of the first issues for the DIX BOF itself, so I'll have more notes on that in tomorrow's post, after the session.

DKIM — Domain Keys Identified Mail

Discussion of issues for draft-ietf-dkim-threats; few issues left, open issues covered, document should be ready for final version next week.

Discussion of issues for draft-ietf-dkim-base. Several were minor. Main issues:

  • Issue: "r=" tag, specifying a "report-to" entity. Defer consideration to SSP document, but then we considered whether to also have it in the key record (or something reachable through the selector). Further discussion to go to the mailing list.
  • Issues: transition plan for new crypto algorithms, and specifically, transition from SHA-1 to SHA-256 hashes. Some discussion here, but discussion ultimately deferred to the general issue of multiple signatures. Consensus among the security folks is to let the verifier decide which crypto is "best".
  • Issue: hashing the message separately and putting that hash into the header, then hashing and signing the header. Consensus for, will take to the mailing list.
  • Issue: some popular mail implementations do things that make header canonicalization of "simple" problematic. Informative text will be added to suggest what the signer should watch for when using "simple" to sign.
  • Lots of other minor issues, as noted above.

"lemonade" &mdash enhancements to Internet email to support diverse service environments

  • Discussion of OMA liaison.
  • Document status: draft-ietf-lemonade-notifications; some significant discussion about encryption of notifications.
  • Document status: draft-ietf-lemonade-convert; little discussion.
  • Document status: draft-ietf-lemonade-imap-sieve; little discussion.
  • Document status: draft-martin-managesieve; discussion of whether use of managesieve would be required or managing the filters, or whether we can set it up to allow other mechanisms.
  • Document status: draft-ietf-lemonade-vfolder; discussion of effect of vfolder on "regular" IMAP clients. Possible solution is that vfolders only appear in specific extended list commands. Initial consensus to do that, but there are some concerns; taking it to the mailing list.
  • Document status: draft-ietf-lemonade-search-within; several issues, some discussion.
  • Discussion of compression; recent topic on the mailing list. Application MUST compress, transport MAY compress. Result document was draft-ietf-lemonade-compress. Much discussion about which compression is "best" when, and which parts of the system "know". Loooong discussion here.
  • The remainder is for the second session...

EAI &mdash Email Address Internationalization

This was divided into "problem/framing" and "solution" sections. Under "problem/framing", were brief discussions of

  • draft-klensin-ima-constraints
  • draft-alvestrand-i18mail-scenarios
There was some discussion that the scenarios document should be merged into the framework document (below).

Under "solution":

  • draft-klensin-ima-framework
  • draft-yeh-ima-utf8headers
  • draft-yao-ima-smtpext
  • draft-yoneya-ima-downgrade
  • draft-newman-ima-pop

There was some significant discussion about the consequences of using UTF8 in certain of the various message headers. There was also significant discussion of quoted strings in email addresses. There was quite a bit of discussion of POP issues, including debate about whether to include the optional "top" command in the UTF8-enabled list, and whether to use separate UTF8-enabled commands or to have a "UTF8 mode" that affects the operation of all POP commands.

Finally, there was discussion on "the partition issue," specifically, as quoted from the agenda:

The claim has been made on the mailing list that changing the form of Internet mail addresses will partition email space unless gateways are part of the core standard. We should discuss this issue explicitly.
No resolution here; more discussion needed on the mailing list. Someone pointed out, in particular, that we must give more consideration of right-to-left languages (like Arabic and Hebrew), which may introduce different considerations when coupled with the left-to-right structure of email addresses.

AntiSpam Research Group

This was a short meeting, and mostly a status update. We briefly discussed a few "best practices" documents, including one about DKIM that ASRG chair John Levine had mentioned in the DKIM session earlier in the day. We also discussed some research ideas, such as message tagging and message categorizing.

No comments: