MPLS上のレイヤー2フレームの伝送に関する歴史文書がRFC 4906として承認された。
　RFC 4906はフレームリレーやATM（Asynchronous Transfer Mode） AAL5（ATM Adaption Layer 5）、イーサーネットといったレイヤー2のPDU（Protocol Data Unit）のMPLSネットワーク上での伝送、SONET（Synchronized Optical Network）回線のMPLSネットワーク上でのエミュレーションサービスについて述べている。RFC 4906が述べているのはいわゆる「draft-martini」プロトコルであり、エッジ間疑似有線エミュレーション作業部によるRFC 4447その他の関連仕様によって置き換えられている。

　MPLSネットワーク上のレイヤー2フレーム伝送用のカプセル化手法に関する歴史的文書がRFC 4905として承認された。
　RFC 4905はフレームリレーやATM（Asynchronous Transfer Mode）、イーサーネットといったレイヤー2のPDU（Protocol Data Unit）をMPLSネットワーク上で伝送するためのカプセル化手法について述べている。RFC 4905が述べているのはいわゆる「draft-martini」プロトコルであり、エッジ間疑似有線エミュレーション作業部によるRFC 4447その他の関連仕様によって置き換えられている。

　DomainKeysに関する歴史的文書がRFC 4870として承認された。
　DomainKeysは電子メール公開鍵技術とDNSを用いた電子メール用のドメインレベル認証フレームワークであり、DomainKeysによって送信元と内容を探査できるようになる。RFC 4870はドメインごとに電子メールをデジタル署名するためのフレームワークについて定義している。
　DomainKeysフレームワークの最終目的は現在の電子メールのデータ形式やプロトコルの解釈方式に変更を加えることなく、電子メールの送信元と内容がデジタル署名されてから改ざんされないようにし、また改ざんされていないことを確認できるようにすることである。電子メールの改ざんを防止したり、改ざんを検出したりできれば、インターネットメール全体のスパムやフィッシング対策にもなる。

　FAX用の音声信号をRTPで伝送する場合に、MIMEサブタイプとして用いる「audio/t38」をIANAに登録するための文書がRFC 4612として承認された。
　RFC 4612によってMIMEサブタイプ「audio/t38」が定義される。「audio/t38」はSDP（Session Description Protocol：セッション記述プロトコル）によってセッション中でFAXデータをRTPで伝送するために用いる。なお、技術の詳細はITU-T勧告のT.38で定義されている。

　リアルタイムのテキスト会話セッションコンテンツをRTPパケット内でどのように伝送するかについての仕様がRFC 4351として承認された。
　テキスト会話セッションはITU-TのT.140勧告で仕様が述べられている。RFC 4351では、単一のRTPセッションで音声とテキストデータを伝送するために、1つのペイロード形式の仕様を述べ、パケットの消失で起きるテキスト消失のリスクを減らすために、すでに伝送済みのパケットから冗長化したテキストを含める方式を推奨している。

　RFC 1738で定義されたURI（Uniform Resource Identifier：定型リソース識別子）スキーム「prospero」に関する仕様がRFC 4157として承認された。
　RFC 4157の目的は、RFC 1738を廃止する一方で、このスキームの情報を標準化過程に保つことである。

　RFC 1738で定義されたURI（Uniform Resource Identifier：定型リソース識別子）スキーム「wais」に関する仕様がRFC 4156として承認された。
　RFC 4156の目的は、RFC 1738を廃止する一方で、このスキームの情報を標準化過程に保つことである。