RFC2221 日本語訳
2221 IMAP4 Login Referrals. M. Gahrns. October 1997. (Format: TXT=9251 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group M. Gahrns Request for Comments: 2221 Microsoft Category: Standards Track October 1997
Gahrnsがコメントのために要求するワーキンググループM.をネットワークでつないでください: 2221年のマイクロソフトカテゴリ: 標準化過程1997年10月
IMAP4 Login Referrals
IMAP4ログイン紹介
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright(C)インターネット協会(1997)。 All rights reserved。
1. Abstract
1. 要約
When dealing with large amounts of users and many IMAP4 [RFC-2060] servers, it is often necessary to move users from one IMAP4 server to another. For example, hardware failures or organizational changes may dictate such a move.
多量のユーザと多くのIMAP4[RFC-2060]サーバに対処するとき、1つのIMAP4サーバから別のサーバまでユーザを動かすのがしばしば必要です。 例えば、ハードウェアの故障か組織変動がそのような移動を決めるかもしれません。
Login referrals allow clients to transparently connect to an alternate IMAP4 server, if their home IMAP4 server has changed.
ログイン紹介で、彼らのホームIMAP4サーバが変化したなら、クライアントは透過的に代替のIMAP4サーバに接続できます。
A referral mechanism can provide efficiencies over the alternative 'proxy method', in which the local IMAP4 server contacts the remote server on behalf of the client, and then transfers the data from the remote server to itself, and then on to the client. The referral mechanism's direct client connection to the remote server is often a more efficient use of bandwidth, and does not require the local server to impersonate the client when authenticating to the remote server.
紹介メカニズムは、ローカルのIMAP4サーバがクライアントを代表してリモートサーバに連絡する'プロキシメソッド'を代替手段の効率に提供して、リモートサーバからそれ自体までそして、クライアントへのデータを当時の転送に提供できます。 リモートサーバへの紹介メカニズムの直接クライアント接続は、しばしば帯域幅の、より効率的な使用であり、リモートサーバに認証するとき、クライアントをまねるためにローカルサーバを必要としません。
2. Conventions used in this document
2. 本書では使用されるコンベンション
In examples, "C:" and "S:" indicate lines sent by the client and server respectively.
例で「C:」 そして、「S:」 クライアントとサーバによってそれぞれ送られた系列を示してください。
A home server, is an IMAP4 server that contains the user's inbox.
ホームサーバはユーザの受信トレイを含むIMAP4サーバです。
A remote server is a server that contains remote mailboxes.
リモートサーバはリモートメールボックスを含むサーバです。
Gahrns Standards Track [Page 1] RFC 2221 IMAP4 Login Referrals October 1997
Gahrns標準化過程[1ページ]RFC2221IMAP4は紹介1997年10月にログインします。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC-2119]で説明されるように本書では解釈されることであるべきですか?
3. Introduction and Overview
3. 序論と概要
IMAP4 servers that support this extension MUST list the keyword LOGIN-REFERRALS in their CAPABILITY response. No client action is needed to invoke the LOGIN-REFERRALS capability in a server.
この拡大をサポートするIMAP4サーバは彼らのCAPABILITY応答でキーワードLOGIN-REFERRALSを記載しなければなりません。 クライアント動作は、全くサーバのLOGIN-REFERRALS能力を呼び出すのに必要ではありません。
A LOGIN-REFERRALS capable IMAP4 server SHOULD NOT return a referral to a server that will return a referral. A client MUST NOT follow more than 10 levels of referral without consulting the user.
SHOULD NOTが紹介を返すサーバへの紹介を返すLOGIN-REFERRALSのできるIMAP4サーバ。 ユーザに相談しないで、クライアントは10以上のレベルの紹介の後をつけてはいけません。
A LOGIN-REFERRALS response code MUST contain as an argument a valid IMAP server URL as defined in [IMAP-URL].
LOGIN-REFERRALS応答コードは議論として[IMAP-URL]で定義される有効なIMAPサーバURLを含まなければなりません。
A home server referral consists of either a tagged NO or OK, or an untagged BYE response that contains a LOGIN-REFERRALS response code.
ホームサーバ紹介はLOGIN-REFERRALS応答コードを含むタグ付けをされたノーかOKかuntagged BYE応答のどちらかから成ります。
Example: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/] Remote Server
例: リモートA001ノー[紹介IMAP://ユーザ; AUTH= *@SERVER2/ ]サーバ
NOTE: user;AUTH=* is specified as required by [IMAP-URL] to avoid a client falling back to anonymous login.
以下に注意してください。 ユーザ; AUTH=*は必要に応じて[IMAP-URL]によって指定されて、匿名のログインへ後ろへ下がっているクライアントを避けます。
4. Home Server Referrals
4. ホームサーバ紹介
A home server referral may be returned in response to an AUTHENTICATE or LOGIN command, or it may appear in the connection startup banner. If a server returns a home server referral in a tagged NO response, that server does not contain any mailboxes that are accessible to the user. If a server returns a home server referral in a tagged OK response, it indicates that the user's personal mailboxes are elsewhere, but the server contains public mailboxes which are readable by the user. After receiving a home server referral, the client can not make any assumptions as to whether this was a permanent or temporary move of the user.
AUTHENTICATEかLOGINコマンドに対応してホームサーバ紹介を返すかもしれませんか、またはそれは接続始動バナーに現れるかもしれません。 サーバがタグ付けをされたいいえ応答におけるホームサーバ紹介を返すなら、そのサーバはどんなユーザにとって、アクセスしやすいメールボックスも含んでいません。 サーバがタグ付けをされたOK応答におけるホームサーバ紹介を返すなら、それは、ユーザの個人的なメールボックスがほかの場所にありますが、サーバがユーザで読み込み可能な公共のメールボックスを含むのを示します。 ホームサーバ紹介を受けた後に、クライアントはこれがユーザの永久的であるか一時的な移動であったかどうかに関して少しの仮定もすることができません。
4.1. LOGIN and AUTHENTICATE Referrals
4.1. ログインしてください、そして、紹介を認証してください。
An IMAP4 server MAY respond to a LOGIN or AUTHENTICATE command with a home server referral if it wishes to direct the user to another IMAP4 server.
別のIMAP4サーバにユーザを向けたいなら、IMAP4サーバはホームサーバ紹介でLOGINかAUTHENTICATEコマンドに反応するかもしれません。
Example: C: A001 LOGIN MIKE PASSWORD
S: A001 NO [REFERRAL IMAP://MIKE@SERVER2/] Specified user
is invalid on this server. Try SERVER2.
例: C: A001ログインマイクパスワードS: A001 NO[REFERRAL IMAP: //MIKE@SERVER2/ ]の指定されたユーザはこのサーバで無効です。SERVER2を試みてください。
Gahrns Standards Track [Page 2] RFC 2221 IMAP4 Login Referrals October 1997
Gahrns標準化過程[2ページ]RFC2221IMAP4は紹介1997年10月にログインします。
Example: C: A001 LOGIN MATTHEW PASSWORD
S: A001 OK [REFERRAL IMAP://MATTHEW@SERVER2/] Specified
user's personal mailboxes located on Server2, but
public mailboxes are available.
例: C: A001ログインマシューパスワードS: A001 OK[REFERRAL IMAP: //MATTHEW@SERVER2/ ]はServer2に見つけられたユーザの個人的なメールボックスを指定しましたが、公共のメールボックスは利用可能です。
Example: C: A001 AUTHENTICATE GSSAPI
<authentication exchange>
S: A001 NO [REFERRAL IMAP://user;AUTH=GSSAPI@SERVER2/]
Specified user is invalid on this server. Try
SERVER2.
例: C: A001 AUTHENTICATE GSSAPI<認証交換>S: A001 NO[REFERRAL IMAP://ユーザ; AUTH= GSSAPI@SERVER2/ ]の指定されたユーザはこのサーバで無効です。SERVER2を試みてください。
4.2. BYE at connection startup referral
4.2. 接続始動紹介におけるBYE
An IMAP4 server MAY respond with an untagged BYE and a REFERRAL response code that contains an IMAP URL to a home server if it is not willing to accept connections and wishes to direct the client to another IMAP4 server.
IMAP4サーバは接続を受け入れることを望まないで、別のIMAP4サーバにクライアントを向けたいならホームサーバにIMAP URLを含むuntagged BYEとREFERRAL応答コードで反応するかもしれません。
Example: S: * BYE [REFERRAL IMAP://user;AUTH=*@SERVER2/] Server not
accepting connections. Try SERVER2
例: S: * 接続を受け入れないBYE[REFERRAL IMAP://ユーザ; AUTH= *@SERVER2/ ]サーバ。 SERVER2を試みてください。
5. Formal Syntax
5. 正式な構文
The following syntax specification uses the augmented Backus-Naur Form (BNF) as described in [ABNF].
以下の構文仕様は[ABNF]で説明されるように増大しているBN記法(BNF)を使用します。
This amends the "resp_text_code" element of the IMAP4 grammar described in [RFC-2060]
これは中で説明されたIMAP4文法の「resp_テキスト_コード」原理を修正します。[RFC-2060]
resp_text_code =/ "REFERRAL" SPACE <imapurl>
; See [IMAP-URL] for definition of <imapurl>
; See [RFC-2060] for base definition of resp_text_code
resp_テキスト_コード=/「紹介」スペース<imapurl>。 <imapurl>の定義に関して[IMAP-URL]を見てください。 resp_テキスト_コードのベース定義に関して[RFC-2060]を見てください。
6. Security Considerations
6. セキュリティ問題
The IMAP4 login referral mechanism makes use of IMAP URLs, and as such, have the same security considerations as general internet URLs [RFC-1738], and in particular IMAP URLs [IMAP-URL].
IMAP4ログイン紹介メカニズムはIMAP URLを利用します、そして、そういうものとして、一般的なインターネットURL[RFC-1738]、および特定のIMAP URL[IMAP-URL]の同じセキュリティ問題を持ってください。
A server MUST NOT give a login referral if authentication for that user fails. This is to avoid revealing information about the user's account to an unauthorized user.
そのユーザのための認証が失敗するなら、サーバはログイン紹介を与えてはいけません。 これは、ユーザのアカウントの顕な情報を権限のないユーザとして避けるためのものです。
With the LOGIN-REFERRALS capability, it is potentially easier to write a rogue 'password catching' server that collects login data and then refers the client to their actual IMAP4 server. Although referrals reduce the effort to write such a server, the referral response makes detection of the intrusion easier.
LOGIN-REFERRALS能力では、それらの実際のIMAP4サーバにログインデータを集めて、次にクライアントを差し向ける凶暴な'パスワード把持'サーバを書くのは潜在的により簡単です。紹介はそのようなサーバを書くために取り組みを減少させますが、紹介応答で、侵入の検出は、より簡単になります。
Gahrns Standards Track [Page 3] RFC 2221 IMAP4 Login Referrals October 1997
Gahrns標準化過程[3ページ]RFC2221IMAP4は紹介1997年10月にログインします。
7. References
7. 参照
[RFC-2060], Crispin, M., "Internet Message Access Protocol - Version 4rev1", RFC 2060, December 1996.
[RFC-2060]、クリスピン、M.、「バージョン4rev1"、RFC2060、1996年インターネットメッセージアクセス・プロトコル--12月。」
[IMAP-URL], Newman, C., "IMAP URL Scheme", RFC 2192, Innosoft, September 1997.
[IMAP-URL]、ニューマン、C.、「IMAP URL体系」、RFC2192、Innosoft、1997年9月。
[RFC-1738], Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform Resource Locators (URL)", RFC 1738, December 1994.
[RFC-1738]とバーナーズ・リーとT.とMasinterとL.とM.McCahill、「Uniform Resource Locator(URL)」、RFC1738、1994年12月。
[RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC-2119]、ブラドナーS.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、RFC2119、1997年3月。
[ABNF], DRUMS working group, Dave Crocker Editor, "Augmented BNF for Syntax Specifications: ABNF", Work in Progress.
[ABNF]、DRUMSワーキンググループ、デーヴクロッカーEditor、「構文仕様のための増大しているBNF:」 "ABNF"は進行中で働いています。
8. Acknowledgments
8. 承認
Many valuable suggestions were received from private discussions and the IMAP4 mailing list. In particular, Raymond Cheng, Mark Crispin, Mark Keasling Chris Newman and Larry Osterman made significant contributions to this document.
個人的な議論とIMAP4メーリングリストから多くの貴重な提案を受領しました。 レイモンド・チェン、マーク・クリスピン、マーク・Keaslingクリス・ニューマン、およびラリー・オスターマンはこのドキュメントへの重要な貢献を特に、しました。
9. Author's Address
9. 作者のアドレス
Mike Gahrns Microsoft One Microsoft Way Redmond, WA, 98072
マイクGahrnsマイクロソフト1マイクロソフト道、レッドモンド、ワシントン 98072
Phone: (206) 936-9833 EMail: mikega@microsoft.com
以下に電話をしてください。 (206) 936-9833 メールしてください: mikega@microsoft.com
Gahrns Standards Track [Page 4] RFC 2221 IMAP4 Login Referrals October 1997
Gahrns標準化過程[4ページ]RFC2221IMAP4は紹介1997年10月にログインします。
10. Full Copyright Statement
10. 完全な著作権宣言文
Copyright (C) The Internet Society (1997). All Rights Reserved.
Copyright(C)インターネット協会(1997)。 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 implmentation may be prepared, copied, published andand 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.
それに関するこのドキュメントと翻訳をコピーして、他のものに提供するかもしれません、そして、そうでなければ、implmentationを批評するか、それについて説明するか、または補助する派生している作品は全体か一部分配された、準備されて、コピーされて、発行されたandandであるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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."
「このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。」
Gahrns Standards Track [Page 5]
Gahrns標準化過程[5ページ]
一覧
スポンサーリンク
