RFC4314 日本語訳
4314 IMAP4 Access Control List (ACL) Extension. A. Melnikov. December 2005. (Format: TXT=56599 bytes) (Obsoletes RFC2086) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Melnikov Request for Comments: 4314 Isode Ltd. Obsoletes: 2086 December 2005 Category: Standards Track
コメントを求めるワーキンググループA.メリニコフの要求をネットワークでつないでください: 4314Isode Ltd.は以下を時代遅れにします。 2086 2005年12月のカテゴリ: 標準化過程
IMAP4 Access Control List (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)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
The Access Control List (ACL) extension (RFC 2086) of the Internet Message Access Protocol (IMAP) permits mailbox access control lists to be retrieved and manipulated through the IMAP protocol.
インターネットMessage Accessプロトコル(IMAP)のAccess Control List(ACL)拡張子(RFC2086)は、メールボックスアクセスコントロールリストがIMAPプロトコルを通して検索されて、操られることを許可します。
This document is a revision of RFC 2086. It defines several new access control rights and clarifies which rights are required for different IMAP commands.
このドキュメントはRFC2086の改正です。 それは、いくつかの新しいアクセス制御権利を定義して、どの権利が異なったIMAPコマンドに必要であるかをはっきりさせます。
Melnikov Standards Track [Page 1] RFC 4314 IMAP ACL December 2005
メリニコフStandardsはIMAP ACL2005年12月にRFC4314を追跡します[1ページ]。
Table of Contents
目次
1. Introduction and Overview .......................................3
1.1. Conventions Used in This Document ..........................3
2. Access Control ..................................................3
2.1. Standard Rights ............................................5
2.1.1. Obsolete Rights .....................................5
2.2. Rights Defined in RFC 2086 .................................8
3. Access control management commands and responses ................8
3.1. SETACL Command .............................................8
3.2. DELETEACL Command ..........................................9
3.3. GETACL Command ............................................10
3.4. LISTRIGHTS Command ........................................10
3.5. MYRIGHTS Command ..........................................11
3.6. ACL Response ..............................................11
3.7. LISTRIGHTS Response .......................................12
3.8. MYRIGHTS Response .........................................12
4. Rights Required to Perform Different IMAP4rev1 Commands ........12
5. Other Considerations ...........................................17
5.1. Additional Requirements and Implementation Notes ..........17
5.1.1. Servers ............................................17
5.1.2. Clients ............................................18
5.2. Mapping of ACL Rights to READ-WRITE and READ-ONLY
Response Codes ............................................19
6. Security Considerations ........................................20
7. Formal Syntax ..................................................21
8. IANA Considerations ............................................22
9. Internationalization Considerations ............................22
Appendix A. Changes since RFC 2086 ................................23
Appendix B. Compatibility with RFC 2086 ...........................24
Appendix C. Known Deficiencies ....................................24
Appendix D. Acknowledgements ......................................25
Normative References ..............................................25
Informative References ............................................25
1. 序論と概要…3 1.1. このドキュメントで中古のコンベンション…3 2. コントロールにアクセスしてください…3 2.1. 規格はまっすぐになります…5 2.1.1. 権利を時代遅れにしてください…5 2.2. RFC2086で定義された権利…8 3. 規制管理命令と応答にアクセスしてください…8 3.1. SETACLは命令します…8 3.2. DELETEACLは命令します…9 3.3. GETACLは命令します…10 3.4. LISTRIGHTSは命令します…10 3.5. MYRIGHTSは命令します…11 3.6. ACL応答…11 3.7. LISTRIGHTS応答…12 3.8. MYRIGHTS応答…12 4. 権利が異なったIMAP4rev1コマンドを実行するのが必要です…12 5. 他の問題…17 5.1. 追加要件と実装注意…17 5.1.1. サーバ…17 5.1.2. クライアント…18 5.2. 読書して書くACL権利と書き込み禁止応答コードに関するマッピング…19 6. セキュリティ問題…20 7. 正式な構文…21 8. IANA問題…22 9. 国際化問題…22 RFC2086以来付録A.は変化します…23 RFC2086との付録B.の互換性…24 付録のC.の知られている欠乏…24 付録D.承認…25 標準の参照…25 有益な参照…25
Melnikov Standards Track [Page 2] RFC 4314 IMAP ACL December 2005
メリニコフStandardsはIMAP ACL2005年12月にRFC4314を追跡します[2ページ]。
1. Introduction and Overview
1. 序論と概要
The ACL (Access Control List) extension of the Internet Message Access Protocol [IMAP4] permits mailbox access control lists to be retrieved and manipulated through the IMAP protocol.
インターネットMessage Accessプロトコル[IMAP4]のACL(アクセスControl List)拡張子は、メールボックスアクセスコントロールリストがIMAPプロトコルを通して検索されて、操られることを許可します。
This document is a revision of RFC 2086 [RFC2086]. It tries to clarify different ambiguities in RFC 2086, in particular, the use of UTF-8 [UTF-8] in access identifiers, which rights are required for different IMAP4 commands, and how READ-WRITE/READ-ONLY response codes are related to ACL.
このドキュメントはRFC2086[RFC2086]の改正です。 それは特にRFC2086の異なったあいまいさと、アクセス識別子におけるUTF-8[UTF-8]の使用と、どの権利が異なったIMAP4コマンドに必要であるか、そして、READ-WRITE/READだけ応答コードがどうACLに関連するかをはっきりさせようとします。
1.1. Conventions Used in This Document
1.1. 本書では使用されるコンベンション
In examples, "C:" and "S:" indicate lines sent by the client and server respectively.
例で「C:」 そして、「S:」 クライアントとサーバによってそれぞれ送られた系列を示してください。
In all examples "/" character is used as hierarchy separator.
」 キャラクタが使用される「すべての例」/、階層構造分離符。
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 [KEYWORDS].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[キーワード]で説明されるように本書では解釈されることであるべきですか?
The phrase "ACL server" is just a shortcut for saying "IMAP server that supports ACL extension as defined in this document".
「ACLサーバ」という句は、ただ「本書では定義されるようにACLが拡大であるとサポートするIMAPサーバ」を言うための近道です。
2. Access Control
2. アクセス制御
The ACL extension is present in any IMAP4 implementation that returns "ACL" as one of the supported capabilities to the CAPABILITY command.
ACL拡張子はサポートしている能力の1つとして"ACL"を能力コマンドに返すどんなIMAP4実装でも存在しています。
A server implementation conformant to this document MUST also return rights (see below) not defined in Section 2.2 in the "RIGHTS=" capability.
またこのドキュメントへのconformantが「権利=」能力でセクション2.2で定義されなかった権利(以下を見る)を返さなければならないサーバ実装。
An access control list is a set of <access identifier,rights> pairs. An ACL applies to a mailbox name.
権利>組、アクセスコントロールリストは1セットの<アクセス識別子です。 ACLはメールボックス名に適用します。
Access identifier (or just "identifier") is a UTF-8 [UTF-8] 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 users. Identifiers starting with a dash ("-") are
reserved for "negative rights", described below. All other
identifier strings are interpreted in an implementation-defined
manner.
アクセス識別子(または、まさしく「識別子」)はUTF-8[UTF-8]ストリングです。 「だれも」という識別子は、普遍的なアイデンティティ(すべての認証であって、包含匿名の)について言及するために予約されます。 LOGINによって受け入れられたすべてのユーザ名前ストリングかIMAPサーバに認証するAUTHENTICATEコマンドが対応するユーザへの識別子として控えられます。 ダッシュ(「-」)から始まる識別子は以下で説明された「否定的権利」のために予約されます。 他のすべての識別子ストリングが実装で定義された方法で解釈されます。
Melnikov Standards Track [Page 3] RFC 4314 IMAP ACL December 2005
メリニコフStandardsはIMAP ACL2005年12月にRFC4314を追跡します[3ページ]。
Rights is a string listing a (possibly empty) set of alphanumeric characters, each character listing a set of operations that is being controlled. Lowercase letters are reserved for "standard" rights, listed in Section 2.1. (Note that for compatibility with deployed clients and servers uppercase rights are not allowed.) The set of standard rights can only be extended by a standards-track document. Digits are reserved for implementation- or site-defined rights.
権利は(ことによると空)のセットの英数字(制御されている1セットの操作を記載する各キャラクタ)を記載するストリングです。 小文字はセクション2.1に記載された「標準」の権利のために予約されます。 (配布しているクライアントとサーバとの互換性において、大文字している権利が許容されていないことに注意してください。) 標準化過程文書は標準の権利のセットを広げることができるだけです。 ケタは実装かサイトで定義された権利のために予約されます。
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 "swite" 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 can discover the set of rights that may be granted to a given identifier in the ACL for a given mailbox name by using the LISTRIGHTS command.
実装は、権利を結びつけるか、または特定の識別子に決して与えられるべきでない権利を強制するかもしれません。 例えば、UNIXモードビットを使用する実装では権利"swite"が結ばれるのを“a"権利はいつもメールボックスの所有者に与えて、別のユーザに決して与えません。 権利が実装で結ばれるなら、実装はSETACLコマンドに対応して権利を与えるのにおいて保守的であるに違いありません--結ばれたセットにおけるすべての権利を指定するというわけではないなら、その識別子のためのACLエントリーにそのセットのいずれも含むべきではありません。 クライアントは与えられたメールボックス名のためにLISTRIGHTSコマンドを使用することによってACLの与えられた識別子に与えられるかもしれない権利のセットを発見できます。
It is possible for multiple identifiers in an access control list to apply to a given user. For example, an ACL may include rights to be granted to the identifier matching the user, one or more implementation-defined identifiers matching groups that 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 use only those rights granted to the most specific identifier present in the ACL. A client can determine the set of rights granted to the logged-in user for a given mailbox name 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 prefixed
by the dash. This is referred to as a "negative right". This
differs from DELETEACL in that a negative right is added to the ACL
and is a part of the calculation of the rights.
ACLの識別子がダッシュ(「-」)から始まるとき、それは、関連権利がダッシュで前に置かれた識別子から取り除かれることであることを示します。 これは「否定的権利」と呼ばれます。 これは否定的権利がACLに加えられて、権利の計算の一部であるという点においてDELETEACLと異なっています。
Let's assume that an identifier "fred" refers to a user with login "fred". 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", even though the user "fred" might have the "w" right as a consequence of some other identifier in the ACL. A DELETEACL of "fred" simply deletes the identifier "fred" from the ACL; it does not affect any rights that the user "fred" may get from another entry in the ACL, in particular it doesn't affect rights granted to the identifier "-fred".
"fred"という識別子がログイン"fred"でユーザについて言及すると仮定しましょう。 「w」権利を識別子"-fred"に与えるなら、それは、「w」権利が"fred"という識別子に合っているユーザから取り除かれることであることを示します、ユーザ"fred"には、ACLのある他の識別子の結果としての「w」権利があるかもしれませんが。 "fred"のDELETEACLはACLから"fred"という識別子を単に削除します。 それはユーザ"fred"がACLで別のエントリーから得るどんな権利にも影響しないで、また特に、"-fred"という識別子に与えられた権利に影響しません。
Melnikov Standards Track [Page 4] RFC 4314 IMAP ACL December 2005
メリニコフStandardsはIMAP ACL2005年12月にRFC4314を追跡します[4ページ]。
Server implementations are not required to support "negative right" identifiers.
サーバ実装は、「否定的権利」識別子をサポートするのに必要ではありません。
2.1. Standard Rights
2.1. 標準の権利
The currently defined standard rights are (note that the list below doesn't list all commands that use a particular right):
現在定義された標準の権利は(以下のリストが特定の権利を使用するすべてのコマンドを記載するというわけではないというメモ)です:
l - lookup (mailbox is visible to LIST/LSUB commands, SUBSCRIBE
mailbox)
r - read (SELECT the mailbox, perform STATUS)
s - keep seen/unseen information across sessions (set or clear
\SEEN flag via STORE, also set \SEEN during APPEND/COPY/
FETCH BODY[...])
w - write (set or clear flags other than \SEEN and \DELETED via
STORE, also set them during APPEND/COPY)
i - insert (perform APPEND, COPY into mailbox)
p - post (send mail to submission address for mailbox,
not enforced by IMAP4 itself)
k - create mailboxes (CREATE new sub-mailboxes in any
implementation-defined hierarchy, parent mailbox for the new
mailbox name in RENAME)
x - delete mailbox (DELETE mailbox, old mailbox name in RENAME)
t - delete messages (set or clear \DELETED flag via STORE, set
\DELETED flag during APPEND/COPY)
e - perform EXPUNGE and expunge as a part of CLOSE
a - administer (perform SETACL/DELETEACL/GETACL/LISTRIGHTS)
l--、ルックアップ、(メールボックス) メールボックスはLIST/LSUBコマンドに目に見えます、登録、r--読んでください、(SELECT、メールボックス、STATUS) sを実行してください--セッション(セットしてください。さもないと、明確な\SEENはストアを通して弛みます、APPEND/COPY/FETCH BODYの間のセット\もSEEN…)wの向こう側に見られたか見えない情報を保ってください--i--差し込み(APPENDを実行してください、メールボックスの中へのCOPY)p--ポストを書いてください(ストアを通して\SEENと\DELETED以外の旗を設定するか、またはきれいにしてください、そして、また、APPEND/COPYの間、それらを設定してください); (IMAP4自身によって実施されるのではなく、メールボックスのための服従アドレスにメールを送ります) k--メールボックス(どんな実装で定義された階層構造のCREATEの新しいサブメールボックス、RENAMEの新しいメールボックス名のための親メールボックスも)xを作成してください--メールボックス(DELETEメールボックス、RENAMEの古いメールボックス名)tを削除してください--メッセージ(セットしてください。さもないと、明確な\DELETEDはストアを通して弛みます、DELETEDがAPPEND/COPYの間に旗を揚げさせるセット\)eを削除してください--EXPUNGEを実行してください、そして、CLOSEの一部としてaを梢消してください--、管理(SETACL/DELETEACL/GETACL/LISTRIGHTSを実行します)
2.1.1. Obsolete Rights
2.1.1. 時代遅れの権利
Due to ambiguity in RFC 2086, some existing RFC 2086 server implementations use the "c" right to control the DELETE command. Others chose to use the "d" right to control the DELETE command. For the former group, let's define the "create" right as union of the "k" and "x" rights, and the "delete" right as union of the "e" and "t" rights. For the latter group, let's define the "create" rights as a synonym to the "k" right, and the "delete" right as union of the "e", "t", and "x" rights.
RFC2086のあいまいさ、RFC2086サーバ実装がまさしく制御するのに「c」を使用するいくつかの存在のため、DELETEは命令します。 他のものは、DELETEコマンドを制御する「d」権利を使用するのを選びました。 前のグループのために、「k」と「x」権利の組合としての「作成」右、および「e」と「t」権利の組合としての「削除」右を定義しましょう。 後者のグループのために、「k」右との同義語としての「作成」権利、および「e」、「t」、および「x」権利の組合としての「削除」右を定義しましょう。
For compatibility with RFC 2086, this section defines two virtual rights "d" and "c".
RFC2086との互換性のために、このセクションは2つの仮想の権利「d」と「c」を定義します。
If a client includes the "d" right in a rights list, then it MUST be treated as if the client had included every member of the "delete" right. (It is not an error for a client to specify both the "d" right and one or more members of the "delete" right, but the effect is no different than if just the "d" right or all members of the "delete" right had been specified.)
クライアントが権利リストの「d」権利を入れるなら、まるでクライアントが「削除」権利のすべてのメンバーを入れたかのようにそれを扱わなければなりません。 (それはクライアントが「d」権利と「削除」権利の1人以上のメンバーの両方を指定する誤りではありませんが、効果は「削除」権利のメンバーがただ「d」権利かすべてなら指定されたほど異なっていません。)
Melnikov Standards Track [Page 5] RFC 4314 IMAP ACL December 2005
メリニコフStandardsはIMAP ACL2005年12月にRFC4314を追跡します[5ページ]。
When any of the "delete" member rights is set in a list of rights, the server MUST also include the "d" right when returning the list in a MYRIGHTS or ACL response. This is to enable older clients conforming to RFC 2086 to work with newer servers. (*)
また、「削除」メンバー権利のどれかが権利のリストに設定されるとき、MYRIGHTSのリストを返すか、ACL応答であるときに、サーバは「d」権利を含まなければなりません。 これは、RFC2086に従うより年取ったクライアントが、より新しいサーバで働いているのを可能にするためのものです。 (*)
Example: C: A001 SeTacl INBOX/Drafts David lrswida
S: A001 OK Setacl complete
例: C: A001 SeTacl受信トレイ/草稿デヴィッドlrswida S: A001 OK Setacl完全です。
The client has specified the "d" right in the SETACL command above and it expands to "et" on the server:
クライアントはSETACLコマンドにおける上の「d」権利を指定しました、そして、サーバに"et"に広がります:
C: A002 getacl INBOX/Drafts
S: * ACL INBOX Fred rwipslxcetda David lrswideta
S: A002 OK Getacl complete
C: A002 getacl受信トレイ/草稿S: * ACL INBOXフレッドrwipslxcetdaデヴィッドlrswideta S: A002 OK Getacl完全です。
If the identifier specified in the LISTRIGHTS command can be granted any of the "delete" member rights on a mailbox, then the server MUST include the "d" right in the corresponding LISTRIGHTS response. (*) If the member rights aren't tied to non-member rights, then the "d" right is returned by itself in the LISTRIGHTS response. If any of the member rights needs to be tied to one (or more) non-member right, then the "d" right and all of the member rights need to be tied to the same non-member right(s) (**).
メールボックスの上の「削除」メンバー権利のどれかをLISTRIGHTSコマンドで指定された識別子に与えることができるなら、サーバは対応するLISTRIGHTS応答における「d」権利を含まなければなりません。 (*) メンバー権利を非会員権利に結ばないなら、LISTRIGHTS応答でそれ自体で「d」権利を返します。 メンバー権利のどれかが、1つ(さらに)の非会員右に結ばれる必要があるなら、メンバー権利の「d」権利とすべてが、同じ非会員右(**)に結ばれる必要があります。
If a client includes the "c" right in a rights list, then it MUST be treated as if the client had included every member of the "create" right. (It is not an error for a client to specify both the "c" right and one or more members of the "create" right, but the effect is no different than if just the "c" right or all members of the "create" right had been specified.)
クライアントが権利リストの「c」権利を入れるなら、まるでクライアントが「作成」権利のすべてのメンバーを入れたかのようにそれを扱わなければなりません。 (それはクライアントが「c」権利と「作成」権利の1人以上のメンバーの両方を指定する誤りではありませんが、効果は「作成」権利のメンバーがただ「c」権利かすべてなら指定されたほど異なっていません。)
When any of the "create" member rights is set in a list of rights, the server MUST also include the "c" right when returning the list in a MYRIGHTS or ACL response. This is to enable older clients conforming to RFC 2086 to work with newer servers. (*)
また、「作成」メンバー権利のどれかが権利のリストに設定されるとき、MYRIGHTSのリストを返すか、ACL応答であるときに、サーバは「c」権利を含まなければなりません。 これは、RFC2086に従うより年取ったクライアントが、より新しいサーバで働いているのを可能にするためのものです。 (*)
Example: C: A003 Setacl INBOX/Drafts Byron lrswikda
S: A001 OK Setacl complete
C: A002 getAcl INBOX/Drafts
S: * ACL INBOX Fred rwipslxcetda Byron lrswikcdeta
S: A002 OK Getacl complete
例: C: A003 Setacl受信トレイ/草稿バイロンlrswikda S: A001 OK SetaclはCを完成します: A002 getAcl受信トレイ/草稿S: * ACL INBOXフレッドrwipslxcetdaバイロンlrswikcdeta S: A002 OK Getacl完全です。
The client has specified the "d" right in the SETACL command above and it expands to "et" on the server: As the client has specified the "k" right (which is a member of the "c" right), the server also returns the "c" right.
クライアントはSETACLコマンドにおける上の「d」権利を指定しました、そして、サーバに"et"に広がります: また、クライアントが「k」権利(「c」権利のメンバーである)を指定したとき、サーバは「c」権利を返します。
Melnikov Standards Track [Page 6] RFC 4314 IMAP ACL December 2005
メリニコフStandardsはIMAP ACL2005年12月にRFC4314を追跡します[6ページ]。
If the identifier specified in the LISTRIGHTS command can be granted any of the "create" member rights on a mailbox, then the server MUST include the "c" right in the corresponding LISTRIGHTS response. (*) If the member rights aren't tied to non-member rights, then the "c" right is returned by itself in the LISTRIGHTS response. If any of the member rights needs to be tied to one (or more) non-member right, then the "c" right and all of the member rights need to be tied to the same non-member right(s) (**).
メールボックスの上の「作成」メンバー権利のどれかをLISTRIGHTSコマンドで指定された識別子に与えることができるなら、サーバは対応するLISTRIGHTS応答における「c」権利を含まなければなりません。 (*) メンバー権利を非会員権利に結ばないなら、LISTRIGHTS応答でそれ自体で「c」権利を返します。 メンバー権利のどれかが、1つ(さらに)の非会員右に結ばれる必要があるなら、メンバー権利の「c」権利とすべてが、同じ非会員右(**)に結ばれる必要があります。
Example: The server that ties the rights as follows:
例: 以下の権利を結ぶサーバ:
lr s w i p k x t
lr s w i p k x t
and c=k
そして、c=k
will return:
戻るでしょう:
S: * LISTRIGHTS archive/imap anyone ""
lr s w i p k x t c d
S: * LISTRIGHTSがだれでも格納するか、またはimapする、「「lr s w i p k x t c d」
Example: The server that ties the rights as follows:
例: 以下の権利を結ぶサーバ:
lr s w i p k xte
lr s w i p k xte
and c=k
そして、c=k
will return:
戻るでしょう:
S: * LISTRIGHTS archive/imap anyone ""
lr s w i p k xte c d
S: * LISTRIGHTSがだれでも格納するか、またはimapする、「「lr s w i p k xte c d」
Example: The server that ties the rights as follows:
例: 以下の権利を結ぶサーバ:
lr s w i p k x te
lr s w i p k x Te
and c=k
そして、c=k
will return:
戻るでしょう:
S: * LISTRIGHTS archive/imap anyone ""
lr s w i p k c x te d
S: * LISTRIGHTSがだれでも格納するか、またはimapする、「「lr s w i p k c x Te d」
Example: The server that ties the rights as follows:
例: 以下の権利を結ぶサーバ:
lr swte i p k x
lr swte i p k x
and c=kx
そして、c=kx
Melnikov Standards Track [Page 7] RFC 4314 IMAP ACL December 2005
メリニコフStandardsはIMAP ACL2005年12月にRFC4314を追跡します[7ページ]。
will return:
戻るでしょう:
S: * LISTRIGHTS archive/imap anyone ""
lr swted i p k x c
S: * LISTRIGHTSがだれでも格納するか、またはimapする、「「lr swted i p k x c」
(*) Clients conforming to this document MUST ignore the virtual "d"
and "c" rights in MYRIGHTS, ACL, and LISTRIGHTS responses.
このドキュメントに従う(*)クライアントはMYRIGHTS、ACL、およびLISTRIGHTS応答における仮想の「d」と「c」権利を無視しなければなりません。
(**) The IMAPEXT Working Group has debated this issue in great length
and after reviewing existing ACL implementations concluded that
this is a reasonable restriction.
(**) IMAPEXT作業部会は、かなりの長さにおけるこの問題について討論して、既存のACL実装を見直した後に、これが合理的な制限であると結論を下しました。
2.2. Rights Defined in RFC 2086
2.2. RFC2086で定義された権利
The "RIGHTS=" capability MUST NOT include any of the rights defined
in RFC 2086: "l", "r", "s", "w", "i", "p", "a", "c", "d", and the
digits ("0" .. "9").
「権利=」能力はRFC2086で定義された権利のどれかを含んではいけません: 「l」、「r」、「s」、「w」、「i」、「p」、“a"、「c」、「d」、およびケタ、(「0インチ、「9インチ)、」
3. Access control management commands and responses
3. アクセス制御管理命令と応答
Servers, when processing a command that has an identifier as a parameter (i.e., any of SETACL, DELETEACL, and LISTRIGHTS commands), SHOULD first prepare the received identifier using "SASLprep" profile [SASLprep] of the "stringprep" algorithm [Stringprep]. If the preparation of the identifier fails or results in an empty string, the server MUST refuse to perform the command with a BAD response. Note that Section 6 recommends additional identifier's verification steps.
サーバ、パラメタ(すなわち、SETACL、DELETEACL、およびLISTRIGHTSコマンドのどれか)として識別子を持っているコマンドを処理するとき、SHOULDは最初に、"SASLprep"という"stringprep"アルゴリズム[Stringprep]のプロフィール[SASLprep]を使用することで受信された識別子を準備します。 識別子の準備が空のストリングを失敗するか、またはもたらすなら、サーバは、BAD応答でコマンドを実行するのを拒否しなければなりません。 セクション6が追加識別子の検証ステップを推薦することに注意してください。
3.1. SETACL Command
3.1. SETACLコマンド
Arguments: mailbox name
identifier
access right modification
議論: メールボックス名前識別子アクセス権変更
Data: no specific data for this command
データ: このコマンドのための特定のデータがありません。
Result: OK - setacl completed
NO - setacl failure: can't set acl
BAD - 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
3番目の議論はゼロがあとに続いた任意のプラス(「+」)かマイナス(「-」)接頭語を含むストリングであるか以上はキャラクタを救います。 ストリングがプラスから始まるなら、以下の権利はいずれにも加えられます。
Melnikov Standards Track [Page 8] RFC 4314 IMAP ACL December 2005
メリニコフStandardsはIMAP ACL2005年12月にRFC4314を追跡します[8ページ]。
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.
存在は識別子のためにまっすぐになります。 ストリングがマイナスから始まるなら、識別子へのどんな既存の権利からも以下の権利を取り除きます。 ストリングがプラスかマイナスから始まらないなら、権利は識別子へのどんな既存の権利も置き換えます。
Note that an unrecognized right MUST cause the command to return the BAD response. In particular, the server MUST NOT silently ignore unrecognized rights.
認識されていない権利がBAD応答を返すコマンドを引き起こさなければならないことに注意してください。 特に、サーバは静かに認識されていない権利を無視してはいけません。
Example: C: A001 GETACL INBOX/Drafts
S: * ACL INBOX/Drafts Fred rwipslxetad Chris lrswi
S: A001 OK Getacl complete
C: A002 SETACL INBOX/Drafts Chris +cda
S: A002 OK Setacl complete
C: A003 GETACL INBOX/Drafts
S: * ACL INBOX/Drafts Fred rwipslxetad Chris lrswicdakxet
S: A003 OK Getacl complete
例: C: A001 GETACL受信トレイ/草稿S: * ACL INBOX/草稿フレッドrwipslxetadクリスlrswi S: A001 OK GetaclはCを完成します: A002 SETACL受信トレイ/草稿クリス+cda S: A002 OK SetaclはCを完成します: A003 GETACL受信トレイ/草稿S: * ACL INBOX/草稿フレッドrwipslxetadクリスlrswicdakxet S: A003 OK Getacl完全です。
C: A035 SETACL INBOX/Drafts John lrQswicda
S: A035 BAD Uppercase rights are not allowed
C: A035 SETACL受信トレイ/草稿ジョンlrQswicda S: A035 BAD Uppercase権利は許容されていません。
C: A036 SETACL INBOX/Drafts John lrqswicda
S: A036 BAD The q right is not supported
C: A036 SETACL INBOX/草稿ジョンlrqswicda S: q権利がサポートされないA036 BAD
3.2. DELETEACL Command
3.2. DELETEACLコマンド
Arguments: mailbox name
identifier
議論: メールボックス名前識別子
Data: no specific data for this command
データ: このコマンドのための特定のデータがありません。
Result: OK - deleteacl completed
NO - deleteacl failure: can't delete acl
BAD - 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コマンドはどんな<識別子も取り除いて、権利>は指定されたメールボックスのためのアクセスコントロールリストからの指定された識別子のために対にされます。
Example: C: B001 getacl INBOX
S: * ACL INBOX Fred rwipslxetad -Fred wetd $team w
S: B001 OK Getacl complete
C: B002 DeleteAcl INBOX Fred
S: B002 OK Deleteacl complete
例: C: B001 getacl受信トレイS: * ACL INBOXフレッド・rwipslxetadフレッドwetd$はw Sを組にします: B001 OK GetaclはCを完成します: B002 DeleteAcl INBOXフレッドS: B002 OK Deleteacl完全です。
Melnikov Standards Track [Page 9] RFC 4314 IMAP ACL December 2005
メリニコフStandardsはIMAP ACL2005年12月にRFC4314を追跡します[9ページ]。
C: B003 GETACL INBOX
S: * ACL INBOX -Fred wetd $team w
S: B003 OK Getacl complete
C: B003 GETACL受信トレイS: * ACL INBOXフレッドwetd$はw Sを組にします: B003 OK Getacl完全です。
3.3. GETACL Command
3.3. GETACLコマンド
Arguments: mailbox name
議論: メールボックス名
Data: untagged responses: ACL
データ: 非タグ付けをされた応答: ACL
Result: OK - getacl completed
NO - getacl failure: can't get acl
BAD - arguments invalid
結果: OK--getaclの完成したノー--getaclの故障: acl BADを手に入れることができません--、議論病人
The GETACL command returns the access control list for mailbox in an untagged ACL response.
GETACLコマンドはメールボックスのためにuntagged ACL応答でアクセスコントロールリストを返します。
Some implementations MAY permit multiple forms of an identifier to reference the same IMAP account. Usually, such implementations will have a canonical form that is stored internally. An ACL response caused by a GETACL command MAY include a canonicalized form of the identifier that might be different from the one used in the corresponding SETACL command.
いくつかの実装が同じIMAPアカウントを参照への識別子の複数のフォームに可能にするかもしれません。 通常、そのような実装には、内部的に保存される標準形があるでしょう。 GETACLコマンドで引き起こされたACL応答は対応するSETACLコマンドに使用されるものと異なるかもしれない識別子のcanonicalizedフォームを含むかもしれません。
Example: C: A002 GETACL INBOX
S: * ACL INBOX Fred rwipsldexta
S: A002 OK Getacl complete
例: C: A002 GETACL受信トレイS: * ACL INBOXフレッドrwipsldexta S: A002 OK Getacl完全です。
3.4. LISTRIGHTS Command
3.4. LISTRIGHTSコマンド
Arguments: mailbox name
identifier
議論: メールボックス名前識別子
Data: untagged responses: LISTRIGHTS
データ: 非タグ付けをされた応答: LISTRIGHTS
Result: OK - listrights completed
NO - listrights failure: can't get rights list
BAD - arguments invalid
結果: OK--listrightsの完成したノー--listrightsの故障: 権利リストBADを手に入れることができません--、議論病人
The LISTRIGHTS command takes a mailbox name and an identifier and returns information about what rights can be granted to the identifier in the ACL for the mailbox.
LISTRIGHTSコマンドは、メールボックスのためにメールボックス名と識別子を取って、どんな権利をACLの識別子に与えることができるかの情報を返します。
Some implementations MAY permit multiple forms of an identifier to reference the same IMAP account. Usually, such implementations will have a canonical form that is stored internally. A LISTRIGHTS
いくつかの実装が同じIMAPアカウントを参照への識別子の複数のフォームに可能にするかもしれません。 通常、そのような実装には、内部的に保存される標準形があるでしょう。 LISTRIGHTS
Melnikov Standards Track [Page 10] RFC 4314 IMAP ACL December 2005
メリニコフStandardsはIMAP ACL2005年12月にRFC4314を追跡します[10ページ]。
response caused by a LISTRIGHTS command MUST always return the same form of an identifier as specified by the client. This is to allow the client to correlate the response with the command.
LISTRIGHTSコマンドで引き起こされた応答はいつもクライアントによる指定されるとしての識別子の同じフォームを返さなければなりません。 これで、クライアントはコマンドで応答を関連させることになっていることができます。
Example: C: a001 LISTRIGHTS ~/Mail/saved smith
S: * LISTRIGHTS ~/Mail/saved smith la r swicdkxte
S: a001 OK Listrights completed
例: C: a001 LISTRIGHTS~/Mail/saved鍛冶屋S: * LISTRIGHTS~/Mail/saved鍛冶屋la r swicdkxte S: OK Listrightsが完成したa001
Example: C: a005 listrights archive/imap anyone
S: * LISTRIGHTS archive.imap anyone ""
l r s w i p k x t e c d a 0 1 2 3 4 5 6 7 8 9
S: a005 Listrights successful
例: C: だれでもSのa005 listrightsのアーカイブ/imapな人: * LISTRIGHTS archive.imap、だれ、も「「l r s w i p k x t e c d、9秒間のa0 1 2 3 4 5 6 7 8:、」 a005 Listrightsうまくいきます。
3.5. MYRIGHTS Command
3.5. MYRIGHTSコマンド
Arguments: mailbox name
議論: メールボックス名
Data: untagged responses: MYRIGHTS
データ: 非タグ付けをされた応答: MYRIGHTS
Result: OK - myrights completed
NO - myrights failure: can't get rights
BAD - 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 rwiptsldaex
S: A003 OK Myrights complete
例: C: A003 MYRIGHTS受信トレイS: * MYRIGHTS INBOX rwiptsldaex S: A003 OK Myrights完全です。
3.6. ACL Response
3.6. 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が申し込むメールボックス名です。 ゼロか、より多くのストリングがこれを支えています。 各組は識別子が持っている権利のセットによって続かれて、エントリーが適用される識別子を含んでいます。
Section 2.1.1 details additional server requirements related to handling of the virtual "d" and "c" rights.
仮想の「d」の取り扱いに関連する追加サーバ要件と「c」が正すセクション2.1.1の詳細。
Melnikov Standards Track [Page 11] RFC 4314 IMAP ACL December 2005
メリニコフStandardsはIMAP ACL2005年12月にRFC4314を追跡します[11ページ]。
3.7. LISTRIGHTS Response
3.7. 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 can be granted in the mailbox. Rights mentioned in the same string are tied together. The server MUST either grant all tied rights to the identifier in the mailbox or grant none. Section 2.1.1 details additional server requirements related to handling of the virtual "d" and "c" rights.
これに続くのは、ゼロであるかメールボックスの中に識別子を与えることができる権利のセットを含んでいて、以上がそれぞれを結びます。 同じストリングで言及された権利は結びつけられます。 サーバは、メールボックスの中の識別子へのすべての結ばれた権利を与えてはいけませんし、なにも与えてはいけません。 仮想の「d」の取り扱いに関連する追加サーバ要件と「c」が正すセクション2.1.1の詳細。
The same right MUST NOT be listed more than once in the LISTRIGHTS command.
LISTRIGHTSコマンドにおける一度より同じ右をもう少し記載してはいけません。
3.8. MYRIGHTS Response
3.8. 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番目のストリングはクライアントが持っている権利のセットです。
Section 2.1.1 details additional server requirements related to handling of the virtual "d" and "c" rights.
仮想の「d」の取り扱いに関連する追加サーバ要件と「c」が正すセクション2.1.1の詳細。
4. Rights Required to Perform Different IMAP4rev1 Commands
4. 権利が異なったIMAP4rev1コマンドを実行するのが必要です。
Before executing a command, an ACL-compliant server MUST check which rights are required to perform it. This section groups command by functions they perform and list the rights required. It also gives the detailed description of any special processing required.
コマンドを実行する前に、ACL対応することのサーバは、どの権利がそれを実行するのに必要であるかをチェックしなければなりません。 このセクションはそれらが実行する機能と権利が必要としたリストによってコマンドから構成されています。 また、それはどんな特別な処理の詳述も必要に与えます。
For the purpose of this section the UID counterpart of a command is considered to be the same command, e.g., both UID COPY and COPY commands require the same set of rights.
コマンドのUID対応者が同じコマンドであると考えられるこのセクションの目的のために、例えば、UID COPYとCOPYコマンドの両方が同じセットに権利を要求します。
Melnikov Standards Track [Page 12] RFC 4314 IMAP ACL December 2005
メリニコフStandardsはIMAP ACL2005年12月にRFC4314を追跡します[12ページ]。
The table below summarizes different rights or their combinations that are required in order to perform different IMAP operations. As it is not always possible to express complex right checking and interactions, the description after the table should be used as the primary reference.
以下のテーブルは異なった権利か異なったIMAP操作を実行するのに必要である彼らの組み合わせをまとめます。 正しい複雑な照合と相互作用を言い表すのがいつも可能であるというわけではないので、テーブルの後の記述はプライマリ参照として使用されるべきです。
+-------------------+---+---+---+---+---+---+---+---+---+---+---+---+ |Operations\Rights | l | r | s | w | i | k | x | t | e | a |Any|Non| +-------------------+---+---+---+---+---+---+---+---+---+---+---+---+ | commands in authenticated state | +-------------------------------------------------------------------+ | LIST | + | | | | | | | | | | | | | SUBSCRIBE | * | | | | | | | | | | | * | | UNSUBSCRIBE | | | | | | | | | | | | + | | LSUB | * | | | | | | | | | | | * | |CREATE (for parent)| | | | | | + | | | | | | | | DELETE | | ? | | | | | + | ? | ? | | | | | RENAME | | | | | | + | + | | | | | | | SELECT/EXAMINE | | + | | | | | | | | | | | | STATUS | | + | | | | | | | | | | | | SETACL/DELETEACL | | | | | | | | | | + | | | | GETACL/LISTRIGHTS | | | | | | | | | | + | | | | MYRIGHTS | | | | | | | | | | | + | | | APPEND | | | ? | ? | + | | | ? | | | | | +-------------------------------------------------------------------+ | commands in selected state | +-------------------------------------------------------------------+ | COPY | | | ? | ? | + | | | ? | | | | | | EXPUNGE | | | | | | | | | + | | | | | CLOSE | | | | | | | | | ? | | | | | FETCH | | | ? | | | | | | | | | | | STORE flags | | | ? | ? | | | | ? | | | | | +-------------------+---+---+---+---+---+---+---+---+---+---+---+---+
+-------------------+---+---+---+---+---+---+---+---+---+---+---+---+ |操作\はまっすぐになります。| l| r| s| w| i| k| x| t| e| a|いくらか|非| +-------------------+---+---+---+---+---+---+---+---+---+---+---+---+ | 認証された状態のコマンド| +-------------------------------------------------------------------+ | リスト| + | | | | | | | | | | | | | 登録| * | | | | | | | | | | | * | | 登録削除| | | | | | | | | | | | + | | LSUB| * | | | | | | | | | | | * | |CREATE(親のための)| | | | | | + | | | | | | | | 削除します。| | ? | | | | | + | ? | ? | | | | | 改名します。| | | | | | + | + | | | | | | | 選択するか、または調べます。| | + | | | | | | | | | | | | 状態| | + | | | | | | | | | | | | SETACL/DELETEACL| | | | | | | | | | + | | | | GETACL/LISTRIGHTS| | | | | | | | | | + | | | | MYRIGHTS| | | | | | | | | | | + | | | 追加します。| | | ? | ? | + | | | ? | | | | | +-------------------------------------------------------------------+ | 選択された状態のコマンド| +-------------------------------------------------------------------+ | コピー| | | ? | ? | + | | | ? | | | | | | 梢消します。| | | | | | | | | + | | | | | 閉鎖| | | | | | | | | ? | | | | | フェッチ| | | ? | | | | | | | | | | | ストア旗| | | ? | ? | | | | ? | | | | | +-------------------+---+---+---+---+---+---+---+---+---+---+---+---+
Note: for all commands in the selected state, the "r" is implied, because it is required to SELECT/EXAMINE a mailbox. Servers are not required to check presence of the "r" right once a mailbox is successfully selected.
以下に注意してください。 選択された状態のすべてのコマンドにおいて、それがSELECT/EXAMINE aメールボックスに必要であるので、「r」は含意されます。 サーバは、メールボックスがいったん首尾よく選択されたあとに「r」権利の存在をチェックするのに必要ではありません。
Legend:
+ - The right is required
* - Only one of the rights marked with * is required
(see description below)
? - The right is OPTIONAL (see description below)
"Any" - at least one of the "l", "r", "i", "k", "x", "a" rights is
required
"Non" - No rights required to perform the command
伝説: +、--、権利は必要な*(*でマークされた権利の唯一の1つが必要です(記述下を見る))です--権利がOPTIONALである(記述下) 「いずれも」を見てください--少なくとも「l」の1つ、「r」、「i」「k」「x」、“a"権利が必要である、「非、」、--どんな権利もコマンドを実行するのが必要でない
Melnikov Standards Track [Page 13] RFC 4314 IMAP ACL December 2005
メリニコフStandardsはIMAP ACL2005年12月にRFC4314を追跡します[13ページ]。
Listing and subscribing/unsubscribing mailboxes:
LIST - "l" right is required. However, unlike other commands
(e.g., SELECT) the server MUST NOT return a NO response if it
can't list a mailbox.
Note that if the user has "l" right to a mailbox "A/B", but not to
its parent mailbox "A", the LIST command should behave as if the
mailbox "A" doesn't exist, for example:
メールボックスを記載して、申し込むか、または外します: LIST--「l」権利が必要です。 しかしながら、メールボックスを記載できないなら、他のコマンド(例えば、SELECT)と異なって、サーバはいいえ応答を返してはいけません。 ユーザがまさしくメールボックス「A/B」に「l」を持っていますが、親メールボックス「A」に持っているというわけではないなら、まるで例えば、メールボックス「A」が存在していないかのようにリストコマンドが振る舞うべきであることに注意してください:
C: A777 LIST "" *
S: * LIST (\NoInferiors) "/" "A/B"
S: * LIST () "/" "C"
S: * LIST (\NoInferiors) "/" "C/D"
S: A777 OK LIST completed
C: A777が記載する、「「*S:」 * 「」 (\NoInferiors)/を記載してください」という「/B」S: * 「リスト()」/」 「C」S: * 「リスト(\NoInferiors)」/」 「C/D」S: 完成したA777 OK LIST
SUBSCRIBE - "l" right is required only if the server checks for
mailbox existence when performing SUBSCRIBE.
登録--働くとき、サーバがメールボックス存在がないかどうかチェックする場合にだけ、「l」権利が必要です。登録。
UNSUBSCRIBE - no rights required to perform this operation.
登録削除--どんな権利もこの操作を実行するのが必要ではありません。
LSUB - "l" right is required only if the server checks for mailbox
existence when performing SUBSCRIBE. However, unlike other
commands (e.g., SELECT) the server MUST NOT return a NO response
if it can't list a subscribed mailbox.
働くとき、サーバがメールボックス存在がないかどうかチェックする場合にだけ、「l」権利が必要です。LSUB--、登録。 しかしながら、申し込まれたメールボックスを記載できないなら、他のコマンド(例えば、SELECT)と異なって、サーバはいいえ応答を返してはいけません。
Mailbox management:
CREATE - "k" right on a nearest existing parent mailbox. When a
new mailbox is created, it SHOULD inherit the ACL from the parent
mailbox (if one exists) in the defined hierarchy.
メールボックス管理: CREATE--まさしく最も近い既存の親メールボックスの「k。」 新しいメールボックスは作成されます、それ。いつ、SHOULDは親メールボックス(1つが存在しているなら)から定義された階層構造でACLを引き継ぐか。
DELETE - "x" right on the mailbox. Note that some servers don't
allow to delete a non-empty mailbox. If this is the case, the
user would also need "r", "e", and "t" rights, in order to open
the mailbox and empty it.
DELETE--まさしくメールボックスの「x。」 いくつかのサーバで非空のメールボックスを削除しない注意。 また、これがそうであるなら、ユーザは「r」、「e」、および「t」権利を必要とするでしょう、メールボックスを開けて、それを空にするために。
The DELETE command MUST delete the ACL associated with the deleted
mailbox.
DELETEコマンドは削除されたメールボックスに関連しているACLを削除しなければなりません。
RENAME - Moving a mailbox from one parent to another requires the
"x" right on the mailbox itself and the "k" right for the new
parent. For example, if the user wants to rename the mailbox
named "A/B/C" to "D/E", the user must have the "x" right for the
mailbox "A/B/C" and the "k" right for the mailbox "D".
The RENAME command SHOULD NOT change the ACLs on the renamed
mailbox and submailboxes.
RENAME--1人の親から別のものへメールボックスを移すのは新しい親のためのまさしくメールボックス自体と「k」右の「x」を必要とします。 例えば、ユーザが「/B/C」というメールボックスを「D/E」に改名したいなら、ユーザにはメールボックス「D」へのまさしくメールボックスのための「x」「/B/C」と「k」権利がなければなりません。 RENAMEコマンドSHOULD NOTは改名されたメールボックスと「副-メールボックス」の上のACLsを変えます。
Melnikov Standards Track [Page 14] RFC 4314 IMAP ACL December 2005
メリニコフStandardsはIMAP ACL2005年12月にRFC4314を追跡します[14ページ]。
Copying or appending messages:
Before performing a COPY/APPEND command, the server MUST check if
the user has "i" right for the target mailbox. If the user
doesn't have "i" right, the operation fails. Otherwise for each
copied/appended message the server MUST check if the user has
"t" right - when the message has \Deleted flag set
"s" right - when the message has \Seen flag set
"w" right - for all other message flags.
Only when the user has a particular right are the corresponding
flags stored for the newly created message. The server MUST NOT
fail a COPY/APPEND if the user has no rights to set a particular
flag.
コピーかメッセージを追加します: COPY/APPENDコマンドを実行する前に、サーバは、ユーザにまさしく目標メールボックスのための「i」があるかどうかチェックしなければなりません。 ユーザが「i」を右に持っていないなら、操作は失敗します。 そうでなければ、それぞれのコピーされたか追加されたメッセージがないかどうか、サーバは、\Seenがメッセージでセット「w」に右に旗を揚げさせるとき、\Deletedが他のすべてのメッセージ旗のためにメッセージでセット「s」に右に旗を揚げさせるとき、ユーザが「t」を右に持っているかどうかチェックしなければなりません。 ユーザに特定の権利がある場合にだけ、対応する旗は新たに作成されたメッセージのために保存されます。 ユーザに特定の旗を設定する権利が全くないなら、サーバはCOPY/APPENDに失敗してはいけません。
Example: C: A003 MYRIGHTS TargetMailbox
S: * MYRIGHTS TargetMailbox rwis
S: A003 OK Myrights complete
例: C: A003 MYRIGHTS TargetMailbox S: * MYRIGHTS TargetMailbox rwis S: A003 OK Myrights完全です。
C: A004 FETCH 1:3 (FLAGS)
S: * 1 FETCH (FLAGS (\Draft \Deleted)
S: * 2 FETCH (FLAGS (\Answered)
S: * 3 FETCH (FLAGS ($Forwarded \Seen)
S: A004 OK Fetch Completed
C: A004は1:3(旗)Sをとって来ます: * 1つのフェッチ、(S: 2がとって来る*に旗を揚げさせる、(\が削除した\草稿)(S: 3がとって来る*に旗を揚げさせる、(\に答えました)(S: A004OKフェッチが完成した旗($は見られた\を進めました)
C: A005 COPY 1:3 TargetMailbox
S: A005 OK Copy completed
C: A005は1:3TargetMailbox Sをコピーします: 完成したA005 OK Copy
C: A006 SELECT TargetMailbox
...
S: A006 Select Completed
C: A006はTargetMailboxを選択します… S: 完成されて、A006は選択します。
Let's assume that the copied messages received message numbers
77:79.
コピーされたメッセージはメッセージ番号77を受けました: 79と仮定しましょう。
C: A007 FETCH 77:79 (FLAGS)
S: * 77 FETCH (FLAGS (\Draft))
S: * 78 FETCH (FLAGS (\Answered))
S: * 79 FETCH (FLAGS ($Forwarded \Seen))
S: A007 OK Fetch Completed
C: A007は77:79(旗)Sをとって来ます: * 77は(旗(\草稿))にSをとって来ます: * 78は(旗(\に答えた))にSをとって来ます: * 79は(旗($は見られた\を進めた))にSをとって来ます: 終了するA007OKフェッチ
\Deleted flag was lost on COPY, as the user has no "t" right in
the target mailbox.
If the MYRIGHTS command with the tag A003 would have returned:
ユーザに目標メールボックスの中の「t」権利が全くないとき、\削除された旗はCOPYでなくされました。 MYRIGHTSがタグで命令するなら、A003は戻ったでしょう:
S: * MYRIGHTS TargetMailbox rsti
S: * MYRIGHTS TargetMailbox rsti
the response from the FETCH with the tag A007 would have been:
タグA007とFETCHからの応答は以下の通りでしょう。
C: A007 FETCH 77:79 (FLAGS)
C: A007は77:79をとって来ます。(旗)
Melnikov Standards Track [Page 15] RFC 4314 IMAP ACL December 2005
メリニコフStandardsはIMAP ACL2005年12月にRFC4314を追跡します[15ページ]。
S: * 77 FETCH (FLAGS (\Deleted))
S: * 78 FETCH (FLAGS ())
S: * 79 FETCH (FLAGS (\Seen))
S: A007 OK Fetch Completed
S: * 77は(旗(削除された\))にSをとって来ます: * 78がとって来る、(旗の())S: * 79は(旗(見られた\))にSをとって来ます: 終了するA007OKフェッチ
In the latter case, \Answered, $Forwarded, and \Draft flags were
lost on COPY, as the user has no "w" right in the target mailbox.
後者の場合では、Answered、$Forwarded、および\Draftが旗を揚げさせる\はCOPYで失われました、ユーザに目標メールボックスの中の「w」権利が全くないとき。
Expunging the selected mailbox:
EXPUNGE - "e" right on the selected mailbox.
選択されたメールボックスを梢消します: EXPUNGE--まさしく選択されたメールボックスの「e。」
CLOSE - "e" right on the selected mailbox. If the server is
unable to expunge the mailbox because the user doesn't have the
"e" right, the server MUST ignore the expunge request, close the
mailbox, and return the tagged OK response.
CLOSE--まさしく選択されたメールボックスの「e。」 ユーザにはまさしく、サーバが無視しなければならない「e」がないのでサーバがメールボックスを梢消できないかどうか、要求を梢消してください、そして、メールボックスを閉じてください、そして、タグ付けをされたOK応答を返してください。
Fetch information about a mailbox and its messages:
SELECT/EXAMINE/STATUS - "r" right on the mailbox.
メールボックスの情報とそのメッセージをとって来てください: SELECT/EXAMINE/STATUS--まさしくメールボックスの「r。」
FETCH - A FETCH request that implies setting \Seen flag MUST NOT
set it, if the current user doesn't have "s" right.
FETCH--Seenが旗を揚げさせる設定\を含意するFETCH要求はそれを設定してはいけません、現在のユーザが「s」を右に持っていないなら。
Changing flags:
STORE - the server MUST check if the user has
"t" right - when the user modifies \Deleted flag
"s" right - when the user modifies \Seen flag
"w" right - for all other message flags.
STORE operation SHOULD NOT fail if the user has rights to modify
at least one flag specified in the STORE, as the tagged NO
response to a STORE command is not handled very well by deployed
clients.
変化は弛みます: ストア--サーバは、他のすべてのメッセージ旗がないかどうかユーザが「t」を右に持っているかどうか--ユーザが\を変更すると、Deletedは「s」に右に旗を揚げさせます(ユーザが\を変更すると、Seenは「w」に右に旗を揚げさせます)チェックしなければなりません。 ユーザにストアで指定された少なくとも1個の旗を変更する権利があるなら、ストア操作SHOULD NOTは失敗します、ストアコマンドへのタグ付けをされたいいえ応答が配布しているクライアントによってそれほどよく扱われないとき。
Changing ACLs:
SETACL/DELETEACL - "a" right on the mailbox.
変化しているACLs: SETACL/DELETEACL--まさしくメールボックスの上の“a"。
Reading ACLs:
GETACL - "a" right on the mailbox.
閲読ACLs: GETACL--まさしくメールボックスの上の“a"。
MYRIGHTS - any of the following rights is required to perform the
operation: "l", "r", "i", "k", "x", "a".
MYRIGHTS--以下の権利のどれかが操作を実行するのに必要です: 「l」、「r」、「i」「k」、「x」“a"。
LISTRIGHTS - "a" right on the mailbox.
LISTRIGHTS--まさしくメールボックスの上の“a"。
Melnikov Standards Track [Page 16] RFC 4314 IMAP ACL December 2005
メリニコフStandardsはIMAP ACL2005年12月にRFC4314を追跡します[16ページ]。
5. Other Considerations
5. 他の問題
5.1. Additional Requirements and Implementation Notes
5.1. 追加要件と実装注意
5.1.1. Servers
5.1.1. サーバ
This document defines an additional capability that is used to announce the list of extra rights (excluding the ones defined in RFC 2086) supported by the server. The set of rights MUST include "t", "e", "x", and "k". Note that the extra rights can appear in any order.
このドキュメントはサーバによってサポートされた付加的な権利(RFC2086で定義されたものを除いた)のリストを発表するのに使用される追加能力を定義します。権利のセットは「t」、「e」、「x」、および「k」を含まなければなりません。 付加的な権利が順不同に現れることができることに注意してください。
Example: C: 1 capability
S: * CAPABILITY IMAP4REV1 STARTTLS LITERAL+
ACL RIGHTS=texk
S: 1 OK completed
例: C: 1 能力S: * 能力IMAP4REV1 STARTTLSリテラル+ACL権利はtexk Sと等しいです: OKが完成した1
Any server implementing an ACL extension MUST accurately reflect the current user's rights in FLAGS and PERMANENTFLAGS responses.
ACLが拡大であると実装するどんなサーバも正確にFLAGSとPERMANENTFLAGS応答に現在のユーザの権利を反映しなければなりません。
Example: C: A142 SELECT INBOX
S: * 172 EXISTS
S: * 1 RECENT
S: * OK [UNSEEN 12] Message 12 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 4392] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] L
S: A142 OK [READ-WRITE] SELECT completed
C: A143 MYRIGHTS INBOX
S: * MYRIGHTS INBOX lrwis
S: A143 OK completed
例: C: A142は受信トレイSを選択します: * 172が存在している、S: * 1、最近のS: * OK[UNSEEN12]メッセージ12は最初に、見えないSです: * OK[UIDVALIDITY3857529045]のUIDs有効なS: * OK[UIDNEXT4392]は次のUID Sを予測しました: * 旗(\に答えた\は\削除された\見られた\草稿に旗を揚げさせた)のS: * OK[PERMANENTFLAGS(見られた\は\*に旗を揚げさせました\が、\に答えた)]L S: A142 OK[READ-WRITE]SELECTはCを完成しました: A143 MYRIGHTS受信トレイS: * MYRIGHTS INBOX lrwis S: 完成したA143 OK
Note that in order to get better performance the client MAY pipeline SELECT and MYRIGHTS commands:
クライアント5月のパイプラインSELECTをより良い性能に得て、コマンドをMYRIGHTSに得るためにそれに注意してください:
C: A142 SELECT INBOX
C: A143 MYRIGHTS INBOX
S: * 172 EXISTS
S: * 1 RECENT
S: * OK [UNSEEN 12] Message 12 is first unseen
S: * OK [UIDVALIDITY 3857529045] UIDs valid
S: * OK [UIDNEXT 4392] Predicted next UID
S: * FLAGS (\Answered \Flagged \Deleted \Seen \Draft)
S: * OK [PERMANENTFLAGS (\Seen \Answered \Flagged \*)] L
S: A142 OK [READ-WRITE] SELECT completed
S: * MYRIGHTS INBOX lrwis
S: A143 OK completed
C: A142は受信トレイCを選択します: A143 MYRIGHTS受信トレイS: * 172が存在している、S: * 1、最近のS: * OK[UNSEEN12]メッセージ12は最初に、見えないSです: * OK[UIDVALIDITY3857529045]のUIDs有効なS: * OK[UIDNEXT4392]は次のUID Sを予測しました: * 旗(\に答えた\は\削除された\見られた\草稿に旗を揚げさせた)のS: * OK[PERMANENTFLAGS(見られた\は\*に旗を揚げさせました\が、\に答えた)]L S: A142 OK[READ-WRITE]SELECTはSを完成しました: * MYRIGHTS INBOX lrwis S: 完成したA143 OK
Melnikov Standards Track [Page 17] RFC 4314 IMAP ACL December 2005
メリニコフStandardsはIMAP ACL2005年12月にRFC4314を追跡します[17ページ]。
Servers MAY cache the rights a user has on a mailbox when the mailbox is selected, so that if a client's rights on a mailbox are changed with SETACL or DELETEACL, commands specific to the selected state (e.g., STORE, EXPUNGE) might not reflect the changed rights until the mailbox is re-selected. If the server checks the rights on each command, then it SHOULD send FLAGS and PERMANENTFLAGS responses if they have changed. If such server detects that the user no longer has read access to the mailbox, it MAY send an untagged BYE response and close connection. It MAY also refuse to execute all commands specific to the selected state until the mailbox is closed; however, server implementors should note that most clients don't handle NO responses very well.
メールボックスが選択されるとき、サーバはユーザがメールボックスの上に持っている権利をキャッシュするかもしれません、SETACLかDELETEACLと共にメールボックスの上のクライアントの権利を変えるなら、メールボックスが再選択されるまで選択された状態(例えば、ストア、EXPUNGE)に特定のコマンドが変えられた権利を反映しないように。 サーバが権利について検査するなら、それぞれが命令して、次に、それはSHOULDです。それらが変化したなら、FLAGSとPERMANENTFLAGS応答を送ってください。 そのようなサーバがそれを検出するなら、ユーザはもうメールボックスへのアクセスを読んでいなくて、それはuntagged BYE応答と浅からぬ関係を送るかもしれません。 また、それは、メールボックスが閉じられるまで選択された状態に特定のすべてのコマンドを実行するのを拒否するかもしれません。 しかしながら、サーバ作成者は、ほとんどのクライアントがそれほど応答を全くよく扱わないことに注意するべきです。
An ACL server MAY modify one or more ACLs for one or more identifiers as a side effect of modifying the ACL specified in a SETACL/DELETEACL. If the server does that, it MUST send untagged ACL response(s) to notify the client about the changes made.
ACLを変更する副作用がSETACL/DELETEACLで指定したようにACLサーバは1つ以上の識別子のために1ACLsを変更するかもしれません。 サーバがそれをするなら、それは、行われた変更に関してクライアントに通知するために応答をuntagged ACLに送らなければなりません。
An ACL server implementation MUST treat received ACL modification commands as a possible ambiguity with respect to subsequent commands affected by the ACL, as described in Section 5.5 of [IMAP4]. Hence a pipeline SETACL + MYRIGHTS is an ambiguity with respect to the server, meaning that the server must execute the SETACL command to completion before the MYRIGHTS. However, clients are permitted to send such a pipeline.
ACLサーバ実装はACLで影響を受けたその後のコマンドに関して容認されたACL変更命令を可能なあいまいさとして扱わなければなりません、[IMAP4]のセクション5.5で説明されるように。 したがって、パイプラインSETACL+MYRIGHTSはサーバに関するあいまいさです、サーバがMYRIGHTSの前での完成にSETACLコマンドを実行しなければならないことを意味して。 しかしながら、クライアントがそのようなパイプラインを送ることが許可されています。
5.1.2. Clients
5.1.2. クライアント
The following requirement is put on clients in order to allow for future extensibility. A client implementation that allows a user to read and update ACLs MUST preserve unrecognized rights that it doesn't allow the user to change. That is, if the client
以下の要件は、将来の伸展性を考慮するためにクライアントに置かれます。 ユーザがACLsを読んで、アップデートするクライアント実装は、ユーザがそれで変えることができない認識されていない権利を保持しなければなりません。 クライアントであるなら、それはそうです。
1) can read ACLs
and
2) can update ACLs
but
3) doesn't allow the user to change the rights the client doesn't
recognize, then it MUST preserve unrecognized rights.
1) ユーザは3で)クライアントが認めない権利を変えることができません、そして、それはACLsを読むことができて、2は)ACLsをアップデートできますが、次に、認識されていない権利を保持しなければなりません。
Otherwise the client could risk unintentionally removing permissions it doesn't understand.
さもなければ、クライアントは、それが理解していない許容を何気なく取り除く危険を冒すことができました。
Melnikov Standards Track [Page 18] RFC 4314 IMAP ACL December 2005
メリニコフStandardsはIMAP ACL2005年12月にRFC4314を追跡します[18ページ]。
5.2. Mapping of ACL Rights to READ-WRITE and READ-ONLY Response Codes
5.2. 読書して書くACL権利と書き込み禁止応答コードに関するマッピング
A particular ACL server implementation MAY allow "shared multiuser access" to some mailboxes. "Shared multiuser access" to a mailbox means that multiple different users are able to access the same mailbox, if they have proper access rights. "Shared multiuser access" to the mailbox doesn't mean that the ACL for the mailbox is currently set to allow access by multiple users. Let's denote a "shared multiuser write access" as a "shared multiuser access" when a user can be granted flag modification rights (any of "w", "s", or "t").
特定のACLサーバ実装はいくつかのメールボックスへの「共有されたマルチユーザアクセス」を許容するかもしれません。 メールボックスへの「共有されたマルチユーザアクセス」は、複数の異なったユーザが同じメールボックスにアクセスできることを意味します、彼らに適切なアクセス権があるなら。 メールボックスへの「共有されたマルチユーザアクセス」は、メールボックスのためのACLが現在複数のユーザによるアクセスを許すように用意ができていることを意味しません。 ユーザの旗の変更を承諾できるとき、「共有されたマルチユーザアクセス」が(「w」のどれか、「s」、または「t」)を正すとき、「共有されたマルチユーザはアクセスを書く」aを指示しましょう。
Section 4 describes which rights are required for modifying different flags.
セクション4は、どの権利が異なった旗を変更するのに必要であるかを説明します。
If the ACL server implements some flags as shared for a mailbox (i.e., the ACL for the mailbox MAY be set up so that changes to those flags are visible to another user), let's call the set of rights associated with these flags (as described in Section 4) for that mailbox collectively as "shared flag rights". Note that the "shared flag rights" set MAY be different for different mailboxes.
ACLサーバがメールボックスのための共有されるとしてのいくつかの旗を実装するなら(メールボックスのためのすなわち、ACLは別のユーザにとって、それらの旗への変化が目に見えるように、セットアップされるかもしれません)、そのメールボックスのために「共有された旗の権利」として権利のセットがこれらの旗(セクション4で説明されるように)に関連しているとまとめて言いましょう。 異なったメールボックスにおいて、「共有された旗の権利」セットが異なるかもしれないことに注意してください。
If the server doesn't support "shared multiuser write access" to a mailbox or doesn't implement shared flags on the mailbox, "shared flag rights" for the mailbox is defined to be the empty set.
サーバが「分配しているマルチユーザはアクセスを書くこと」をメールボックスにサポートしないか、またはメールボックス、メールボックスのために「共有された旗はまっすぐになるところ」で共有された旗を実装しない、空集合になるように、定義されます。
Example 1: Mailbox "banan" allows "shared multiuser write access" and
implements flags \Deleted, \Answered, and $MDNSent as
shared flags. "Shared flag rights" for the mailbox "banan"
is a set containing flags "t" (because system flag
\Deleted requires "t" right) and "w" (because both
\Answered and $MDNSent require "w" right).
例1: メールボックス"banan"は「共有されたマルチユーザはアクセスを書い」て旗の\Deleted、\Answered、および共有されるとしての$MDNSentが旗を揚げさせる道具を許容します。 メールボックス"banan"のために「共有された旗はまっすぐになること」が、旗「t」(システム旗の\Deletedが「t」をまさしく必要とするので)と「w」を含むセット(\Answeredと$MDNSentの両方が「w」をまさしく必要とするので)です。
Example 2: Mailbox "apple" allows "shared multiuser write access" and
implements \Seen system flag as shared flag. "Shared flag
rights" for the mailbox "apple" contains "s" right
because system flag \Seen requires "s" right.
例2: 「りんご」が「共有されたマルチユーザはアクセスを書くこと」を許して、\Seenシステム旗を実装するメールボックスは旗を共有しました。 まさしくシステム旗の\Seenが「s」をまさしく必要とするので、メールボックス「りんご」のために「共有された旗はまっすぐになること」が「s」を含んでいます。
Example 3: Mailbox "pear" allows "shared multiuser write access" and
implements flags \Seen, \Draft as shared flags. "Shared
flag rights" for the mailbox "apple" is a set containing
flags "s" (because system flag \Seen requires "s" right)
and "w" (because system flag \Draft requires "w" right).
例3: 「洋梨」が「共有されたマルチユーザはアクセスを書い」て道具を許容するメールボックスは\Seen、共有されるとしてのDraftが旗を揚げさせる\に旗を揚げさせます。 メールボックス「りんご」のために「共有された旗はまっすぐになること」が、旗「s」(システム旗の\Seenが「s」をまさしく必要とするので)と「w」を含むセット(システム旗の\Draftが「w」をまさしく必要とするので)です。
The server MUST include a READ-ONLY response code in the tagged OK response to a SELECT command if none of the following rights is granted to the current user:
以下の権利のいずれも現在のユーザに与えられないなら、サーバはSELECTコマンドへのタグ付けをされたOK応答にREADだけ応答コードを含まなければなりません:
Melnikov Standards Track [Page 19] RFC 4314 IMAP ACL December 2005
メリニコフStandardsはIMAP ACL2005年12月にRFC4314を追跡します[19ページ]。
"i", "e", and "shared flag rights"(***).
「i」、「e」、および「共有された旗の権利。」(***)
The server SHOULD include a READ-WRITE response code in the tagged OK response if at least one of the "i", "e", or "shared flag rights"(***) is granted to the current user.
少なくとも「i」、「e」、または「共有された旗の権利」(***)の1つを現在のユーザに与えるなら、サーバSHOULDはタグ付けをされたOK応答にREAD-WRITE応答コードを含んでいます。
(***) Note that a future extension to this document can extend the list of rights that causes the server to return the READ-WRITE response code.
(***) このドキュメントへの今後の拡大がサーバにREAD-WRITE応答コードを返させる権利のリストを広げることができることに注意してください。
Example 1 (continued): The user that has "lrs" rights for the mailbox
"banan". The server returns READ-ONLY
response code on SELECT, as none of "iewt"
rights is granted to the user.
例1(続けられています): "lrs"を持っているユーザはメールボックス"banan"のためにまっすぐになります。 "iewt"権利のいずれもユーザに与えられないとき、サーバはSELECTで応答コードをREADだけに返します。
Example 2 (continued): The user that has "rit" rights for the mailbox
"apple". The server returns READ-WRITE
response code on SELECT, as the user has "i"
right.
例2(続けられています): "rit"を持っているユーザはメールボックス「りんご」のためにまっすぐになります。 ユーザが「i」を右に持っているとき、サーバはSELECTで応答コードをREAD-WRITEに返します。
Example 3 (continued): The user that has "rset" rights for the
mailbox "pear". The server returns READ-WRITE
response code on SELECT, as the user has "e"
and "s" rights.
例3(続けられています): "rset"を持っているユーザはメールボックス「洋梨」のためにまっすぐになります。 ユーザに「e」と「s」権利があるとき、サーバはSELECTで応答コードをREAD-WRITEに返します。
6. Security Considerations
6. セキュリティ問題
An implementation MUST make sure the ACL commands themselves do not give information about mailboxes with appropriately restricted ACLs. For example, when a user agent executes a GETACL command on a mailbox that the user has no permission to LIST, the server would respond to that request with the same error that would be used if the mailbox did not exist, thus revealing no existence information, much less the mailbox's ACL.
実現は、ACLコマンド自体が適切に制限されたACLsがあるメールボックスに関して知らせないのを確実にしなければなりません。 ユーザエージェントがメールボックスの上にGETACLコマンドを実行するとき、例えば、ユーザがLIST、サーバに許可を全く持っていないのはメールボックスが存在していないなら使用されるのと同じ誤りでその要求に応じるでしょう、その結果、存在情報、ましてメールボックスのACLを全く明らかにしません。
IMAP clients implementing ACL that are able to modify ACLs SHOULD warn a user that wants to give full access (or even just the "a" right) to the special identifier "anyone".
ACLs SHOULDを変更できるACLを実行するIMAPクライアントが「だれも」という特別な識別子への完全なアクセス(または、まさしく“a"権利さえ)を与えたがっているユーザに警告します。
This document relies on [SASLprep] to describe steps required to perform identifier canonicalization (preparation). The preparation algorithm in SASLprep was specifically designed such that its output is canonical, and it is well-formed. However, due to an anomaly [PR29] in the specification of Unicode normalization, canonical equivalence is not guaranteed for a select few character sequences. Identifiers prepared with SASLprep can be stored and returned by an ACL server. The anomaly affects ACL manipulation and evaluation of identifiers containing the selected character sequences. These
このドキュメントは、識別子canonicalization(準備)を実行するのに必要であるステップについて説明するために[SASLprep]を当てにします。 SASLprepの準備アルゴリズムは出力が正準であるように、明確に設計されました、そして、それはよく形成されています。 しかしながら、ユニコード正常化の仕様による異常[PR29]のため、正準な等価性はわずかな選んだキャラクタシーケンスのために保証されません。 ACLサーバはSASLprepによって準備された識別子を、格納して、返すことができます。異常は選択されたキャラクタシーケンスを含む識別子のACL操作と評価に影響します。 これら
Melnikov Standards Track [Page 20] RFC 4314 IMAP ACL December 2005
メリニコフStandardsはIMAP ACL2005年12月にRFC4314を追跡します[20ページ]。
sequences, however, do not appear in well-formed text. In order to address this problem, an ACL server MAY reject identifiers containing sequences described in [PR29] by sending the tagged BAD response. This is in addition to the requirement to reject identifiers that fail SASLprep preparation as described in Section 3.
しかしながら、系列はよく形成されたテキストに載っていません。 このその問題を訴えるために、ACLサーバは[PR29]でタグ付けをされたBAD応答を送ることによって説明された系列を含む識別子を拒絶するかもしれません。 これはセクション3で説明されるようにSASLprep準備に失敗する識別子を拒絶するという要件に加えています。
Other security considerations described in [IMAP4] are relevant to this document. In particular, ACL information is sent in the clear over the network unless confidentiality protection is negotiated.
[IMAP4]で説明された他のセキュリティ問題はこのドキュメントに関連しています。 秘密性保護を交渉しない場合、特に、ネットワークの上の明確でACL情報を送ります。
This can be accomplished either by the use of STARTTLS, negotiated privacy protection in the AUTHENTICATE command, or some other protection mechanism.
STARTTLSの使用、AUTHENTICATEコマンドにおける交渉されたプライバシー保護、またはある他の保護メカニズムはこれを達成できます。
7. Formal Syntax
7. 正式な構文
Formal syntax is defined using ABNF [ABNF], extending the ABNF rules in Section 9 of [IMAP4]. Elements not defined here can be found in [ABNF] and [IMAP4].
[IMAP4]のセクション9のABNF規則を広げていて、正式な構文は、ABNF[ABNF]を使用することで定義されます。 [ABNF]と[IMAP4]でここで定義されなかった要素は見つけることができます。
Except as noted otherwise, all alphabetic characters are case insensitive. The use of uppercase or lowercase characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
別の方法で注意されるのを除いて、すべての英字が大文字と小文字を区別しないです。 象徴ストリングを定義する大文字しているか小文字のキャラクタの使用は編集の明快だけのためのものです。 実現は大文字と小文字を区別しないファッションでこれらのストリングを受け入れなければなりません。
LOWER-ALPHA = %x61-7A ;; a-z
下側のアルファー=%x61-7A。 1zです。
acl-data = "ACL" SP mailbox *(SP identifier SP
rights)
acl-データは"ACL"SPメールボックス*と等しいです。(SP識別子SP権利)
capability =/ rights-capa
;;capability is defined in [IMAP4]
能力権利=/高級キューバタバコ。能力は中で定義されます。[IMAP4]
command-auth =/ setacl / deleteacl / getacl /
listrights / myrights
;;command-auth is defined in [IMAP4]
コマンド-authは/ setacl / deleteacl / getacl / listrights / myrightsと等しいです。コマンド-authは中で定義されます。[IMAP4]
deleteacl = "DELETEACL" SP mailbox SP identifier
deleteaclは"DELETEACL"SPメールボックスSP識別子と等しいです。
getacl = "GETACL" SP mailbox
getaclは"GETACL"SPメールボックスと等しいです。
identifier = astring
識別子=astring
listrights = "LISTRIGHTS" SP mailbox SP identifier
listrightsは「LISTRIGHTS」SPメールボックスSP識別子と等しいです。
listrights-data = "LISTRIGHTS" SP mailbox SP identifier
SP rights *(SP rights)
listrights-データは「LISTRIGHTS」SPメールボックスSP識別子SP権利*と等しいです。(SP権利)
Melnikov Standards Track [Page 21] RFC 4314 IMAP ACL December 2005
メリニコフStandardsはIMAP ACL2005年12月にRFC4314を追跡します[21ページ]。
mailbox-data =/ acl-data / listrights-data / myrights-data
;;mailbox-data is defined in [IMAP4]
メールボックスデータmyrights listrights acl=/データ/データ/データ。メールボックスデータは中で定義されます。[IMAP4]
mod-rights = astring
;; +rights to add, -rights to remove
;; rights to replace
モッズ権利はastringと等しいです。 + 加える権利、取り外す権利。 置き換える権利
myrights = "MYRIGHTS" SP mailbox
myrightsは「MYRIGHTS」SPメールボックスと等しいです。
myrights-data = "MYRIGHTS" SP mailbox SP rights
myrights-データは「MYRIGHTS」SPメールボックスSP権利と等しいです。
new-rights = 1*LOWER-ALPHA
;; MUST include "t", "e", "x", and "k".
;; MUST NOT include standard rights listed
;; in section 2.2
新しい権利は1*LOWER-アルファーと等しいです。 「t」、「e」、「x」、および「k」を含まなければなりません。 ;; 記載された標準の権利を含んではいけません。 セクション2.2で
rights = astring
;; only lowercase ASCII letters and digits
;; are allowed.
権利はastringと等しいです。 単にASCII手紙とケタを小文字で印刷してください。 許容されています。
rights-capa = "RIGHTS=" new-rights
;; RIGHTS=... capability
権利高級キューバタバコ=は新しい権利で「=を正します」。 RIGHTS=…能力
setacl = "SETACL" SP mailbox SP identifier
SP mod-rights
setaclは"SETACL"SPメールボックスSP識別子SPモッズ権利と等しいです。
8. IANA Considerations
8. IANA問題
IMAP4 capabilities are registered by publishing a standards-track or IESG-approved experimental RFC. The registry is currently located at:
IMAP4能力は、標準化過程かIESGによって承認された実験的なRFCを発行することによって、登録されます。 登録は現在、以下に位置しています。
http://www.iana.org/assignments/imap4-capabilities
http://www.iana.org/assignments/imap4-capabilities
This document defines the RIGHTS= IMAP capability. IANA has added this capability to the registry.
このドキュメントはRIGHTS= IMAP能力を定義します。 IANAは登録へのこの能力を加えました。
9. Internationalization Considerations
9. 国際化問題
Section 3 states requirements on servers regarding internationalization of identifiers.
セクション3は識別子の国際化に関するサーバに関する要件を述べます。
Melnikov Standards Track [Page 22] RFC 4314 IMAP ACL December 2005
メリニコフStandardsはIMAP ACL2005年12月にRFC4314を追跡します[22ページ]。
Appendix A. Changes since RFC 2086
RFC2086以来の付録A.変化
1. Changed the charset of "identifier" from US-ASCII to UTF-8.
2. Specified that mailbox deletion is controlled by the "x" right
and EXPUNGE is controlled by the "e" right.
3. Added the "t" right that controls STORE \Deleted. Redefined the
"d" right to be a macro for "e", "t", and possibly "x".
4. Added the "k" right that controls CREATE. Redefined the "c"
right to be a macro for "k" and possibly "x".
5. Specified that the "a" right also controls DELETEACL.
6. Specified that the "r" right also controls STATUS.
7. Removed the requirement to check the "r" right for CHECK, SEARCH
and FETCH, as this is required for SELECT/EXAMINE to be
successful.
8. LISTRIGHTS requires the "a" right on the mailbox (same as
SETACL).
9. Deleted "PARTIAL", this is a deprecated feature of RFC 1730.
10. Specified that the "w" right controls setting flags other than
\Seen and \Deleted on APPEND. Also specified that the "s" right
controls the \Seen flag and that the "t" right controls the
\Deleted flag.
11. Specified that SUBSCRIBE is NOT allowed with the "r" right.
12. Specified that the "l" right controls SUBSCRIBE.
13. GETACL is NOT allowed with the "r" right, even though there are
several implementations that allows that. If a user only has
"r" right, GETACL can disclose information about identifiers
existing on the mail system.
14. Clarified that RENAME requires the "k" right for the new parent
and the "x" right for the old name.
15. Added new section that describes which rights are required
and/or checked when performing various IMAP commands.
16. Added mail client security considerations when dealing with
special identifier "anyone".
17. Clarified that negative rights are not the same as DELETEACL.
18. Added "Compatibility with RFC 2086" section.
19. Added section about mapping of ACL rights to READ-WRITE and
READ-ONLY response codes.
20. Changed BNF to ABNF.
21. Added "Implementation Notes" section.
22. Updated "References" section.
23. Added more examples.
24. Clarified when the virtual "c" and "d" rights are returned in
ACL, MYRIGHTS, and LISTRIGHTS responses.
1. 「識別子」のcharsetを米国-ASCIIからUTF-8に変えました。 2. メールボックス削除が「x」権利によって制御されて、EXPUNGEが「e」権利によって制御されると指定しました。 3. ストア\Deletedを制御する「t」右を加えました。 「e」、「t」、およびことによると「x」のためのマクロである「d」右を再定義しました。 4. CREATEを制御する「k」右を加えました。 「k」とことによると「x」のためのマクロである「c」右を再定義しました。 5. また、“a"権利がDELETEACLを制御すると指定しました。 6. また、「r」権利がSTATUSを制御すると指定しました。 7. 取り除いて、これとしてまさしくCHECK、検索、およびFETCHのための「r」をチェックするという要件が、SELECT/EXAMINEがうまくいっているのに必要です。 8. LISTRIGHTSはメールボックス(SETACLと同じ)の上の“a"権利を必要とします。 9. 削除されて、「部分的であること」で、これはRFC1730の推奨しない特徴です。 10. 「w」権利がAPPENDの上の\Seenと\Deleted以外の設定旗を制御すると指定しました。 また、「s」権利がSeenが旗を揚げさせる\を制御して、「t」権利がDeletedが旗を揚げさせる\を制御すると指定しました。 11. 指定されて、登録は「r」権利で許容されていません。 12. 指定されて、その「l」権利は制御されます。登録。 13. それがそれを許容するいくつかの実現がありますが、GETACLは「r」権利で許容されていません。 ユーザが「r」を右に持っているだけであるなら、GETACLはメールシステムの上に存在する識別子に関して情報を開示できます。 14. はっきりさせられて、そのRENAMEはまさしく新しい親のための「k」とまさしく旧名のための「x」を必要とします。 15. 様々なIMAPコマンドを実行するとき、どの権利について説明する加えられた新しいセクションが、必要である、そして/または、チェックされます。 16. 「だれも」という特別な識別子に対処するとき、メールクライアントセキュリティ問題を加えました。 17. はっきりさせられて、そんなに否定的な権利はDELETEACLと同じではありません。 18. 「RFC2086との互換性」セクションを加えました。 19. ACLのマッピングに関する加えられたセクションはREAD-WRITEとREADだけ応答コードにまっすぐになります。 20. BNFをABNFに変えました。 21. 「実現注意」セクションを加えました。 22. 「参照」セクションをアップデートしました。 23. より多くの例を加えました。 24. 仮想の「c」と「d」権利がいつACL、MYRIGHTS、およびLISTRIGHTS応答で返されるかをはっきりさせました。
Melnikov Standards Track [Page 23] RFC 4314 IMAP ACL December 2005
メリニコフStandardsはIMAP ACL2005年12月にRFC4314を追跡します[23ページ]。
Appendix B. Compatibility with RFC 2086
RFC2086との付録B.の互換性
This non-normative section gives guidelines as to how an existing RFC 2086 server implementation may be updated to comply with this document.
この非標準のセクションはこのドキュメントに従うためにどう2086年の既存のRFCサーバ実現をアップデートするかもしれないかに関してガイドラインを与えます。
This document splits the "d" right into several new different rights: "t", "e", and possibly "x" (see Section 2.1.1 for more details). The "d" right remains for backward-compatibility, but it is a virtual right. There are two approaches for RFC 2086 server implementors to handle the "d" right and the new rights that have replaced it:
このドキュメントは「d」をまさしくいくつかの新しい異なった権利に分けます: 「t」、「e」、およびことによると「x。」(その他の詳細に関してセクション2.1.1を見ます) 「d」権利は後方の互換性のために残っていますが、それは仮想の権利です。 2086人のRFCサーバ作成者が「d」権利とそれを取り替えた新しい権利を扱うように、2つのアプローチがあります:
a. Tie "t", "e" (and possibly "x) together - almost no changes.
b. Implement separate "x", "t" and "e". Return the "d" right in a
MYRIGHTS response or an ACL response containing ACL information
when any of the "t", "e" (and "x") is granted.
a。 「t」、「e」を結んでください、(そして、ことによると「x) 変化いいえ、一緒に、ほとんどb。」 別々の「x」、「t」、および「e」を実行してください。 与えた状態で「t」のどれか、「e」(そして、「x」)がいつかというACL情報を含むMYRIGHTS応答かACL応答における「d」権利を返してください。
In a similar manner this document splits the "c" right into several new different rights: "k" and possibly "x" (see Section 2.1.1 for more details). The "c" right remains for backwards-compatibility but it is a virtual right. Again, RFC 2086 server implementors can choose to tie rights or to implement separate rights, as described above.
同じようにこのドキュメントは「c」をまさしくいくつかの新しい異なった権利に分けます: 「k」とことによると「x。」(その他の詳細に関してセクション2.1.1を見ます) 「c」権利は遅れている互換性のために残っていますが、それは仮想の権利です。 一方、2086人のRFCサーバ作成者が、上で説明されるように権利を結ぶか、または別々の権利を実行するのを選ぶことができます。
Also check Sections 5.1.1 and 5.1.2, as well as Appendix A, to see other changes required. Server implementors should check which rights are required to invoke different IMAP4 commands as described in Section 4.
また、セクション5.1 .1と5.1の.2、およびAppendix Aをチェックして、他の変化が必要であることを確認してください。 サーバ作成者は、どの権利がセクション4で説明されるように異なったIMAP4コマンドを呼び出すのに必要であるかをチェックするべきです。
Appendix C. Known Deficiencies
付録のC.の知られている欠乏
This specification has some known deficiencies including:
持っていて、:この仕様にはいくつかの知られている欠乏があります。
1. This is inadequate to provide complete read-write access to
mailboxes protected by Unix-style rights bits because there is no
equivalent to "chown" and "chgrp" commands nor is there a good
way to discover such limitations are present.
2. Because this extension leaves the specific semantics of how
rights are combined by the server as implementation defined, the
ability to build a user-friendly interface is limited.
3. Users, groups, and special identifiers (e.g., anyone) exist in
the same namespace.
1. これは、"chown"と"chgrp"コマンドと同等物が全くなくて、またそのような制限が存在していると発見する早道がないのでUnix-スタイル権利ビットによって保護されたメールボックスへの完全な読書して書いているアクセスを提供するために不十分です。 2. この拡大が権利が定義された実現としてサーバによってどう結合されるかに関する特定の意味論を残すので、ユーザフレンドリーなインタフェースを造る能力は限られています。 3. ユーザ、グループ、および特別な識別子(例えば、だれも)は同じ名前空間でいます。
The work-in-progress "ACL2" extension is intended to redesign this extension to address these deficiencies without the constraint of backward-compatibility and may eventually supercede this facility.
「ACL2"拡張子は、後方の互換性の規制なしでこれらの欠乏を記述するためにこの拡大を再設計することを意図して、結局、この施設をスーパー割譲するかもしれません」仕事進行中の。
Melnikov Standards Track [Page 24] RFC 4314 IMAP ACL December 2005
メリニコフStandardsはIMAP ACL2005年12月にRFC4314を追跡します[24ページ]。
However, RFC 2086 is deployed in multiple implementations so this intermediate step, which fixes the straightforward deficiencies in a backward-compatible fashion, is considered worthwhile.
しかしながら、RFC2086が複数の実現で配備されるので、この途中経過(後方コンパチブルファッションで簡単な欠乏を修正する)は価値があると考えられます。
Appendix D. Acknowledgements
付録D.承認
This document is a revision of RFC 2086 written by John G. Myers.
このドキュメントはジョン・G.マイアーズによって書かれたRFC2086の改正です。
Editor appreciates comments received from Mark Crispin, Chris Newman, Cyrus Daboo, John G. Myers, Dave Cridland, Ken Murchison, Steve Hole, Vladimir Butenko, Larry Greenfield, Robert Siemborski, Harrie Hazewinkel, Philip Guenther, Brian Candler, Curtis King, Lyndon Nerenberg, Lisa Dusseault, Arnt Gulbrandsen, and other participants of the IMAPEXT working group.
エディタはIMAPEXTワーキンググループのマーク・クリスピン、クリス・ニューマン、サイラスDaboo、ジョン・G.マイアーズ、デーヴCridland、ケン・マーチソン、スティーブHole、ウラジミールButenko、ラリー・グリーンフィールド、ロバートSiemborski、Harrie Hazewinkel、フィリップ・グンサー、ブライアン・カンドラー、カーティス・キング、リンドン・ネーレンバーグ、リサDusseault、Arnt Gulbrandsen、および他の関係者から受けられたコメントに感謝します。
Normative References
引用規格
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[KEYWORDS]ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[ABNF] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、2005年10月のRFC4234。
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[IMAP4] クリスピン、M.、「バージョン4rev1"、RFC3501、2003年インターネットメッセージアクセス・プロトコル--3月。」
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[UTF-8]Yergeau、F.、「UTF-8、ISO10646の変化形式」STD63、RFC3629、11月2003日
[Stringprep] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454,
December 2002.
[Stringprep] ホフマンとP.とM.Blanchet、「国際化しているストリング("stringprep")の準備」、RFC3454、2002年12月。
[SASLprep] Zeilenga, K., "SASLprep: Stringprep Profile for User
Names and Passwords", RFC 4013, February 2005.
[SASLprep]Zeilenga、K.、「SASLprep:」 「ユーザ名とパスワードのためのStringprepプロフィール」、RFC4013、2005年2月。
Informative References
有益な参照
[RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086,
January 1997.
[RFC2086] マイアーズ、J.、「IMAP4 ACL拡張子」、RFC2086、1997年1月。
[PR29] "Public Review Issue #29: Normalization Issue",
February 2004,
<http://www.unicode.org/review/pr-29.html>.
[PR29] 「公開レビューは#29、を発行します」。 「正常化問題」、2004年2月、<http://www.unicode.org/レビュー/pr-29.html>。
Melnikov Standards Track [Page 25] RFC 4314 IMAP ACL December 2005
メリニコフStandardsはIMAP ACL2005年12月にRFC4314を追跡します[25ページ]。
Author's Address
作者のアドレス
Alexey Melnikov Isode Ltd. 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX GB
AlexeyメリニコフIsode Ltd.5城のビジネス村36の駅のRoadハンプトン、ミドルセックスTW12 2BX GB
EMail: alexey.melnikov@isode.com
メール: alexey.melnikov@isode.com
Melnikov Standards Track [Page 26] RFC 4314 IMAP ACL December 2005
メリニコフStandardsはIMAP ACL2005年12月にRFC4314を追跡します[26ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Melnikov Standards Track [Page 27]
メリニコフ標準化過程[27ページ]
一覧
スポンサーリンク
