http://www.rfcnews.jp/ RFCの日本語訳（概要部分）を随時掲載しています。 ja Copyright 2007 Sat, 15 Sep 2007 09:24:26 +0900 http://www.sixapart.com/movabletype/?v=3.21-ja http://blogs.law.harvard.edu/tech/rss RFC 5017として勧告された。 　このMIBモジュールはURI（STD 66）を表現するための省略表記を定義している。独自の表記方法を持つMIBモジュールで導入される。]]> http://www.rfcnews.jp/archives/2007/09/rfc_5017urimib.html http://www.rfcnews.jp/archives/2007/09/rfc_5017urimib.html STANDARDS TRACK Sat, 15 Sep 2007 09:24:26 +0900 RFC 5008として承認された。 　RFC 5008は、RFC 3851で定義されているS/MIMEにおける米国国家安全保障庁のスイートBアルゴリズムを使うための方法について定義している。]]> http://www.rfcnews.jp/archives/2007/09/rfc_5008smimeb.html http://www.rfcnews.jp/archives/2007/09/rfc_5008smimeb.html INFORMATIONAL Sat, 15 Sep 2007 09:24:12 +0900 RFC 5007として勧告された。 　RFC 5007はDHCPv6でリース期間を問い合わせるやりとりの仕様を定めて、DHCPv6クライアントがDHCPv6サーバーからリース期間の情報を取得できるようにする。RFC 5007は取得できるデータの範囲と、DHCPv6のリース期間問い合わせの要求とサーバー側の処理を定義している。]]> http://www.rfcnews.jp/archives/2007/09/rfc_5007dhcpv6.html http://www.rfcnews.jp/archives/2007/09/rfc_5007dhcpv6.html STANDARDS TRACK Sat, 15 Sep 2007 09:24:05 +0900 RFC 5005として勧告された。 　RFC 5005は3つのタイプのWebフィードを定義して、1つ以上のフィード文書にまたがるエントリーを発行できるようにする。 　ページ化フィードは、フィードをページに分けた形態であり、アーカイブ化フィードはフィードの内容を再構成できる形態であり、完全フィードはすべてのエントリーを含む形態である。]]> http://www.rfcnews.jp/archives/2007/09/rfc_5005.html http://www.rfcnews.jp/archives/2007/09/rfc_5005.html STANDARDS TRACK Sat, 08 Sep 2007 09:41:00 +0900 RFC 5004として勧告された。 　RFC 5004では、ある条件下における外部の経路間の不要な最良経路の遷移を回避するBGPの経路選択ルールの拡張が提案されている。この拡張により、ネットワーク全体の安定性が高まり、さらに重要なことに、1つのBGPスピーカーが引き起こされる外部経路の遷移が繰り返される現象をなくせる。]]> http://www.rfcnews.jp/archives/2007/09/rfc_5004bgp.html http://www.rfcnews.jp/archives/2007/09/rfc_5004bgp.html STANDARDS TRACK Sat, 08 Sep 2007 09:40:48 +0900 RFC 5022として承認された。 　MSCMLとは、SIPとともに用いて、先進的なカンファレンスとIVR（Interactive Voice Response：音声自動応答）を実現するためのマークアップ言語である。MSCMLが表現するのは装置レベルの制御モデルではなく、アプリケーションレベルの制御モデルであり、IETFのSIPカンファレンスフレームワークにおいて、カンファレンスフォーカスとミキサー間の通信を実現するために利用できる。]]> http://www.rfcnews.jp/archives/2007/09/rfc_5022mscml.html http://www.rfcnews.jp/archives/2007/09/rfc_5022mscml.html INFORMATIONAL Sat, 08 Sep 2007 09:40:31 +0900 RFC 5010として勧告された。 　RFC 5010はDHCPリレーエージェント情報オプションの新しいサブオプションを定義して、DHCPリレーで転送されたパケット用に2つのフラグを付けられるようにする。 　1つのフラグは、DHCPリレーがパケットをユニキャストパケットで受信したか、ブロードキャストパケットで受信したのかを示すためにある。DHCPサーバーがこのフラグを使って、クライアントからの要求が元々ブロードキャストなのかユニキャストなのかで扱いを変えられるようになる。]]> http://www.rfcnews.jp/archives/2007/09/rfc_5010dhcpv4.html http://www.rfcnews.jp/archives/2007/09/rfc_5010dhcpv4.html STANDARDS TRACK Sat, 08 Sep 2007 09:40:04 +0900 RFC 4981として承認された。 　最近5年間のP2Pネットワークに関する研究の進歩は、P2Pを重要視した調査が真実であったことがわかる。P2Pは破壊的な技術となる可能性を秘めており、導入コストや拡大コストをなるべく抑えながら、膨大な量のストレージや処理能力を集約しうる。ただ、従来型アーキテクチャに比べれば個々のエラーの影響はずっと少ないとはいえ、分散された膨大な数のピア間ではエラーが日常茶飯事であり、すでにあるファイル共有以上のアプリケーションをP2Pで実現する鍵となるのは頑強さである。 　RFC 4981ではまず、P2Pに分類されるあらゆる技術における検索方式を調べている。Plaxtonツリーやリング、tori、バタフライ、de Bruijnダイグラフ、スキップグラフに基づく、簡単なキー検索用P2Pインデックスを評価し、同様にキーワード検索や情報取得、データ管理用のP2Pインデックスについても調べている。最後に、検索範囲の最適化やマルチ属性、参加、P2Pインデックスの問い合わせの集約に関する初期の模索についても評価している。 　検索方式について基本文献で言及されている限りにおいて、RFC 4981では頑強さのメカニズムとその指標に重きを置いているが、文献中では頑強さにもっとも影響を与える低レベルメカニズムが上位のメカニズムきちんと分離していない。RFC 4981には将来の研究用の推奨仕様も含まれる。]]> http://www.rfcnews.jp/archives/2007/09/rfc_4981p2p.html http://www.rfcnews.jp/archives/2007/09/rfc_4981p2p.html INFORMATIONAL Sat, 08 Sep 2007 09:39:48 +0900 RFC 5032として勧告された。 　RFC 5032はIMAPのSEARCHコマンドに対するWITHIN拡張について述べている。IMAPのSEARCHは日時が指定された範囲内あるいは範囲外にあるメッセージを応答するコマンドである。SEARCHコマンドの既存のオプションであるBEFOREおよびSINCEでは、クライアントが指定した日時を基準に検索するのに対して、RFC 5032で定義されたOLDERおよびYOUNGERでは、クライアントが指定した間隔（秒）を基準にメッセージを検索する。 　WITHIN拡張は常時検索するクライアントで、一定間隔で検索処理を実行する性能がなかったり、ネットワークの帯域幅が不足していたりして、何度も同じ要求を送りたくない場合や、同じ応答を受け取りたくない場合に有用である。]]> http://www.rfcnews.jp/archives/2007/09/rfc_5032imapwit.html http://www.rfcnews.jp/archives/2007/09/rfc_5032imapwit.html STANDARDS TRACK Fri, 07 Sep 2007 00:56:19 +0900 RFC 5011として勧告された。 　RFC 5011はDNSSECのトラストアンカーの更新の自動化と認証、証明方法について述べている。この方法は、トラストポイントのキーセットにおけるN個の鍵のうちのN-1個の鍵の危殆化に対する保護になる。現行アンカーの存在によって確立された信頼に基づいて、他のアンカーを階層構造内に追加（究極的には置き換え）してもよい。 　このメカニズムにはリゾルバー管理のやり方を変更（リゾルバーの解決時のやり方ではない）し、DNSKEYレコードのフラグを1ビット追加する必要がある。]]> http://www.rfcnews.jp/archives/2007/09/rfc_5011dnssec.html http://www.rfcnews.jp/archives/2007/09/rfc_5011dnssec.html STANDARDS TRACK Fri, 07 Sep 2007 00:56:07 +0900 RFC 5003として勧告された。 　AIIとは、疑似有線（Pseudowire）エンドポイントを識別するTLV（Type Length Value）フィールドを含むポイント間疑似有線を確立するために用いるシグナリングプロトコルのことである。RFC 5003は、AII TLVフィールドの新形態となるAII構造体を定義して、スケーラビリティを改善し、VPN（Virtual Private Network）の自動発見用のAII集約に対応する。 　AII集約は、顧客のニーズに基づいて、選択されたローカルPE（Provider Edge）とリモートPE間で疑似有線が確立されている大規模なドメイン間の仮想専用線サービスネットワークで利用する場合に有用である。]]> http://www.rfcnews.jp/archives/2007/09/rfc_5003aii.html http://www.rfcnews.jp/archives/2007/09/rfc_5003aii.html STANDARDS TRACK Fri, 07 Sep 2007 00:55:50 +0900 RFC 4990として承認された。 　RFC 4990はGMPLSネットワークにおけるアドレスの使用について明らかにし、GMPLS対応のLSR（Label Switching Router）の互換性を高めることが目的である。RFC 4990は、実装や互換性のテスト、実運用での経験に基づいている。 　RFC 4990はGMPLSプロトコルでアドレスや識別子フィールドをどのように解釈すべきか、また、どのアドレスを特定の制御プレーンユーゼージモデルに当てはめるかについても述べている。さらに、IPv6の送信元と宛先アドレスをMPLS/GMPLSのトラフィックエンジニアリングMIB（Management Information Base）でどのように扱うかについても議論している。 　なお、RFC 4990は新しい手続きや処理は定義していない。要件の提示や推奨を示している部分は、規範となる参照先RFCから引用されたものである。]]> http://www.rfcnews.jp/archives/2007/09/rfc_4990gmpls.html http://www.rfcnews.jp/archives/2007/09/rfc_4990gmpls.html INFORMATIONAL Fri, 07 Sep 2007 00:55:27 +0900 RFC 4964として承認された。 　RFC 4964はOMAのPoCアプリケーションに限定される、SIPのプライベートヘッダー（Pヘッダー）について述べている。Pアンサー状態ヘッダーは特定のPoCアプリケーションがハンドセットの応答モードを示すために用いる。]]> http://www.rfcnews.jp/archives/2007/09/rfc_4964oma_poc.html http://www.rfcnews.jp/archives/2007/09/rfc_4964oma_poc.html INFORMATIONAL Fri, 07 Sep 2007 00:55:17 +0900 RFC 4985として勧告された。 　RFC 4985はX.509所有者代替名拡張に新しい名前を格納できるようにして、サービス名およびDNSのサービス資源レコードのドメイン名コンポーネントと証明書の所有者を関連付けられるようにする。]]> http://www.rfcnews.jp/archives/2007/08/rfc_4985x509pki.html http://www.rfcnews.jp/archives/2007/08/rfc_4985x509pki.html STANDARDS TRACK Thu, 30 Aug 2007 06:10:18 +0900 RFC 4986として承認された。 　DNSセキュリティに対応するすべてのリゾルバーは、DNS署名ゾーンからの応答を検証するために、少なくとも1つのトラストアンカーを持たなければならない。また、さまざまな理由により、DNSセキュリティに対応したほとんどのリゾルバーは、複数のトラストアンカーを持つことになっている。 　運用形態によっては、トラストアンカーの手動による監視と更新も可能だが、多くの場合はDNSセキュリティに対応したリゾルバーによる自動化されたトラストアンカーの更新が必要である。そこでRFC 4986は、DNSセキュリティに対応したリゾルバー用に、DNSトラストアンカーのロールオーバーを自動化するための要件を述べている。]]> http://www.rfcnews.jp/archives/2007/08/rfc_4986dnssec.html http://www.rfcnews.jp/archives/2007/08/rfc_4986dnssec.html INFORMATIONAL Thu, 30 Aug 2007 06:10:08 +0900