RFC5257 日本語訳
5257 Internet Message Access Protocol - ANNOTATE Extension. C. Daboo,R. Gellens. June 2008. (Format: TXT=58786 bytes) (Status: EXPERIMENTAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group C. Daboo
Request for Comments: 5257 Apple Inc.
Category: Experimental R. Gellens
QUALCOMM Incorporated
June 2008
Dabooがコメントのために要求するワーキンググループC.をネットワークでつないでください: 5257年のアップル株式会社カテゴリ: 2008年6月の法人組織の実験的なR.Gellensクアルコム
Internet Message Access Protocol - ANNOTATE Extension
インターネットメッセージアクセス・プロトコル--拡大を注釈してください。
Status of This Memo
このメモの状態
This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのためにExperimentalプロトコルを定義します。 それはどんな種類のインターネット標準も指定しません。 議論と改善提案は要求されています。 このメモの分配は無制限です。
Abstract
要約
The ANNOTATE extension to the Internet Message Access Protocol permits clients and servers to maintain "meta data" for messages, or individual message parts, stored in a mailbox on the server. For example, this can be used to attach comments and other useful information to a message. It is also possible to attach annotations to specific parts of a message, so that, for example, they could be marked as seen, or important, or a comment added.
インターネットMessage AccessプロトコルへのANNOTATE拡張子は、クライアントとサーバがメッセージのための「メタデータ」、またはサーバにメールボックスの中に保存された個々のメッセージの部品を維持することを許可します。例えば、コメントと他の役に立つ情報をメッセージに添付するのにこれは使用できます。 また、メッセージの特定の部分に注釈を付けるのも可能です、例えば、見られる、重要であるとしてそれらをマークできたか、またはコメントが加えたように。
Note that this document was the product of a WG that had good consensus on how to approach the problem. Nevertheless, the WG felt it did not have enough information on implementation and deployment hurdles to meet all of the requirements of a Proposed Standard. The IETF solicits implementations and implementation reports in order to make further progress.
このドキュメントがどう問題にアプローチするかに関する良いコンセンサスを持っていたWGの製品であったことに注意してください。 それにもかかわらず、WGは、それには実装と展開ハードルのProposed Standardの要件のすべてに会うことができるくらいの情報がなかったと感じました。 IETFは、一段と進歩するように実装と実装レポートに請求します。
Implementers should be aware that this specification may change in an incompatible manner when going to Proposed Standard status. However, any incompatible changes will result in a new capability name being used to prevent problems with any deployments of the experimental extension.
ImplementersはProposed Standard状態に行くとき、この仕様が両立しない方法で変化するかもしれないのを意識しているべきです。 しかしながら、どんな非互換な変化も、実験的な拡大のどんな展開に関する問題も防ぐのに使用されることで新しい能力名をもたらすでしょう。
Daboo & Gellens Experimental [Page 1] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[1ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
Table of Contents
目次
1. Introduction and Overview .......................................3
2. Conventions Used in This Document ...............................4
3. Data Model ......................................................4
3.1. Overview ...................................................4
3.2. Namespace of Entries and Attributes ........................4
3.2.1. Entry Names .........................................5
3.2.2. Attribute Names .....................................7
3.3. Private Versus Shared ......................................7
3.4. Access Control .............................................8
3.5. Access to Standard IMAP Flags and Keywords ................11
4. IMAP Protocol Changes ..........................................11
4.1. General Considerations ....................................11
4.2. ANNOTATE Parameter with the SELECT/EXAMINE Commands .......12
4.3. ANNOTATION Message Data Item in FETCH Command .............12
4.4. ANNOTATION Message Data Item in FETCH Response ............14
4.5. ANNOTATION Message Data Item in STORE .....................16
4.6. ANNOTATION Interaction with COPY ..........................18
4.7. ANNOTATION Message Data Item in APPEND ....................18
4.8. ANNOTATION Criterion in SEARCH ............................19
4.9. ANNOTATION Key in SORT ....................................20
4.10. New ACL Rights ...........................................21
5. Formal Syntax ..................................................21
6. IANA Considerations ............................................23
6.1. Entry and Attribute Registration Template .................23
6.2. Entry Registrations .......................................24
6.2.1. /comment ...........................................24
6.2.2. /flags .............................................24
6.2.3. /altsubject ........................................25
6.2.4. /<section-part>/comment ............................25
6.2.5. /<section-part>/flags/seen .........................26
6.2.6. /<section-part>/flags/answered .....................26
6.2.7. /<section-part>/flags/flagged ......................27
6.2.8. /<section-part>/flags/forwarded ....................27
6.3. Attribute Registrations ...................................28
6.3.1. value ..............................................28
6.3.2. size ...............................................28
6.4. Capability Registration ...................................28
7. Internationalization Considerations ............................29
8. Security Considerations ........................................29
9. References .....................................................29
9.1. Normative References ......................................29
9.2. Informative References ....................................30
10. Acknowledgments ...............................................30
1. 序論と概要…3 2. このドキュメントで中古のコンベンション…4 3. データはモデル化されます…4 3.1. 概要…4 3.2. エントリーと属性の名前空間…4 3.2.1. 入口名…5 3.2.2. 名前を結果と考えてください…7 3.3. 共有にされるに対して個人的…7 3.4. コントロールにアクセスしてください…8 3.5. 旗とキーワードに標準のIMAPにアクセスしてください…11 4. IMAPは変化について議定書の中で述べます…11 4.1. 一般問題…11 4.2. 選んだ/審査コマンドでパラメタを注釈してください…12 4.3. とって来コマンドにおける注釈メッセージデータ項目…12 4.4. フェッチ応答における注釈メッセージデータ項目…14 4.5. 用意して注釈メッセージデータ項目…16 4.6. コピーとの注釈相互作用…18 4.7. データ項目が中に追加する注釈メッセージ…18 4.8. 検索における注釈評価基準…19 4.9. 種類で主要な注釈…20 4.10. 新しいACLはまっすぐになります…21 5. 正式な構文…21 6. IANA問題…23 6.1. エントリーと属性登録テンプレート…23 6.2. エントリー登録証明書…24 6.2.1. /コメント…24 6.2.2. /は弛みます…24 6.2.3. /altsubject…25 6.2.4. /<部部分>/コメント…25 6.2.5. 見られた/<部パート>/flags/…26 6.2.6. /<部パート>/flags/に答えました…26 6.2.7. /<部パート>/flags/は弛みました…27 6.2.8. >/flags/が進めた/<部部分…27 6.3. 登録証明書を結果と考えてください…28 6.3.1値…28 6.3.2サイズ…28 6.4. 能力登録…28 7. 国際化問題…29 8. セキュリティ問題…29 9. 参照…29 9.1. 標準の参照…29 9.2. 有益な参照…30 10. 承認…30
Daboo & Gellens Experimental [Page 2] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[2ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
1. Introduction and Overview
1. 序論と概要
The ANNOTATE extension is present in any IMAP [RFC3501] implementation that returns "ANNOTATE-EXPERIMENT-1" as one of the supported capabilities in the CAPABILITY response.
ANNOTATE拡張子が戻るどんなIMAP[RFC3501]実装でも存在している、「実験1インチを注釈する、能力応答におけるサポートしている能力の1つ、」
This extension makes the following changes to the IMAP protocol:
この拡大はIMAPプロトコルへの以下の変更を行います:
a. adds a new ANNOTATION message data item for use in FETCH.
a. FETCHにおける使用のために新しいANNOTATIONメッセージデータ項目を加えます。
b. adds a new ANNOTATION message data item for use in STORE.
b. ストアでの使用のために新しいANNOTATIONメッセージデータ項目を加えます。
c. adds a new ANNOTATION search criterion for use in SEARCH.
c. 検索における使用のために新しいANNOTATION検索評価基準を加えます。
d. adds a new ANNOTATION sort key for use in the SORT extension.
d. SORT拡張子における使用のために新しいANNOTATION分類用キーを加えます。
e. adds a new ANNOTATION data item for use in APPEND.
e. APPENDにおける使用のために新しいANNOTATIONデータ項目を加えます。
f. adds a new requirement on the COPY command.
f. COPYコマンドに関する新しい要件を加えます。
g. adds a new ANNOTATE parameter for use with the SELECT/EXAMINE
commands.
g. SELECT/EXAMINEコマンドで使用のための新しいANNOTATEパラメタを加えます。
h. adds two new response codes to indicate store failures of
annotations.
h. 示す2つの新しい応答コードが注釈の失敗を保存すると言い足します。
i. adds a new untagged response code for the SELECT or EXAMINE
commands to indicate the maximum sized annotation that can be
stored.
i. SELECTか最大が保存できる注釈を大きさで分けたのを示すEXAMINEコマンドのために新しい非タグ付けをされた応答コードを加えます。
j. adds a new Access Control List (ACL) "bit" for use with the ACL
extensions [RFC2086] and [RFC4314].
j. 使用のためにACL拡張子[RFC2086]と[RFC4314]で新しいAccess Control List(ACL)「ビット」を加えます。
The data model used for the storage of annotations is based on the Application Configuration Access Protocol [RFC2244]. Note that there is no inheritance in annotations.
注釈のストレージに使用されるデータモデルはApplication Configuration Accessプロトコル[RFC2244]に基づいています。 注釈には継承が全くないことに注意してください。
If a server supports annotations, then it MUST store all annotation data permanently, i.e., there is no concept of "session only" annotations that would correspond to the behavior of "session" flags as defined in the IMAP base specification.
サーバが注釈をサポートするなら、永久にすべての注釈データを保存しなければなりません、すなわち、IMAP基礎仕様に基づき定義されるように「セッション」旗の働きに対応する「セッション専用」注釈の概念が全くありません。
In order to provide optimum support for a disconnected client (one that needs to synchronize annotations for use when offline), servers SHOULD also support the Conditional STORE [RFC4551] extension.
また、切断しているクライアント(オフラインであることのときに、使用のための注釈を同時にさせる必要があるもの)の最適なサポートを提供するために、サーバSHOULDは、Conditionalがストア[RFC4551]拡大であるとサポートします。
The rest of this document describes the data model and protocol changes more rigorously.
このドキュメントの残りはデータモデルとプロトコル変化について、よりきびしく説明します。
Daboo & Gellens Experimental [Page 3] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[3ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
2. Conventions Used in This Document
2. 本書では使用されるコンベンション
The examples in this document use "C:" and "S:" to indicate lines sent by the client and server, respectively.
これの例が使用を記録する、「C:」 そして、「S:」 クライアントとサーバによってそれぞれ送られた系列を示すために。
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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
3. Data Model
3. データモデル
3.1. Overview
3.1. 概要
The data model for annotations in ANNOTATE uses a uniquely named entry that contains a set of standard attributes. Thus, a single coherent unit of "meta data" for a message is stored as a single entry, made up of several attributes.
ANNOTATEの注釈のためのデータモデルは1セットの標準の属性を含む唯一命名されたエントリーを使用します。 したがって、メッセージのための「メタデータ」の単一の一貫性を持っている単位はいくつかの属性で作られた単一のエントリーとして保存されます。
For example, a comment annotation added to a message has an entry name of "/comment". This entry is composed of several attributes such as "value", "size", etc., that contain the properties and data of the entry.
「例えば、メッセージに追加されたコメント注釈は」 /コメントの入口名を持っています。」 このエントリーは「値」、エントリーに関する特性とデータを含む「サイズ」などのいくつかの属性で構成されます。
The protocol changes to IMAP, described below, allow a client to access or change the values of any attribute in any entry in a message annotation, assuming it has sufficient access rights to do so (see Section 3.4 for specifics).
クライアントは、以下で説明されたIMAPへのプロトコル変化で、メッセージ注釈におけるどんなエントリーでも、どんな属性の値もアクセスするか、または変えます、それにはそうすることができるくらいのアクセス権がある(詳細に関してセクション3.4を見る)と仮定して。
3.2. Namespace of Entries and Attributes
3.2. エントリーと属性の名前空間
A message may contain zero or more annotations, each of which is a
single uniquely named entry. Each entry has a hierarchical name,
with each component of the name separated by a slash ("/"). An entry
name MUST NOT contain two consecutive "/" characters and MUST NOT end
with a "/" character.
メッセージはゼロか、より多くの注釈を含むかもしれません。それはそれぞれ単一の唯一命名されたエントリーです。 各エントリーには、スラッシュ(「/」)によって切り離される名前のそれぞれの成分の階層的な名前があります。 「入口名が2を含んではいけない、連続、」 /、」 キャラクタと必須はa」/で」 キャラクタを終わらせません。
Each entry is made up of a set of attributes. Each attribute has a
hierarchical name, with each component of the name separated by a
period ("."). An attribute name MUST NOT contain two consecutive "."
characters and MUST NOT end with a "." character.
各エントリーは1セットの属性で作られます。 期間までに切り離される名前のそれぞれの成分の階層的な名前が各属性にある、(「」、)。 「属性名が2を含んではいけない、連続、」 . 」 キャラクタと必須はa」 」 キャラクタと共に終わりません。
The value of an attribute is "NIL" (has no value), or is a string of zero or more octets.
属性の値は、「無い」か(値を全く持っていません)、一連のゼロであるか以上は八重奏です。
Entry and attribute names MUST NOT contain asterisk ("*") or percent
("%") characters, and MUST NOT contain non-ASCII characters or the
NULL octet. Invalid entry or attribute names result in a BAD
response in any IMAP commands where they are used.
エントリーと属性名は、アスタリスク(「*」)かパーセント(「%」)キャラクタを含んではいけなくて、非ASCII文字かヌル八重奏は含んではいけません。 無効のエントリーか属性名がそれらが使用されているどんなIMAPコマンドでもBAD応答をもたらします。
Daboo & Gellens Experimental [Page 4] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[4ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
Attribute names MUST NOT contain any hierarchical components with the names "priv" or "shared", as those have special meaning (see Section 3.3).
"priv"という名前があるどんな階層的なコンポーネントも含んではいけない、さもなければ、属性名は、「共有されました」、ものに特別な意味があるとき(セクション3.3を見てください)。
Entry and attribute names are case-sensitive.
エントリーと属性名は大文字と小文字を区別しています。
Use of control or punctuation characters in entry and attribute names is strongly discouraged.
エントリーにおけるコントロールか句読文字と属性名の使用は強くお勧めできないです。
This specification defines an initial set of entry and attribute names available for use in message annotations. In addition, an extension mechanism is described to allow additional names to be added as needed.
この仕様は1人の始発のエントリーとメッセージ注釈における使用に利用可能な属性名を定義します。 さらに、拡張機能は、追加名前が必要に応じて加えられるのを許容するために説明されます。
3.2.1. Entry Names
3.2.1. 入口名
Entry names MUST be specified in a standards track or IESG approved experimental RFC, or fall under the vendor namespace. See Section 6.1 for the registration template.
標準化過程で入口名を指定しなければならないか、またはIESGは実験的なRFCを承認するか、ベンダー名前空間の下で落ちます。 登録テンプレートのためにセクション6.1を見てください。
/
Defines the top-level of entries associated with an entire
message. This entry itself does not contain any attributes. All
entries that start with a numeric character ("0" - "9") refer to
an annotation on a specific body part. All other entries are for
annotations on the entire message.
/は全体のメッセージに関連しているエントリーのトップレベルを定義します。 このエントリー自体はどんな属性も含んでいません。 数字から始まるすべてのエントリー、(「0インチ--、「9インチ) 特定の身体の部分における注釈を参照してください、」 他のすべてのエントリーが全体のメッセージにおける注釈のためのものです。
/comment
Defines a comment or note associated with an entire message.
コメントか注意が全体のメッセージに関連づけた/コメントDefines。
/flags
This entry hierarchy is reserved for future use.
/旗Thisエントリー階層構造は今後の使用のために予約されます。
/altsubject
Contains text supplied by the message recipient to be used by the
client, instead of the original message Subject.
オリジナルのメッセージSubjectの代わりにクライアントによって使用されるようにメッセージ受取人によって供給された/altsubject Containsテキスト。
/vendor/<vendor-token>
Defines the top-level of entries associated with an entire message
as created by a particular product of some vendor. These sub-
entries can be used by vendors to provide client-specific
annotations. The vendor-token MUST be registered with IANA, using
the [RFC2244] vendor subtree registry.
トップレベルのエントリーが、あるベンダーの特定の製品によって作成されるように全体のメッセージに関連づけた/vendor/<ベンダートークン>Defines。 ベンダーは、クライアント特有の注釈を提供するのにこれらのサブエントリーを使用できます。 [RFC2244]ベンダー下位木登録を使用して、ベンダートークンをIANAに登録しなければなりません。
/<section-part>
Defines the top-level of entries associated with a specific body
part of a message. This entry itself does not contain any
attributes. The section-part is a numeric part specifier. Its
トップレベルのエントリーがメッセージの特定の身体の部分に関連づけた/<部パート>Defines。 このエントリー自体はどんな属性も含んでいません。 セクション一部が数値部分特許説明書の作成書です。 それ
Daboo & Gellens Experimental [Page 5] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[5ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
syntax is the same as the section-part ABNF element defined in
[RFC3501]. The server MUST return a BAD response if the client
uses an incorrect part specifier (either incorrect syntax or a
specifier referring to a non-existent part). The server MUST
return a BAD response if the client uses an empty part specifier
(which is used in IMAP to represent the entire message).
構文は[RFC3501]で定義されたセクション一部ABNF要素と同じです。 クライアントが不正確な部分特許説明書の作成書(実在しない部分について言及する不正確な構文か特許説明書の作成書のどちらか)を使用するなら、サーバはBAD応答を返さなければなりません。 クライアントが空の部分特許説明書の作成書(全体のメッセージを表すのにIMAPで使用される)を使用するなら、サーバはBAD応答を返さなければなりません。
/<section-part>/comment
Defines a comment or note associated with a specific body part of
a message.
コメントか注意がメッセージの特定の身体の部分に関連づけた/<部パート>/コメントDefines。
/<section-part>/flags
Defines the top-level of entries associated with the flag state
for a specific body part of a message. All sub-entries are
maintained entirely by the client. There is no implicit change to
any flag by the server.
トップレベルのエントリーがメッセージの特定の身体の部分のために旗国に関連づけた/<部パート>/旗のDefines。 すべてのサブエントリーが完全にクライアントによって維持されます。 サーバによるどんな旗へのどんな内在している変化もありません。
/<section-part>/flags/seen
This is similar to the IMAP \Seen flag, except it applies
to only the body part referenced by the entry.
/<部パート>/flags/seen ThisはSeenが旗を揚げさせるIMAP\と同様であり、それを除いて、エントリーで参照をつけられる身体の部分だけに適用します。
/<section-part>/flags/answered
This is similar to the IMAP \Answered flag, except it
applies to only the body part referenced by the entry.
/<部パート>/flags/answered ThisはAnsweredが旗を揚げさせるIMAP\と同様であり、それを除いて、エントリーで参照をつけられる身体の部分だけに適用します。
/<section-part>/flags/flagged
This is similar to the IMAP \Flagged flag, except it
applies to only the body part referenced by the entry.
/<部パート>/flags/flagged ThisはFlaggedが旗を揚げさせるIMAP\と同様であり、それを除いて、エントリーで参照をつけられる身体の部分だけに適用します。
/<section-part>/flags/forwarded
This is similar to the IMAP $Forwarded keyword, except it
applies to only the body part referenced by the entry.
/<部パート>/flags/forwarded ThisはIMAP$Forwardedキーワードと同様であり、それを除いて、エントリーで参照をつけられる身体の部分だけに適用します。
Defines flags for a specific body part of a message. The "value"
attribute of each of the entries described above must be either
"1", "0", or "NIL". "1" corresponds to the flag being set.
メッセージの特定の身体の部分と旗を定義します。 上で説明されたそれぞれのエントリーの「値」属性がどちらかであるに違いない、「1インチか、「0インチ、または「無」。」 「1インチは設定される旗に対応しています。」
/<section-part>/vendor/<vendor-token>
Defines the top-level of entries associated with a specific body
part of a message as created by a particular product of some
vendor. This entry can be used by vendors to provide client
specific annotations. The vendor-token MUST be registered with
IANA.
トップレベルのエントリーが、あるベンダーの特定の製品によって作成されるようにメッセージの特定の身体の部分に関連づけた/<部パート>/vendor/<ベンダートークン>Defines。 ベンダーは、特定の注釈をクライアントに提供するのにこのエントリーを使用できます。 ベンダートークンをIANAに登録しなければなりません。
Daboo & Gellens Experimental [Page 6] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[6ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
3.2.2. Attribute Names
3.2.2. 属性名
Attribute names MUST be specified in a standards track or IESG approved experimental RFC. See Section 6.1 for the registration template.
標準化過程で属性名を指定しなければならない、さもなければ、IESGは実験的なRFCを承認しました。 登録テンプレートのためにセクション6.1を見てください。
All attribute names implicitly have a ".priv" and a ".shared" suffix that maps to private and shared versions of the entry. Searching or fetching without using either suffix will include both. The client MUST specify either a ".priv" or ".shared" suffix when storing an annotation or sorting on annotations.
すべての属性名には、それがエントリーの個人的で共有されたバージョンに写像する".priv"と".shared"接尾語がそれとなくあります。 どちらの接尾語も使用することのない探すかとって来るのが両方を含むでしょう。 注釈のときに注釈かソーティングを保存するとき、クライアントは".priv"か".shared"接尾語を指定しなければなりません。
value
A string or binary data representing the value of the annotation.
To delete an annotation, the client can store "NIL" into the
value. If the client requests the value attribute for a non-
existent entry, then the server MUST return "NIL" for the value.
The content represented by the string is determined by the
content-type used to register the entry (see Section 6.1 for entry
registration templates). Where applicable, the registered
content-type MUST include a charset parameter. Text values SHOULD
use the utf-8 [RFC3629] character set. Note that binary data
(data which may contain the NULL octet) is allowed (e.g., for
storing images), and this extension uses the "literal8" syntax
element [RFC4466] to allow such data to be written to or read from
the server.
注釈の値を表す五弦かバイナリ・データを評価してください。 注釈を削除するために、クライアントは「無」を値として保存できます。 クライアントが非目下のエントリーに値の属性を要求するなら、サーバは値のためのリターン「無」がそうしなければなりません。 ストリングによって表された内容はエントリーを登録するのに使用されるcontent typeで決定します(エントリー登録テンプレートのためにセクション6.1を見てください)。 適切であるところでは、登録されたcontent typeがcharsetパラメタを含まなければなりません。 テキスト値のSHOULDはutf-8[RFC3629]文字集合を使用します。 バイナリ・データ(NULL八重奏を含むかもしれないデータ)が許容されていて(例えば、イメージを保存するために)、この拡大が「サーバからそのようなデータが書かれているのを許容するか、または読み込むliteral8"構文要素[RFC4466]」を使用することに注意してください。
size
The size of the value, in octets. Set automatically by the
server, read-only to clients. If the client requests the size
attribute for a non-existent entry, then the server MUST return
"0" (zero) for the size.
サイズ、八重奏における、価値のサイズ。 サーバ、クライアントへの書き込み禁止で自動的にセットしてください。 クライアントが実在しないエントリーにサイズ属性を要求するなら、サーバは「サイズのための0インチ(ゼロ)」を返さなければなりません。
3.3. Private Versus Shared
3.3. 共有にされるに対して個人的です。
Some IMAP mailboxes are private, accessible only to the owning user. Other mailboxes are not, either because the owner has set an ACL [RFC4314] that permits access by other users, or because it is a shared mailbox.
所有しているユーザだけに、いくつかのIMAPメールボックスが、個人的であって、アクセスしやすいです。 他のメールボックスはそうではありません、所有者が他のユーザでアクセスを許可するACL[RFC4314]を設定したか、それが共有されたメールボックスであるので。
This raises the issue of shared versus private annotations.
これは個人的な注釈に対して共有されることの問題を提起します。
If all annotations are private, it is then impossible to have annotations in a shared or otherwise non-private mailbox be visible to other users. This eliminates what could be a useful aspect of annotations in a shared environment. An example of such use is a shared IMAP folder containing bug reports. Engineers may want to use
すべての注釈が個人的であるなら、他のユーザにとって、共有されたかそうでなければ、非個人的なメールボックスにおける注釈が目に見えるのを持っているのは不可能です。 これは共有された環境における注釈の役に立つ局面であるかもしれないことを排除します。 そのような使用に関する例はバグレポートを含む共有されたIMAPフォルダーです。 技術者は使用に欲しいかもしれません。
Daboo & Gellens Experimental [Page 7] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[7ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
annotations to add information to existing messages, indicate assignments, status, etc. This use requires shared annotations.
既存のメッセージに情報を追加して、課題、状態を示すなど注釈 この使用は共有された注釈を必要とします。
If all annotations are shared, it is impossible to use annotations for private notes on messages in shared mailboxes. Also, modifying an ACL to permit access to a mailbox by other users may unintentionally expose private information.
すべての注釈が共有されるなら、共有されたメールボックスの中のメッセージに関する私募債に注釈を使用するのは不可能です。 また、他のユーザでメールボックスへのアクセスを可能にするようにACLを変更すると、個人情報は何気なく暴露するかもしれません。
There are also situations in which both shared and private annotations are useful. For example, an administrator may want to set shared annotations on messages in a shared folder, which individual users may wish to supplement with additional notes.
共有されたものと同様に個人的な注釈が役に立つ状況もあります。 例えば、管理者は共有フォルダのメッセージに共有された注釈を設定したがっているかもしれません。(個々のユーザは共有フォルダを補注を補いたがっているかもしれません)。
If shared and private annotations are to coexist, we need a clear way to differentiate them. Also, it should be as easy as possible for a client to access both and not overlook either. There is also a danger in allowing a client to store an annotation without knowing if it is shared or private.
共有されて個人的な注釈が共存することであるなら、私たちはそれらを差別化する明確な方法を必要とします。 また、クライアントが両方にアクセスして、どちらも見落とさないのも、できるだけ簡単であるはずです。 また、それが共有されているか、または個人的であるかを知らないクライアントが注釈を保存するのを許容するのにおいて危険があります。
This document proposes two standard suffixes for all attributes: ".shared" and ".priv". A SEARCH or FETCH command that specifies neither, uses both. STORE, APPEND, and SORT commands MUST explicitly use ".priv" or ".shared" suffixes.
このドキュメントはすべての属性のために2つの標準の接尾語を提案します: ".shared"と".priv"。 検索かどちらも指定しないFETCHコマンド、用途の両方。 ストア、APPEND、およびSORTコマンドは明らかに".priv"か".shared"接尾語を使用しなければなりません。
If the ANNOTATE extension is present, support for shared annotations in servers is REQUIRED, while support for private annotations in servers is OPTIONAL. This recognizes the fact that support for private annotations may introduce a significant increase in complexity to a server in terms of tracking ownership of the annotations, how quota is determined for users based on their own annotations, etc. Clients that support the ANNOTATE extension MUST handle both shared and private annotations.
ANNOTATE拡張子が存在しているなら、サーバにおける共有された注釈のサポートはREQUIREDです、サーバにおける個人的な注釈のサポートがOPTIONALですが。 これは個人的な注釈のサポートが注釈の追跡所有権に関して複雑さのかなりの増加をサーバに紹介するかもしれないという事実を認識します、割当てがそれら自身の注釈などに基づくユーザのためにどう測定されるか。 ANNOTATEが拡大であるとサポートするクライアントは共有されたものと同様に個人的な注釈を扱わなければなりません。
3.4. Access Control
3.4. アクセス制御
A user needs to have appropriate rights in order to read or write ".priv" or ".shared" annotation values. How those rights are calculated depends on whether or not the ACL [RFC2086] extension or its update [RFC4314] is present. If a client attempts to store or fetch an annotation to which they do not have the appropriate rights, the server MUST respond with a NO response.
ユーザは、".priv"か".shared"注釈値を読むか、または書くために適切な権利を必要とします。 それらの権利がどう計算されるかはACL[RFC2086]拡張子かそのアップデート[RFC4314]が存在しているかどうかによります。 クライアントが、彼らが適切な権利を持っていない注釈を保存するか、またはとって来るのを試みるなら、サーバはいいえ応答で反応しなければなりません。
When the ACL extension is not present, access to annotation values is governed by the nature of the selected state, in particular whether the mailbox was SELECTED or EXAMINED in READ-ONLY or READ-WRITE mode.
ACL拡張子が存在していないとき、注釈値へのアクセスは選択された状態、メールボックスが特に、READだけのSELECTEDかそれともEXAMINEDであったか、そして、またはREAD-WRITEモードの本質によって治められます。
Daboo & Gellens Experimental [Page 8] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[8ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
When the ACL extension is present, the server MUST recognize the new ACL "n" right, in addition to the ones defined by the ACL extension itself.
ACL拡張子が存在しているとき、サーバは新しいACL「n」権利を認識しなければなりません、ACL拡張子自体で定義されたものに加えて。
For ".priv" annotation values, the "r" right controls both read and write access. When it is on, access to ".priv" annotations is allowed; when it is off, access to ".priv" annotations is disallowed.
".priv"注釈値、右のコントロールがともに読み書きする「r」アクセサリーのために それがオンであるときに、".priv"注釈へのアクセスは許されています。 それがオフであるときに、".priv"注釈へのアクセスは禁じられます。
For ".shared" annotation values, the "r" right controls read access. When it is on, ".shared" annotations can be read; when it is off, ".shared" annotations cannot be read.
".shared"注釈値、右のコントロールが読む「r」アクセサリーのために それがオンであるときに、".shared"注釈を読むことができます。 それがオフであるときに、".shared"注釈を読むことができません。
For ".shared" annotation values, the "n" right controls write access. When it is on, ".shared" annotations can be changed or created through either a STORE or APPEND command; when it is off, ".shared" annotations cannot be changed or created. The "n" right constitutes a "shared flag right" as defined in Section 6.2 of [RFC4314].
".shared"注釈値のために、右の「n」コントロールがアクセサリーを書きます。 それがオンであるときに、ストアかAPPENDコマンドのどちらかで".shared"注釈を変えるか、または作成できます。 それがオフであるときに、".shared"注釈を変えることができませんし、作成できません。 「n」権利は[RFC4314]のセクション6.2で定義されるように「共有された旗の権利」を構成します。
Daboo & Gellens Experimental [Page 9] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[9ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
A summary of all the access control restrictions is tabulated below
すべてのアクセス制御制限の概要は以下に表にされます。
+---------------+---------------+-----------------------------------+ | Server Type | Action on | Type of mailbox | | | annotation | | +===============+===============+===================================+ | | | | | | read .priv | Any mailbox that can be SELECTED | | | values | or EXAMINED. | | | | | | +---------------+-----------------------------------+ | | | | | | write .priv | Any SELECTED [READ-WRITE] mailbox.| | | values | SELECTED [READ-ONLY] mailboxes MAY| | Server | | also permit writes. | | without | | | | ACL Extension +---------------+-----------------------------------+ | | | | | | read .shared | Any mailbox that can be SELECTED | | | values | or EXAMINED. | | | | | | +---------------+-----------------------------------+ | | | | | | write .shared | Any mailbox that can be SELECTED | | | values | or EXAMINED and is [READ-WRITE]. | | | | | +---------------+---------------+-----------------------------------+ | | | | | | read .priv | Any mailbox with the "r" | | | values | ACL right. | | | | | | +---------------+-----------------------------------+ | | | | | | write .priv | Any mailbox with the "r" | | Server | values | ACL right. | | with | | | | ACL Extension +---------------+-----------------------------------+ | | | | | | read .shared | Any mailbox with the "r" | | | values | ACL right. | | | | | | +---------------+-----------------------------------+ | | | | | | write .shared | Any mailbox with the "n" | | | values | ACL right. | | | | | +---------------+---------------+-----------------------------------+
+---------------+---------------+-----------------------------------+ | サーバタイプ| 動作、オン| メールボックスのタイプ| | | 注釈| | +===============+===============+===================================+ | | | | | | .privを読んでください。| SELECTEDであるかもしれないどんなメールボックス| | | 値| または、調べられます。 | | | | | | +---------------+-----------------------------------+ | | | | | | .privに書いてください。| どんなSELECTED[READ-WRITE]メールボックス、も|| | 値| SELECTED[READだけ]メールボックス5月| | サーバ| | また、許可証は書きます。 | | without| | | | ACL拡張子+---------------+-----------------------------------+ | | | | | | .sharedを読んでください。| SELECTEDであるかもしれないどんなメールボックス| | | 値| または、調べられます。 | | | | | | +---------------+-----------------------------------+ | | | | | | .sharedに書いてください。| SELECTEDであるかもしれないどんなメールボックス| | | 値| EXAMINED、[READ-WRITE]はそうです。 | | | | | +---------------+---------------+-----------------------------------+ | | | | | | .privを読んでください。| 「r」があるどんなメールボックス| | | 値| ACL権利。 | | | | | | +---------------+-----------------------------------+ | | | | | | .privに書いてください。| 「r」があるどんなメールボックス| | サーバ| 値| ACL権利。 | | with| | | | ACL拡張子+---------------+-----------------------------------+ | | | | | | .sharedを読んでください。| 「r」があるどんなメールボックス| | | 値| ACL権利。 | | | | | | +---------------+-----------------------------------+ | | | | | | .sharedに書いてください。| 「n」があるどんなメールボックス| | | 値| ACL権利。 | | | | | +---------------+---------------+-----------------------------------+
Daboo & Gellens Experimental [Page 10] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[10ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
3.5. Access to Standard IMAP Flags and Keywords
3.5. 標準のIMAP旗とキーワードへのアクセス
Due to the ambiguity of how private and shared values would map to the base IMAP flag and keyword values, the ANNOTATE extension does not expose IMAP flags or keywords as entries. However, the /flags annotation entry is reserved for future use and MUST NOT be used by clients or servers supporting this extension.
個人的で共有された値がどうベースIMAP旗とキーワードに値を写像するだろうかに関するあいまいさのため、ANNOTATE拡張子はエントリーとしてIMAP旗かキーワードを暴露しません。 しかしながら、/旗注釈エントリーを、今後の使用のために控えて、この拡大をサポートするクライアントかサーバは使用してはいけません。
Clients that need to implement shared and private "flags" can create their own annotation entries for those, completely bypassing the base IMAP flag/keyword behavior.
共有されて個人的な「旗」を実装する必要があるクライアントはそれらのためにそれら自身の注釈エントリーを作成できます、ベースIMAP旗/キーワードの振舞いを完全に迂回させて。
4. IMAP Protocol Changes
4. IMAPプロトコル変化
4.1. General Considerations
4.1. 一般問題
Servers may be able to offer only a limited level of support for annotations in mailboxes, and it is useful for clients to be able to know what level of support is available. Servers MUST return an ANNOTATIONS response code during the SELECT or EXAMINE command for a mailbox to indicate the level of support. Possible data items used with the ANNOTATIONS response code are:
サーバはメールボックスにおける注釈のために限られたレベルのサポートしか提供できないかもしれません、そして、クライアントが、どんなサポート水準が利用可能であるかを知ることができるのは、役に立ちます。 サーバはSELECTかメールボックスがサポート水準を示すEXAMINEコマンドの間、ANNOTATIONS応答コードを返さなければなりません。 ANNOTATIONS応答コードと共に使用される可能なデータ項目は以下の通りです。
"NONE" - this indicates that the mailbox being selected does not
support annotations at all. Clients MUST NOT attempt to use
annotation extensions in commands for this mailbox.
"NONE"--これは、選択されるメールボックスが全く注釈をサポートしないのを示します。 クライアントは、このメールボックスにコマンドにおける注釈拡張子を使用するのを試みてはいけません。
"READ-ONLY" - this indicates that the annotations supported by the
mailbox cannot be changed by the client. Clients MUST NOT attempt
to store annotations on any messages in a mailbox with this
response code.
「READだけ」--これは、クライアントがメールボックスで後押しされている注釈を変えることができないのを示します。 クライアントは、メールボックスの中のどんなメッセージにもこの応答コードで注釈を保存するのを試みてはいけません。
"NOPRIVATE" - this indicates that the server does not support
private annotations on the mailbox. Only shared annotations are
supported. Clients SHOULD only attempt to read or store
annotations attributes with the ".shared" suffix. If a client
uses an attribute with the ".priv" suffix in a FETCH command, then
servers should return the attribute value in the FETCH response as
"NIL". If a client uses an attribute with the ".priv" suffix in a
STORE command (or an APPEND command targeted at the mailbox), then
the server MUST return a NO response.
"NOPRIVATE"--これは、サーバがメールボックスの上に個人的な注釈をサポートしないのを示します。 共有された注釈だけがサポートされます。 クライアントSHOULDは、".shared"接尾語で注釈属性を読むか、または保存するのを試みるだけです。 クライアントがFETCHコマンドに".priv"接尾語がある属性を使用するなら、サーバは「無」としてFETCH応答における属性値を返すべきです。 クライアントがストアコマンド(または、メールボックスをターゲットにしたAPPENDコマンド)に".priv"接尾語がある属性を使用するなら、サーバはいいえ応答を返さなければなりません。
numeric values - if servers support writable annotations, then the
server MUST indicate the maximum size in octets for an annotation
value by providing the maximum size value in the response code.
Clients MUST NOT store annotation values of a size greater than
the amount indicated by the server. Servers MUST accept a minimum
数値--サーバが書き込み可能な注釈をサポートするなら、サーバは、最大サイズ値を応答コードに提供することによって、注釈値のための八重奏における最大サイズを示さなければなりません。 クライアントはサーバによって示された量より大きいサイズの注釈値を保存してはいけません。サーバは最小限を受け入れなければなりません。
Daboo & Gellens Experimental [Page 11] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[11ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
annotation data size of at least 1024 octets if annotations can be
written.
注釈であるなら少なくとも1024の八重奏の注釈データサイズを書くことができます。
In addition, the server MAY limit the total number of annotations for a single message. However, the server MUST provide a minimum annotation count per message of at least 10.
さらに、サーバはただ一つのメッセージのための注釈の総数を制限するかもしれません。 しかしながら、サーバは少なくとも10に関するメッセージあたり1つの最小の注釈カウントを提供しなければなりません。
4.2. ANNOTATE Parameter with the SELECT/EXAMINE Commands
4.2. 選んだ/審査コマンドでパラメタを注釈してください。
The ANNOTATE extension defines a single optional SELECT parameter [RFC4466] "ANNOTATE", which is used to turn on unsolicited responses for annotations as described in Section 4.4. This optional parameter results in a per-mailbox state change, i.e., it must be used in each SELECT/EXAMINE command in order to be effective, irrespective of whether it was used in a previous SELECT/EXAMINE during the same session.
ANNOTATE拡張子は「注釈」というただ一つの任意のSELECTパラメタ[RFC4466]を定義します。(それは、セクション4.4で説明されるように注釈のための求められていない応答をつけるのに使用されます)。 この任意のパラメタは1メールボックスあたり1回の州の変化をもたらします、すなわち、有効になるのにそれぞれのSELECT/EXAMINEコマンドにそれを使用しなければなりません、それが同じセッションの間、前のSELECT/EXAMINEで使用されたかどうかの如何にかかわらず。
Example:
例:
C: a SELECT INBOX (ANNOTATE)
S: * FLAGS (\Answered \Flagged \Draft \Deleted \Seen)
S: * OK [PERMANENTFLAGS (\Answered \Flagged \Draft
\Deleted \Seen \*)]
S: * 10268 EXISTS
S: * 1 RECENT
S: * OK [UNSEEN 10268]
S: * OK [UIDVALIDITY 890061587]
S: * OK [UIDNEXT 34643]
S: * OK [ANNOTATIONS 20480 NOPRIVATE]
S: a OK [READ-WRITE] Completed
C: 選んだ受信トレイ(注釈する)S: * 旗(\旗を揚げさせられた\草稿\に答えた\は見られた\を削除した)のS: * OK[PERMANENTFLAGS(\旗を揚げさせられた\草稿\に答えた\は\見られた\*を削除した)]S: * 10268が存在している、S: * 1、最近のS: * OK[見えない10268]S: * OK[UIDVALIDITY890061587]S: * OK[UIDNEXT34643]S: * OK[注釈20480NOPRIVATE]S: 完成したOK[-読まれて、書いてください]
In the above example, a SELECT command with the ANNOTATE parameter
is issued. The response from the server includes the required
ANNOTATIONS response that indicates that the server supports
annotations up to a maximum size of 20480 octets, and does not
support private annotations (only shared).
上記の例では、ANNOTATEパラメタがあるSELECTコマンドを発行します。 サーバからの応答はサーバが注釈を20480の八重奏の最大サイズまでサポートして、個人的な注釈(共有されただけの)はサポートしないのを示す必要なANNOTATIONS応答を含んでいます。
4.3. ANNOTATION Message Data Item in FETCH Command
4.3. とって来コマンドにおける注釈メッセージデータ項目
This extension adds an ANNOTATION message data item to the FETCH command. This allows clients to retrieve annotations for a range of messages in the currently selected mailbox.
この拡大はANNOTATIONメッセージデータ項目をFETCHコマンドに追加します。 これで、クライアントは現在選択されたメールボックスの中のさまざまなメッセージのための注釈を検索できます。
ANNOTATION <entry-specifier> <attribute-specifier>
注釈<エントリー特許説明書の作成書><属性特許説明書の作成書>。
The ANNOTATION message data item, when used by the client in the
FETCH command, takes an entry specifier and an attribute
specifier.
FETCHコマンドにクライアントによって使用されると、ANNOTATIONメッセージデータ項目はエントリー特許説明書の作成書と属性特許説明書の作成書を連れて行きます。
Daboo & Gellens Experimental [Page 12] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[12ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
Example:
例:
C: a FETCH 1 (ANNOTATION (/comment value))
S: * 1 FETCH (ANNOTATION (/comment
(value.priv "My comment"
value.shared "Group note")))
S: a OK Fetch complete
C: FETCH1(ANNOTATION(/コメント価値))S: * 1 FETCH(ANNOTATION(/コメント(value.priv「私のコメント」value.shared「グループ注意」)))S: Fetchが完成するOK
In the above example, the content of the "value" attribute for the
"/comment" entry is requested by the client and returned by the
server. Since neither ".shared" nor ".priv" was specified, both
are returned.
」 エントリーをクライアントは要求して、サーバは返します。「上記の例、「値」属性の内容、」 以来".shared"も".priv"も指定しなかったという/コメント、両方を返します。
"*" and "%" wild card characters can be used in entry specifiers to match one or more characters at that position, with the exception that "%" does not match the "/" hierarchy delimiter. Thus, an entry specifier of "/%" matches entries such as "/comment" and "/altsubject", but not "/1/comment".
「その位置の1つ以上のキャラクタを合わせるのにエントリー特許説明書の作成書で「*」と「%」ワイルドカードキャラクタを使用できます、「%」が合っていない例外で」 /、」 階層構造デリミタ。 」 」 」 /が」 どんな"/1/comment"もaltsubjectしないという/コメントなどの「その結果、」 /%のエントリー特許説明書の作成書」マッチエントリー。
Example:
例:
C: a UID FETCH 1123 (UID ANNOTATION
(/* (value.priv size.priv)))
S: * 12 FETCH (UID 1123 ANNOTATION
(/comment (value.priv "My comment"
size.priv "10")
/altsubject (value.priv "Rhinoceroses!"
size.priv "13")
/vendor/foobar/label.priv
(value.priv "label43"
size.priv "7")
/vendor/foobar/personality
(value.priv "Tallulah Bankhead"
size.priv "17")))
S: a OK Fetch complete
C: UID FETCH1123(UID ANNOTATION(/*(value.priv size.priv)))S: * 12FETCH、(UID1123ANNOTATION、(/コメント、(value.priv「私のコメント」size.priv、「10インチ) /altsubject、(value.priv「サイ!」size.priv、「13インチ) /vendor/foobar/label.priv、(value.priv、」 label43" size.priv、「7インチ) /vendor/foobar/personality、(value.priv「タルラー・バンクヘッド」size.priv、「17インチ) S:、」 Fetchが完成するOK
In the above example, the contents of the private "value" and
"size" attributes for any entries in the "/" hierarchy are
requested by the client and returned by the server.
「上記の例、個人的な「値」と「サイズ」属性の中のどんなエントリーへのコンテンツ、も」 」 階層構造がクライアントによって要求されていて、サーバによって返される/。
Daboo & Gellens Experimental [Page 13] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[13ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
Example:
例:
C: a FETCH 1 (ANNOTATION (/% value.shared))
S: * 1 FETCH (ANNOTATION
(/comment (value.shared "Patch Mangler")
/altsubject (value.shared "Patches? We don't
need no steenkin patches!")))
S: a OK Fetch complete
C: FETCH1(ANNOTATION(/%value.shared))S: * 1つのフェッチ(注釈(/コメント(value.shared「パッチ挽き肉器」)/altsubject(value.shared「パッチ」? 「私たちはsteenkinパッチを全く必要としません!」)) S: Fetchが完成するOK
In the above example, the contents of the shared "value"
attributes for entries at the top level only of the "/" hierarchy
are requested by the client and returned by the server.
「上記の例、先端のエントリーへの属性が平らにする共有された「値」だけのコンテンツ、」 」 階層構造がクライアントによって要求されていて、サーバによって返される/。
Entry and attribute specifiers can be lists of atomic specifiers, so that multiple items of each type may be returned in a single FETCH command.
エントリーと属性特許説明書の作成書は原子特許説明書の作成書のリストであるかもしれません、ただ一つのFETCHコマンドでそれぞれのタイプの複数の商品を返すことができるように。
Example:
例:
C: a FETCH 1 (ANNOTATION
((/comment /altsubject) value.priv))
S: * 1 FETCH (ANNOTATION
(/comment (value.priv "What a chowder-head")
/altsubject (value.priv "How to crush beer cans")))
S: a OK Fetch complete
C: FETCH1(ANNOTATION((/comment /altsubject)value.priv))S: * 1FETCH、(ANNOTATION、(/コメント、(「何というチャウダーヘッド」) /がaltsubjectするvalue.priv、(value.priv、「どうビール缶をつぶす」) S: Fetchが完成するOK
In the above example, the contents of the private "value"
attributes for the two entries "/comment" and "/altsubject" are
requested by the client and returned by the server.
「上記の例、「2つのエントリーに」 属性を評価してください」という個人的な/コメント」 」 /altsubjectのコンテンツ」をクライアントが要求して、サーバで返します。
4.4. ANNOTATION Message Data Item in FETCH Response
4.4. フェッチ応答における注釈メッセージデータ項目
The ANNOTATION message data item in the FETCH response displays information about annotations in a message.
FETCH応答におけるANNOTATIONメッセージデータ項目はメッセージにおける注釈の情報を表示します。
ANNOTATION parenthesized list
ANNOTATION parenthesizedリスト
The response consists of a list of entries, each of which have a
list of attribute-value pairs.
応答はエントリーのリストから成ります。それはそれぞれ属性値組のリストを持っています。
Daboo & Gellens Experimental [Page 14] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[14ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
Example:
例:
C: a FETCH 1 (ANNOTATION (/comment value))
S: * 1 FETCH (ANNOTATION (/comment
(value.priv "My comment"
value.shared NIL)))
S: a OK Fetch complete
C: FETCH1(ANNOTATION(/コメント価値))S: * 1 FETCH(ANNOTATION(/コメント(value.priv「私のコメント」value.shared NIL)))S: Fetchが完成するOK
In the above example, a single entry with a single attribute-value
pair is returned by the server. Since the client did not specify
a ".shared" or ".priv" suffix, both are returned. Only the
private attribute has a value (the shared value is "NIL").
上記の例では、サーバは1属性値組との単一のエントリーを返します。クライアントが".shared"か".priv"接尾語を指定しなかったので、両方を返します。 個人的な属性だけに、値があります(共有された値は「無いです」)。
Example:
例:
C: a FETCH 1 (ANNOTATION
((/comment /altsubject) value))
S: * 1 FETCH (ANNOTATION
(/comment (value.priv "My comment"
value.shared NIL)
/altsubject (value.priv "My subject"
value.shared NIL)))
S: a OK Fetch complete
C: FETCH1(ANNOTATION((/comment /altsubject)値))S: * 1 FETCH(ANNOTATION(/コメント(value.priv「私のコメント」value.shared NIL)/altsubject(value.priv「私の対象」value.shared NIL)))S: Fetchが完成するOK
In the above example, two entries, each with a single attribute-
value pair, are returned by the server. Since the client did not
specify a ".shared" or ".priv" suffix, both are returned. Only
the private attributes have values; the shared attributes are
"NIL".
上記の例では、サーバは2つのエントリー(1属性値の組があるそれぞれ)を返します。クライアントが".shared"か".priv"接尾語を指定しなかったので、両方を返します。 個人的な属性だけに、値があります。 共用属性は「無いです」。
Example:
例:
C: a FETCH 1 (ANNOTATION
(/comment (value size)))
S: * 1 FETCH (ANNOTATION
(/comment
(value.priv "My comment"
value.shared NIL
size.priv "10"
size.shared "0")))
S: a OK Fetch complete
C: FETCH1(ANNOTATION(/コメント(値のサイズ)))S: * 1FETCH、(ANNOTATION、(/コメント、(value.priv「私のコメント」value.shared NIL size.priv、「10インチのsize.shared、「0インチ) S:、」 Fetchが完成するOK
In the above example, a single entry with two attribute-value
pairs is returned by the server. Since the client did not specify
a ".shared" or ".priv" suffix, both are returned. Only the
private attributes have values; the shared attributes are "NIL".
上記の例では、サーバは2属性値組との単一のエントリーを返します。クライアントが".shared"か".priv"接尾語を指定しなかったので、両方を返します。 個人的な属性だけに、値があります。 共用属性は「無いです」。
Daboo & Gellens Experimental [Page 15] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[15ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
Servers SHOULD send ANNOTATION message data items in unsolicited FETCH responses if an annotation entry is changed by a third-party, and the ANNOTATE select parameter was used. This allows servers to keep clients updated with changes to annotations by other clients.
注釈エントリーが第三者によって変えられて、ANNOTATEの選んだパラメタが使用されたなら、サーバSHOULDは求められていないFETCH応答でメッセージデータ項目をANNOTATIONに送ります。 これで、サーバは、他のクライアントが注釈への変化でクライアントにアップデートし続けることができます。
Unsolicited ANNOTATION responses MUST NOT include ANNOTATION data values -- only the entry name of the ANNOTATION that has changed. This restriction avoids sending ANNOTATION data values (which may be large) to a client unless the client explicitly asks for the value.
求められていないANNOTATION応答はANNOTATIONデータ値を含んではいけません--変化したANNOTATIONの入口名だけ。 この制限は、クライアントが明らかに値を求めない場合クライアントへのデータ値(大きいかもしれない)をANNOTATIONに送るのを避けます。
Example:
例:
C: a STORE 1 +FLAGS (\Seen)
S: * 1 FETCH (FLAGS (\Seen))
ANNOTATION (/comment))
S: a OK STORE complete
C: 店1+旗(見られた\)S: * 1 フェッチ(旗(見られた\))注釈(/コメント) S: ストアが完成するOK
In the above example, an unsolicited ANNOTATION response is
returned during a STORE command. The unsolicited response
contains only the entry name of the annotation that changed, and
not its value.
上記の例では、ストアコマンドの間、求められていないANNOTATION応答を返します。 求められていない応答は値ではなく、変化した注釈の入口名だけを含んでいます。
4.5. ANNOTATION Message Data Item in STORE
4.5. 用意して注釈メッセージデータ項目
ANNOTATION <parenthesized entry-attribute-value list>
ANNOTATION<はエントリー属性値リスト>をparenthesizedしました。
Sets the specified list of entries by adding or replacing the
specified attributes with the values provided. Clients can use
"NIL" for values of attributes it wants to remove from entries.
加えるか、または指定された属性を値に取り替えるのによるエントリーに関する明細表が提供したセット。 クライアントはそれがエントリーから取り除きたがっている属性の値に「無」を使用できます。
The ANNOTATION message data item used with the STORE command has an implicit ".SILENT" behavior. This means the server does not generate an untagged FETCH in response to the STORE command and assumes that the client updates its own cache if the command succeeds. Though note, that if the Conditional STORE extension [RFC4551] is present, then an untagged FETCH response with a MODSEQ data item will be returned by the server as required by [RFC4551].
ストアコマンドと共に使用されるANNOTATIONメッセージデータ項目は暗黙の".SILENT"の振舞いを持っています。 これは、サーバがストアコマンドに対応してuntagged FETCHを生成しないことを意味して、コマンドが成功するならクライアントがそれ自身のキャッシュをアップデートすると仮定します。 Conditionalストア拡張子[RFC4551]が存在しているとMODSEQデータ項目があるuntagged FETCH応答が必要に応じてサーバによって[RFC4551]によって返されるというメモですが。
If the server is unable to store an annotation because the size of its value is too large, the server MUST return a tagged NO response with a "[ANNOTATE TOOBIG]" response code.
価値のサイズが大き過ぎるのでサーバが注釈を保存できないなら、サーバは「[TOOBIGを注釈します]」応答コードによるタグ付けをされたいいえ応答を返さなければなりません。
If the server is unable to store a new annotation because the maximum number of allowed annotations has already been reached, the server MUST return a tagged NO response with a "[ANNOTATE TOOMANY]" response code.
許容注釈の最大数に既に達したのでサーバが新しい注釈を保存できないなら、サーバは「[TOOMANYを注釈します]」応答コードによるタグ付けをされたいいえ応答を返さなければなりません。
Daboo & Gellens Experimental [Page 16] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[16ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
Example:
例:
C: a STORE 1 ANNOTATION (/comment
(value.priv "My new comment"))
S: a OK Store complete
C: ストア1ANNOTATION、(/コメント、(value.priv、「私の新しいコメント」) S: ストアが完成するOK
In the above example, the entry "/comment" is created (if not
already present). Its private attribute "value" is created if not
already present, or replaced if it exists. "value.priv" is set to
"My new comment".
「上記の例、」 /が論評するエントリー」は、作成されるのと(既に現在。)です。 存在しているなら、個人的な属性「値」をそうでなければ、既に存在していた状態で作成するか、または取り替えます。 "value.priv"は「私の新しいコメント」に設定されます。
Example:
例:
C: a STORE 1 ANNOTATION (/comment
(value.shared NIL))
S: a OK Store complete
C: 店1つの注釈(/コメント(value.shared無))S: ストアが完成するOK
In the above example, the shared "value" attribute of the entry
"/comment" is removed by storing "NIL" into the attribute.
「無」を属性として保存することによって、「上記の例、「」 エントリーの属性を評価してください」という共有されて、/コメント」を取り除きます。
Multiple entries can be set in a single STORE command by listing entry-attribute-value pairs in the list.
多回入国はリストにエントリー属性値組を記載するのによるただ一つのストアコマンドでセットであるかもしれません。
Example:
例:
C: a STORE 1 ANNOTATION (/comment
(value.priv "Get tix Tuesday")
/altsubject
(value.priv "Wots On"))
S: a OK Store complete
C: ストア1ANNOTATION、(/コメント(value.privは「火曜日にtixを手に入れる」)/altsubjectである、(value.priv、「Wots、オンである、」、)、S: ストアが完成するOK
In the above example, the entries "/comment" and "/altsubject" are
created (if not already present) and the private attribute "value"
is created or replaced for each entry.
「上記の例、エントリー」 /コメント」 」 /altsubject」が作成されるのと(既に現在)であり、個人的な属性「値」を各エントリーに作成するか、または取り替えます。
Multiple attributes can be set in a single STORE command by listing multiple attribute-value pairs in the entry list.
複数の属性がエントリーリストに複数の属性値組を記載するのによるただ一つのストアコマンドでセットであるかもしれません。
Daboo & Gellens Experimental [Page 17] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[17ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
Example:
例:
C: a STORE 1 ANNOTATION (/comment
(value.priv "My new comment"
value.shared "foo's bar"))
S: a OK Store complete
C: ストア1ANNOTATION(/コメント(「」 私の新しいコメントvalue.shared「はfoo禁じる」value.priv))S: ストアが完成するOK
In the above example, the entry "/comment" is created (if not
already present) and the private and shared "value" attributes are
created if not already present, or replaced if they exist.
「上記の例、」 /が論評するエントリー」が作成されるのと(既に現在)であり、存在しているなら、個人的で共有された「値」属性をそうでなければ、既に存在していた状態で作成するか、または取り替えます。
4.6. ANNOTATION Interaction with COPY
4.6. コピーとの注釈相互作用
The COPY command can be used to move messages from one mailbox to another on the same server. Servers that support the ANNOTATION extension MUST, for each message being copied, copy all ".priv" annotation data for the current user only, and all ".shared" annotation data along with the message to the new mailbox. The only exceptions to this are if the destination mailbox permissions are such that either the ".priv" or ".shared" annotations are not allowed, or if the destination mailbox is of a type that does not support annotations or does not support storing of annotations (a mailbox that returns a "NONE" or "READ-ONLY" response code in its ANNOTATIONS response), or if the destination mailbox cannot support the size of an annotation because it exceeds the ANNOTATIONS value. Servers MUST NOT copy ".priv" annotation data for users other than the current user.
同じサーバで1個のメールボックスから別のメールボックスまでメッセージを動かすのにCOPYコマンドを使用できます。コピーされる各メッセージのために、ANNOTATIONが拡大であるとサポートするサーバは、現在のユーザだけへのすべての".priv"注釈データ、およびメッセージに伴うすべての".shared"注釈データを新しいメールボックスにコピーしなければなりません。 これへの唯一の例外は".priv"か".shared"のどちらか注釈があて先メールボックス許容がそのようなものであるので許容されていないかどうか、または注釈値を超えているのであて先メールボックスが注釈のサイズをサポートすることができないなら、注釈をサポートしないか、または注釈の保存が(注釈応答における「なにも」か「書き込み禁止」応答コードを返すメールボックス)であるとサポートしないタイプにあて先メールボックスがあるということです。 サーバは現在のユーザ以外のユーザのために".priv"注釈データをコピーしてはいけません。
4.7. ANNOTATION Message Data Item in APPEND
4.7. データ項目が中に追加する注釈メッセージ
ANNOTATION <parenthesized entry-attribute-value list>
ANNOTATION<はエントリー属性値リスト>をparenthesizedしました。
Sets the specified list of entries and attributes in the resulting
message.
結果として起こるメッセージのエントリーと属性に関する明細表を設定します。
The APPEND command can include annotations for the message being appended via the addition of a new append data item [RFC4466]. The new data item can also be used with the multi-append [RFC3502] extension that allows multiple messages to be appended via a single APPEND command.
aの追加で新しい状態で追加されるメッセージがデータ項目[RFC4466]を追加するので、APPENDコマンドは注釈を含むことができます。 また、新しいデータ項目を使用できる、マルチ、追加、複数のただ一つのAPPENDコマンドで追加されるべきメッセージを許容する[RFC3502]拡大。
Daboo & Gellens Experimental [Page 18] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[18ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
Example:
例:
C: a APPEND drafts ANNOTATION (/comment
(value.priv "Don't send until I say so")) {310}
S: + Ready for literal data
C: MIME-Version: 1.0
...
C:
S: a OK APPEND completed
C: APPENDはANNOTATION(/コメント(value.privは「私がそのように言うまで、発信しない」))310Sを作成します: +は文字通りのデータのためにCを準備します: MIMEバージョン: 1.0 ... C: S: 完成したOK APPEND
In the above example, a comment with a private value is added to a
new message appended to the mailbox. The ellipsis represents the
bulk of the message.
上記の例では、個人的な値があるコメントはメールボックスに追加された新しいメッセージに追加されます。 省略はメッセージの大半を表します。
4.8. ANNOTATION Criterion in SEARCH
4.8. 検索における注釈評価基準
ANNOTATION <entry-name> <attribute-name> <value>
注釈<入口名><属性名の><値の>。
The ANNOTATION criterion for the SEARCH command allows a client to search for a specified string in the value of an annotation entry of a message.
検索命令のためのANNOTATION評価基準で、クライアントはメッセージの注釈エントリーの値で指定されたストリングを捜し求めることができます。
Messages that have annotations with entries matching <entry-name>, attributes matching <attribute-name>, and the specified string <value> in their values are returned in the SEARCH results. The "*" character can be used in the entry name field to match any content in those items. The "%" character can be used in the entry name field to match a single level of hierarchy only.
検索結果でエントリーがそれらの値で<入口名>、属性合っている<属性名の>、および指定されたストリング<値の>に合っている注釈を持っているメッセージを返します。 それらの項目のどんな内容も合わせるのに入口名分野で「*」キャラクタを使用できます。ただ一つのレベルの階層構造だけを合わせるのに入口名分野で「%」キャラクタを使用できます。
Only the "value", "value.priv", and "value.shared" attributes can be searched. Clients MUST NOT specify an attribute other than either "value", "value.priv", or "value.shared". Servers MUST return a BAD response if the client tries to search any other attribute.
「値」、"value.priv"、および"value.shared"属性しか捜すことができません。 クライアントは「値」、"value.priv"か"value.shared"のどちらか以外の属性を指定してはいけません。 クライアントがいかなる他の属性も捜そうとするなら、サーバはBAD応答を返さなければなりません。
Example:
例:
C: a SEARCH ANNOTATION /comment value "IMAP4"
S: * SEARCH 2 3 5 7 11 13 17 19 23
S: a OK Search complete
C: 検索ANNOTATION/コメント値、「IMAP4" S:」 * 23秒間の検索2 3 5 7 11 13 17 19: 検索が完成するOK
In the above example, the message numbers of any messages
containing the string "IMAP4" in the shared or private "value"
attribute of the "/comment" entry are returned in the search
results.
「上記の例、ストリングを含むどんなメッセージのメッセージ番号、も「共有されるか個人的のIMAP4"が属性を「評価する」、」 検索で」 エントリーを返すという/コメントは結果として生じます。
Daboo & Gellens Experimental [Page 19] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[19ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
Example:
例:
C: a SEARCH ANNOTATION * value.priv "IMAP4"
S: * SEARCH 1 2 3 5 8 13 21 34
S: a OK Search complete
C: 検索ANNOTATION*value.priv、「IMAP4" S:」 * 34秒間の検索1 2 3 5 8 13 21: 検索が完成するOK
In the above example, the message numbers of any messages
containing the string "IMAP4" in the private "value" attribute of
any entry are returned in the search results.
上記の例、ストリングを含むどんなメッセージのメッセージ番号ではも、「検索結果でどんなエントリーの個人的な「値」属性におけるIMAP4"も返します」。
4.9. ANNOTATION Key in SORT
4.9. 種類で主要な注釈
ANNOTATION <entry-name> <attribute-name>
注釈<入口名><属性名の>。
The ANNOTATION criterion for the SORT command [RFC5256] instructs the server to return the sequence numbers or Unique Identifiers (UIDs) of messages in a mailbox, sorted using the values of the specified annotations. The ANNOTATION criterion is available if the server returns both ANNOTATE-EXPERIMENT-1 and SORT as supported capabilities in the CAPABILITY command response.
SORTコマンド[RFC5256]のためのANNOTATION評価基準は、指定された注釈の値を使用することで分類されたメールボックスの中にメッセージの一連番号かUnique Identifiers(UIDs)を返すようサーバに命令します。 CAPABILITYコマンド応答における能力であるとサポートされるようにサーバがANNOTATE-EXPERIMENT-1とSORTの両方を返すなら、ANNOTATION評価基準は利用可能です。
Messages are sorted using the values of the <attribute-name> attributes in the <entry-name> entries.
メッセージは、<入口名>エントリーにおける、属性という<属性名の>の値を使用することで分類されます。
Clients MUST provide either the ".priv" or ".shared" suffix to the attribute name to ensure that the server knows which specific value to sort on.
クライアントは、サーバが種類にオンなどの特定の値を知っているかを保証するために".priv"か".shared"接尾語を属性名に提供しなければなりません。
Only the "value.priv" and "value.shared" attributes can be used for sorting. Clients MUST NOT specify an attribute other than either "value.priv" or "value.shared". Servers MUST return a BAD response if the client tries to sort on any other attribute.
ソーティングに"value.priv"と"value.shared"属性しか使用できません。 クライアントは"value.priv"か"value.shared"のどちらか以外の属性を指定してはいけません。 サーバはクライアントトライであるならいかなる他の属性の種類にもBAD応答を返さなければなりません。
When either "value.priv" or "value.shared" is being sorted, the server MUST use the character set value specified in the SORT command to determine the appropriate sort order.
"value.priv"か"value.shared"のどちらかが分類されているとき、サーバは適切なソート順序を決定するSORTコマンドで指定された文字集合値を使用しなければなりません。
Example:
例:
C: a SORT (ANNOTATION /altsubject value.shared) UTF-8 ALL
S: * SORT 2 3 4 5 1 11 10 6 7 9 8
S: a OK Sort complete
C: SORT(ANNOTATION /altsubject value.shared)UTF-8 ALL S: * 種類2 3 4 5 1の11 10、8秒間の6 7 9: Sortが完成するOK
In the above example, the message numbers of all messages are
returned, sorted according to the shared "value" attribute of the
"/altsubject" entry.
「共有された「値」属性に従って、すべてのメッセージのメッセージ番号が上記の例では、返されて、分類されている、」 /は」 エントリーをaltsubjectします。
Daboo & Gellens Experimental [Page 20] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[20ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
Note that the ANNOTATION sort key must include a fully specified entry -- wild cards are not allowed.
ANNOTATION分類用キーが完全に指定されたエントリーを含まなければならないことに注意してください--ワイルドカードは許容されていません。
4.10. New ACL Rights
4.10. 新しいACL権利
As discussed in Section 3.4, this extension adds a new "n" right to the list of rights provided by the ACL extensions [RFC2086] and [RFC4314].
セクション3.4で議論するように、この拡大はまさしくACL拡大[RFC2086]と[RFC4314]によって提供された権利のリストに新しい「n」を追加します。
5. Formal Syntax
5. 正式な構文
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) notation as specified in [RFC5234].
以下の構文仕様は[RFC5234]の指定されるとしてのAugmented BN記法(ABNF)記法を使用します。
Non-terminals referenced but not defined below are as defined by [RFC3501] with the new definitions in [RFC4466] superseding those in [RFC3501].
[RFC4466]との新しい定義が[RFC3501]でそれらに取って代わっていて[RFC3501]によって定義されるように参照をつけられましたが、以下で定義されなかった非端末があります。
Except as noted otherwise, all alphabetic characters are case- insensitive. The use of upper or lower case characters to define token strings is for editorial clarity only. Implementations MUST accept these strings in a case-insensitive fashion.
別の方法で注意されるのを除いて、すべての英字がケース神経が鈍いです。 トークンストリングを定義する上側の、または、下側のケースキャラクタの使用は編集の明快だけのためのものです。 実装は大文字と小文字を区別しないファッションでこれらのストリングを受け入れなければなりません。
ann-size = "NONE" /
(("READ-ONLY" / nz-number)
[SP "NOPRIVATE"])
; response codes indicating the level of
; support for annotations in a mailbox
ann-サイズは「なにも」/と等しいです((nz「書き込み禁止」/番号)[SP"NOPRIVATE"])。 応答がコード化する、レベルを示します。 メールボックスにおける注釈のサポート
append-ext =/ att-annotate
; modifies [RFC3501] extension behaviour
/がatt注釈するextを追加している=。 [RFC3501]拡大のふるまいを変更します。
att-annotate = "ANNOTATION" SP
"(" entry-att *(SP entry-att) ")"
「(「エントリー-att*(SPエントリー-att)」)」という=「注釈」SPをatt注釈してください。
att-search = "value" / "value.priv" / "value.shared"
; the only attributes that can be searched
att-検索は「値」/"value.priv"/"value.shared"と等しいです。 捜すことができる唯一の属性
att-sort = "value.priv" / "value.shared"
; the only attributes that can be sorted
att-種類は"value.priv"/"value.shared"と等しいです。 分類できる唯一の属性
att-value = attrib SP value
att-値はattrib SP値と等しいです。
attrib = astring
; dot-separated attribute name
; MUST NOT contain "*" or "%"
attribはastringと等しいです。 ドットで切り離された属性名。 NOTは「*」か「%」を含まなければなりませんか?
Daboo & Gellens Experimental [Page 21] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[21ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
attribs = attrib / "(" attrib *(SP attrib) ")"
; one or more attribute specifiers
attribsは「(「attrib*(SP attrib)」)」というattrib/と等しいです。 1人以上の属性特許説明書の作成書
capability =/ "ANNOTATE-EXPERIMENT-1"
; defines the capability for this extension
=/「実験を何1インチも注釈している」能力。 この拡大のために能力を定義します。
entries = entry-match /
"(" entry-match *(SP entry-match) ")"
エントリーは「(「エントリーマッチ*(SPエントリーマッチ)」)」というエントリーマッチ/と等しいです。
entry = astring
; slash-separated path to entry
; MUST NOT contain "*" or "%"
エントリーはastringと等しいです。 エントリーへの経路をスラッシュで切り離します。 NOTは「*」か「%」を含まなければなりませんか?
entry-att = entry SP "(" att-value *(SP att-value) ")"
エントリー-attは「(「att-値の*(SP att-値)」)」というエントリーSPと等しいです。
entry-match = list-mailbox
; slash-separated path to entry
; MAY contain "*" or "%" for use as wild cards
エントリーマッチはリストメールボックスと等しいです。 エントリーへの経路をスラッシュで切り離します。 ワイルドカードとして使用のための「*」か「%」を含むかもしれません。
fetch-att =/ "ANNOTATION" SP "(" entries SP attribs ")"
; modifies original IMAP fetch-att
「(「エントリーSP attribs」)」というフェッチ-att=/「注釈」SP。 オリジナルのIMAPフェッチ-attを変更します。
msg-att-dynamic =/ "ANNOTATION" SP
( "(" entry-att *(SP entry-att) ")" /
"(" entry *(SP entry) ")" )
; extends FETCH response with annotation data
msg-attダイナミックな=/「注釈」SP(「(「エントリー-att*(SPエントリー-att)」)」/「(「エントリー*(SPエントリー)」)」)。 注釈データでFETCH応答を広げています。
resp-text-code =/ "ANNOTATE" SP "TOOBIG" /
"ANNOTATE" SP "TOOMANY" /
"ANNOTATIONS" SP ann-size
; new response codes
respテキストコード=/「注釈」SP"TOOBIG"/はSP"TOOMANY"/「注釈」SP ann-サイズを「注釈します」。 新しい応答コード
search-key =/ "ANNOTATION" SP entry-match SP att-search
SP value
; modifies original IMAP search-key
検索主要な「注釈」SPエントリー=/マッチSP att-検索SP価値。 オリジナルのIMAP検索キーを変更します。
select-param =/ "ANNOTATE"
; defines the select parameter used with
; ANNOTATE extension
選んだparam=/「注釈」。 使用されていた状態で選んだパラメタを定義します。 ANNOTATE拡張子
sort-key =/ "ANNOTATION" SP entry SP att-sort
; modifies original sort-key
分類用キー=/「注釈」SPエントリーSP att-種類。 オリジナルの分類用キーを変更します。
store-att-flags =/ att-annotate
; modifies original IMAP STORE command
=/がatt注釈する店att旗。 オリジナルのIMAP STOREコマンドを変更します。
value = nstring / literal8
値はnstring / literal8と等しいです。
Daboo & Gellens Experimental [Page 22] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[22ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
6. IANA Considerations
6. IANA問題
Entry names MUST be specified in a standards track or IESG approved experimental RFC, or fall under the vendor namespace. Vendor names MUST be registered.
標準化過程で入口名を指定しなければならないか、またはIESGは実験的なRFCを承認するか、ベンダー名前空間の下で落ちます。 ベンダー名を登録しなければなりません。
Attribute names MUST be specified in a standards track or IESG approved experimental RFC.
標準化過程で属性名を指定しなければならない、さもなければ、IESGは実験的なRFCを承認しました。
Each entry registration MUST include a content-type that is used to indicate the nature of the annotation value. Where applicable, a charset parameter MUST be included with the content-type.
それぞれのエントリー登録は注釈価値の本質を示すのに使用されるcontent typeを含まなければなりません。 適切であるところでは、content typeでcharsetパラメタを含まなければなりません。
6.1. Entry and Attribute Registration Template
6.1. エントリーと属性登録テンプレート
To: iana@iana.org Subject: IMAP Annotate Registration
To: iana@iana.org Subject: IMAPは登録を注釈します。
Please register the following IMAP Annotate item:
以下のIMAP Annotateの品目を登録してください:
[] Entry [] Attribute
[]エントリー[]属性
Name: ______________________________
以下を命名してください。 ______________________________
Description: _______________________
記述: _______________________
____________________________________
____________________________________
____________________________________
____________________________________
Content-Type:_______________________
コンテントタイプ:_______________________
Contact person: ____________________
人に連絡してください: ____________________
email: ____________________
メール: ____________________
Daboo & Gellens Experimental [Page 23] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[23ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
6.2. Entry Registrations
6.2. エントリー登録証明書
The following templates specify the IANA registrations of annotation entries specified in this document.
以下のテンプレートは本書では指定された注釈エントリーのIANA登録証明書を指定します。
6.2.1. /comment
6.2.1. /コメント
To: iana@iana.org Subject: IMAP Annotate Registration
To: iana@iana.org Subject: IMAPは登録を注釈します。
Please register the following IMAP Annotate item:
以下のIMAP Annotateの品目を登録してください:
[X] Entry [] Attribute
[X]エントリー[]属性
Name: /comment
以下を命名してください。 /コメント
Description: Defined in IMAP ANNOTATE extension document.
記述: IMAP ANNOTATE拡大ドキュメントでは、定義されます。
Content-Type: text/plain; charset=utf-8
コンテントタイプ: テキスト/平野。 charset=utf-8
Contact person: Cyrus Daboo
人に連絡してください: サイラスDaboo
email: cyrus@daboo.name
メール: cyrus@daboo.name
6.2.2. /flags
6.2.2. /旗
To: iana@iana.org Subject: IMAP Annotate Registration
To: iana@iana.org Subject: IMAPは登録を注釈します。
Please register the following IMAP Annotate item:
以下のIMAP Annotateの品目を登録してください:
[X] Entry [] Attribute
[X]エントリー[]属性
Name: /flags
以下を命名してください。 /旗
Description: Reserved entry hierarchy.
記述: 予約されたエントリー階層構造。
Content-Type: -
コンテントタイプ: -
Contact person: Cyrus Daboo
人に連絡してください: サイラスDaboo
email: cyrus@daboo.name
メール: cyrus@daboo.name
Daboo & Gellens Experimental [Page 24] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[24ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
6.2.3. /altsubject
6.2.3. /altsubject
To: iana@iana.org Subject: IMAP Annotate Registration
To: iana@iana.org Subject: IMAPは登録を注釈します。
Please register the following IMAP Annotate item:
以下のIMAP Annotateの品目を登録してください:
[X] Entry [] Attribute
[X]エントリー[]属性
Name: /altsubject
以下を命名してください。 /altsubject
Description: Defined in IMAP ANNOTATE extension document.
記述: IMAP ANNOTATE拡大ドキュメントでは、定義されます。
Content-Type: text/plain; charset=utf-8
コンテントタイプ: テキスト/平野。 charset=utf-8
Contact person: Cyrus Daboo
人に連絡してください: サイラスDaboo
email: cyrus@daboo.name
メール: cyrus@daboo.name
6.2.4. /<section-part>/comment
6.2.4. /<部部分>/コメント
To: iana@iana.org Subject: IMAP Annotate Registration
To: iana@iana.org Subject: IMAPは登録を注釈します。
Please register the following IMAP Annotate item:
以下のIMAP Annotateの品目を登録してください:
[X] Entry [] Attribute
[X]エントリー[]属性
Name: /<section-part>/comment
以下を命名してください。 /<部部分>/コメント
Description: Defined in IMAP ANNOTATE extension document.
記述: IMAP ANNOTATE拡大ドキュメントでは、定義されます。
Content-Type: text/plain; charset=utf-8
コンテントタイプ: テキスト/平野。 charset=utf-8
Contact person: Cyrus Daboo
人に連絡してください: サイラスDaboo
email: cyrus@daboo.name
メール: cyrus@daboo.name
Daboo & Gellens Experimental [Page 25] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[25ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
6.2.5. /<section-part>/flags/seen
6.2.5. /<部パート>/flags/seen
To: iana@iana.org Subject: IMAP Annotate Registration
To: iana@iana.org Subject: IMAPは登録を注釈します。
Please register the following IMAP Annotate item:
以下のIMAP Annotateの品目を登録してください:
[X] Entry [] Attribute
[X]エントリー[]属性
Name: /<section-part>/flags/seen
以下を命名してください。 /<部パート>/flags/seen
Description: Defined in IMAP ANNOTATE extension document.
記述: IMAP ANNOTATE拡大ドキュメントでは、定義されます。
Content-Type: text/plain; charset=utf-8
コンテントタイプ: テキスト/平野。 charset=utf-8
Contact person: Cyrus Daboo
人に連絡してください: サイラスDaboo
email: cyrus@daboo.name
メール: cyrus@daboo.name
6.2.6. /<section-part>/flags/answered
6.2.6. /<部パート>/flags/answered
To: iana@iana.org Subject: IMAP Annotate Registration
To: iana@iana.org Subject: IMAPは登録を注釈します。
Please register the following IMAP Annotate item:
以下のIMAP Annotateの品目を登録してください:
[X] Entry [] Attribute
[X]エントリー[]属性
Name: /<section-part>/flags/answered
以下を命名してください。 /<部パート>/flags/answered
Description: Defined in IMAP ANNOTATE extension document.
記述: IMAP ANNOTATE拡大ドキュメントでは、定義されます。
Content-Type: text/plain; charset=utf-8
コンテントタイプ: テキスト/平野。 charset=utf-8
Contact person: Cyrus Daboo
人に連絡してください: サイラスDaboo
email: cyrus@daboo.name
メール: cyrus@daboo.name
Daboo & Gellens Experimental [Page 26] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[26ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
6.2.7. /<section-part>/flags/flagged
6.2.7. /<部パート>/flags/flagged
To: iana@iana.org Subject: IMAP Annotate Registration
To: iana@iana.org Subject: IMAPは登録を注釈します。
Please register the following IMAP Annotate item:
以下のIMAP Annotateの品目を登録してください:
[X] Entry [] Attribute
[X]エントリー[]属性
Name: /<section-part>/flags/flagged
以下を命名してください。 /<部パート>/flags/flagged
Description: Defined in IMAP ANNOTATE extension document.
記述: IMAP ANNOTATE拡大ドキュメントでは、定義されます。
Content-Type: text/plain; charset=utf-8
コンテントタイプ: テキスト/平野。 charset=utf-8
Contact person: Cyrus Daboo
人に連絡してください: サイラスDaboo
email: cyrus@daboo.name
メール: cyrus@daboo.name
6.2.8. /<section-part>/flags/forwarded
6.2.8. /<部パート>/flags/forwarded
To: iana@iana.org Subject: IMAP Annotate Registration
To: iana@iana.org Subject: IMAPは登録を注釈します。
Please register the following IMAP Annotate item:
以下のIMAP Annotateの品目を登録してください:
[X] Entry [] Attribute
[X]エントリー[]属性
Name: /<section-part>/flags/forwarded
以下を命名してください。 /<部パート>/flags/forwarded
Description: Defined in IMAP ANNOTATE extension document.
記述: IMAP ANNOTATE拡大ドキュメントでは、定義されます。
Content-Type: text/plain; charset=utf-8
コンテントタイプ: テキスト/平野。 charset=utf-8
Contact person: Cyrus Daboo
人に連絡してください: サイラスDaboo
email: cyrus@daboo.name
メール: cyrus@daboo.name
Daboo & Gellens Experimental [Page 27] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[27ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
6.3. Attribute Registrations
6.3. 属性登録証明書
The following templates specify the IANA registrations of annotation attributes specified in this document.
以下のテンプレートは本書では指定された注釈属性のIANA登録証明書を指定します。
6.3.1. value
6.3.1. 値
To: iana@iana.org Subject: IMAP Annotate Registration
To: iana@iana.org Subject: IMAPは登録を注釈します。
Please register the following IMAP Annotate item:
以下のIMAP Annotateの品目を登録してください:
[] Entry [X] Attribute
[]エントリー[X]属性
Name: value
以下を命名してください。 値
Description: Defined in IMAP ANNOTATE extension document.
記述: IMAP ANNOTATE拡大ドキュメントでは、定義されます。
Contact person: Cyrus Daboo
人に連絡してください: サイラスDaboo
email: cyrus@daboo.name
メール: cyrus@daboo.name
6.3.2. size
6.3.2. サイズ
To: iana@iana.org Subject: IMAP Annotate Registration
To: iana@iana.org Subject: IMAPは登録を注釈します。
Please register the following IMAP Annotate item:
以下のIMAP Annotateの品目を登録してください:
[] Entry [X] Attribute
[]エントリー[X]属性
Name: size
以下を命名してください。 サイズ
Description: Defined in IMAP ANNOTATE extension document.
記述: IMAP ANNOTATE拡大ドキュメントでは、定義されます。
Contact person: Cyrus Daboo
人に連絡してください: サイラスDaboo
email: cyrus@daboo.name
メール: cyrus@daboo.name
6.4. Capability Registration
6.4. 能力登録
This document registers "ANNOTATE-EXPERIMENT-1" as an IMAPEXT capability.
このドキュメントが登録される、「実験1インチを注釈する、IMAPEXT能力、」
Daboo & Gellens Experimental [Page 28] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[28ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
7. Internationalization Considerations
7. 国際化問題
Annotations may contain values that include text strings, and both searching and sorting are possible with annotations. Servers MUST follow standard IMAP text normalization, character set conversion, and collation rules when such operations are carried out, as would be done for other textual fields being searched or sorted on.
注釈はテキスト文字列を含んでいる値を含むかもしれません、そして、探すのとソーティングの両方が注釈で可能です。 サーバは標準のIMAPテキスト標準化、文字集合変換、および照合規則に従わなければなりません。そのような操作が行われます、捜されるか、または分類される他の原文の分野にするようにいつに関して?
8. Security Considerations
8. セキュリティ問題
Annotations whose values are intended to remain private MUST be stored in ".priv" values instead of ".shared" values, which may be accessible to other users.
".shared"値の代わりに".priv"値で値が個人的に残るつもりである注釈を保存しなければなりません。他のユーザにとって、値はアクセスしやすいかもしれません。
Excluding the above issues, the ANNOTATE extension does not raise any security considerations that are not present in the base IMAP protocol; these issues are discussed in [RFC3501].
上記の問題を除いて、ANNOTATE拡張子はどんなベースIMAPプロトコルで存在していないセキュリティ問題も提起しません。 [RFC3501]でこれらの問題について議論します。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[RFC2086] Myers, J., "IMAP4 ACL extension", RFC 2086, January 1997.
[RFC2086] マイアーズ、J.、「IMAP4 ACL拡張子」、RFC2086、1997年1月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC2244] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November 1997.
[RFC2244] ニューマン、C.、およびJ.マイアーズ、「ACAP--アプリケーション構成アクセスは議定書を作る」、RFC2244、11月1997日
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003.
[RFC3501] クリスピン、M.、「バージョン4rev1"、RFC3501、2003年インターネットメッセージアクセス・プロトコル--3月。」
[RFC3502] Crispin, M., "Internet Message Access Protocol (IMAP) -
MULTIAPPEND Extension", RFC 3502, March 2003.
[RFC3502]クリスピン、M.、「インターネットはアクセス・プロトコル(IMAP)を通信させます--MULTIAPPEND拡張子」、RFC3502、3月2003日
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC3629]Yergeau、F.、「UTF-8、ISO10646の変換形式」STD63、RFC3629、11月2003日
[RFC4314] Melnikov, A., "IMAP4 Access Control List (ACL) Extension",
RFC 4314, December 2005.
[RFC4314] メリニコフ、A.、「IMAP4アクセスコントロールリスト(ACL)拡大」、RFC4314、2005年12月。
[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4
ABNF", RFC 4466, April 2006.
[RFC4466] メリニコフとA.とC.Daboo、「IMAP4 ABNFへの集まっている拡大」、RFC4466、2006年4月。
[RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for
Syntax Specifications: ABNF", STD 68, RFC 5234, January
2008.
エド[RFC5234]クロッカー、D.、P.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、STD68、RFC5234、2008年1月。
Daboo & Gellens Experimental [Page 29] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[29ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
[RFC5256] Crispin, M. and K. Murchison, "Internet Message Access
Protocol - SORT and THREAD Extensions", RFC 5256, June
2008.
[RFC5256] クリスピンとM.とK.マーチソン、「インターネットメッセージアクセス・プロトコル--拡大を分類して、糸を通す」RFC5256、2008年6月。
9.2. Informative References
9.2. 有益な参照
[RFC4551] Melnikov, A. and S. Hole, "IMAP Extension for Conditional
STORE Operation or Quick Flag Changes Resynchronization",
RFC 4551, June 2006.
メリニコフ、A.、およびS.が掘る[RFC4551]、「条件付きの店舗運営か迅速な旗のためのIMAP拡張子はResynchronizationを変えます」、RFC4551、2006年6月。
10. Acknowledgments
10. 承認
Many thanks to Chris Newman for his detailed comments on the first draft of this document, and to the participants at the ACAP working dinner in Pittsburgh. The participants of the IMAPext working group made significant contributions to this work.
このドキュメントの最初の草稿の彼の詳細なコメントのためのクリス・ニューマンと、そして、ピッツバーグのACAP夕食会における関係者をありがとうございます。 IMAPextワーキンググループの関係者はこの仕事への重要な貢献をしました。
Authors' Addresses
作者のアドレス
Cyrus Daboo Apple Inc. 1 Infinite Loop Cupertino, CA 95014 USA
サイラスDabooアップルInc.1無限ループカリフォルニア95014カルパチーノ(米国)
EMail: cyrus@daboo.name URI: http://www.apple.com/
メール: cyrus@daboo.name ユリ: http://www.apple.com/
Randall Gellens QUALCOMM Incorporated 5775 Morehouse Dr. San Diego, CA 92121-2779 USA
ランドルサンディエゴ、Gellensクアルコムの法人組織の5775モアハウス博士カリフォルニア92121-2779米国
EMail: randy@qualcomm.com
メール: randy@qualcomm.com
Daboo & Gellens Experimental [Page 30] RFC 5257 IMAP ANNOTATE Extension June 2008
Daboo&Gellensの実験的な[30ページ]RFC5257IMAPは2008年6月に拡大を注釈します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
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, THE IETF TRUST 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.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
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に情報を扱ってください。
Daboo & Gellens Experimental [Page 31]
Daboo&Gellens実験的です。[31ページ]
一覧
スポンサーリンク
