RFC2193 日本語訳

Network Working Group                                        M. Gahrns
Request for Comments: 2193                                   Microsoft
Category: Standards Track                               September 1997

Gahrnsがコメントのために要求するワーキンググループM.をネットワークでつないでください: 2193年のマイクロソフトカテゴリ: 標準化過程1997年9月

                        IMAP4 Mailbox 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)の現行版を参照してください。 このメモの分配は無制限です。

1. Abstract

1. 要約

   When dealing with large amounts of users, messages and geographically
   dispersed IMAP4 [RFC-2060] servers, it is often desirable to
   distribute messages amongst different servers within an organization.
   For example an administrator may choose to store user's personal
   mailboxes on a local IMAP4 server, while storing shared mailboxes
   remotely on another server.  This type of configuration is common
   when it is uneconomical to store all data centrally due to limited
   bandwidth or disk resources.

多量のユーザ、メッセージ、および地理的に分散しているIMAP4[RFC-2060]サーバに対処するとき、組織の中で異なったサーバにメッセージを分配するのはしばしば望ましいです。 例えば、管理者は、別のサーバに共有されたメールボックスを離れて保存している間、ローカルのIMAP4サーバにユーザの個人的なメールボックスを保存するのを選ぶかもしれません。限られた帯域幅かディスクリソースのため中心にすべてのデータを保存するのが不経済であるときに、このタイプの構成は一般的です。

   Mailbox referrals allow clients to seamlessly access mailboxes that
   are distributed across several IMAP4 servers.

メールボックス紹介で、クライアントはシームレスにいくつかの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 mailbox is a mailbox that is not hosted on the user's home
   server.

リモートメールボックスはユーザのホームサーバで接待されないメールボックスです。

Gahrns                      Standards Track                     [Page 1]

RFC 2193                IMAP4 Mailbox Referrals           September 1997

Gahrns規格はIMAP4メールボックス紹介1997年9月にRFC2193を追跡します[1ページ]。

   A remote server is a server that contains remote mailboxes.

リモートサーバはリモートメールボックスを含むサーバです。

   A shared mailbox, is a mailbox that multiple users have access to.

共有されたメールボックスは複数のユーザが近づく手段を持っているメールボックスです。

   An IMAP mailbox referral is when the server directs the client to
   another IMAP mailbox.

IMAPメールボックス紹介はサーバが別のIMAPメールボックスにクライアントを向ける時です。

   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
   MAILBOX-REFERRALS in their CAPABILITY response.  No client action is
   needed to invoke the MAILBOX-REFERRALS capability in a server.

この拡大をサポートするIMAP4サーバは彼らのCAPABILITY応答でキーワードMAILBOX-REFERRALSを記載しなければなりません。 クライアント動作は、全くサーバのMAILBOX-REFERRALS能力を呼び出すのに必要ではありません。

   A MAILBOX-REFERRALS capable IMAP4 server MUST NOT return referrals
   that result in a referrals loop.

MAILBOX-REFERRALSのできるIMAP4サーバは紹介輪でその結果を紹介に返してはいけません。

   A referral response consists of a tagged NO response and a REFERRAL
   response code.  The REFERRAL response code MUST contain as an
   argument a one or more valid URLs separated by a space as defined in
   [RFC-1738]. If a server replies with multiple URLs for a particular
   object, they MUST all be of the same type. In this case, the URL MUST
   be an IMAP URL as defined in [RFC-2192].  A client that supports the
   REFERRALS extension MUST be prepared for a URL of any type, but it
   need only be able to process IMAP URLs.

紹介応答はタグ付けをされたいいえ応答とREFERRAL応答コードから成ります。 REFERRAL応答コードは議論として[RFC-1738]で定義されるようにスペースによって切り離された1つ以上の有効なURLを含まなければなりません。 サーバが特定のオブジェクトのために複数のURLで返答するなら、同じタイプにはそれらがすべてあるに違いありません。 この場合、URLは[RFC-2192]で定義されるようにIMAP URLであるに違いありません。 REFERRALS拡張子をサポートするクライアントはどんなタイプの1つのURLのためにも用意ができていなければなりませんが、それはIMAP URLを処理するだけでよいことができます。

   A server MAY respond with multiple IMAP mailbox referrals if there is
   more than one replica of the mailbox.  This allows the implementation
   of a load balancing or failover scheme. How a server keeps multiple
   replicas of a mailbox in sync is not addressed by this document.

メールボックスの1つ以上のレプリカがあれば、サーバは複数のIMAPメールボックス紹介で反応するかもしれません。 これはロードバランシングかフェイルオーバー体系の実装を許容します。 サーバが同時性でどうメールボックスの複数のレプリカを保管するかはこのドキュメントによって扱われません。

   If the server has a preferred order in which the client should
   attempt to access the URLs, the preferred URL SHOULD be listed in the
   first, with the remaining URLs presented in descending order of
   preference.  If multiple referrals are given for a mailbox, a server
   should be aware that there are synchronization issues for a client if
   the UIDVALIDITY of the referred mailboxes are different.

サーバにクライアントがURL、都合のよいURL SHOULDにアクセスするのを試みるべきである都合のよいオーダーがあるなら、1番目に記載されてください、残っているURLが好みの降順で提示されている状態で。 メールボックスのために複数の紹介を与えるなら、サーバは参照されたメールボックスのUIDVALIDITYが異なるならクライアントのための同期問題があるのを意識しているべきです。

   An IMAP mailbox referral may be given in response to an IMAP command
   that specifies a mailbox as an argument.

議論としてメールボックスを指定するIMAPコマンドに対応してIMAPメールボックス紹介を与えるかもしれません。

Gahrns                      Standards Track                     [Page 2]

RFC 2193                IMAP4 Mailbox Referrals           September 1997

Gahrns規格はIMAP4メールボックス紹介1997年9月にRFC2193を追跡します[2ページ]。

   Example:

例:

      A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/REMOTE]Remote Mailbox

リモートA001ノー[紹介IMAP://ユーザ; AUTH= *@SERVER2/REMOTE ]メールボックス

   NOTE: user;AUTH=* is specified as required by [RFC-2192] to avoid a
   client falling back to anonymous login.

以下に注意してください。 ユーザ; AUTH=*は、匿名のログインへ後ろへ下がっているクライアントを避けるために必要に応じて[RFC-2192]によって指定されます。

   Remote mailboxes and their inferiors, that are accessible only via
   referrals SHOULD NOT appear in LIST and LSUB responses issued against
   the user's home server.  They MUST appear in RLIST and RLSUB
   responses issued against the user's home server. Hierarchy referrals,
   in which a client would be required to connect to the remote server
   to issue a LIST to discover the inferiors of a mailbox are not
   addressed in this document.

それはSHOULD NOTがLISTで見える紹介と単にユーザのホームサーバに対して発行されたLSUB応答でアクセスしやすいです。リモートメールボックスと彼らの目下、それらはユーザのホームサーバに対して発行されたRLISTとRLSUB応答で見えなければなりません。そこでは、クライアントがそうでしょう。階層構造紹介がメールボックスの目下が本書では宛てられないと発見するためにLISTを発行するためにリモートサーバに接続するのが必要です。

   For example, if shared mailboxes were only accessible via referrals
   on a remote server, a RLIST "" "#SHARED/%" command would return the
   same response if issued against the user's home server or the remote
   server.

例えば、共有されるなら、メールボックスは単にリモートサーバにおける紹介でアクセスしやすかったです、RLIST、「「ユーザのホームサーバかリモートサーバに対して発行されるなら、「#共有された/%」コマンドは同じ応答を返すでしょう」。

   Note: Mailboxes that are available on the user's home server do not
   need to be available on the remote server.  In addition, there may be
   additional mailboxes available on the remote server, but they will
   not accessible to the client via referrals unless they appear in the
   LIST response to the RLIST command against the user's home server.

以下に注意してください。 ユーザのホームサーバで利用可能なメールボックスはリモートサーバで利用可能である必要はありません。さらに、リモートサーバで利用可能な追加メールボックスがあるかもしれませんが、ユーザのホームサーバに対してRLISTコマンドへのLIST応答で見えないなら、それらはクライアントには紹介でアクセスしやすくない状態で望んでいます。

   A MAILBOX-REFERRALS capable client will issue the RLIST and RLSUB
   commands in lieu of LIST and LSUB.  The RLIST and RLSUB commands
   behave identically to their LIST and LSUB counterparts, except remote
   mailboxes are returned in addition to local mailboxes in the LIST and
   LSUB responses.  This avoids displaying to a non MAILBOX-REFERRALS
   enabled client inaccessible remote mailboxes.

MAILBOX-REFERRALSの有能なクライアントはLISTとLSUBの代わりにRLISTとRLSUBにコマンドを発行するでしょう。 RLISTとRLSUBコマンドは同様にそれらのLISTとLSUB対応者に振る舞って、リモートメールボックスを除いて、LISTとLSUB応答における地方のメールボックスに加えて返します。 これは、非MAILBOX-REFERRALSの可能にされたクライアントに近づきがたいリモートメールボックスを表示するのを避けます。

4.1. SELECT, EXAMINE, DELETE, SUBSCRIBE, UNSUBSCRIBE, STATUS and APPEND
     Referrals

4.1. 選ぶ、審査、削除、申し込んでください、そして、登録削除、状態、紹介を追加してください。

   An IMAP4 server MAY respond to the SELECT, EXAMINE, DELETE,
   SUBSCRIBE, UNSUBSCRIBE, STATUS or APPEND command with one or more
   IMAP mailbox referrals to indicate to the client that the mailbox is
   hosted on a remote server.

登録、登録削除、IMAP4サーバはSELECT、EXAMINE、DELETEに反応するかもしれなくて、STATUSかAPPENDが1IMAPと共にメールボックス紹介が、メールボックスがリモートサーバで接待されるのをクライアントに示すと命令します。

   When a client processes an IMAP mailbox referral, it will open a new
   connection or use an existing connection to the remote server so that
   it is able to issue the commands necessary to process the remote
   mailbox.

クライアントがIMAPメールボックス紹介を処理するとき、新しい接続を開くか、またはリモートサーバに既存の接続を使用するので、それはリモートメールボックスを処理するのに必要なコマンドを発行できます。

Gahrns                      Standards Track                     [Page 3]

RFC 2193                IMAP4 Mailbox Referrals           September 1997

Gahrns規格はIMAP4メールボックス紹介1997年9月にRFC2193を追跡します[3ページ]。

   Example:  <IMAP4 connection to home server>

例: ホームサーバ>との<IMAP4接続

      C: A001 DELETE "SHARED/FOO"
      S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO]
             Remote mailbox. Try SERVER2.

C: A001は「分配している/FOO」Sを削除します: A001 NO[REFERRAL IMAP://ユーザ; AUTH= *@SERVER2/SHARED/FOO ]のリモートメールボックス。 SERVER2を試みてください。

      <Client established a second connection to SERVER2 and
      issues the DELETE command on the referred mailbox>

<クライアントは、2番目の接続をSERVER2に確立して、参照されたメールボックス>でDELETEにコマンドを発行します。

      S: * OK IMAP4rev1 server ready
      C: B001 AUTHENTICATE KERBEROS_V4
      <authentication exchange>
      S: B001 OK user is authenticated

S: * IMAP4rev1サーバ持ち合わせのCを承認してください: B001 AUTHENTICATE KERBEROS_V4<認証交換>S: B001 OKユーザは認証されます。

      C: B002 DELETE "SHARED/FOO"
      S: B002 OK DELETE completed

C: B002は「分配している/FOO」Sを削除します: 完成したB002 OK DELETE

   Example:  <IMAP4 connection to home server>

例: ホームサーバ>との<IMAP4接続

      C: A001 SELECT REMOTE
      S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/REMOTE
          IMAP://user;AUTH=*@SERVER3/REMOTE] Remote mailbox.
          Try SERVER2 or SERVER3.

C: A001はリモートSを選択します: A001 NO[REFERRAL IMAP://ユーザ; AUTH= *@SERVER2/REMOTE IMAP://ユーザ; AUTH= *@SERVER3/REMOTE ]のリモートメールボックス。 SERVER2かSERVER3を試みてください。

      <Client opens second connection to remote server, and
       issues the commands needed to process the items in the
       remote mailbox>

<クライアントはコマンドがリモートメールボックス>の項目を処理するために必要としたリモートサーバ、および問題に2番目の接続を開きます。

      S: * OK IMAP4rev1 server ready
      C: B001 AUTHENTICATE KERBEROS_V4
      <authentication exchange>
      S: B001 OK user is authenticated

S: * IMAP4rev1サーバ持ち合わせのCを承認してください: B001 AUTHENTICATE KERBEROS_V4<認証交換>S: B001 OKユーザは認証されます。

      C: B002 SELECT REMOTE
      S: * 12 EXISTS
      S: * 1 RECENT
      S: * OK [UNSEEN 10] Message 10 is first unseen
      S: * OK [UIDVALIDITY 123456789]
      S: * FLAGS (Answered Flagged Deleted Seen Draft)
      S: * OK [PERMANENTFLAGS (Answered Deleted Seen ]
      S: B002 OK [READ-WRITE] Selected completed

C: B002はリモートSを選択します: * 12が存在している、S: * 1、最近のS: * OK[UNSEEN10]メッセージ10は最初に、見えないSです: * OK[UIDVALIDITY123456789]S: * 旗(旗を揚げさせられた削除された見られた草稿に答える)のS: * OKである、[完成されて、PERMANENTFLAGS(Deleted Seenに答える]S: B002 OK[READ-WRITE]は選択しました。

      C: B003 FETCH 10:12 RFC822
      S: * 10 FETCH . . .
      S: * 11 FETCH . . .
      S: * 12 FETCH . . .
      S: B003 OK FETCH Completed

C: B003は10:12RFC822 Sをとって来ます: * 10 …Sをとって来てください: * 11 …Sをとって来てください: * 12 …Sをとって来てください: 終了するB003OKフェッチ

Gahrns                      Standards Track                     [Page 4]

RFC 2193                IMAP4 Mailbox Referrals           September 1997

Gahrns規格はIMAP4メールボックス紹介1997年9月にRFC2193を追跡します[4ページ]。

      <Client is finished processing the REMOTE mailbox and
       wants to process a mailbox on its home server>

<クライアントは、REMOTEメールボックスを処理し終わっていて、ホームサーバ>にメールボックスを処理したがっています。

      C: B004 LOGOUT
      S: * BYE IMAP4rev1 server logging out
      S: B004 OK LOGOUT Completed

C: B004がログアウトする、S: * SをログアウトするBYE IMAP4rev1サーバ: B004OKがログアウトする、完成

      <Client continues with first connection>

<クライアントは最初に、接続>を続行します。

      C: A002 SELECT INBOX
      S: * 16 EXISTS
      S: * 2 RECENT
      S: * OK [UNSEEN 10] Message 10 is first unseen
      S: * OK [UIDVALIDITY 123456789]
      S: * FLAGS (Answered Flagged Deleted Seen Draft)
      S: * OK [PERMANENTFLAGS (Answered Deleted Seen ]
      S: A002 OK [READ-WRITE] Selected completed

C: A002は受信トレイSを選択します: * 16が存在している、S: * 2、最近のS: * OK[UNSEEN10]メッセージ10は最初に、見えないSです: * OK[UIDVALIDITY123456789]S: * 旗(旗を揚げさせられた削除された見られた草稿に答える)のS: * OKである、[完成されて、PERMANENTFLAGS(Deleted Seenに答える]S: A002 OK[READ-WRITE]は選択しました。

4.2. CREATE Referrals

4.2. 紹介を作成してください。

   An IMAP4 server MAY respond to the CREATE command with one or more
   IMAP mailbox referrals, if it wishes to direct the client to issue
   the CREATE against another server.  The server can employ any means,
   such as examining the hierarchy of the specified mailbox name, in
   determining which server the mailbox should be created on.

IMAP4サーバは1IMAPのメールボックス紹介でCREATEコマンドに反応するかもしれません、別のサーバに対してCREATEを発行するようクライアントに指示したいなら。サーバはどんな手段も使うことができます、指定されたメールボックス名の階層構造を調べるのなどようにどのサーバを決定するかでは、メールボックスはオンな状態で作成されるべきです。

   Example:

例:

      C: A001 CREATE "SHARED/FOO"
      S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO]
         Mailbox should be created on remote server

C: A001は「分配している/FOO」Sを作成します: A001 NO[REFERRAL IMAP://ユーザ; AUTH= *@SERVER2/SHARED/FOO ]メールボックスはリモートサーバで作成されるべきです。

   Alternatively, because a home server is required to maintain a
   listing of referred remote mailboxes, a server MAY allow the creation
   of a mailbox that will ultimately reside on a remote server against
   the home server, and provide referrals on subsequent commands that
   manipulate the mailbox.

あるいはまた、ホームサーバが参照されたリモートメールボックスのリストを維持するのに必要であるので、サーバは結局リモートサーバにホームサーバに対して住んでいて、メールボックスを操作するその後のコマンドのときに紹介を提供するメールボックスの作成を許容するかもしれません。

   Example:

例:

      C: A001 CREATE "SHARED/FOO"
      S: A001 OK CREATE succeeded

C: A001は「分配している/FOO」Sを作成します: A001 OK CREATEは成功しました。

      C: A002 SELECT "SHARED/FOO"
      S: A002 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/FOO]
         Remote mailbox.  Try SERVER2

C: A002は「分配している/FOO」Sを選択します: A002 NO[REFERRAL IMAP://ユーザ; AUTH= *@SERVER2/SHARED/FOO ]のリモートメールボックス。 SERVER2を試みてください。

Gahrns                      Standards Track                     [Page 5]

RFC 2193                IMAP4 Mailbox Referrals           September 1997

Gahrns規格はIMAP4メールボックス紹介1997年9月にRFC2193を追跡します[5ページ]。

4.3. RENAME Referrals

4.3. 紹介を改名してください。

   An IMAP4 server MAY respond to the RENAME command with one or more
   pairs of IMAP mailbox referrals.  In each pair of IMAP mailbox
   referrals, the first one is an URL to the existing mailbox name and
   the second is an URL to the requested new mailbox name.

IMAP4サーバは1組以上のIMAPメールボックス紹介でRENAMEコマンドに反応するかもしれません。 それぞれの組のIMAPメールボックス紹介では、最初の1つは既存のメールボックス名へのURLです、そして、2番目は要求された新しいメールボックス名へのURLです。

   If within an IMAP mailbox referral pair, the existing and new mailbox
   URLs are on different servers, the remote servers are unable to
   perform the RENAME operation.   To achieve the same behavior of
   server RENAME, the client MAY issue the constituent CREATE, FETCH,
   APPEND, and DELETE commands against both servers.

存在と新しいメールボックスURLが異なったサーバにIMAPメールボックス紹介組の中にあるなら、リモートサーバはRENAME操作を実行できません。 サーバRENAMEの同じ動きを達成するために、クライアントは両方のサーバに対して構成しているCREATE、FETCH、APPEND、およびDELETEコマンドを発行するかもしれません。

   If within an IMAP mailbox referral pair, the existing and new mailbox
   URLs are on the same server it is an indication that the currently
   connected server is unable to perform the operation.  The client can
   simply re-issue the RENAME command on the remote server.

存在と新しいメールボックスURLがそれが現在接続されたサーバが操作を実行できないという同じサーバにおける、指示であるというIMAPメールボックス紹介組の中のことであるなら。 クライアントはリモートサーバで単にRENAMEコマンドを再発行できます。

   Example:

例:

      C: A001 RENAME FOO BAR
      S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER1/FOO
              IMAP://user;AUTH=*@SERVER2/BAR] Unable to rename mailbox
              across servers

C: A001はバーSにFOOを改名します: サーバの向こう側にメールボックスを改名できないA001 NO[REFERRAL IMAP://ユーザ; AUTH= *@SERVER1/FOO IMAP://ユーザ; AUTH= *@SERVER2/BAR ]

   Since the existing and new mailbox names are on different servers,
   the client would be required to make a connection to both servers and
   issue the constituent commands require to achieve the RENAME.

存在と新しいメールボックス名が異なったサーバにあるので、クライアントは接続を構成しているコマンドがRENAMEを達成するのを必要とするサーバと問題の両方にしなければならないでしょう。

   Example:

例:

      C: A001 RENAME FOO BAR
      S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/FOO
              IMAP://user;AUTH=*@SERVER2/BAR] Unable to rename mailbox
              located on SERVER2

C: A001はバーSにFOOを改名します: SERVER2に見つけられたメールボックスを改名できないA001 NO[REFERRAL IMAP://ユーザ; AUTH= *@SERVER2/FOO IMAP://ユーザ; AUTH= *@SERVER2/BAR ]

   Since both the existing and new mailbox are on the same remote
   server, the client can simply make a connection to the remote server
   and re-issue the RENAME command.

両方以来、存在と新しいメールボックスが同じリモートサーバにあって、クライアントは、単に接続をリモートサーバにして、RENAMEコマンドを再発行できます。

4.4. COPY Referrals

4.4. コピー紹介

   An IMAP4 server MAY respond to the COPY command with one or more IMAP
   mailbox referrals.  This indicates that the destination mailbox is on
   a remote server.  To achieve the same behavior of a server COPY, the
   client MAY issue the constituent FETCH and APPEND commands against
   both servers.

IMAP4サーバは1IMAPのメールボックス紹介でCOPYコマンドに反応するかもしれません。 これは、あて先メールボックスがリモートサーバにあるのを示します。サーバの同じ働きを達成するために、クライアント5月号のCOPY、構成しているFETCH、およびAPPENDは両方のサーバに対して命令します。

Gahrns                      Standards Track                     [Page 6]

RFC 2193                IMAP4 Mailbox Referrals           September 1997

Gahrns規格はIMAP4メールボックス紹介1997年9月にRFC2193を追跡します[6ページ]。

   Example:

例:

      C: A001 COPY 1 "SHARED/STUFF"
      S: A001 NO [REFERRAL IMAP://user;AUTH=*@SERVER2/SHARED/STUFF]
              Unable to copy message(s) to SERVER2.

C: A001コピー1はSを「共有されるか、または詰めます」: SERVER2にメッセージをコピーできないA001 NO[REFERRAL IMAP://ユーザ; AUTH= *@SERVER2/SHARED/STUFF ]。

5.1 RLIST command

5.1 RLISTコマンド

   Arguments:  reference name
               mailbox name with possible wildcards

議論: 可能なワイルドカードの参照名前メールボックス名

   Responses:  untagged responses: LIST

応答: 非タグ付けをされた応答: リスト

   Result:     OK - RLIST Completed
               NO - RLIST Failure
               BAD - command unknown or arguments invalid

結果: OK--RLIST Completedノー--RLIST Failure BAD--コマンド未知か議論病人

   The RLIST command behaves identically to its LIST counterpart, except
   remote mailboxes are returned in addition to local mailboxes in the
   LIST responses.

同様にLIST対応者に振る舞って、リモートメールボックスを除いて、LIST応答における地方のメールボックスに加えて返されますRLISTが、命令する。

5.2 RLSUB Command

5.2 RLSUBコマンド

   Arguments:  reference name
               mailbox name with possible wildcards

議論: 可能なワイルドカードの参照名前メールボックス名

   Responses:  untagged responses: LSUB

応答: 非タグ付けをされた応答: LSUB

   Result:     OK - RLSUB Completed
               NO - RLSUB Failure
               BAD - command unknown or arguments invalid

結果: OK--RLSUB Completedノー--RLSUB Failure BAD--コマンド未知か議論病人

   The RLSUB command behaves identically to its LSUB counterpart, except
   remote mailboxes are returned in addition to local mailboxes in the
   LSUB responses.

同様にLSUB対応者に振る舞って、リモートメールボックスを除いて、LSUB応答における地方のメールボックスに加えて返されますRLSUBが、命令する。

6. Formal Syntax

6. 正式な構文

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) as described in [ABNF].

以下の構文仕様は[ABNF]で説明されるように増大しているBN記法(BNF)を使用します。

   list_mailbox = <list_mailbox> as defined in [RFC-2060]

中で定義されるリスト_メールボックス=<リスト_メールボックス>。[RFC-2060]

   mailbox = <mailbox> as defined in [RFC-2060]

中で定義されるメールボックス=<メールボックス>。[RFC-2060]

   mailbox_referral = <tag> SPACE "NO" SPACE
      <referral_response_code> (text / text_mime2)
      ; See [RFC-2060] for <tag>, text and text_mime2 definition

_<タグ>SPACE「いいえ」宇宙<メールボックス_紹介=紹介応答_コード>(_テキスト/テキストmime2)。 <タグ>、テキスト、およびテキスト_mime2定義に関して[RFC-2060]を見てください。

Gahrns                      Standards Track                     [Page 7]

RFC 2193                IMAP4 Mailbox Referrals           September 1997

Gahrns規格はIMAP4メールボックス紹介1997年9月にRFC2193を追跡します[7ページ]。

   referral_response_code = "[" "REFERRAL" 1*(SPACE <url>) "]"
      ; See [RFC-1738] for <url> definition

紹介_応答_コードは「[「「紹介」1*(スペース<url>)」]」と等しいです。 <url>定義に関して[RFC-1738]を見てください。

   rlist = "RLIST" SPACE mailbox SPACE list_mailbox

rlistは"RLIST"スペースメールボックススペースリスト_メールボックスと等しいです。

   rlsub = "RLSUB" SPACE mailbox SPACE list_mailbox

rlsubは"RLSUB"スペースメールボックススペースリスト_メールボックスと等しいです。

6. Security Considerations

6. セキュリティ問題

   The IMAP4 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 [RFC-2192].

IMAP4紹介メカニズムはIMAP URLを利用します、そして、そういうものとして、一般的なインターネットURL[RFC1738]、および特定のIMAP URL[RFC-2192]の同じセキュリティ問題を持ってください。

   With the MAILBOX-REFERRALS capability, it is potentially easier to
   write a rogue server that injects a bogus referral response that
   directs a user to an incorrect mailbox.  Although referrals reduce
   the effort to write such a server, the referral response makes
   detection of the intrusion easier.

MAILBOX-REFERRALS能力では、不正確なメールボックスにユーザを向けるにせの紹介応答を注入する凶暴なサーバを書くのは潜在的により簡単です。 紹介はそのようなサーバを書くために取り組みを減少させますが、紹介応答で、侵入の検出は、より簡単になります。

7. References

7. 参照

   [RFC-2060], Crispin, M., "Internet Message Access Protocol - Version
   4rev1", RFC 2060, University of Washington, December 1996.

[RFC-2060]、クリスピン、M.、「バージョン4rev1"、RFC2060、ワシントン大学、1996年インターネットメッセージアクセス・プロトコル--12月。」

   [RFC-2192], Newman, C., "IMAP URL Scheme", RFC 2192, Innosoft,
   September 1997.

[RFC-2192]、ニューマン、C.、「IMAP URL体系」、RFC2192、Innosoft、1997年9月。

   [RFC-1738], Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
   Resource Locators (URL)", RFC 1738, CERN, Xerox Corporation,
   University of Minnesota, December 1994.

[RFC-1738]とバーナーズ・リーとT.とMasinter、L.とM.McCahill、「Uniform Resource Locator(URL)」、RFC1738、CERN、ゼロックス社、ミネソタ大学、1994年12月。

   [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", RFC 2119, Harvard University, 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, Internet Mail
   Consortium, April 1997.

[ABNF]、DRUMSワーキンググループ、デーヴクロッカーEditor、「構文仕様のための増大しているBNF:」 "ABNF"は1997年4月に進歩、インターネットメール共同体で働いています。

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、クリス・ニューマン、およびラリー・オスターマンはこのドキュメントへの重要な貢献を特に、しました。

Gahrns                      Standards Track                     [Page 8]

RFC 2193                IMAP4 Mailbox Referrals           September 1997

Gahrns規格はIMAP4メールボックス紹介1997年9月にRFC2193を追跡します[8ページ]。

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 9]

Gahrns標準化過程[9ページ]