RFC2342 日本語訳

Network Working Group                                         M. Gahrns
Request for Comments: 2342                                    Microsoft
Category: Standards Track                                     C. Newman
                                                               Innosoft
                                                               May 1998

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

                            IMAP4 Namespace

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 (1998).  All Rights Reserved.

Copyright(C)インターネット協会(1998)。 All rights reserved。

1. Abstract

1. 要約

   IMAP4 [RFC-2060] does not define a default server namespace. As a
   result, two common namespace models have evolved:

IMAP4[RFC-2060]は標準サーバー名前空間を定義しません。 その結果、2つの一般的な名前空間モデルが発展しました:

   The "Personal Mailbox" model, in which the default namespace that is
   presented consists of only the user's personal mailboxes. To access
   shared mailboxes, the user must use an escape mechanism to reach
   another namespace.

「個人的なメールボックス」モデル。((そこでは、ユーザの個人的なメールボックスだけから成ります)提示されるデフォルト名前空間)。 共有されたメールボックスにアクセスするなら、ユーザは、別の名前空間に達するのに逃避機制を使用しなければなりません。

   The "Complete Hierarchy" model, in which the default namespace that
   is presented includes the user's personal mailboxes along with any
   other mailboxes they have access to.

「完全な階層構造」モデル。((そこでは、それらが近づく手段を持っているいかなる他のメールボックスに伴うユーザの個人的なメールボックスも含んでいます)提示されるデフォルト名前空間)。

   These two models, create difficulties for certain client operations.
   This document defines a NAMESPACE command that allows a client to
   discover the prefixes of namespaces used by a server for personal
   mailboxes, other users' mailboxes, and shared mailboxes.  This allows
   a client to avoid much of the manual user configuration that is now
   necessary when mixing and matching IMAP4 clients and servers.

これらの2は、あるクライアント操作のためにモデル化して、困難を作成します。 このドキュメントはクライアントが個人的なメールボックス、他のユーザのメールボックス、および共有されたメールボックスにサーバによって使用される名前空間の接頭語を発見できるNAMESPACEコマンドを定義します。 これで、クライアントはIMAP4クライアントとサーバを混ぜて、現在合わせるとき必要な手動のユーザ構成の多くを避けることができます。

2. Conventions used in this document

2. 本書では使用されるコンベンション

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.  If such lines are wrapped without a new "C:" or
   "S:" label, then the wrapping is for editorial clarity and is not
   part of the command.

例で「C:」 そして、「S:」 クライアントとサーバによってそれぞれ送られた系列を示してください。 そのような系列が新しいaなしで包装される、「C:」 または、「S:」 次に、ラベル、ラッピングは、編集の明快ためにあって、コマンドの一部ではありません。

Gahrns & Newman             Standards Track                     [Page 1]

RFC 2342                    IMAP4 Namespace                     May 1998

GahrnsとニューマンStandardsはIMAP4名前空間1998年5月にRFC2342を追跡します[1ページ]。

   Personal Namespace: A namespace that the server considers within the
   personal scope of the authenticated user on a particular connection.
   Typically, only the authenticated user has access to mailboxes in
   their Personal Namespace. It is the part of the namespace that
   belongs to the user that is allocated for mailboxes. If an INBOX
   exists for a user, it MUST appear within the user's personal
   namespace.  In the typical case, there SHOULD be only one Personal
   Namespace on a server.

個人的な名前空間: サーバが特定の接続のときに認証されたユーザの個人的な範囲の中で考える名前空間。 認証されたユーザだけがそれらのパーソナルNamespaceでメールボックスに近づく手段を持っています。 それはメールボックスのために割り当てられるユーザのものである名前空間の部分です。 受信トレイがユーザのために存在しているなら、それはユーザの個人的な名前空間の中に現れなければなりません。 典型的がそこにケースに入れるコネ、SHOULD、単にサーバの1パーソナルNamespaceになってください。

   Other Users' Namespace: A namespace that consists of mailboxes from
   the Personal Namespaces of other users.  To access mailboxes in the
   Other Users' Namespace, the currently authenticated user MUST be
   explicitly granted access rights.  For example, it is common for a
   manager to grant to their secretary access rights to their mailbox.
   In the typical case, there SHOULD be only one Other Users' Namespace
   on a server.

他のユーザの名前空間: 他のユーザのパーソナルNamespacesからのメールボックスから成る名前空間。 Other UsersのNamespaceでメールボックスにアクセスするために、明らかに現在認証されたユーザにアクセス権を与えなければなりません。 例えば、マネージャがそれらのメールボックスへのアクセス権を彼らの秘書に与えるのは、一般的です。 典型的がそこにケースに入れるコネ、SHOULD、サーバの1Other UsersだけのNamespaceになってください。

   Shared Namespace: A namespace that consists of mailboxes that are
   intended to be shared amongst users and do not exist within a user's
   Personal Namespace.

名前空間を共有します: ユーザの中で共有されて、ユーザのパーソナルNamespaceの中に存在しないことを意図するメールボックスから成る名前空間。

   The namespaces a server uses MAY differ on a per-user basis.

サーバが使用する名前空間は1ユーザあたり1つの基礎について異なる意見をもつかもしれません。

   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. 序論と概要

   Clients often attempt to create mailboxes for such purposes as
   maintaining a record of sent messages (e.g. "Sent Mail") or
   temporarily saving messages being composed (e.g. "Drafts").  For
   these clients to inter-operate correctly with the variety of IMAP4
   servers available, the user must enter the prefix of the Personal
   Namespace used by the server.  Using the NAMESPACE command, a client
   is able to automatically discover this prefix without manual user
   configuration.

クライアントは、しばしば送信されたメッセージ(例えば、「メールを送る」)に関する記録を保守するか、または一時構成されるメッセージ(例えば、「草稿」)を保存するような目的のためのメールボックスを作成するのを試みます。 IMAP4サーバのバラエティーが利用可能な状態でこれらのクライアントが正しく共同利用するように、ユーザはサーバによって使用されるパーソナルNamespaceの接頭語に入らなければなりません。NAMESPACEコマンドを使用して、クライアントは手動のユーザ構成なしでこの接頭語を自動的に発見できます。

   In addition, users are often required to manually enter the prefixes
   of various namespaces in order to view the mailboxes located there.
   For example, they might be required to enter the prefix of #shared to
   view the shared mailboxes namespace. The NAMESPACE command allows a
   client to automatically discover the namespaces that are available on
   a server. This allows a client to present the available namespaces to
   the user in what ever manner it deems appropriate.  For example, a

さらに、ユーザは、そこに位置したメールボックスを見るためにしばしば手動で様々な名前空間の接頭語を入れなければなりません。 例えば、彼らは共有されたメールボックス名前空間を見るために共有された#の接頭語を入れなければならないかもしれません。 NAMESPACEコマンドは自動的に名前空間を発見するクライアントが. これでいったい何で利用可能な名前空間をユーザに提示できるサーバに手があいているクライアントにそれが適切であると考える方法を許容します。 例えば、a

Gahrns & Newman             Standards Track                     [Page 2]

RFC 2342                    IMAP4 Namespace                     May 1998

GahrnsとニューマンStandardsはIMAP4名前空間1998年5月にRFC2342を追跡します[2ページ]。

   client could choose to initially display only personal mailboxes, or
   it may choose to display the complete list of mailboxes available,
   and initially position the user at the root of their Personal
   Namespace.

クライアントが、初めは個人的なメールボックスだけを表示するのを選ぶことができたか、それは、メールボックスの利用可能な全リストを表示して、初めはそれらのパーソナルNamespaceの根でユーザを置くのを選ぶかもしれません。

   A server MAY choose to make available to the NAMESPACE command only a
   subset of the complete set of namespaces the server supports. To
   provide the ability to access these namespaces, a client SHOULD allow
   the user the ability to manually enter a namespace prefix.

サーバは、サーバがサポートする名前空間の完全なセットの部分集合をNAMESPACEコマンドだけに利用可能にするのを選ぶかもしれません。 これらの名前空間、クライアントSHOULDにアクセスする能力を提供するには、手動で名前空間接頭語を入れる能力をユーザに許容してください。

4. Requirements

4. 要件

   IMAP4 servers that support this extension MUST list the keyword
   NAMESPACE in their CAPABILITY response.

この拡大をサポートするIMAP4サーバは彼らのCAPABILITY応答でキーワードNAMESPACEを記載しなければなりません。

   The NAMESPACE command is valid in the Authenticated and Selected
   state.

NAMESPACEコマンドはAuthenticatedとSelected状態で有効です。

5. NAMESPACE Command

5. 名前空間コマンド

   Arguments: none

議論: なし

   Response:  an untagged NAMESPACE response that contains the prefix
                 and hierarchy delimiter to the server's Personal
                 Namespace(s), Other Users' Namespace(s), and Shared
                 Namespace(s) that the server wishes to expose. The
                 response will contain a NIL for any namespace class
                 that is not available. Namespace_Response_Extensions
                 MAY be included in the response.
                 Namespace_Response_Extensions which are not on the IETF
                 standards track, MUST be prefixed with an "X-".

応答: サーバが暴露したがっているサーバのパーソナルNamespace(s)、Other UsersのNamespace(s)、およびShared Namespace(s)に接頭語と階層構造デリミタを含むuntagged NAMESPACE応答。 応答はどんな利用可能でない名前空間のクラスのためのNILも含むでしょう。 名前空間_Response_Extensionsは応答に含まれるかもしれません。 名前空間、_IETF規格にないResponse_Extensionsは追跡して、「X」と共に前に置かなければなりません。

   Result:    OK - Command completed
                 NO - Error: Can't complete command
                 BAD - argument invalid

結果: OK--コマンドはいいえ--誤りを終了しました: コマンドBADを完成できません--、議論病人

   Example 5.1:
   ===========

例5.1: ===========

      < A server that supports a single personal namespace.  No leading
      prefix is used on personal mailboxes and "/" is the hierarchy
      delimiter.>

ただ一つの個人的な名前空間をサポートする<Aサーバ。 「どんな主な接頭語も」 個人的なメールボックスと/で使用されません」が階層構造デリミタである、>。

      C: A001 NAMESPACE
      S: * NAMESPACE (("" "/")) NIL NIL
      S: A001 OK NAMESPACE command completed

C: A001名前空間S: * 名前空間、(「「「/」) 無S無:、」 終了するA001 OK NAMESPACEコマンド

Gahrns & Newman             Standards Track                     [Page 3]

RFC 2342                    IMAP4 Namespace                     May 1998

GahrnsとニューマンStandardsはIMAP4名前空間1998年5月にRFC2342を追跡します[3ページ]。

   Example 5.2:
   ===========

例5.2: ===========

      < A user logged on anonymously to a server.  No personal mailboxes
      are associated with the anonymous user and the user does not have
      access to the Other Users' Namespace.  No prefix is required to
      access shared mailboxes and the hierarchy delimiter is "." >

ユーザが匿名でサーバ個人的なメールボックスがないのにログオンした<は匿名のユーザに関連しています、そして、ユーザはOther UsersのNamespaceに近づく手段を持っていません。 「接頭語は全く共有されたメールボックスにアクセスするのに必要ではありません、そして、階層構造デリミタが必要である」、」 >。

      C: A001 NAMESPACE
      S: * NAMESPACE NIL NIL (("" "."))
      S: A001 OK NAMESPACE command completed

C: A001名前空間S: * 名前空間無無、(「「「」、)、S:、」 終了するA001 OK NAMESPACEコマンド

   Example 5.3:
   ===========

例5.3: ===========

      < A server that contains a Personal Namespace and a single Shared
      Namespace. >

パーソナルNamespaceと独身のShared Namespaceを含む<Aサーバ。 >。

      C: A001 NAMESPACE
      S: * NAMESPACE (("" "/")) NIL (("Public Folders/" "/"))
      S: A001 OK NAMESPACE command completed

C: A001名前空間S: * 名前空間、(「「「/」) 無、(「公共のフォルダー/」、」 /、」、)、S: 終了するA001 OK NAMESPACEコマンド

   Example 5.4:
   ===========

例5.4: ===========

      < A server that contains a Personal Namespace, Other Users'
      Namespace and multiple Shared Namespaces.  Note that the hierarchy
      delimiter used within each namespace can be different. >

パーソナルNamespace、Other UsersのNamespace、および複数のShared Namespacesを含む<Aサーバ。 各名前空間の中で使用された階層構造デリミタが異なる場合があることに注意してください。 >。

      C: A001 NAMESPACE
      S: * NAMESPACE (("" "/")) (("~" "/")) (("#shared/" "/")
         ("#public/" "/")("#ftp/" "/")("#news." "."))
      S: A001 OK NAMESPACE command completed

C: A001名前空間S: * NAMESPACE (("" "/")) (("~" "/")) (("#shared/" "/") ("#public/" "/")("#ftp/" "/")("#news." ".")) S: 終了するA001 OK NAMESPACEコマンド

   The prefix string allows a client to do things such as automatically
   creating personal mailboxes or LISTing all available mailboxes within
   a namespace.

接頭語ストリングで、クライアントは名前空間の中で自動的に個人的なメールボックスかLISTingを作成などなどのものにすべての利用可能なメールボックスができます。

   Example 5.5:
   ===========

例5.5: ===========

      < A server that supports only the Personal Namespace, with a
      leading prefix of INBOX to personal mailboxes and a hierarchy
      delimiter of ".">

「個人的なメールボックスへの受信トレイの主な接頭語と」 . ">"の階層構造デリミタでパーソナルだけNamespaceをサポートする<Aサーバ

      C: A001 NAMESPACE
      S: * NAMESPACE (("INBOX." ".")) NIL  NIL
      S: A001 OK NAMESPACE command completed

C: A001名前空間S: * 「名前空間、(「受信トレイ。」、」、」、)、無S無: 終了するA001 OK NAMESPACEコマンド

Gahrns & Newman             Standards Track                     [Page 4]

RFC 2342                    IMAP4 Namespace                     May 1998

GahrnsとニューマンStandardsはIMAP4名前空間1998年5月にRFC2342を追跡します[4ページ]。

      < Automatically create a mailbox to store sent items.>

<は、送られた項目 >を保存するために自動的にメールボックスを作成します。

      C: A002 CREATE "INBOX.Sent Mail"
      S: A002 OK CREATE command completed

C: A002は「INBOX.Sentメール」Sを作成します: 終了するA002 OK CREATEコマンド

   Although typically a server will support only a single Personal
   Namespace, and a single Other User's Namespace, circumstances exist
   where there MAY be multiples of these, and a client MUST be prepared
   for them.   If a client is configured such that it is required to
   create a certain mailbox, there can be circumstances where it is
   unclear which Personal Namespaces it should create the mailbox in.
   In these situations a client SHOULD let the user select which
   namespaces to create the mailbox in.

サーバは、単一の唯一のパーソナルがNamespaceと、独身のOther UserのNamespaceであると通常サポートするでしょうが、事情はこれらの倍数があるかもしれないところに存在しています、そして、クライアントはそれらのために用意ができていなければなりません。 クライアントが構成されるなら、あるメールボックスを作成するのがそこで必要であるようなものはそれがどのパーソナルNamespacesでメールボックスを作成するべきであるかが、不明瞭である事情であるかもしれません。 これらの状況で、クライアントSHOULDはユーザにどの名前空間にメールボックスを作成するかを選択させることができました。

   Example 5.6:
   ===========

例5.6: ===========

      < In this example, a server supports 2 Personal Namespaces.  In
      addition to the regular Personal Namespace, the user has an
      additional personal namespace to allow access to mailboxes in an
      MH format mailstore. >

この例の<、サーバは2パーソナルNamespacesをサポートします。 通常のパーソナルNamespaceに加えて、ユーザはMH形式mailstoreにメールボックスへのアクセスを許す追加個人的な名前空間を持っています。 >。

      < The client is configured to save a copy of all mail sent by the
      user into a mailbox called 'Sent Mail'.  Furthermore, after a
      message is deleted from a mailbox, the client is configured to
      move that message to a mailbox called 'Deleted Items'.>

クライアントの<は、ユーザによって'送られたメール'と呼ばれるメールボックスの中に送られたすべてのメールのコピーを保存するために構成されます。 その上、メッセージがメールボックスから削除された後にクライアントは、そのメッセージを'削除されたItems'と呼ばれるメールボックスに動かすために構成されます。>。

      < Note that this example demonstrates how some extension flags can
      be passed to further describe the #mh namespace. >

さらに#mh名前空間について説明するために、この例が何らかの拡大がどう弛むかを示すという<メモを渡すことができます。 >。

      C: A001 NAMESPACE
      S: * NAMESPACE (("" "/")("#mh/" "/" "X-PARAM" ("FLAG1" "FLAG2")))
         NIL NIL
      S: A001 OK NAMESPACE command completed

C: A001名前空間S: * 名前空間、(「「「/」) (」 「#mh/」」 /"X-PARAM"("FLAG1""FLAG2"))無S無: 終了するA001 OK NAMESPACEコマンド

      < It is desired to keep only one copy of sent mail. It is unclear
      which Personal Namespace the client should use to create the 'Sent
      Mail' mailbox.  The user is prompted to select a namespace and
      only one 'Sent Mail' mailbox is created. >

写し1部だけを取っておくのが必要である<はメールを送りました。 クライアントが'送られたメール'メールボックスを作成するのにどのパーソナルNamespaceを使用するべきであるかは、不明瞭です。 ユーザが名前空間を選択するようにうながされて、1個の'送られたメール'メールボックスだけが作成されます。 >。

      C: A002 CREATE "Sent Mail"
      S: A002 OK CREATE command completed

C: A002は「送られたメール」Sを作成します: 終了するA002 OK CREATEコマンド

      < The client is designed so that it keeps two 'Deleted Items'
      mailboxes, one for each namespace. >

クライアントの<は、2'削除されたItems'のメールボックス、各名前空間あたり1つを保つように、設計されています。 >。

      C: A003 CREATE "Delete Items"
      S: A003 OK CREATE command completed

C: A003は「項目を削除してください」というSを作成します: 終了するA003 OK CREATEコマンド

Gahrns & Newman             Standards Track                     [Page 5]

RFC 2342                    IMAP4 Namespace                     May 1998

GahrnsとニューマンStandardsはIMAP4名前空間1998年5月にRFC2342を追跡します[5ページ]。

      C: A004 CREATE "#mh/Deleted Items"
      S: A004 OK CREATE command completed

C: 「A004は」 #mh/削除された項目を作成する」というS: 終了するA004 OK CREATEコマンド

   The next level of hierarchy following the Other Users' Namespace
   prefix SHOULD consist of <username>, where <username> is a user name
   as per the IMAP4 LOGIN or AUTHENTICATE command.

Other UsersのNamespace接頭語SHOULDに続く階層構造の次のレベルは<ユーザ名>から成ります。そこでは、<ユーザ名>がIMAP4 LOGINかAUTHENTICATEコマンドに従ってユーザ名です。

   A client can construct a LIST command by appending a "%" to the Other
   Users' Namespace prefix to discover the Personal Namespaces of other
   users that are available to the currently authenticated user.

クライアントは、他の現在認証されたユーザにとって、手があいているユーザの個人的な名前空間を発見するために他のユーザの名前空間接頭語に「%」添えることによって、LISTコマンドを構成できます。

   In response to such a LIST command, a server SHOULD NOT return user
   names that have not granted access to their personal mailboxes to the
   user in question.

そのようなLISTコマンド、SHOULD NOTが返すサーバに対応して、そうしたユーザ名はそれらの個人的なメールボックスへの問題のユーザのアクセスを承諾しませんでした。

   A server MAY return a LIST response containing only the names of
   users that have explicitly granted access to the user in question.

サーバは明らかに問題のユーザへのアクセスを承諾したユーザの名前だけを含むLIST応答を返すかもしれません。

   Alternatively, a server MAY return NO to such a LIST command,
   requiring that a user name be included with the Other Users'
   Namespace prefix before listing any other user's mailboxes.

あるいはまた、サーバはそのようなLISTコマンドにいいえを返すかもしれません、ユーザ名がいかなる他のユーザのメールボックスも記載する前のOther UsersのNamespace接頭語で含まれているのが必要であることで。

   Example 5.7:
   ===========

例5.7: ===========

      < A server that supports providing a list of other user's
      mailboxes that are accessible to the currently logged on user. >

提供が他のユーザの現在ユーザの上に登録されているのにアクセスしやすいメールボックスのリストであるとサポートする<Aサーバ。 >。

      C: A001 NAMESPACE
      S: * NAMESPACE (("" "/")) (("Other Users/" "/")) NIL
      S: A001 OK NAMESPACE command completed

C: A001名前空間S: * 名前空間、(「「「/」)、(「他のユーザ/」、」 /、」、)、無S: 終了するA001 OK NAMESPACEコマンド

      C: A002 LIST "" "Other Users/%"
      S: * LIST () "/" "Other Users/Mike"
      S: * LIST () "/" "Other Users/Karen"
      S: * LIST () "/" "Other Users/Matthew"
      S: * LIST () "/" "Other Users/Tesa"
      S: A002 OK LIST command completed

C: A002が記載する、「「「他のユーザ/%」S:」 * 「リスト()」/」 「他のユーザ/マイク」S: * 「リスト()」/」 「他のユーザ/カレン」S: * 「リスト()」/」 「他のユーザ/マシュー」S: * 「リスト()」/」 「他のユーザ/Tesa」S: 終了するA002 OK LISTコマンド

   Example 5.8:
   ===========

例5.8: ===========

      < A server that does not support providing a list of other user's
      mailboxes that are accessible to the currently logged on user.
      The mailboxes are listable if the client includes the name of the
      other user with the Other Users' Namespace prefix. >

提供が他のユーザの現在ユーザの上に登録されているのにアクセスしやすいメールボックスのリストであるとサポートしない<Aサーバ。 クライアントがOther UsersのNamespace接頭語でもう片方のユーザの名前を入れるなら、メールボックスは記載可能です。 >。

Gahrns & Newman             Standards Track                     [Page 6]

RFC 2342                    IMAP4 Namespace                     May 1998

GahrnsとニューマンStandardsはIMAP4名前空間1998年5月にRFC2342を追跡します[6ページ]。

      C: A001 NAMESPACE
      S: * NAMESPACE (("" "/")) (("#Users/" "/")) NIL
      S: A001 OK NAMESPACE command completed

C: A001名前空間S: * 名前空間、(「「「/」)、(「#ユーザ/」、」 /、」、)、無S: 終了するA001 OK NAMESPACEコマンド

      < In this example, the currently logged on user has access to the
      Personal Namespace of user Mike, but the server chose to suppress
      this information in the LIST response.  However, by appending the
      user name Mike (received through user input) to the Other Users'
      Namespace prefix, the client is able to get a listing of the
      personal mailboxes of user Mike. >

この例の<、現在ユーザの上に登録されているのはユーザマイクのパーソナルNamespaceに近づく手段を持っていますが、サーバは、LIST応答におけるこの情報を抑圧するのを選びました。 しかしながら、マイクというユーザ名をOther UsersのNamespace接頭語に追加することによって(ユーザ入力で、受信します)、クライアントはユーザマイクの個人的なメールボックスのリストを手に入れることができます。 >。

      C: A002 LIST "" "#Users/%"
      S: A002 NO The requested item could not be found.

C: A002が記載する、「「「#ユーザ/%」S:」 要求された項目を見つけることができなかったA002 NO。

      C: A003 LIST "" "#Users/Mike/%"
      S: * LIST () "/" "#Users/Mike/INBOX"
      S: * LIST () "/" "#Users/Mike/Foo"
      S: A003 OK LIST command completed.

C: A003が記載する、「「「#Users/Mike/%」S:」 * 「」 」 () 」 /#ユーザ/マイク/受信トレイを記載してください」というS: * 「リスト()」 /」 」 #ユーザ/マイク/Foo」S: 終了するA003 OK LISTコマンド。

      A prefix string might not contain a hierarchy delimiter, because
      in some cases it is not needed as part of the prefix.

接頭語ストリングは階層構造デリミタを含まないかもしれません、それがいくつかの場合接頭語の一部として必要でないので。

      Example 5.9:
      ===========

例5.9: ===========

      < A server that allows access to the Other Users' Namespace by
      prefixing the others' mailboxes with a '~' followed by <username>,
      where <username> is a user name as per the IMAP4 LOGIN or
      AUTHENTICATE command.>

'<はAUTHENTICATEコマンド<ユーザ名>がIMAP4 LOGINに従ってユーザ名である<ユーザ名>による'~'が続かれている状態で他のもの'メールボックスを前に置くのによるOther UsersのNamespaceか>へのアクセスを許すサーバです。

      C: A001 NAMESPACE
      S: * NAMESPACE (("" "/")) (("~" "/")) NIL
      S: A001 OK NAMESPACE command completed

C: A001名前空間S: * 名前空間、(「「「/」)、(「~、」 」 /、」、)、無S: 終了するA001 OK NAMESPACEコマンド

      < List the mailboxes for user mark >

ユーザのためのメールボックスが>であるとマークする<リスト

      C: A002 LIST "" "~mark/%"
      S: * LIST () "/" "~mark/INBOX"
      S: * LIST () "/" "~mark/foo"
      S: A002 OK LIST command completed

C: A002が記載する、「「「~マーク/%」S:」 * 「() 」 」 」 ~、が/受信トレイであるとマークする/を記載してください」というS: * 「リスト()」 /」 」 ~マーク/foo」S: 終了するA002 OK LISTコマンド

   Historical convention has been to start all namespaces with the "#"
   character.  Namespaces that include the "#" character are not IMAP
   URL [IMAP-URL] friendly requiring the "#" character to be represented
   as %23 when within URLs.  As such, server implementers MAY instead
   consider using namespace prefixes that do not contain the "#"
   character.

歴史的なコンベンションは、すべての名前空間を始めに「#」キャラクタから行ったことがあります。 URLの中にあるとき、「#」キャラクタが%23として代理をされるのが必要でありながら、「#」キャラクタを含んでいる名前空間はIMAP URL[IMAP-URL]好意的ではありません。 そういうものとして、サーバimplementersは、「#」キャラクタを含まない名前空間接頭語を使用すると代わりに考えるかもしれません。

Gahrns & Newman             Standards Track                     [Page 7]

RFC 2342                    IMAP4 Namespace                     May 1998

GahrnsとニューマンStandardsはIMAP4名前空間1998年5月にRFC2342を追跡します[7ページ]。

6. Formal Syntax

6. 正式な構文

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

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

   atom = <atom>
      ; <atom> as defined in [RFC-2060]

原子は<原子>と等しいです。 中で定義される<原子>。[RFC-2060]

   Namespace = nil / "(" 1*( "(" string SP  (<"> QUOTED_CHAR <"> /
      nil) *(Namespace_Response_Extension) ")" ) ")"

名前空間=無/、「(「1*、(「(「SPを結んでください、(<、「>QUOTED_CHAR<、「>/無) *(名前空間_Response_Extension)」、)、」、)、」、)、」、」

   Namespace_Command = "NAMESPACE"

名前空間_コマンドは「名前空間」と等しいです。

   Namespace_Response_Extension = SP string SP "(" string *(SP string)
      ")"

「(「ストリング*(SPストリング)」)」という名前空間_Response_Extension=SPストリングSP

   Namespace_Response = "*" SP "NAMESPACE" SP Namespace SP Namespace SP
      Namespace

名前空間_応答は「*」SP「名前空間」SP名前空間SP名前空間SP名前空間と等しいです。

      ; The first Namespace is the Personal Namespace(s)
      ; The second Namespace is the Other Users' Namespace(s)
      ; The third Namespace is the Shared Namespace(s)

; 最初のNamespaceはパーソナルNamespace(s)です。 第2NamespaceはOther UsersのNamespace(s)です。 第3NamespaceはShared Namespaceです。(s)

      nil = <nil>
         ; <nil> as defined in [RFC-2060]

無は<の無い>と等しいです。 中で定義される<無>。[RFC-2060]

      QUOTED_CHAR = <QUOTED_CHAR>
         ; <QUOTED_CHAR> as defined in [RFC-2060]

引用された_炭=<は_炭の>を引用しました。 中で定義される<QUOTED_CHAR>。[RFC-2060]

      string = <string>
         ; <string> as defined in [RFC-2060]
         ; Note that  the namespace prefix is to a mailbox and following
         ; IMAP4 convention, any international string in the NAMESPACE
         ; response MUST be of modified UTF-7 format as described in
         ;  [RFC-2060].

=<ストリング>を結んでください。 [RFC-2060]で定義される<ストリング>。 名前空間接頭語がメールボックスにはあって、次のである注意してください。 IMAP4コンベンション、NAMESPACEのどんな国際的なストリングも。 応答は中で説明されるように変更されたUTF-7形式のものであるに違いありません。 [RFC-2060。]

7. Security Considerations

7. セキュリティ問題

   In response to a LIST command containing an argument of the Other
   Users' Namespace prefix, a server SHOULD NOT list users that have not
   granted list access to their personal mailboxes to the currently
   authenticated user.  Providing such a list, could compromise security
   by potentially disclosing confidential information of who is located
   on the server, or providing a starting point of a list of user
   accounts to attack.

Other UsersのNamespace接頭語、サーバの議論を含むLISTコマンドに対応して、SHOULD NOTは彼らの個人的なメールボックスへの現在認証されたユーザのリストアクセスを承諾していないユーザを記載します。 そのようなリストを提供して、潜在的にだれが見つけられているかに関する秘密情報をサーバに関して明らかにするか、または攻撃するためにユーザアカウントのリストの出発点を提供するのによる妥協セキュリティを提供できました。

Gahrns & Newman             Standards Track                     [Page 8]

RFC 2342                    IMAP4 Namespace                     May 1998

GahrnsとニューマンStandardsはIMAP4名前空間1998年5月にRFC2342を追跡します[8ページ]。

8. References

8. 参照

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

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

   [RFC-2119], Bradner, S., "Key words for use in RFCs to Indicate
   Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC-2119]、ブラドナーS.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [ABNF] Crocker, D., Editor, and P. Overell, "Augmented BNF for Syntax
   Specifications: ABNF", RFC 2234, November 1997.

[ABNF] クロッカー、D.、エディタ、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。

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

[IMAP-URL]、ニューマン、C.、「IMAP URL計画」、RFC2192、1997年9月。

9.  Acknowledgments

9. 承認

   Many people have participated in the discussion of IMAP namespaces on
   the IMAP mailing list.  In particular, the authors would like to
   thank Mark Crispin for many of the concepts relating to the Personal
   Namespace and accessing the Personal Namespace of other users, Steve
   Hole for summarizing the two namespace models, John Myers and Jack De
   Winter for their work in a preceding effort trying to define a
   standardized personal namespace, and Larry Osterman for his review
   and collaboration on this document.

多くの人々がIMAPメーリングリストについてのIMAP名前空間の議論に参加しました。 特に、作者はパーソナルNamespaceに関連して、他のユーザのパーソナルNamespace、2つの名前空間モデル(標準化された個人的な名前空間を定義しようとする前の努力における彼らの仕事のためのジョン・マイアーズとジャックDe Winter)をまとめるためのスティーブHole、およびこのドキュメントについての彼のレビューと共同のためのラリー・オスターマンにアクセスする概念の多くについてマーク・クリスピンに感謝したがっています。

11. Authors' Addresses

11. 作者のアドレス

   Mike Gahrns
   Microsoft
   One Microsoft Way
   Redmond, WA, 98072, USA

マイクGahrnsマイクロソフト1マイクロソフト道、レッドモンド、ワシントン、98072、米国

   Phone: (425) 936-9833
   EMail: mikega@microsoft.com

以下に電話をしてください。 (425) 936-9833 メールしてください: mikega@microsoft.com

   Chris Newman
   Innosoft International, Inc.
   1050 East Garvey Ave. South
   West Covina, CA, 91790, USA

クリスニューマンInnosoft国際のInc.1050の東ガーヴェーAve。 South Westコビーナ、カリフォルニア 91790、米国

   EMail: chris.newman@innosoft.com

メール: chris.newman@innosoft.com

Gahrns & Newman             Standards Track                     [Page 9]

RFC 2342                    IMAP4 Namespace                     May 1998

GahrnsとニューマンStandardsはIMAP4名前空間1998年5月にRFC2342を追跡します[9ページ]。

12.  Full Copyright Statement

12. 完全な著作権宣言文

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Copyright(C)インターネット協会(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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネット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 & Newman             Standards Track                    [Page 10]

Gahrnsとニューマン標準化過程[10ページ]