Network Working Group H. Kennedy Request for Comments: 3252 Mimezine Category: Informational 1 April 2002 二進形式の字句オクテットのアドホックな転送 Binary Lexical Octet Ad-hoc Transport このメモの位置づけ このメモはインターネットコミュニティに情報を提供する。これは、いか なる種類のインターネット標準も規定しない。このメモの配布は制限され ない。 著作権の表示 Copyright (C) The Internet Society (2002). All Rights Reserved. 要約 本文書は IP および 2 つのトランスポート層プロトコル(TCP と UDP)を XML アプリケーションとして再定式化するものである。 1. 導入 1.1. 概要 本文書は二進形式字句オクテットのアドホックな転送(the Binary Lexical Octet Ad-hoc Transport(BLOAT))、すなわち、広く利用されているネット ワーク層プロトコル(IP [RFC791])と関連する 2 つのトランスポート層プ ロトコル(TCP [RFC793] および UDP [RFC768])を XML [XML] アプリケーショ ンとしての再定式化について述べる。また、公共用インターネットを越え て BLOAT を中継するために IP に BLOAT をカプセル化することと同様に、 イーサネットや IEEE 802 ネットワークに載せて BLOAT を転送する手法に ついても述べる。 1.2. 動機 汎用オブジェクト交換プロトコル(the Blocks Extensible Exchange Protocol [RFC3080])やオブジェクトアクセスプロトコル(the Simple Object Access Protocol [SOAP])、そして、Jabber [JABBER] といったア プリケーションレベルプロトコルのための基盤としての XML のたいへんな 人気ぶりにより、プロトコルスタックにおける XML の利用の拡張性に向け ての調査が盛んに行なわれている。アプリケーション層に加えて、トラン スポートおよびネットワーク両層において XML を使用することで、独占的 で理解しがたい二進形式のプロトコルへの依存を断ち切る一方で、驚くべ き力と柔軟性を提供するようになるだろう。このプロトコルの統一により、 アプリケーションがその操作というあらゆる観点について、ただ一つの XML パーザを使えばよくなり、それぞれの新しいプロトコルの複雑さを記 述するのに開発者が浪費する時間を削減し、文法解析するというつらい仕 Kennedy Informational [Page 1] RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 事を XML ツールセットに移行するだろう。XML の利用により、また、多く のネットワークアプリケー所のバグの根幹となっている「ネットワークと ホスト」のバイトオーダーへの心配を軽減するだろう。 1.3. 既存のプロトコルとの関係 本 RFC で規定される再定式化は RFC がよって立つ精神に可能な限り厳密 に従うので、純粋な再作業において必要とされない要素や属性(例えば、 XML で暗黙となっている長さ属性)を含むかもしれない。 ネットワークおよびトランスポートプロトコルの階層化は、各行がなにか ぼんやりしたもの(すなわち、TCP と IP を DTD における単一の巨大な要 素に併合したもの)だったとしたら、行なわれたかもしれない最適化を無視 して、このプロトコルを、他のプロトコル(例えば ICMP)を再定式化するた めの基礎としての将来の利用を促進するために本 RFC で整備される。 符号化以外の個々の既存のプロトコルの振る舞いは変更されない。経路制 御、アドレス空間、TCP 輻輳制御などは、既存の標準で規定されている通 りに振る舞う。新しい標準やパフォーマンスを向上させるための実験的発 見的アルゴリズムへの対応は、一旦 BLOAT への移行が済んでしまえば、ずっ と容易になるだろう。 1.4. 要求レベル 本文書中の「しなければならない」「してはならない」「必要とされる」 「すべきだ」「すべきでない」「推奨される」「してもよい」「オプショ ンの」のキーワードは、BCP 14, RFC 2119 [RFC2119]で記述されている通 りに解釈されるべきだ。 2. IPoXML このプロトコルは、本 RFC に準拠するように実装「しなければならない」。 IPoXML は TCPpXML(3 節参照)やより上位の層のアプリケーションプロトコ ルを実際に利用するのに「必要とされる」基幹プロトコルである。 この文書型の DTD は 7.1 節に記述される。 正規構造が文書/データグラムの文法解析と検証をし、次のホップへそれを 送信する前に宛先アドレスやTTL, 検査合計を処理するのにとても役に立つ ので、IPoXML の経路制御は、XML パーザをもつホストに容易に実装される だろう。 IPv4 の方がより広く流布していることとXML として IPv6 [RFC2460] を実 装すると、1500 バイトのイーサネットの MTU を超えてしまうという現実 により、IPv4 の再定式化が選ばれた。 Kennedy Informational [Page 2] RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 すべての BLOAT の実装は、RFC 2279 [RFC2279] の UTF-8 符号化を使用し、 規定「しなければならない」。すべての BLOAT 文書/データグラムは、整 形式であり、XMLDect を包含「しなければならない」。 2.1. IP 記述 いくつかのアイテムは(改良のために)オリジナルの IP の仕様から変更し た。既存のビットマスクは可読な値に変換された。IP アドレスはそのドッ ト付十進記法 [RFC1123] で一覧される。長さと検査合計値は十進整数で表 現される。 IP 要素の長さと検査合計のフィールドを計算するために、要素の正規化形 式を使わ「なければならない」。正規化形式は要素の間に(改行文字も含め た)空白を含む「べきでな」く、属性の間にただ 1 つの空白文字を含む 「べきだ」。ある要素中の最後の属性に引き続く空白はある「べきでない」。 反復メソッドは、長さフィールドが検査合計の大きさによって変化するの で、検査合計を計算するために使われる「べきだ」。 ペイロード要素は特別な取り扱いを受けるに値する。XML の文字セットの 制約により、(任意のデータを含ん「でもよい」)IP データグラムのペイロー ドは転送のために符号化され「なければならない」。本 RFC はペイロード の内容が RFC 2045 [RFC2045] の base-64 符号化で符号化されていること を必要とするが、符号化された出力の行が 76 文字で折り返され「なけれ ばならない」という要求は削除する。 Kennedy Informational [Page 3] RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 2.2. データグラムの例 以下は、ペイロードが空の IPoXML データグラムの例である。
3. TCPoXML このプロトコルは、本 RFC に準拠して実装され「なければならない」。こ の文書型の DTD は 7.2 節にある。 3.1. TCP 記述 いくつかのアイテムは、オリジナルの TCP の仕様から変更している。存在 するビットマスクは可読な値に変換されている。長さや検査合計、ポート の値は十進の整数で表現する。 TCP 要素における長さと検査合計のフィールドを計算するため、要素の正 規化形式は 2.1 節で使われているのと同様で「なければならない」。 反復メソッドは 2.1 節と同様に検査合計を計算するのに使われる「べき だ」。 ペイロード要素は、2.1 節と同様に符号化され「なければならない」。 Kennedy Informational [Page 4] RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 TCP オフセット要素は XML のヘッダのサイズが増加したことのために、最 大値が許されている 16 から 255 に拡張された。 IPoXML によってカプセル化された TCPoXML データグラムは 宣言と同様に、 ヘッダを省略「してもよい」。 3.2. データグラムの例 以下は、ペイロードが空の TCPoXML データグラムの例である。 4. UDPoXML このプロトコルは、本 RFC に準拠して実装され「なければならない」。こ の文書型の DTD は 7.3 節にある。 4.1. UDP 記述 いくつかのアイテムは、オリジナルの UDP の仕様から変更された。存在す るビットマスクは可読な値に変換された。長さと検査合計とポートの値は 十進整数として表現される。 Kennedy Informational [Page 5] RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 UDP要素の長さと検査合計のフィールドを計算するため、要素の正規化形式 は 2.1 節のものと同じように使われ「なければならない」。反復メソッド は 2.1 節と同様に検査合計を計算するのに使われる「べきだ」。 ペイロード要素は 2.1 節と同様に符号化され「なければならない」。 IPoXML でカプセル化された UDPoXML データグラムは 宣言と 同様に ヘッダを省略「してもよい」。 4.2. データグラムの例 以下は、ペイロードが空の UDPoXML データグラムの例である。 5. ネットワーク転送 本文書は物理層の 2 つの共通なファミリーの上を BLOAT データグラムの 伝送を規定する。将来の RFC では、仕様に対して経路制御のベンダーが取 り組んだ追加の転送を扱うだろう。そして、我々はインターネットのバッ クボーン越しに経路制御された BLOAT を見始める。 5.1. イーサネット BLOAT はイーサネットフレームの型フィールドが 0xBEEF という値を含ま 「なければならない」という点を除いて、[RFC894] と同じようにイーサネッ トデータグラムにカプセル化される。イーサネットフレームペイロードの はじめの 5 オクテットは 0x3c 3f 78 6d 6c (" --> Kennedy Informational [Page 7] RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 Kennedy Informational [Page 9] RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 Kennedy Informational [Page 10] RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 7.2. TCPoXML DTD Kennedy Informational [Page 11] RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 Kennedy Informational [Page 12] RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 7.3. UDPoXML DTD Kennedy Informational [Page 13] RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 8. セキュリティの考察 SGML のサブセットとしての XML は SGML メディアタイプ [RFC1874] で規 定されているのと同じセキュリティの考察がされる。IP, TCP そして UDP に適用するセキュリティの考察は、メッセージフォーマットに関係しない 論点を修正を試みていないので、BLOAT にも同様に適用される。 9. 参考文献 [JABBER] Miller, J., "Jabber", draft-miller-jabber-00.txt, February 2002. (作業中) [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980. [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981. [RFC894] Hornig, C., "Standard for the Transmission of IP Datagrams over Ethernet Networks.", RFC 894, April 1984. [RFC1042] Postel, J. and J. Reynolds, "Standard for the Transmission of IP Datagrams Over IEEE 802 Networks", STD 43, RFC 1042, February 1988. [RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", RFC 1123, October 1989. [RFC1874] Levinson, E., "SGML Media Types", RFC 1874, December 1995. [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996. [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2279] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. Kennedy Informational [Page 14] RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3080] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001. [SOAP] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Nielsen, H. F., Thatte, S. Winer, D., "Simple Object Access Protocol (SOAP) 1.1" World Wide Web Consortium Note, May 2000 http://www.w3.org/TR/SOAP/ [XML] Bray, T., Paoli, J., Sperberg-McQueen, C. M., "Extensible Markup Language (XML)" World Wide Web Consortium Recommendation REC- xml-19980210. http://www.w3.org/TR/1998/REC-xml-19980210 10. 著者の連絡先 Hugh Kennedy Mimezine 1060 West Addison Chicago, IL 60613 USA EMail: kennedyh@engin.umich.edu Kennedy Informational [Page 15] RFC 3252 Binary Lexical Octet Ad-hoc Transport 1 April 2002 11. 完全な著作権の表示 Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 謝辞 RFC 編者機能の資金は、現在、インターネットソサエティによって提供さ れている。 Kennedy Informational [Page 16]