IETFの人々と協力しながらHTTP仕様のRFC2616を改定するのに過去1年と半年においてかなりの時間を費やしました。Roy Fielding氏の分割されたドラフト(source)は新しい仕様の基礎をなる可能性が高い。しかしながらその認可書(source)の範囲はかなり制限されているように見える。
ワークグループはRFC2626を下記のように改良する。Mark氏はこれが更なる変化をもたらすと信じている。
*エラッタとアップデートを行う(例:リファレンス、IANAレジストリ、ABNF)
* 仕様の誤解を招いた編集的な問題を修正する
* 適合性条件を明確にする
* インタオペラビリティに影響を及ぼす不明瞭性を排除する
* 既存の拡張メソッドを明確にする
* 広く実装されていない、また極度にインタオペラビリティに影響を与える機能を排除する
* 必要な部分に実装アドバイスを加える
* HTTPのセキュリティプロパティと共通のアプリケーション用にそれに関連した強化点(例:ベージック、ダイジェスト認証、クッキー、TLS)をドキュメント化する
そうする際に下記の事項を考慮する
* 実装者の実装
* HTTPの実践使用
* 既存の実装とデプロイメントにおける影響
HTTPはブラウザのためのみのプロトコルとして始まり、そのタスクは比較的シンプルなものでした。そうです。持続接続と多様なリクエストは事を少し複雑にするのですが、その使用ケースは10年前に比較的同じような実装を行っている人々はそれらの一般的なケース用に内部動作を確保することができました。明らかに標準が数年間の使用の後に改定される際に、いつでも起こりうる通常のタイプのアップデートとの明確化もあるだろう。現在の標準の裏にある元々の設計決定は、デベロッパ、ユーザ達にとって必ずしも明晰であるとは限らない。だからこれら範囲が改善される必要があるのだとMark氏は指摘している。現在新たな世代のデベロッパ達は当時考えもされていなかった事にHTTPを使用しています。AJAX、Atom、CalDAV、"RESTful Web Services"とそれらと同類のものがHTTPができる事の限界を押し上げています。RFC2616が急いで発行される中、あまり注意深く見られなかった暗がりの部分が今明るみに出てそれらに対応する事で、HTTPの使用が分岐するのを助長するよりもむしろ新たな使用を補助するでしょう。
だからWGの焦点が実装者に合わされている一方、私にとってそれはApache、IIS、Mozilla、Squidとその同類への対応を意味していなければいけないわけではありません。それはまたOAuth(source)とAtom Publishing Protocolのような新たなプロトコルを構築するために人々がHTTPを使用すると言うことを意味しているのです。それはあまり一般的でない方法でHTTPを使用している大規模なサイトを運営している人々を意味しています。
原文はこちらです:http://www.infoq.com/news/2007/12/http-revision