Network Working Group A. Melnikov
Request for Comments: 4314 Isode Ltd.
Obsoletes: 2086 December 2005
Category: Standards Track
IMAP4 Access Control List (ACL) Extension
Status of this 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権（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.
インターネットメッセージアクセスプロトコル（IMAP）のアクセス制御リスト（ACL）の拡張（RFC 2086）は、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.
この文書では、それはいくつかの新しいアクセス制御権と権利は異なるIMAPコマンドのために必要とされる明確化を定義するRFC 2086の改訂版です。
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
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.
インターネットメッセージアクセスプロトコル[IMAP4]のACL（アクセス制御リスト）拡張は、メールボックスアクセス制御リストが検索され、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.
この文書は、RFC 2086 [RFC2086]の改訂版です。それは権利が異なるIMAP4コマンドのために必要とされるアクセス識別子の[UTF-8] UTF-8の使用、特に、RFC 2086で異なる曖昧さを解明しようとし、そしてどのように読み書き/ READ-ONLY応答コードが関連していますACLへ。
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"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119 [KEYWORDS]で説明されるように解釈されます。
The phrase "ACL server" is just a shortcut for saying "IMAP server that supports ACL extension as defined in this document".
句「ACLサーバは」ただ「この文書で定義されたACLの拡張機能をサポートしているIMAPサーバ」を言うためのショートカットです。
The ACL extension is present in any IMAP4 implementation that returns "ACL" as one of the supported capabilities to the CAPABILITY command.
ACL拡張は、CAPABILITYコマンドにサポートされる機能の一つとして、「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.
この文書に準拠サーバーの実装は、「権利の=」能力の2.2節で定義されていない（下記参照）権利を返さなければなりません。
An access control list is a set of <access identifier,rights> pairs. An ACL applies to a mailbox name.
アクセス制御リストは、<アクセス識別子、権利>のペアのセットです。 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サーバーへの認証にコマンドを認証するすべてのユーザー名の文字列は、対応するユーザのための識別子として予約されています。ダッシュ（「 - 」）で始まる識別子は下記の「負の権利」、のために予約されています。他のすべての識別文字列は、実装定義の方法で解釈されます。
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.
権利英数字の（空）のセット、制御されている一連の操作をリストし、各文字をリストする文字列です。小文字は、セクション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は、」「」、右が常にメールボックスの所有者に付与され、別のユーザーに付与されることはありません、関連付けられています。権利が実装で結ばれている場合、実装はコマンドを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は、ユーザ、ユーザを含むグループに一致一つ以上の実装定義の識別子と一致する識別子に付与する、及び/又は識別子「誰」。これらの権利は、ユーザーのアクセスを決定するために組み合わされてどのように定義された実装があります。実装は、該当する識別子に付与された権利の組合を使用するように、例えば、選択することができます。実装は代わりに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」の権利を持っている可能性があるにもかかわらず、「W」は右識別子「フレッド」が一致するユーザーから削除されることを示し、「W」権利が付与される「-fred」場合ACL内の他の識別子の結果として。 ACLから「フレッド」単に識別子を削除する「フレッド」のDELETEACL。それは特にそれが「-fred」識別子に付与された権利には影響しません、ユーザー「フレッド」はACL内の別のエントリから取得することのできる権利には影響を与えません。
Server implementations are not required to support "negative right" identifiers.
サーバ実装は、「負の権利」の識別子をサポートする必要はありません。
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 - ルックアップ（メールボックスがリストに表示されている/ LSUBメールボックスをSUBSCRIBE、コマンド）R - S読み取る（メールボックスを選択し、STATUSを行う） - も設定、STOREを介してフラグを見てセッション（セットまたはクリア\横切って見/目に見えない情報を保持\ SEENワットAPPEND / COPY / FETCH BODY [...]）の間に - 書き込み（設定または\ SEEN以外の明確なフラグ\ STOREで削除、また、i）はAPPEND / COPY中にそれらを設定 - メールボックスにコピー、APPENDを行う（挿入） P - ポストがk（IMAP4自体によって強制されない、メールボックスのサブミッションアドレスにメールを送信） - （削除メールボックス - メールボックス（、任意の実装定義の階層でRENAMEで新しいメールボックス名の親のメールボックスを新しいサブメールボックスを作成）のxを作成トン）RENAMEにメールボックス、古いメールボックス名を削除 - 削除したメッセージが（設定またはSTOREを通じて明らか\ Deletedフラグ、APPEND / COPY時の設定\ Deletedフラグ）eは - EXPUNGEを実行し、CLOSEの一環として抹消 - SETACLを行う（管理/ DELETEACL / GETACL / LISTRIGHTS）
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.
RFC 2086での曖昧さに起因する、いくつかの既存のRFC 2086のサーバーの実装は、DELETEコマンドを制御するために、「C」、右を使用しています。その他には、DELETEコマンドを制御するために、「D」の権利を使用することにしました。前者については、の「K」と「X」権利の労働組合としての権利を「作成」、そして右の「E」と「T」権利の労働組合としての「削除」を定義してみましょう。後者のグループのために、のは「K」の右に同義語として権利を「作成」、そして右の「E」、「T」、および「X」権利の労働組合としての「削除」を定義してみましょう。
For compatibility with RFC 2086, this section defines two virtual rights "d" and "c".
RFC 2086との互換性のため、このセクションでは、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」右または「削除のすべてのメンバー場合よりも違いはありません「右が指定されていました。）
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」を含まなければなりません。これは、新しいサーバで動作するように、RFC 2086に準拠した古いクライアントを有効にすることです。 （*）
Example: C: A001 SeTacl INBOX/Drafts David lrswida S: A001 OK Setacl complete
例：C：A001 SETACL INBOX /ドラフトデイヴィッド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」を指定しており、それがサーバー上で「ら」に展開されます：
C: A002 getacl INBOX/Drafts
S: * ACL INBOX Fred rwipslxcetda David lrswideta
S: A002 OK Getacl complete
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」を含まなければなりません。会員権は非会員権に縛られていない場合（*）、そして「d」は右LISTRIGHTS応答で自身によって返されます。会員権のいずれかが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」を含まなければなりません。これは、新しいサーバで動作するように、RFC 2086に準拠した古いクライアントを有効にすることです。 （*）
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 INBOX /下書きバイロンlrswikdaはS：A001 OK SETACL完全なC：A002 GETACL INBOX /下書き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」を指定していると、それは「ら」サーバ上に展開：クライアントは、指定されたように（右の「C」のメンバーである）権利を「K」、サーバーまた、右側の「c」が返されます。
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：私のp k個のX TはD = W * LISTRIGHTSアーカイブ/ IMAPの誰もが "" LRの
Example: The server that ties the rights as follows:
例：次のように権利を結び付けサーバー：
lr s w i p k xte
XTEでLR kとP
and c=k
およびc = K
will return:
戻ります：
S: * LISTRIGHTS archive/imap anyone "" lr s w i p k xte c d
S：私のp kのXTEはD = W * LISTRIGHTSアーカイブ/ IMAPの誰もが "" LRの
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：私のp k個のC X TE Dワット* LISTRIGHTSアーカイブ/ IMAPの誰もが "" LRの
Example: The server that ties the rights as follows:
例：次のように権利を結び付けサーバー：
lr swte i p k x
LR swte私のp k個のX
and c=kx will return:
C =のKXが返されます：
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の実装を検討した後、これは合理的な制限であると結論づけました。
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").
"権利の=" 能力は、RFC 2086で定義された権利のいずれかを含んではいけません： "L"、 "R"、 "S"、 "W"、 "I"、 "P"、 "A"、 "C"、 "D"、および数字（ "0" ... "9"）。
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.
「文字列準備」アルゴリズム【のstringprep]のパラメータ（すなわち、SETACL、DELETEACL、及びLISTRIGHTSコマンドのいずれか）のような識別子を有するコマンドを処理する最初の「SASLprep」プロファイルを使用して、受信した識別子を準備する必要があり、サーバ、[SASLprep] 。識別子の準備が失敗した場合や、空の文字列での結果ならば、サーバはBAD応答でコマンドを実行することを拒否しなければなりません。第6節は、追加の識別子の確認手順を推奨していることに注意してください。
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はNOを完了 - 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コマンドは、指定したメールボックスのアクセス制御リストを変更します。
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番目の引数はオプションのプラス（「+」）またはマイナス（「」）を含む文字列です。文字列がプラスで始まっている場合、以下の権利は識別子の既存の権利に追加されます。文字列がマイナスで始まっている場合、以下の権利は識別子の既存の権利から削除されます。文字列がプラスまたはマイナスに起動しない場合、権利は識別子の既存の権限を交換してください。
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 INBOX /下書きS：* ACL INBOX /下書きフレッドはクリスlrswi Sをrwipslxetad：A001 OK GETACL完全なC：A002 SETACL INBOX /下書きクリス+ CDAのS：A002 OK SETACL完全なC：A003 GETACL INBOX /下書きS ：* ACL INBOX /下書きフレッドは、クリスのlrswicdakxet Sをrwipslxetad：A003 OK GETACLは完了
C: A035 SETACL INBOX/Drafts John lrQswicda
S: A035 BAD Uppercase rights are not allowed
C: A036 SETACL INBOX/Drafts John lrqswicda S: A036 BAD The q right is not supported
C：A036 SETACL INBOX /下書きジョンlrqswicda S：A036 BAD Q権がサポートされていません。
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
結果：ACL BADを削除することはできません - 無効な引数：OK - deleteacl失敗 - deleteacl完了NO
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 INBOX S：* ACL INBOXフレッドは、S wは-Fred wetd $チームをrwipslxetad：B001 OK GETACL完全なC：B002 DeleteAcl INBOXフレッドS：B002 OK Deleteacl完全な
C: B003 GETACL INBOX
S: * ACL INBOX -Fred wetd $team w
S: B003 OK Getacl complete
Arguments: mailbox name
引数：メールボックス名
Data: untagged responses: ACL
データ：タグなし応答：ACL
Result: OK - getacl completed NO - getacl failure: can't get acl BAD - arguments invalid
結果：ACL BAD取得することはできません - 無効な引数：OK - GETACL失敗 - GETACL完了NO
The GETACL command returns the access control list for mailbox in an untagged ACL response.
GETACLコマンドは、タグなし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コマンドで使用されるものとは異なるかもしれない識別子の正規化形式を含むかもしれません。
Example: C: A002 GETACL INBOX S: * ACL INBOX Fred rwipsldexta S: A002 OK Getacl complete
例：C：A002 GETACL INBOX S：* ACL INBOXフレッドrwipsldexta S：A002 OK GETACL完全な
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はNOを完了 - 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 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.
一部の実装では、同じIMAPアカウントを参照するための識別子の複数のフォームを許可することができます。通常、このような実装は内部的に保存されている標準的な形式を持っています。 LISTRIGHTSコマンドによって引き起こさLISTRIGHTS応答は常にクライアントで指定された識別子の同じ形を返さなければなりません。これは、クライアントがコマンドと応答を相関させることです。
Example: C: a001 LISTRIGHTS ~/Mail/saved smith S: * LISTRIGHTS ~/Mail/saved smith la r swicdkxte S: a001 OK Listrights completed
例：C：A001 LISTRIGHTS〜/メール/保存スミスS：* LISTRIGHTS〜/メール/保存スミス・ラ・RのswicdkxteのS：完成A001 OK LISTRIGHTS
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
A005 LISTRIGHTS成功例：C：A005 LISTRIGHTSアーカイブ/ IMAPの誰もがS：誰でも "" L rのS I、P、W、K、X、T、EはD = 0 1 2 3 4 5 6 7 8 9 S archive.imap * LISTRIGHTS
Arguments: mailbox name
引数：メールボックス名
Data: untagged responses: MYRIGHTS
データ：タグなし応答：MYRIGHTS
Result: OK - myrights completed NO - myrights failure: can't get rights BAD - arguments invalid
結果：BAD権利を取得することはできません - 無効な引数を：OK - MYRIGHTS障害 - MYRIGHTS完了NO
The MYRIGHTS command returns the set of rights that the user has to mailbox in an untagged MYRIGHTS reply.
MYRIGHTSコマンドは、ユーザーが返信タグなしMYRIGHTSでメールボックスに持っている権利のセットを返します。
Example: C: A003 MYRIGHTS INBOX S: * MYRIGHTS INBOX rwiptsldaex S: A003 OK Myrights complete
例：C：A003 MYRIGHTS INBOX S：* MYRIGHTS INBOXのrwiptsldaexのS：A003 OK MYRIGHTS完全な
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.
2.1.1詳細仮想「D」および「C」権利の取り扱いに関連する追加のサーバー要件。
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コマンドの結果として起こります。最初の二つの文字列は、この権利のリストが適用されるメールボックス名と識別子です。識別子の後には、識別子は、常にメールボックスに付与される権利の（空）のセットを含む文字列です。
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.
これは、ゼロ以上の文字列識別子がメールボックスに付与することができる権利のセットを含む各は、次のとおりです。同じ文字列で言及した権利は、相互に接続されています。サーバーは、メールボックス内の識別子へのすべて結ば権利を与えるか、どれを付与していない必要があります。 2.1.1詳細仮想「D」および「C」権利の取り扱いに関連する追加のサーバー要件。
The same right MUST NOT be listed more than once in the LISTRIGHTS command.
同じ権利が一度LISTRIGHTSコマンドで複数表示されてはなりません。
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.
2.1.1詳細仮想「D」および「C」権利の取り扱いに関連する追加のサーバー要件。
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コマンドの両方は、権利の同じセットを必要とします。
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 | | | ? | ? | | | | ? | | | | |
+-------------------+---+---+---+---+---+---+---+---+---+---+---+---+
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.
注：/メールボックスを調べて選択する必要があるので、選択状態にあるすべてのコマンドのために、「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つだけ（下の説明を参照）が必要ですか？ - 右の「ANY」（以下の説明参照）はオプションである - 「I」、「K」、「X」、「L」、「R」の少なくとも一つを、「」権利が「非」が必要である - いいえコマンドを実行するのに必要な権限
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」にではなく、その親のメールボックス「A」に「L」を持っている場合は、LISTコマンドは、メールボックスかのように振る舞うべきであることに注意してください
C: A777 LIST "" *
S: * LIST (\NoInferiors) "/" "A/B"
S: * LIST () "/" "C"
S: * LIST (\NoInferiors) "/" "C/D"
S: A777 OK LIST completed
SUBSCRIBE - "l" right is required only if the server checks for mailbox existence when performing SUBSCRIBE.
SUBSCRIBE - 「L」は右のメールボックスの存在をサーバーがチェックを行うときにSUBSCRIBE場合にのみ必要です。
UNSUBSCRIBE - no rights required to perform this operation.
UNSUBSCRIBE - この操作を実行するために必要な権利無し。
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.
LSUB - 「L」は、右実行するときに、メールボックスの存在のために、サーバーチェックがSUBSCRIBE場合にのみ必要です。しかし、他のコマンドとは異なり、それが加入したメールボックスを一覧表示することができない場合は、サーバーが無応答を返してはなりません（例えば、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」を。新しいメールボックスが作成されると（存在する場合）、それが定義された階層内の親メールボックスから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 - 右のボックスに「×」。一部のサーバが非空のメールボックスを削除することはできませんので注意してください。この場合、ユーザーはメールボックスを開いて、それを空にするために、「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 - 別の親からメールボックスを移動すると、右のメールボックス自体と右の新しい親のための「K」の上に「×」が必要です。ユーザーは、「D / E」を「A / B / C」という名前のメールボックスの名前を変更したい場合たとえば、ユーザーがメールボックス「A / B / C」と「K」のための「x」の権利を持っている必要があります右のメールボックス「D」のために。 RENAMEコマンドは、名前を変更したメールボックスとサブメールボックスのACLを変更しないでください。
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」権利を持っていない場合、操作は失敗します。メッセージが「S」右Deletedフラグのセットを\している - - ユーザーが正しい「t」を有する場合、別段の各コピー/添付メッセージをサーバが確認しなければならない他のすべてのメッセージのための - メッセージが正しい「W」\見フラグセットを有する場合フラグ。ユーザは、特定の権利を有している場合にのみ、新たに作成されたメッセージの格納された対応するフラグです。ユーザーが特定のフラグを設定するためのいかなる権利を持っていない場合、サーバは、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: A005 COPY 1:3 TargetMailbox S: A005 OK Copy completed
C：A005 COPY 1：3 TargetMailbox S：A005 OKコピー完了
C: A006 SELECT TargetMailbox ... S: A006 Select Completed
C：A006 SELECT 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
\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:
\ Deletedフラグは、ユーザーが右のターゲットメールボックスには「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（フラグ）FETCH
S: * 77 FETCH (FLAGS (\Deleted)) S: * 78 FETCH (FLAGS ()) S: * 79 FETCH (FLAGS (\Seen)) S: A007 OK Fetch Completed
S：* 77 FETCH（FLAGS（\削除））S：* 78 FETCH（FLAGS（））S：* 79 FETCH（FLAGS（\見られる））S：A007 OK完了フェッチ
In the latter case, \Answered, $Forwarded, and \Draft flags were lost on COPY, as the user has no "w" right in the target mailbox.
後者の場合は、\ $転送され、回答、およびユーザーは、右対象のメールボックスには「W」を持っていないよう\ドラフトフラグは、COPYに失われました。
Expunging the selected mailbox: EXPUNGE - "e" right on the selected mailbox.
選択したメールボックスに「E」、右 - EXPUNGE：選択したメールボックスを抹消。
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」の権利を持っていないため、メールボックスを抹消することができない場合、サーバは、EXPUNGE要求を無視するメールボックスを閉じ、タグ付きOK応答を返さなければなりません。
Fetch information about a mailbox and its messages: SELECT/EXAMINE/STATUS - "r" right on the mailbox.
メールボックスとそのメッセージに関する情報を取得する：SELECT / / STATUS EXAMINE - 右のボックスに「R」を。
FETCH - A FETCH request that implies setting \Seen flag MUST NOT set it, if the current user doesn't have "s" right.
FETCH - それを設定してはいけません\見フラグを設定する暗示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.
フラグを変更：STORE - ユーザーが右の「t」を持っている場合、サーバーがチェックしなければなりません - ユーザー修正\ Deletedフラグ「S」右 - 他のすべてのメッセージフラグのために - ユーザーが権利「W」\見フラグを変更したとき。ユーザーが展開され、クライアントによって非常にうまく処理されないSTOREコマンドに対する応答をタグ付けしないよう、STOREで指定された少なくとも1つのフラグを変更する権利を持っている場合STORE操作は失敗すべきではありません。
Changing ACLs: SETACL/DELETEACL - "a" right on the mailbox.
ACLを変更：は、setfaclは/ ACLの削除 - メールボックスの「」右を。
Reading ACLs: GETACL - "a" right on the mailbox.
GETACL - メールボックスの「」右：ACLを読みます。
MYRIGHTS - any of the following rights is required to perform the operation: "l", "r", "i", "k", "x", "a".
"L"、 "R"、 "I"、 "K"、 "X"、 "A"： - MYRIGHTS次の権限のいずれかの操作を行う必要があります。
LISTRIGHTS - "a" right on the mailbox.
LISTRIGHTS - メールボックスの「」右。
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.
この文書では、サーバーでサポートされている（RFC 2086で定義されたものを除く）の余分な権利のリストを発表するために使用される追加機能を定義します。権利のセットは、 "T"、 "E"、 "X"、および "K" を含まなければなりません。余分な権利をどのような順序で表示されることに注意してください。
Example: C: 1 capability S: * CAPABILITY IMAP4REV1 STARTTLS LITERAL+ ACL RIGHTS=texk S: 1 OK completed
例：C：1機能S：* CAPABILITY IMAP4rev1のSTARTTLS LITERAL + ACL RIGHTS = texkのS：完成1 OK
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 SELECT INBOX S * 172 SをEXISTS：* 1 RECENT S：* OK [UNSEEN 12]メッセージ12最初の目に見えないSである：* OK [UIDVALIDITY 3857529045]のUID有効S：* OK [UIDNEXT 4392】次に予測UID S：* FLAGS（\答える\フラグ付き\削除\見\ドラフト）S：* OK [PERMANENTFLAGS（\見\答える\フラグ付き\ *）] LS：A142 OK [読み書き]を完了C SELECT：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:
より良いクライアントMAYパイプラインは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
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で変更された場合、選択された状態に固有のコマンドようにメールボックスが、選択されたメールボックスに持っている権利をキャッシュすることができる（例えば、STORE、EXPUNGE）が反映されない場合がありますメールボックスが再選択されるまでの権限を変更しました。サーバは各コマンドの権利をチェックした場合、彼らは変更されている場合、それはFLAGSとPERMANENTFLAGS応答を送るべきです。そのようなサーバは、もはやユーザーがメールボックスへのアクセスを読んでいないことを検出した場合は、タグなしBYE応答と密接な接続を送るかもしれません。また、メールボックスが閉じるまで選択状態に固有のすべてのコマンドを実行するために拒否することができます。ただし、サーバーの実装者は、ほとんどのクライアントは非常によく、NOの応答を処理しませんので注意してください。
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つ以上の識別子のための1つ以上のACLを変更してもよいです。サーバーはそれをした場合、それが行われた変更についてクライアントに通知するために、タグなし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.
[IMAP4]のセクション5.5に記載されているようにACLサーバの実装は、ACLによって影響を受ける後続のコマンドに対する可能曖昧としてACL変更コマンドを受信した扱わなければなりません。したがって、パイプラインSETACL + MYRIGHTSサーバがMYRIGHTS前に完了するSETACLコマンドを実行しなければならないことを意味し、サーバに対して曖昧です。ただし、クライアントは、このようなパイプラインを送ることが許可されています。
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
次の要件は、将来的な拡張を可能にするために、クライアントに置かれています。ユーザーがACLを読んで、更新することができ、クライアントの実装では、それは、ユーザーが変更することはできません認識されない権利を保存しなければなりません。つまり、クライアントの場合
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）ACLを読むことができるし、2）のACLを更新することができますが、3）ユーザーは、クライアントが認識されない権利を変更することはできません、それは認識されていない権利を保存しなければなりません。
Otherwise the client could risk unintentionally removing permissions it doesn't understand.
そうでなければ、クライアントはそれを理解していない権限を削除する意図せずに危険にさらす可能性があります。
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」）付与することができたときの「共有のマルチユーザアクセス」と「共有マルチユーザの書き込みアクセス」を示すものとします。
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：メールボックス「バナンは」「共有マルチユーザの書き込みアクセス」を可能にし、\回答フラグを\削除され、実装、および共有のフラグとして$ MDNSent。メールボックス（削除済み\システムフラグが右の「t」を必要とするため）「バナンは」「T」フラグを含む集合であり、「W」は、「フラグ権を共有」（\答えて$の両方のためには、右の「W」が必要ですMDNSent）。
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：メールボックスの「りんご」の共有フラグとして、システムフラグを見て、\「共有マルチユーザの書き込みアクセス」と実装することができます。見たシステムフラグ\は、右の「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：メールボックスの「梨」を「共有マルチユーザの書き込みアクセス」を可能にし、フラグ\共有フラグと見られ、\ドラフトを実装しています。 （システムフラグ\ドラフトは、右の「W」必要があるため）（見たシステムフラグ\は、右の「s」を必要とするため）、「りんご」はフラグを含む集合「S」であるメールボックスの「フラグ権を共有」と「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-ONLY応答コードを含める必要があります。
"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」のいずれか、または「共有フラグ権利」（***）は、現在のユーザーに付与されている場合、サーバは、タグ付けされたOK応答して読み取りと書き込み応答コードを含むべきです。
(***) 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」メールボックス「バナン」の権限を持つユーザー。サーバ・リターンはREAD-ONLY SELECTでの応答コードを、「iewt」権利のどれもがユーザーに付与されませんよう。
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」権限を持つユーザー。サーバーが返すSELECTでの読み書きの応答コード、ユーザーが持っているとして、「I」右。
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レスポンスコードを返します。
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自体が適切に制限ACLを持つメールボックスに関する情報を与えていないコマンドを確認する必要があります。ユーザーエージェントは、ユーザーがリストに何の権限を持っていないことをメールボックスにGETACLコマンドを実行したときにたとえば、サーバーは、このように何の存在情報を明らかにしない、メールボックスが存在しなかった場合に使用されるのと同じエラーでその要求に応答することになります、はるかに少ないメールボックスの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".
ACLを変更することができますACLを実装するIMAPクライアントには特別な識別子「誰」へのフルアクセス（あるいは単に「」右）を与えたいユーザーに警告すべきです。
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 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.
このドキュメントは、識別子の正規化（準備）を行うために必要な手順を説明するために、[SASLprep]に依存しています。 SASLprepで準備アルゴリズムは、具体的には、その出力が正規であるように設計され、それが十分に形成されました。しかし、Unicode正規化の仕様の異常[PR29]に、標準的な同値は、選ばれた少数の文字配列について保証するものではありません。 SASLprepを用いて調製した識別子が格納されているとACLサーバによって返すことができます。異常が選択した文字列を含む識別子のACL操作や評価に影響を与えます。これらの配列は、しかし、よく形成されたテキストには表示されません。この問題に対処するために、ACLサーバがタグ付けされたBAD応答を送信することにより、[PR29]に記載の配列を含む識別子を拒否することができます。これは、第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コマンドにおけるプライバシー保護、または他の保護メカニズムを交渉しました。
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
LOWER-ALPHA =％x61-7A ;; -Z
acl-data = "ACL" SP mailbox *(SP identifier SP rights)
ACL-データ= "ACL" SPメールボックス*（SP識別子SP権）
capability =/ rights-capa ;;capability is defined in [IMAP4]
能力= /権利CAPA ;;能力が定義されている[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
getfaclの= "は、setfacl" SPメールボックス
identifier = 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権）
mailbox-data =/ acl-data / listrights-data / myrights-data ;;mailbox-data is defined in [IMAP4]
メールボックスデータ= / ACLデータ/ LISTRIGHTSデータ/ MYRIGHTSデータ;;メールボックスデータは[IMAP4]で定義されています
mod-rights = astring ;; +rights to add, -rights to remove ;; rights to replace
MOD-権=のAString ;; +追加する権利を、削除する-rights ;;交換する権利
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-ALPHA新しい権利;; "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
権利-CAPA = "権利=" 新しい権利;;権利= ...機能
setacl = "SETACL" SP mailbox SP identifier SP mod-rights
SETACL = "SETACL" SPメールボックスSP識別子SP modの権利
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
ｈっｔｐ：／／ｗっｗ。いあな。おｒｇ／あっしｇんめんｔｓ／いまｐ４ーかぱびぃちえｓ
This document defines the RIGHTS= IMAP capability. IANA has added this capability to the registry.
この文書は、権利= IMAP機能を定義します。 IANAは、レジストリにこの機能を追加しました。
Section 3 states requirements on servers regarding internationalization of identifiers.
第3節では、識別子の国際化に関するサーバー上の要求事項を記載しています。
Appendix A. Changes since
付録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. UTF-8にUS-ASCIIから "識別子" の文字セットを変更しました。 2.メールボックスの削除は「×」、右によって制御され、EXPUNGEは、右の「e」によって制御されていることを指定します。 3. STORE \削除さを制御し、「T」権利を追加しました。 「E」、「T」のマクロ、およびおそらく「X」と「D」の権利を再定義します。 4. CREATE制御「K」権利を追加しました。 「K」のためのマクロおよびおそらく「X」と「C」の権利を再定義します。 5.「」右もDELETEACLを制御することを指定します。 6.「R」は、右もSTATUSを制御することを指定します。これはSELECTのために必要とされるように7が、CHECKのための「R」権利をチェックし検索やFETCHするための要件を削除/成功するために調べます。 8. LISTRIGHTSは（SETACLと同じ）メールボックスの「」権利を必要とします。 9.「PARTIAL」を削除し、これがAPPENDに見て、\削除された\以外のフラグを設定する「W」、右コントロールすることを指定されたRFC 1730 10の廃止予定の機能です。また、「s」は右\見フラグを制御し、「t」は右\ Deletedフラグを制御することを指定しました。 11.右の「R」で許可されていないSUBSCRIBE指定されています。 12.「L」、右のコントロールがSUBSCRIBEことを指定します。 13. GETACLはそれを可能にするいくつかの実装があるにもかかわらず、「R」、右に許可されていません。ユーザーは唯一の「R」権利を持っている場合、GETACLは、メールシステム上で既存の識別子に関する情報を開示することができます。 14. RENAMEは、右の古い名の右の新しい親のための「K」と「X」を必要とすることを明らかにしました。 15.様々なIMAPコマンドを実行するときに必要および/またはチェックされる権利を説明し、新しいセクションを追加しました。 16.追加されたメールクライアントのセキュリティの考慮事項は、特別な識別子「誰」を扱うとき。 17.否定権はDELETEACLと同じではないことを明らかにしました。 18.セクション「RFC 2086との互換性」を追加しました。読み書きやREAD-ONLY応答コードをするためにACL権のマッピングについて19セクションを追加。 20. ABNFにBNFを変更しました。 21.「実装の注意事項」のセクションを追加しました。 22.更新「参考文献」セクション。 23.より多くの例を追加しました。明確化24.時に仮想「C」と「D」の権限がACL、MYRIGHTSで返されており、LISTRIGHTS応答。
Appendix B. Compatibility with
と付録B.互換性
This non-normative section gives guidelines as to how an existing RFC 2086 server implementation may be updated to comply with this document.
この非標準のセクションでは、既存のRFC 2086のサーバーの実装は、この文書に準拠するように更新することができる方法についてのガイドラインを示します。
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」は右後方互換性のために残っているが、それは仮想的権利です。 「D」右、それを交換した新しい権利を処理するために、RFC 2086のサーバーの実装のための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を右MYRIGHTS応答またはACL応答にD "" RETURN"。 「T」、「E」（「×」）のいずれかが付与されたときにACL情報を含みます。
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」は右後方互換性のために残っているが、それは仮想的権利です。ここでも、RFC 2086枚のサーバーの実装は、前述したように、権利を結び付けるために、または別個の権利を実装することを選択することができます。
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.
また、必要なその他の変更を確認するために、付録Aだけでなく、セクション5.1.1および5.1.2をご確認ください。サーバーの実装者は、第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」拡張子の下位互換性の制約なしに、これらの欠陥に対処するために、この拡張機能を再設計することを意図しており、最終的にはこの機能に優先します。
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.
しかし、RFC 2086は、下位互換性の方法で簡単な欠陥を修正し、この中間工程、ように複数の実装に配備され、価値があると考えられます。
Appendix D. Acknowledgements
付録D.謝辞
This document is a revision of RFC 2086 written by John G. Myers.
この文書では、ジョン・G.マイヤーズによって書かれたRFC 2086の改訂版です。
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.
エディタはマーク・クリスピン、クリス・ニューマン、サイラスDaboo、ジョン・G.マイヤーズ、デイブCridland、ケンマーチソン、スティーブ・ホール、ウラジミールButenko、ラリー・グリーンフィールド、ロバートSiemborski、Harrie Hazewinkel、フィリップ・ギュンター、ブライアン・キャンドラー、カーティス・キング、リンドンから寄せられたコメントを高く評価しますNerenberg、リサDusseault、ARNT Gulbrandsenの、そしてIMAPEXTワーキンググループの他の参加者。
Normative References
引用規格
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[ABNF]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[IMAP4] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.
[IMAP4]クリスピン、M.、 "インターネットメッセージアクセスプロトコル - バージョン4rev1"、RFC 3501、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、ISO 10646の変換フォーマット"、STD 63、RFC 3629、2003年11月。
[Stringprep] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.
"（文字列準備 "）"、RFC 3454、2002年12月【のstringprep]ホフマン、P.及びM.ブランシェ、国際化された文字列の準備"。
[SASLprep] Zeilenga, K., "SASLprep: Stringprep Profile for User Names and Passwords", RFC 4013, February 2005.
[SASLprep] Zeilenga、K.、 "SASLprep：ユーザ名とパスワードのためのstringprepプロフィール"、RFC 4013、2005年2月。
Informative References
参考文献
[RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997.
[RFC2086]マイヤーズ、J.、 "IMAP4 ACL拡張"、RFC 2086、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/review/pr-29.html>。
Author's Address
著者のアドレス
Alexey Melnikov Isode Ltd. 5 Castle Business Village 36 Station Road Hampton, Middlesex TW12 2BX GB
アレクセイ・メルニコフISODE株式会社5キャッスルビジネス村の36の駅道ハンプトン、ミドルTW12 2BX GB
EMail: alexey.melnikov@isode.com
メールアドレス：alexey.melnikov@isode.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
著作権（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.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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は、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
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リポジトリから。
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機能のための基金は現在、インターネット協会によって提供されます。