July 31, 2007

IETF highlights: HTTP Bis and BIFF BoF

Event Driven Architectures, IETF, Security By: ams

The 69th IETF was last week in Chicago (windy and good pizza, who knew?). The two highlights for me were the HTTP Bis BoF and the BIFF BoF. A BoF is a “Birds of a Feather” meeting used to gauge interest and feasibility towards forming an IETF working group.

The HTTP Bis BOF was initially proposed simply to do editorial fixes and feature removal on RFC2616. The scope expanded slightly to include documenting HTTP’s security issues and possibly some work on cookies. I’m glad of the expanded scope, personally — I think it’s the right group to think about security and cookies even if no fixes come about immediately. HTTP is rife with security problems that we’ve become better at avoiding in more recent protocol work. Luckily there’s also a general body of knowledge how to deal with most of these problems, so the documentation of the problems and common solutions shouldn’t be too badly contentious.

The work on revising RFC2616 itself is likely to be quite contentious, however. People have very different models of HTTP, what it is or should be or could have been. I got enmeshed once in a disagreement between Roy Fielding and Jeff Mogul about whether the HTTP data model should include the concept of instances or not. My original problem was a proposal to use the Content-Type request header to refer to the type of a resource rather than the type of the body of the request. The discussion soon entered into the definitions of entities as well as resources, bodies, content and many other terms which are less well-defined in RFC2616 than you’d think they are. The REST model of HTTP, described in Roy Fielding’s dissertation, is one theory and widely admired, but it was written in 2000 — a year after even RFC2616 was published, thus too late to have served as a shared model for any version of HTTP.

The BIFF BoF: this is not some obscure acronym but named after the UNIX program (itself named after a dog) that notified the user when there was new email to read. It may sound trivial to try to replicate this functionality in a standardized way but it’s not so trivial: today email servers are not necessarily in the same administrative domain as the user and may run over IMAP, POP3 or HTTP. I use three email accounts daily: my main work account is run by a hosted email service provider over IMAP, another account is GMail and I use the Web interface, while a third account happens also to be IMAP. POP3 users can learn about new mail when their clients poll, which can be configured. IMAP clients often hold connections open to IMAP servers and features such as IMAP IDLE make it easier for an IMAP client to quickly learn about new mail. But not all mail servers are IMAP servers, and not all mail clients (or status tools, etc) are IMAP clients.

My involvement in the HTTP Bis BoF is that I’m the sponsoring Area Director. I’ll be handling the request for a WG including requesting IETF last call and IESG approval, assuming the charter discussions here continue. I’m a participant in the BIFF efforts — having written an Internet-Draft proposing an architectural model — so my colleague Chris Newman is the sponsoring AD for that one.

  • blog

  • companies & initiatives

  • February 2019
    M T W T F S S
    « May    
  • archive

  • categories