UTF-8 encoded Translated into Japanese language by Yuuki OKANO. 日本語訳 陸野 優樹 Email: marimo@wdic.org 翻訳 1998年 8月22日 / translation 22 August 1998 修正 2006年12月09日 / correction 09 December 2006 日本語に訳された文書に関する著作権は訳者に帰属します。 著作権についてはオリジナルに記載された著作権全文に従います。 配布についてはオリジナルと同様に無制限です。 内容は不定期に更新されます。 最新の内容は http://www.akanko.net/marimo/rfc/ にあります。 この文書は rfc2384 を訳者(marimo@wdic.org)が個人的な好奇心で適当に 翻訳したものです。したがって、翻訳の正確さなどは全く保証いたしません。 誤訳や根本的な勘違いなどが多く含まれていると思います。正確な情報が必要 な場合は英語原文も合わせてお読みください。誤字・誤訳など翻訳内容につい ての指摘は、いつでも歓迎します。 著作権全文 (Full Copyright Statement) --- 本文書末尾の原文より Copyright (C) The Internet Society (1998). 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. 訳: この文書およびその翻訳は、コピーされ、他に供給され、そして派生語を 論評、違った形で説明、またはその実装の促進が準備され、コピーされ、 出版されて、もし上記の版権情報およびこのパラグラフが、すべてのその ようなコピーおよび派生した作品に含まれるなら、どのような種類の制限 なしで全体や部分を配布できる。しかし、この文書自身は、発展途上のイ ンターネット標準やインターネット標準プロセスにおいて定義された著作 権のための手続のために必要な場合や、英語以外の言語への翻訳の要求が ある場合を除いて、インターネットソサエティまたは他のインターネット 組織の版権情報や参照を削除するなど、いかなる点でも修正できない。 上記で与えられる制限された権限は永久で、インターネットソサエティま たはその後継者、委託人によって撤回されることはない。 ここに含まれるこの文書及び情報は、ありのまま "AS IS" インターネット ソサエティに関して提供され、そして、インターネット特別技術調査委員会 (IETF)タスクフォースは、保証、説明または暗示、どのような保証にも制限 されない一切の権利を侵害しない情報を利用すること、何らかの市販性の保 証の暗示、または、特定の目的のための適切性の全てを否定する。 Network Working Group R. Gellens Request for Comments: 2384 QUALCOMM, Incorporated Category: Standards Track August 1998 POP URL スキーム このメモの位置づけ この文書は、インターネットコミュニティのためのインターネット標準運 用プロトコルを策定し、改善のための議論、提案を求めるものである。 規格化状態とプロトコルのステータスのために、この現在の版である「イ ンターネット公的プロトコル標準」 (STD 1) も参照されたい。このメモの 配布は無制限である。 著作権について Copyright (C) The Internet Society (1998). All Rights Reserved. 1. はじめに [POP3]は、広く使われているメールアクセスプロトコルである。多くの プログラムはPOP3メッセージ記憶装置にアクセスし、従って、それにはPOP3 構成情報が必要となる。ポストにアクセスするために必要な複数の構成要素 があるので、単一の文字列表現が便利である。 POP3ポスト([IMAP4]ポストのような)は、ネットワーク資源であり、URL は、ネットワーク資源の広く支えられた一般化した表現である。 URLとしてPOP3ポストを指定する方法は、たぶん、多くのプログラムとプ ロトコルで有益であろう。[ACAP] ネットワークサービスにアクセスするた めに必要な要素の文字列カプセル化が、必要な1つのケースである。例えば、 [IMAP4] メッセージ記憶装置は、[IMAP-URL] として ACAP データセットに おいて通常指定される。 このメモは、POPポストに参照を付けることについてのURLスキームを定義 する。 2. このドキュメントに使われる規定 キーワード "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" および "MAY" は、標示要求レベル [ KEYWORDS ] への RFC での使用のためのキーワード において定義されたように、解釈されるべきである。 (訳注:日本語の文章では該当する訳語に【】をつけた。) 3. POP スキーム POP URL スキームは、POPサーバ、任意ポート番号、認証メカニズム、認証 ID かつ、または 認可ID を示す。 明瞭なテクストパスワードが許されないことを除けば、RFC 1738 [BASIC-URL] において定義されるように共通なインターネット計画構文に従 う。 もし : が省略されたら、ポートは 110をデフォルトで採用する。 POP URLは、セクション8の [ABNF] を使って記述される。 POP URLのもつ一般的なフォームは: pop://;auth=@: および は RFC 1738において定義されている。さ らに、要素のうちのいくつか、またはすべての "pop://" と は省略 されるかもしれない。 4. POP のユーザ名と認証メカニズム 認可(どのポストにアクセスするか)、および認証(誰のパスワードに対 してチェックするか)同一性(単純性のための「ユーザ名」として差し向け られる)かつ、または認証メカニズム名が供給できる。 これらは、POPサーバとの接続後に、"USER"、"APOP"、"AUTH" [POP-AUTH]、 または拡張命令において利用される。 もし URL が認証識別子を供給しないならば、POP URLを説明しているプロ グラムはそれをユーザーに要求【するべき】だろう。 認証メカニズムは、";AUTH=" をユーザ名の終わりに付加 することによって表現される。もし認証メカニズム名に "+" が先行しない ときは、それは SASL POP [SASL] メカニズムである。もしそれに "+" が先 行するならば、それは "APOP" または拡張メカニズムである。 が指定される時には、クライアントは適切な権限をその メカニズムに与える【べき】で、"USER" 命令の代わりに "AUTH"、"APOP"、 または拡張命令を使う。 もしユーザー名が指定されないなら、それはメカニズムから得るか、また は適切ものをユーザに要求【するべき】である。 文字列 ";AUTH=*" は、クライアントが適切な認証メカニズムを選ぶべき であることを示す。それは、POPサーバーによりサポートされたあらゆるメ カニズムでも使うことができる【かもしれない】。 もし ";AUTH=*" を除いた が指定されるならば、クライ アントは、明示的なユーザー許可なしで、違うメカニズムを使う【べきでは ない】だろう。もし認証メカニズムなしでユーザー名が含まれるならば、そ の時、";AUTH=*" が仮定される。 URL が、容易には信頼できないソースのものであることもあり得るので、 あらゆる種類の認証を必要とする。または要求する URL を解決する時に注 意をせねばならない。もし権限の認証が誤ったサーバに供給されると、それ はユーザのアカウントの安全性を脅かすからになるかもしれない。 URL を解決するプログラムは、このケースにそれが以下の標準のうちの最 低1つを満たしていることを確かめるべきである: (1) URLは、クライアントがサイト方針に従って有効にし、そして、信頼で きる参照サーバのような信頼されたソースから来る。ユーザとサイト方針 の経験レベルに依存して、URLのユーザーエントリーが、信頼されたソース としてカウントできないまたはカウントできてはならないかもしれないこ とに注意する。 (2) 明白なローカルなサイト方針により、クライアントが URL のサーバに 接続することが可能となる。例えば、もしクライアントがサイトドメイン 名を知っているなら、その領域に終わるどのようなhostnameでも信頼され ることをサイト方針は表すであろう、 (3) ユーザは、指定された権限かつ、またはメカニズムによるそのドメイ ン名への接続が可能にになることを確認する。 (4) メカニズムは、潜在的な妥協クライアント権限を通過する前にサーバ を有効にして使われるか。 (5) 認証メカニズムは、未来の接続を解決するために使用できたサーバに 明らかにしないで使われるか。 それが更に弱いセキュリティメカニズムに依存するため、";AUTH=*" を含 んでいる URL は、特別な注意によって処理されるべきである。 最後に、接続が強い暗号化(例えば、56ビットを超えるキー長)を持って いない限り、クライアントは、明瞭なテクストパスワードを ";AUTH=*" に よる頼みの綱として使うことは思いとどまるべきだ。 もしユーザー名または認証メカニズムで、" " や ";" などの危険なまた は確保された文字が存在するなら、RFC 1738[BASIC-URL]において記述さ れるようにそれらが符号化されなければ【ならない】ことに注意する。 5. 相対的な POP URL 相対的な POP URL は許されない。 6. 多国籍の考慮 URLにおいては 8ビット文字が許されないので、UTF8 文字は URL仕様 [BASIC-URL] に必要に応じて符号化される。 7. 例 以下の例は、どのようにPOPクライアントプログラムが様々な POP URL を 一連のPOP命令に変換できるかを説明する。 クライアントからサーバに送られた命令は、"C:" を前置されて、サーバ からクライアントに送られた返答は、"S:" を前置される。 URL: 以下のクライアント命令の結果: S: +OK POP3 server ready <1896.697170952@mailsrv.qualcomm.com> C: USER rg S: +OK C: PASS secret S: +OK rg's mailbox has 2 messages (320 octets) URL: 以下のクライアント命令の結果: S: +OK POP3 server ready <1896.697170952@mail.eudora.com> C: APOP rg c4c9334bac560ecc979e58001b3e22fb S: +OK mailbox has 1 message (369 octets) URL: 以下のクライアント命令の結果: S: +OK POP3 server ready <1896.697170952@foo.bar> C: AUTH SCRAM-MD5 AGNocmlzADx0NG40UGFiOUhCMEFtL1FMWEI3MmVnQGVsZW Fub3IuaW5ub3NvZnQuY29tPg== S: + dGVzdHNhbHQBAAAAaW1hcEBlbGVhbm9yLmlubm9zb2Z0LmNvbQBq aGNOWmxSdVBiemlGcCt2TFYrTkN3 C: AQAAAMg9jU8CeB4KOfk7sUhSQPs= S: + U0odqYw3B7XIIW0oSz65OQ== C: S: +OK mailbox has 1 message (369 octets) 8. POP URLスキームのためのABNF POP URLスキームは、[ABNF] を使って記述される: achar = uchar / "&" / "=" / "~" ; "uchar" 定義のための [BASIC-URL] を見る auth = ";AUTH=" ( "*" / enc-auth-type ) enc-auth-type = enc-sasl / enc-ext enc-ext = "+" ("APOP" / 1*achar) ;APOPまたは符号化された拡張メカニズム名 enc-sasl = 1*achar ;encoded version of [SASL] "auth_type" ; [SASL] "auth_type" の符号化されたバー ; ジョン enc-user = 1*achar ;[POP3]ポストの符号化されたバージョン pop-url = "pop://" server server = [user-auth "@"] hostport ; "hostport" 定義のための [BASIC-URL] ; を見る user-auth = enc-user [auth] 9. セキュリティ対策 [POP3] 指定と [BASIC-URL] 指定において論じられたセキュリティ対策は 適切である。認証されているURLに関連したセキュリティ対策は、この文書 のセクション4にて論じられる。 多くの電子メールクライアントは、POPサーバにログインした後に、後で 使うために、明瞭なテクストパスワードを格納する。そのようなクライアン トは、ユーザーから指定されたホストの名前へのパスワードが指定する供給 までの明示的な許可なしで、POP URLに答えて格納されたパスワードを使っ ては【ならない】。 10. 肯定応答 この文書は Chris Newman の [IMAP-URL] 仕様から重く借りて、そして、 [URL-GUIDELINES] のアドバイスに従うことを試みた。 11. 参照 [ABNF] Crocker, D., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [ACAP] Newman, C., and J. Myers, "ACAP -- Application Configuration Access Protocol", RFC 2244, November 1997. [BASIC-URL] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994. [IMAP-URL] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997. [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996. [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [POP-AUTH] Myers, J., "POP3 AUTHentication command", RFC 1734, December 1994. [POP3] Myers, J., and M. Rose, "Post Office Protocol -- Version 3", STD 53, RFC 1939, May 1996. [SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997. [URL-GUIDELINES] Masinter, Alvestrand, Zigmond, "Guidelines for new URL Schemes", Work in Progress. [UTF8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998. 12. 奥付 Randall Gellens QUALCOMM, Incorporated 6455 Lusk Blvd. San Diego, CA 92121-2779 U.S.A. Phone: +1 619 651 5115 Fax: +1 619 651 5334 EMail: Randy@Qualcomm.Com