RFC2086 日本語訳

Network Working Group                                           J. Myers
Request for Comments: 2086                               Carnegie Mellon
Category: Standards Track                                   January 1997

コメントを求めるワーキンググループJ.マイアーズの要求をネットワークでつないでください: 2086年のカーネギーメロンCategory: 標準化過程1997年1月

                          IMAP4 ACL extension

IMAP4 ACL拡張子

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. 要約

   The ACL extension of the Internet Message Access Protocol [IMAP4]
   permits access control lists to be manipulated through the IMAP
   protocol.

インターネットMessage Accessプロトコル[IMAP4]のACL拡張子は、アクセスコントロールリストがIMAPプロトコルを通して操られることを許可します。

Table of Contents

目次

   1.   Abstract............................................... 1
   2.   Conventions Used in this Document...................... 1
   3.   Introduction and Overview.............................. 2
   4.   Commands............................................... 3
   4.1. SETACL................................................. 3
   4.2. DELETEACL.............................................. 4
   4.3. GETACL................................................. 4
   4.4. LISTRIGHTS............................................. 4
   4.5. MYRIGHTS............................................... 5
   5.   Responses.............................................. 5
   5.1. ACL.................................................... 5
   5.2. LISTRIGHTS............................................. 6
   5.3. MYRIGHTS............................................... 6
   6.   Formal Syntax.......................................... 6
   7.   References............................................. 7
   8.   Security Considerations................................ 7
   9.   Author's Address....................................... 8

1. 要約… 1 2. このDocumentのコンベンションUsed… 1 3. 序論と概要… 2 4. コマンド… 3 4.1. SETACL… 3 4.2. DELETEACL… 4 4.3. GETACL… 4 4.4. LISTRIGHTS… 4 4.5. MYRIGHTS… 5 5. 応答… 5 5.1. ACL… 5 5.2. LISTRIGHTS… 6 5.3. MYRIGHTS… 6 6. 正式な構文… 6 7. 参照… 7 8. セキュリティ問題… 7 9. 作者のアドレス… 8

2.   Conventions Used in this Document

2. このDocumentのコンベンションUsed

   In examples, "C:" and "S:" indicate lines sent by the client and
   server respectively.

例で「C:」 そして、「S:」 クライアントとサーバによってそれぞれ送られた系列を示してください。

Myers                       Standards Track                     [Page 1]

RFC 2086                     ACL extension                  January 1997

マイアーズStandards Track[1ページ]RFC2086ACL拡張子1997年1月

3.   Introduction and Overview

3. 序論と概要

   The ACL extension is present in any IMAP4 implementation which
   returns "ACL" as one of the supported capabilities to the CAPABILITY
   command.

ACL拡張子はサポートしている能力の1つとして"ACL"を能力コマンドに返すどんなIMAP4実装でも存在しています。

   An access control list is a set of <identifier,rights> pairs.

権利>組、アクセスコントロールリストは1セットの<識別子です。

   Identifier is a US-ASCII string.  The identifier anyone is reserved
   to refer to the universal identity (all authentications, including
   anonymous). All user name strings accepted by the LOGIN or
   AUTHENTICATE commands to authenticate to the IMAP server are reserved
   as identifiers for the corresponding user.  Identifiers starting with
   a dash ("-") are reserved for "negative rights", described below.
   All other identifier strings are interpreted in an implementation-
   defined manner.

識別子は米国-ASCIIストリングです。 だれでも控え目である識別子は普遍的なアイデンティティ(すべての認証であって、包含匿名の)について言及します。 LOGINによって受け入れられたすべてのユーザ名前ストリングかIMAPサーバに認証するAUTHENTICATEコマンドが対応するユーザへの識別子として控えられます。 ダッシュ(「-」)から始まる識別子は以下で説明された「否定的権利」のために予約されます。 他のすべての識別子ストリングが実装の定義された方法で解釈されます。

   Rights is a string listing a (possibly empty) set of alphanumeric
   characters, each character listing a set of operations which is being
   controlled. Letters are reserved for ``standard'' rights, listed
   below.  The set of standard rights may only be extended by a
   standards-track document.  Digits are reserved for implementation or
   site defined rights.  The currently defined standard rights are:

権利は(ことによると空)のセットの英数字(制御されている1セットの操作を記載する各キャラクタ)を記載するストリングです。 手紙は以下に記載された「標準」の権利のために予約されます。 標準の権利のセットは標準化過程文書によって広げられるだけであるかもしれません。 ケタは実装かサイトの定義された権利のために予約されます。 現在定義された標準の権利は以下の通りです。

   l - lookup (mailbox is visible to LIST/LSUB commands)
   r - read (SELECT the mailbox, perform CHECK, FETCH, PARTIAL,
       SEARCH, COPY from mailbox)
   s - keep seen/unseen information across sessions (STORE SEEN flag)
   w - write (STORE flags other than SEEN and DELETED)
   i - insert (perform APPEND, COPY into mailbox)
   p - post (send mail to submission address for mailbox,
       not enforced by IMAP4 itself)
   c - create (CREATE new sub-mailboxes in any implementation-defined
       hierarchy)
   d - delete (STORE DELETED flag, perform EXPUNGE)
   a - administer (perform SETACL)

l(ルックアップ(メールボックスはLIST/LSUBコマンドに目に見える)r)が読む、(SELECT、メールボックス、CHECKを実行してください、FETCH、PARTIAL、検索、メールボックス) sからのCOPY--セッション(STORE SEENは弛む)wの向こう側に見られたか見えない情報を保ってください--iを書いてください、(SEENとDELETED以外のストア旗)-; ポスト(IMAP4自身によって実施されるのではなく、メールボックスのための服従アドレスにメールを送る)c--d--aを削除するのを(STORE DELETEDは弛んで、EXPUNGEを実行してください)作成するという(どんな実装で定義された階層構造のCREATEの新しいサブメールボックスも)pが管理する差し込み(APPENDを実行してください、メールボックスの中へのCOPY)(SETACLを実行します)

   An implementation may tie rights together or may force rights to
   always or never be granted to particular identifiers.  For example,
   in an implementation that uses unix mode bits, the rights "wisd" are
   tied, the "a" right is always granted to the owner of a mailbox and
   is never granted to another user.  If rights are tied in an
   implementation, the implementation must be conservative in granting
   rights in response to SETACL commands--unless all rights in a tied
   set are specified, none of that set should be included in the ACL
   entry for that identifier.  A client may discover the set of rights
   which may be granted to a given identifier in the ACL for a given
   mailbox by using the LISTRIGHTS command.

実装は、権利を結びつけるか、または特定の識別子に決して与えられるべきでない権利を強制するかもしれません。 例えば、unixモードビットを使用する実装では権利"wisd"が結ばれるのを“a"権利はいつもメールボックスの所有者に与えて、別のユーザに決して与えません。 権利が実装で結ばれるなら、実装はSETACLコマンドに対応して権利を与えるのにおいて保守的であるに違いありません--結ばれたセットにおけるすべての権利を指定するというわけではないなら、その識別子のためのACLエントリーにそのセットのいずれも含むべきではありません。 クライアントは与えられたメールボックスのためにLISTRIGHTSコマンドを使用することによってACLの与えられた識別子に与えられるかもしれない権利のセットを発見するかもしれません。

Myers                       Standards Track                     [Page 2]

RFC 2086                     ACL extension                  January 1997

マイアーズStandards Track[2ページ]RFC2086ACL拡張子1997年1月

   It is possible for multiple identifiers in an access control list to
   apply to a given user (or other authentication identity).  For
   example, an ACL may include rights to be granted to the identifier
   matching the user, one or more implementation-defined identifiers
   matching groups which include the user, and/or the identifier
   "anyone".  How these rights are combined to determine the user's
   access is implementation-defined.  An implementation may choose, for
   example, to use the union of the rights granted to the applicable
   identifiers.  An implementation may instead choose, for example, to
   only use those rights granted to the most specific identifier present
   in the ACL. A client may determine the set of rights granted to the
   logged-in user for a given mailbox by using the MYRIGHTS command.

アクセスコントロールリストにおける複数の識別子が与えられたユーザ(または、他の認証のアイデンティティ)に適用されるのは、可能です。 例えば、ACLはユーザに合っている識別子に与えられるべき権利、ユーザを含んでいるグループに合っている1つ以上の実装で定義された識別子、そして/または、「だれも」という識別子を含むかもしれません。 これらの権利がユーザのアクセスを決定するためにどう結合されるかは、実装で定義されています。 例えば、実装は、適切な識別子に与えられた権利の組合を使用するのを選ぶかもしれません。 例えば、実装は、ACLの現在の最も特定の識別子に与えられたそれらの権利を使用するだけであるのを代わりに選ぶかもしれません。 クライアントは与えられたメールボックスのためにMYRIGHTSコマンドを使用することによってログインしているユーザに与えられた権利のセットを決定するかもしれません。

   When an identifier in an ACL starts with a dash ("-"), that indicates
   that associated rights are to be removed from the identifier that is
   prefixed by the dash.  For example, if the identifier "-fred" is
   granted the "w" right, that indicates that the "w" right is to be
   removed from users matching the identifier "fred".  Implementations
   need not support having identifiers which start with a dash in ACLs.

ACLの識別子がダッシュ(「-」)から始まるとき、それは、関連権利がダッシュで前に置かれている識別子から取り除かれることであることを示します。 例えば、「w」権利を識別子"-fred"に与えるなら、それは、「w」権利が"fred"という識別子に合っているユーザから取り除かれることであることを示します。 実装はACLsでダッシュから始まる識別子を持っているどんなサポートも必要としません。

4.   Commands

4. コマンド

4.1. SETACL

4.1. SETACL

   Arguments:  mailbox name
               authentication identifier
               access right modification

議論: メールボックス名前認証識別子アクセス権変更

   Data:       no specific data for this command

データ: このコマンドのための特定のデータがありません。

   Result:     OK - setacl completed
               NO - setacl failure: can't set acl
              BAD - command unknown or arguments invalid

結果: OK--setaclの完成したノー--setaclの故障: acl BADを設定できません--未知か議論病人を命令してください。

      The SETACL command changes the access control list on the
      specified mailbox so that the specified identifier is granted
      permissions as specified in the third argument.

SETACLコマンドが指定されたメールボックスでアクセスコントロールリストを変えるので、3番目の議論における指定されるとしての許容は指定された識別子に承諾されます。

      The third argument is a string containing an optional plus ("+")
      or minus ("-") prefix, followed by zero or more rights characters.
      If the string starts with a plus, the following rights are added
      to any existing rights for the identifier.  If the string starts
      with a minus, the following rights are removed from any existing
      rights for the identifier.  If the string does not start with a
      plus or minus, the rights replace any existing rights for the
      identifier.

3番目の議論はゼロがあとに続いた任意のプラス(「+」)かマイナス(「-」)接頭語を含むストリングであるか以上はキャラクタを救います。 ストリングがプラスから始まるなら、以下の権利は識別子へのどんな既存の権利にも追加されます。 ストリングがマイナスから始まるなら、識別子へのどんな既存の権利からも以下の権利を取り除きます。 ストリングがプラスかマイナスから始まらないなら、権利は識別子へのどんな既存の権利も置き換えます。

Myers                       Standards Track                     [Page 3]

RFC 2086                     ACL extension                  January 1997

マイアーズStandards Track[3ページ]RFC2086ACL拡張子1997年1月

4.2. DELETEACL

4.2. DELETEACL

   Arguments:  mailbox name
               authentication identifier

議論: メールボックス名前認証識別子

   Data:       no specific data for this command

データ: このコマンドのための特定のデータがありません。

   Result:     OK - deleteacl completed
               NO - deleteacl failure: can't delete acl
              BAD - command unknown or arguments invalid

結果: OK--deleteaclの完成したノー--deleteaclの故障: acl BADを削除できません--未知か議論病人を命令してください。

      The DELETEACL command removes any <identifier,rights> pair for the
      specified identifier from the access control list for the specified
      mailbox.

DELETEACLコマンドはどんな<識別子も取り除いて、権利>は指定されたメールボックスのためのアクセスコントロールリストからの指定された識別子のために対にされます。

4.3. GETACL

4.3. GETACL

   Arguments:  mailbox name

議論: メールボックス名

   Data:       untagged responses: ACL

データ: 非タグ付けをされた応答: ACL

   Result:     OK - getacl completed
               NO - getacl failure: can't get acl
              BAD - command unknown or arguments invalid

結果: OK--getaclの完成したノー--getaclの故障: acl BADを手に入れることができません--未知か議論病人を命令してください。

      The GETACL command returns the access control list for mailbox in
      an untagged ACL reply.

GETACLコマンドはメールボックスのためにuntagged ACL回答でアクセスコントロールリストを返します。

   Example:    C: A002 GETACL INBOX
               S: * ACL INBOX Fred rwipslda
               S: A002 OK Getacl complete

例: C: A002 GETACL受信トレイS: * ACL INBOXフレッドrwipslda S: A002 OK Getacl完全です。

4.4. LISTRIGHTS

4.4. LISTRIGHTS

   Arguments:  mailbox name
               authentication identifier

議論: メールボックス名前認証識別子

   Data:       untagged responses: LISTRIGHTS

データ: 非タグ付けをされた応答: LISTRIGHTS

   Result:     OK - listrights completed
               NO - listrights failure: can't get rights list
              BAD - command unknown or arguments invalid

結果: OK--listrightsの完成したノー--listrightsの故障: 権利リストBADを手に入れることができません--未知か議論病人を命令してください。

      The LISTRIGHTS command takes a mailbox name and an identifier and
      returns information about what rights may be granted to the identifier
      in the ACL for the mailbox.

LISTRIGHTSコマンドは、メールボックスのためにメールボックス名と識別子を取って、どんな権利をACLの識別子に与えるかもしれないかの情報を返します。

Myers                       Standards Track                     [Page 4]

RFC 2086                     ACL extension                  January 1997

マイアーズStandards Track[4ページ]RFC2086ACL拡張子1997年1月

   Example:    C: a001 LISTRIGHTS ~/Mail/saved smith
               S: * LISTRIGHTS ~/Mail/saved smith la r swicd
               S: a001 OK Listrights completed

例: C: a001 LISTRIGHTS~/Mail/saved鍛冶屋S: * LISTRIGHTS~/Mail/saved鍛冶屋la r swicd S: OK Listrightsが完成したa001

               C: a005 LISTRIGHTS archive.imap anyone
               S: * LISTRIGHTS archive.imap anyone "" l r s w i p c d a
               0 1 2 3 4 5 6 7 8 9

C: a005 LISTRIGHTS archive.imap、Sのだれも: * LISTRIGHTS archive.imap、だれ、も「「l r s w i p c d a0 1 2 3 4 5 6 7 8 9」

4.5. MYRIGHTS

4.5. MYRIGHTS

   Arguments:  mailbox name

議論: メールボックス名

   Data:       untagged responses: MYRIGHTS

データ: 非タグ付けをされた応答: MYRIGHTS

   Result:     OK - myrights completed
               NO - myrights failure: can't get rights
              BAD - command unknown or arguments invalid

結果: OK--myrightsの完成したノー--myrightsの故障: 権利BADを手に入れることができません--未知か議論病人を命令してください。

      The MYRIGHTS command returns the set of rights that the user has
      to mailbox in an untagged MYRIGHTS reply.

MYRIGHTSコマンドはユーザがuntagged MYRIGHTS回答でメールボックスに持っている権利のセットを返します。

   Example:    C: A003 MYRIGHTS INBOX
               S: * MYRIGHTS INBOX rwipslda
               S: A003 OK Myrights complete

例: C: A003 MYRIGHTS受信トレイS: * MYRIGHTS INBOX rwipslda S: A003 OK Myrights完全です。

5.   Responses

5. 応答

5.1. ACL

5.1. ACL

   Data:       mailbox name
               zero or more identifier rights pairs

データ: メールボックス名ゼロか、より多くの識別子権利組

      The ACL response occurs as a result of a GETACL command. The first
      string is the mailbox name for which this ACL applies.  This is
      followed by zero or more pairs of strings, each pair contains the
      identifier for which the entry applies followed by the set of
      rights that the identifier has.

ACL応答はGETACLコマンドの結果、起こります。 最初のストリングはこのACLが申し込むメールボックス名です。 ゼロか、より多くのストリングがこれを支えていて、各組は識別子が持っている権利のセットによって続かれて、エントリーが適用される識別子を含んでいます。

Myers                       Standards Track                     [Page 5]

RFC 2086                     ACL extension                  January 1997

マイアーズStandards Track[5ページ]RFC2086ACL拡張子1997年1月

5.2. LISTRIGHTS

5.2. LISTRIGHTS

   Data:       mailbox name
               identifier
               required rights
               list of optional rights

データ: メールボックス名前識別子は任意の権利の権利リストを必要としました。

      The LISTRIGHTS response occurs as a result of a LISTRIGHTS
      command. The first two strings are the mailbox name and identifier
      for which this rights list applies.  Following the identifier is a
      string containing the (possibly empty) set of rights the
      identifier will always be granted in the mailbox.

LISTRIGHTS応答はLISTRIGHTSコマンドの結果、起こります。 最初の2個のストリングが、この権利リストが適用されるメールボックス名と識別子です。 識別子に従うのは、識別子がメールボックスの中にいつも与えられる権利の(ことによると空)のセットを含むストリングです。

      Following this are zero or more strings each containing a set of
      rights the identifier may be granted in the mailbox.  Rights
      mentioned in the same string are tied together--either all must be
      granted to the identifier in the mailbox or none may be granted.

これに続くのは、ゼロであるか識別子がメールボックスの中に与えられるかもしれない権利のセットを含んでいて、以上がそれぞれを結びます。 同じストリングで言及された権利は結びつけられます--メールボックスの中の識別子にすべてを与えてはいけないかもしれない、さもなければ、なにも与えないかもしれません。

      The same right may not be listed more than once in the LISTRIGHTS
      command.

同じ右はLISTRIGHTSコマンドにおける一度よりもう少し記載されていないかもしれません。

5.3. MYRIGHTS

5.3. MYRIGHTS

   Data:       mailbox name
               rights

データ: メールボックス名前権利

      The MYRIGHTS response occurs as a result of a MYRIGHTS command.
      The first string is the mailbox name for which these rights apply.
      The second string is the set of rights that the client has.

MYRIGHTS応答はMYRIGHTSコマンドの結果、起こります。 最初のストリングはこれらの権利が申請されるメールボックス名です。 2番目のストリングはクライアントが持っている権利のセットです。

6.   Formal Syntax

6. 正式な構文

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4].
   Non-terminals referenced but not defined below are as defined by
   [IMAP4].

以下の構文仕様は変更されるとしての[RFC-822]ごとの指定されるとしての増大しているBN記法(BNF)記法を使用します。 [IMAP4]によって定義されるように参照をつけられましたが、以下で定義されなかった非端末があります。

   Except as noted otherwise, all alphabetic characters are case-
   insensitive.  The use of upper or lower case characters to define
   token strings is for editorial clarity only. Implementations MUST
   accept these strings in a case-insensitive fashion.

別の方法で注意されるのを除いて、すべての英字がケース神経が鈍いです。 トークンストリングを定義する上側の、または、下側のケースキャラクタの使用は編集の明快だけのためのものです。 実装は大文字と小文字を区別しないファッションでこれらのストリングを受け入れなければなりません。

Myers                       Standards Track                     [Page 6]

RFC 2086                     ACL extension                  January 1997

マイアーズStandards Track[6ページ]RFC2086ACL拡張子1997年1月

   acl_data        ::= "ACL" SPACE mailbox *(SPACE identifier SPACE
                        rights)

acl_データ:、:= "ACL"SPACEメールボックス*(SPACE識別子SPACE権利)

   deleteacl       ::= "DELETEACL" SPACE mailbox SPACE identifier

deleteacl:、:= "DELETEACL"SPACEメールボックスSPACE識別子

   getacl          ::= "GETACL" SPACE mailbox

getacl:、:= "GETACL"SPACEメールボックス

   identifier      ::= astring

識別子:、:= astringします。

   listrights      ::= "LISTRIGHTS" SPACE mailbox SPACE identifier

listrights:、:= 「LISTRIGHTS」SPACEメールボックスSPACE識別子

   listrights_data ::= "LISTRIGHTS" SPACE mailbox SPACE identifier
                           SPACE rights *(SPACE rights)

listrights_データ:、:= 「LISTRIGHTS」SPACEメールボックスSPACE識別子SPACE権利*(SPACE権利)

   mod_rights      ::= astring
                           ;; +rights to add, -rights to remove
                           ;; rights to replace

モッズ_は以下を正します:= astringします。 + 加える権利、取り外す権利。 置き換える権利

   myrights        ::= "MYRIGHTS" SPACE mailbox

myrights:、:= 「MYRIGHTS」SPACEメールボックス

   myrights_data   ::= "MYRIGHTS" SPACE mailbox SPACE rights

myrights_データ:、:= 「MYRIGHTS」SPACEメールボックスSPACE権利

   rights          ::= astring

権利:、:= astringします。

   setacl          ::= "SETACL" SPACE mailbox SPACE identifier
                       SPACE mod_rights

setacl:、:= "SETACL"SPACEメールボックスSPACE識別子SPACEモッズ_権利

7.   References

7. 参照

   [IMAP4] Crispin, M., "Internet Message Access Protocol - Version 4",
   RFC 1730, University of Washington, December 1994.

[IMAP4] クリスピン、M.、「バージョン4インチ、RFC1730、ワシントン大学、1994年インターネットメッセージアクセス・プロトコル--12月。」

   [RFC-822] Crocker, D., "Standard for the Format of ARPA Internet Text
   Messages", STD 11, RFC 822.

[RFC-822] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822。

8.   Security Considerations

8. セキュリティ問題

   An implementation must make sure the ACL commands themselves do not
   give information about mailboxes with appropriately restricted ACL's.
   For example, a GETACL command on a mailbox for which the user has
   insufficient rights should not admit the mailbox exists, much less
   return the mailbox's ACL.

実装は、ACLコマンド自体が適切に制限されたACLのものと共にメールボックスに関して知らせないのを確実にしなければなりません。 例えば、ユーザが不十分な権利を持っているメールボックスにおけるGETACLコマンドは、メールボックスが存在することを認めるべきではありませんし、またまして、メールボックスのACLを返すべきではありません。

Myers                       Standards Track                     [Page 7]

RFC 2086                     ACL extension                  January 1997

マイアーズStandards Track[7ページ]RFC2086ACL拡張子1997年1月

9.   Author's Address

9. 作者のアドレス

   John G. Myers
   Carnegie-Mellon University
   5000 Forbes Ave.
   Pittsburgh PA, 15213-3890

ジョンG.マイアーズカーネギーメロン大学5000フォーブズAve。 ピッツバーグPA、15213-3890

   Email: jgm+@cmu.edu

メール: jgm+@cmu.edu

Myers                       Standards Track                     [Page 8]

マイアーズ標準化過程[8ページ]