IMAP 、 POP 、 ACAP などのプロトコルは暗号化さ れていないため、盗聴やハイジャック攻撃を受ける可能生 がある。したがって、なんらかのセキュリティ機構をオ プションとして用いることカ甘隹奨されている。 SSL として知られる TLS は、一イ勺なアプリケーショ ン・プロトコルに被せて利用するセキュリティ・プロトコ ルであり、盗聴などの攻撃からアプリケーション・プロト コル描矍できる。ューザー認証インフラストラクチャが ローカルで整備されている現状において、 TLS のような ューザー認証と密接に関連しないセキュリティ・プロトコ ルは新たな投資を要求しないため、管理者からは歓迎され る傾向にある。 RFC2595 では、 TLS をアプリケーションと組み合わ せてセキュリティを向上させる去として、単純なパス ワード認証コマンドのない ACAP や SMTP のような プロトコルて利用できる PLAIN SASL オ冓を定義して いる。 、 VWW 関連 RFC2611 URN Namespace Definition Mechanisms URN 名間定構 BCP. 、 L. DaigIe 他 ( 別 . BCP 33 ) URN 、、名前空間 " を確立するための一一般的な定義と機 構について説明している。、現時点での最良の去 " とし て 1999 年 6 月に公開された。 BCP シリーズ (BCP 33 ) としても公開されている。 URN は、資源の位置に依存しない識別と長期間の参照 を可能にするという要求にもとづいた資源識別子である。 RFC2611 では、 URN について以下の 2 つを仮定して ・ URN の名前空間は管理される。 ・ URN の割当て過程は管理される。 いる。 UNIX MAGAZINE 1999.9 物青報 ・名前空間 ID トには、以下の要素が含まれている。 RFC2611 における URN 名前空間定義のテンプレー 構の褪各を述べ、テンプレートを提供している。 間 ID" または、、 NID") 結・合機構に従った名前空間定幾 そのうえで、 IANA に当求されている識別子 ( 、、名前空 RFC ダイジェスト - 朝 ・名前空間登録名情報 関連する補助的文書 (RFC 、標その他の公開文書 徴の各 ) ・シンタックス構青報 ( 名前空間内の識別・子の構造自寺 細 ) ほかにも、 URN 名前空間の登録・史新、 NID 割当て ・名前空間の範囲 ・有効化欟冓 ・ URN シンタックスとの一致 ・語彙同一生に関する規則 ・識別 - 子解決用の過程 ・識別子割当ての過程 ( 割当てをおこなう欟冓や機関の詳 ・識別子の持続性に関する考察 ・識別子の一意性に関する考察 など ) 157 ・コンテンツ符号化、、 identity" の導入 ( 3.5 節 ) ( 3.6 、 4.4 、 7.2.2 、 13.5.2 、 14.13 、 14.16 節 ) ・符号化長とメッセージ長のインタラクションの導入 ・ Content-Base ヘッダの削除 を CREATE に付加 ( 10.2.2 節 ) ・原の最初の生成時に送信される Etag を要求する搨生 を明石ヒ ( 10.5.5 節 ) ・到着サーバーの失敗を示すために利用するエラーコード RFC2068 からのおもな変史点を以下に示す。 酉占逶されるデータとは無関係にシステムを構築できる。 データ表現の型付け (typing) およひ交渉で、これにより、 でのデータ転送のために使われている。 HTTP の特徴は アプリケーション層プロトコルで、 1990 年から WWW 化され共同て使われるハイバーメディア情報システム用の HTTP (HyperText Transfer Protocol) は、分散 る RFC として 1999 年 6 月に公開された。 草稿 (Draft Standard)" である。 RFC2068 を置き換え HTTP/I.1 を定義している。現在の状態は、、標準化の DS. 、 R. Fielding 他 ( RFC2068 置換 ) HTTP 第 1 ユ版 RFC2616 Hypertext Transfer ProtocoI-- HTTP/I.1 挙げている。 の過程について論し、 URN 名前空間テンプレートの例を

11. 情報サービスおよびファイル中幻 を提案している。上記の 2 項目が目的に対して有効である ことを実証するために、 RFC2629 は実際に 1 の DTD 12. ネットワーク層およびトランスポート層 を用いて言当さオ t 、 2 のソフトウェアを用いて生成されて 13. 電子メール いる。 14. ネットワーク日日プロトコル (NTP) RFC2629 の形式では、従来の普通の文書に対してマー 15. 名前サービス クアップによる孑ぐや新たな情報を追加することになる。 16. ネットワーク管理 その効果や景グとして、以下の項目か挙げられている。 17. ネットワーク・ ・テキスト形式の RFC 文書は、通常のエデイタを用い 18. 実日サーヒ、ス て従来どおり作成できる。 19. 経路制御 ・既存のソフトウェア環境になんらかの追加が必要にな 20. セキュリティ る。 21. イ反想端末 ・情報の組織化や検索などが可能になる。 22. その他 各方面からの才亢は多いが、今後の RFC の発展を考え 23. セキュリティに関する考察 るとこのような拡張は必頭であると思われる。すぐに移行 24. 参考文献 することはなさそうだが、慎重かっ十分に検討していく必 25. 編者の ; 叫各先 要はあるだろう。 イ求 A : 各カテゴリーごとの RFC 一覧 イ寸録 B : 調査に使われた PerI プログラム MIME 関連 伺録 C : 伺録 B のプログラムの出力 RFC2586 The Audio/L16 MIME content type イ寸求 D : HTTP 1.0 の問題について MIME コンテンツタイプ audio / L16 fo. 、」 . SaIsman 他 RFC2629 Writing l-Ds and RFCs using XML MIME コンテンツタイプ audio / L16 を定義している。 XML を禾堋した I-D および RFC の幸嫌 、、広報 " として 1999 年 5 月に公開された。 fo. 、 M. Rose RFC2586 で扱われている L16 は、 16 ピット非圧研彡 インターネット・ドラフト ( I - D ) や RFC の筆用の 式の音声フォーマットである。これは RTP トランスポー ソース形式として、 XML ( 拡張可能マークアッフ言調を トて利用される音声フォーマットとして、 RFC1890 で定 用いる手法について論している。、、広報 " として 1999 年 義されている。 L16 は、インターネットで利用されている 6 月に公開された。 アプリケーション用として十分な品質を備えており、現在 RFC は、さまざまなキーワードやカテゴリー、多数の 定義されているほかの音声フォーマットを補完できると考 参考文献への参照を含む文書である。 RFC がひろく用い えられている。 られるにしたがって、人間か読めることに加え、、、欟戒で 売める " ことか重視されるようになった。 電子メール関連 RFC2629 は、 XML 形式で RFC を言当して、オ戒で RFC2595 Using TLS with IMAP, POP3 and ACAP 売めるようにすることを目的としている。そこで、 IMAP 、 POP3 、 ACAP における TLS の利用 PS. 、 C. Newman 1. RFC のような性質をもつ文書の整形や言当を両立させ る形式と、 XML DTD ( 文書タイフ。定鞫 電子メール関連の機構のセキュリティ向上を目的とし 2. 従来の RFC のに関する規定 ( RFC2223 ) に従い、 て、 IMAP 、 POP3 、 ACAP における TLS の利用につ HTML 形式などから XML ソースファイルを生成す いて定義している。現在の状態は、、標準化への提唱 (Pro- るソフトウェア posed Standard)" である。 1999 年 6 月に公開された。 ュース ニ = ロ ニ = ロ 156 UNIX MAGAZINE 1999.9

RFC ダイジェストー・ て述べている。洋寺点での最良の方法 (Best Current Practice)" として 1999 年 6 月に公開された。 BCP シ リーズ (BCP 32 ) としても公開されている。 ドメイン名には、説明のための例や試験用として使われ るものがある。そうした不圸勺な利用時に混乱や誤解を避け るために、いくつかの最十、イ立レベルおよび次レベルドメイ ン名が予約されている。 TLD に関しては、以下の 4 つのドメイン名が予約され ている。 . test : DNS 嬲里コードの試験に使われる。 ・ example : 解説などでの言当および伊示用に使われる。 . invalid : 無効と思われる / 明らかに無効と分かるドメイ ン名をオンラインて構築する場合に使われる。 . localhost : 伝糸勺に、ルーフ。バック IP アドレスを孑す - A レコードを有するホスト DNS の実装において静的に 定義されている。したがって、今後もその目的て使うた めに予約されている。 SLD については、伊ぐ用のドメイン名として example .com 、 example. net 、 example.org が予約されている。 RFC2626 The lnternet and the Millennium Problem (Year 2000 ) インターネットと 2000 年問題 fo. 、 P. Nesser Ⅱ インターネット関連プロトコルの 2000 年間題につい て、 IETF の 2000 年問題分科会か査した結果をまとめ ている。、、広報 (lnformational)" として 1999 年 6 月に 公開された。 2000 年問題がひろく認知されるようになり、それに対 する危機意扁勧皜まるにつれて、さまざまな分野で調査が おこなわれている。 2000 年問題の多くは、利用している ソフトウェアやプロトコルで 2 桁の日付表現が用いられて いるなど、設言段階のいすれかで日韶ミの仮定がなされてい ることに起因する。 インターネットが普及するにつインターネットを 重要な業務に利用する糸目系勧蒴えている。そのため、イン ターネット・プロトコルおよびインターネットで利用さ れるソフトウェアなどの、、インターネットにおける 2000 年間題 " についても検討、分析する必要性か高まっている。 ュース UNIX MAGAZINE 1999.9 3.8. セキュリティ 3.7. 実時間サーピス 3.6. ネットワーク・ 3.5. ネットワーク管理 3.4. 名偂甘是供 3.3. 電子メール 6. 調査方法 5 イ多正について 4.2. 経路制御 4.1. 名前サーピス 4.2000 年間題以汐 ) 、、期間 " に関する問題 ( 以 -- ド、 22 章まで各領域ごとに詳しく説明している ) 7. 自動コンフィギュレーション 10. ゲームおよびチャット 9. ディスク共有 8. ディレクトリ・サービス 155 インターネットが 1999 年 12 月 31 日で崩壊するといっ た幸慮首もみられる。 そこで、 IETF では 2000 年間題分科会を組織し、 RFC シリーズで記述されてきたすべての重要なインターネッ ト・プロトコルの調査をおこなった。 RFC2626 は、各 不慮首に対する回答として、また同様の調査が各企業で繰 り返される無駄を避けるために、調査結果を公開したもの である。 査結果では、ほはすべてのインターネット・プロトコ ルに問題はなかったが、 2 桁の年表記を用いる旧い実装が いくっか発見された。また、その他の、、期間 " に関する問 題も数例みつかった。 RFC2626 はたいへん長い文書で、多くの章に分かれて いる。しかし、文書自体には目次がないので、簡単な説明 を付けて以下に示す。 1. はじめに 2. 注意 ( 調査か完全なものではないことを明記している ) 3.2000 年問題が発見された領域 3.1. ディレクトリ・サービス 3.2. 情報サービスおよびファイル中幻医