[要約] RFC 8474は、IMAPプロトコルにオブジェクト識別子を拡張するための仕様です。目的は、IMAPサーバーがオブジェクトを一意に識別し、効率的に操作できるようにすることです。
Internet Engineering Task Force (IETF) B. Gondwana, Ed.
Request for Comments: 8474 FastMail
Updates: 3501 September 2018
Category: Standards Track
ISSN: 2070-1721
IMAP Extension for Object Identifiers
オブジェクト識別子のIMAP拡張
Abstract
概要
This document updates RFC 3501 (IMAP4rev1) with persistent identifiers on mailboxes and messages to allow clients to more efficiently reuse cached data when resources have changed location on the server.
このドキュメントは、メールボックスとメッセージの永続的な識別子でRFC 3501（IMAP4rev1）を更新し、リソースがサーバー上の場所を変更したときにクライアントがキャッシュデータをより効率的に再利用できるようにします。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8474.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8474で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 3
3. CAPABILITY Identification . . . . . . . . . . . . . . . . . . 3
4. MAILBOXID Object Identifier . . . . . . . . . . . . . . . . . 3
4.1. New Response Code for CREATE . . . . . . . . . . . . . . 4
4.2. New OK Untagged Response for SELECT and EXAMINE . . . . . 4
4.3. New Attribute for STATUS . . . . . . . . . . . . . . . . 5
5. EMAILID Object Identifier and THREADID Correlator . . . . . . 6
5.1. EMAILID Identifier for Identical Messages . . . . . . . . 6
5.2. THREADID Identifier for Related Messages . . . . . . . . 6
5.3. New Message Data Items in FETCH and UID FETCH Commands . 7
6. New Filters on SEARCH Command . . . . . . . . . . . . . . . . 9
7. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9
8. Implementation Considerations . . . . . . . . . . . . . . . . 10
8.1. Assigning Object Identifiers . . . . . . . . . . . . . . 10
8.2. Interaction with Special Cases . . . . . . . . . . . . . 11
8.3. Client Usage . . . . . . . . . . . . . . . . . . . . . . 11
8.4. Advice to Client Implementers . . . . . . . . . . . . . . 12
9. Future Considerations . . . . . . . . . . . . . . . . . . . . 12
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 13
12.1. Normative References . . . . . . . . . . . . . . . . . . 13
12.2. Informative References . . . . . . . . . . . . . . . . . 14
Appendix A. Ideas for Implementing Object Identifiers . . . . . 15
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16
IMAP stores are often used by many clients. Each client may cache data from the server so that it doesn't need to redownload information. [RFC3501] states that a mailbox can be uniquely referenced by its name and UIDVALIDITY, and a message within that mailbox can be uniquely referenced by its mailbox (name + UIDVALIDITY) and unique identifier (UID). The triple of mailbox name, UIDVALIDITY, and UID is guaranteed to be immutable.
IMAPストアは、多くのクライアントでよく使用されます。各クライアントはサーバーからのデータをキャッシュするため、情報を再ダウンロードする必要はありません。 [RFC3501]は、メールボックスはその名前とUIDVALIDITYによって一意に参照でき、そのメールボックス内のメッセージはそのメールボックス（名前+ UIDVALIDITY）と一意の識別子（UID）によって一意に参照できると述べています。メールボックス名、UIDVALIDITY、およびUIDのトリプルは、不変であることが保証されています。
[RFC4315] defines a COPYUID response that allows a client that copies messages to know the mapping between the UIDs in the source and destination mailboxes and, hence, update its local cache.
[RFC4315]は、メッセージをコピーするクライアントがソースメールボックスと宛先メールボックスのUID間のマッピングを認識し、ローカルキャッシュを更新できるようにするCOPYUID応答を定義します。
If a mailbox is successfully renamed by a client, that client will know that the same messages exist in the destination mailbox name as previously existed in the source mailbox name.
クライアントによってメールボックスの名前が正常に変更された場合、そのクライアントは、以前にソースメールボックス名に存在していたのと同じメッセージが宛先メールボックス名に存在することを認識します。
The result is that the client that copies (or moves [RFC6851]) messages or renames a mailbox can update its local cache, but any other client connected to the same store cannot know with certainty that the messages are identical, so it will redownload everything.
その結果、メッセージをコピー（または移動[RFC6851]）またはメールボックスの名前を変更するクライアントはローカルキャッシュを更新できますが、同じストアに接続されている他のクライアントはメッセージが同一であることを確実に認識できないため、すべてを再ダウンロードします。 。
This extension adds new properties to a message (EMAILID) and mailbox (MAILBOXID). These properties allow a client to quickly identify messages or mailboxes that have been renamed by another client.
この拡張機能は、メッセージ（EMAILID）およびメールボックス（MAILBOXID）に新しいプロパティを追加します。これらのプロパティにより、クライアントは別のクライアントによって名前が変更されたメッセージまたはメールボックスをすばやく識別できます。
This extension also adds an optional thread identifier (THREADID) to messages, which can be used by the server to indicate messages that it has identified to be related. A server that does not implement threading will return NIL to all requests for THREADID.
この拡張機能は、オプションのスレッド識別子（THREADID）をメッセージに追加します。これは、サーバーが使用して、関連すると識別されたメッセージを示すことができます。スレッドを実装しないサーバーは、THREADIDのすべての要求にNILを返します。
In examples, "C:" indicates lines sent by a client that is connected to a server. "S:" indicates lines sent by the server to the client.
例では、「C：」はサーバーに接続されているクライアントによって送信された行を示します。 「S：」は、サーバーからクライアントに送信される行を示します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
IMAP servers that support this extension MUST include "OBJECTID" in the response list to the CAPABILITY command.
この拡張機能をサポートするIMAPサーバーは、CAPABILITYコマンドへの応答リストに「OBJECTID」を含める必要があります。
The MAILBOXID is a server-allocated unique identifier for each mailbox.
MAILBOXIDは、メールボックスごとにサーバーが割り当てた一意の識別子です。
The server MUST return the same MAILBOXID for a mailbox with the same name and UIDVALIDITY.
サーバーは、同じ名前とUIDVALIDITYを持つメールボックスに対して同じMAILBOXIDを返さなければなりません（MUST）。
The server MUST NOT report the same MAILBOXID for two mailboxes at the same time.
サーバーは、2つのメールボックスに対して同じMAILBOXIDを同時に報告してはなりません（MUST NOT）。
The server MUST NOT reuse the same MAILBOXID for a mailbox that does not obey all the invariants that [RFC3501] defines for a mailbox that does not change name or UIDVALIDITY.
サーバーは、名前またはUIDVALIDITYを変更しないメールボックスに対して[RFC3501]が定義するすべての不変式に従わないメールボックスに同じMAILBOXIDを再利用してはなりません（MUST NOT）。
The server MUST keep the same MAILBOXID for the source and destination when renaming a mailbox in a way that keeps the same messages (but see [RFC3501] for the special case regarding the renaming of INBOX, which is treated as creating a new mailbox and moving the messages).
サーバーは、同じメッセージを保持する方法でメールボックスの名前を変更するとき、送信元と宛先の同じMAILBOXIDを保持する必要があります（ただし、新しいメールボックスの作成と移動として扱われるINBOXの名前変更に関する特別なケースについては、[RFC3501]を参照してください）メッセージ）。
This document extends the CREATE command to have the response code MAILBOXID on successful mailbox creation.
このドキュメントでは、CREATEコマンドを拡張して、メールボックスが正常に作成されたときに応答コードMAILBOXIDを取得します。
A server advertising the OBJECTID capability MUST include the MAILBOXID response code in the tagged OK response to all successful CREATE commands.
OBJECTID機能をアドバタイズするサーバーは、すべての成功したCREATEコマンドへのタグ付きOK応答にMAILBOXID応答コードを含める必要があります。
Syntax: "MAILBOXID" SP "(" objectid ")"
構文： "MAILBOXID" SP "（" objectid "）"
Response code in tagged OK response for successful CREATE command.
CREATEコマンドが成功した場合のタグ付きOK応答の応答コード。
Example:
例：
C: 3 create foo
S: 3 OK [MAILBOXID (F2212ea87-6097-4256-9d51-71338625)] Completed
C: 4 create bar
S: 4 OK [MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3)] Completed
C: 5 create foo
S: 5 NO Mailbox already exists
This document adds a new untagged response code to the SELECT and EXAMINE commands.
このドキュメントは、新しいタグなし応答コードをSELECTコマンドとEXAMINEコマンドに追加します。
A server advertising the OBJECTID capability MUST return an untagged OK response with the MAILBOXID response code on all successful SELECT and EXAMINE commands.
OBJECTID機能をアドバタイズするサーバーは、成功したすべてのSELECTおよびEXAMINEコマンドで、MAILBOXID応答コードとともにタグなしのOK応答を返さなければなりません（MUST）。
Syntax: "OK" SP "[" "MAILBOXID" SP "(" objectid ")" "]" SP text
構文： "OK" SP "[" "MAILBOXID" SP "（" objectid "）" "]" SPテキスト
Untagged OK response to SELECT or EXAMINE.
SELECTまたはEXAMINEへのタグなしOK応答。
Example:
例：
C: 27 select "foo"
[...]
S: * OK [MAILBOXID (F2212ea87-6097-4256-9d51-71338625)] Ok
[...]
S: 27 OK [READ-WRITE] Completed
This document adds the MAILBOXID attribute to the STATUS command using the extended syntax defined in [RFC4466].
このドキュメントは、[RFC4466]で定義されている拡張構文を使用して、STATUSコマンドにMAILBOXID属性を追加します。
A server that advertises the OBJECTID capability MUST support the MAILBOXID status attribute.
OBJECTID機能をアドバタイズするサーバーは、MAILBOXIDステータス属性をサポートする必要があります。
Syntax: "MAILBOXID"
構文： "MAILBOXID"
The attribute in the STATUS command.
STATUSコマンドの属性。
Syntax: "MAILBOXID" SP "(" objectid ")"
構文： "MAILBOXID" SP "（" objectid "）"
The response item in the STATUS response contains the ObjectID assigned by the server for this mailbox.
STATUS応答の応答アイテムには、サーバーがこのメールボックスに割り当てたObjectIDが含まれています。
Example:
例：
C: 6 status foo (mailboxid)
S: * STATUS foo (MAILBOXID (F2212ea87-6097-4256-9d51-71338625))
S: 6 OK Completed
C: 7 status bar (mailboxid)
S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3))
S: 7 OK Completed
C: 8 rename foo renamed
S: * OK rename foo renamed
S: 8 OK Completed
C: 9 status renamed (mailboxid)
S: * STATUS renamed (MAILBOXID (F2212ea87-6097-4256-9d51-71338625))
S: 9 OK Completed
C: 10 status bar (mailboxid)
S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3))
S: 10 OK Completed
When the LIST-STATUS IMAP capability defined in [RFC5819] is also available, the STATUS command can be combined with the LIST command.
[RFC5819]で定義されているLIST-STATUS IMAP機能も使用できる場合、STATUSコマンドをLISTコマンドと組み合わせることができます。
Example:
例：
C: 11 list "" "*" return (status (mailboxid))
S: * LIST (\HasNoChildren) "." INBOX
S: * STATUS INBOX (MAILBOXID (Ff8e3ead4-9389-4aff-adb1-d8d89efd8cbf))
S: * LIST (\HasNoChildren) "." bar
S: * STATUS bar (MAILBOXID (F6352ae03-b7f5-463c-896f-d8b48ee3))
S: * LIST (\HasNoChildren) "." renamed
S: * STATUS renamed (MAILBOXID (F2212ea87-6097-4256-9d51-71338625))
S: 11 OK Completed (0.001 secs 3 calls)
The EMAILID data item is an ObjectID that uniquely identifies the content of a single message. Anything that must remain immutable on a {name, uidvalidity, uid} triple must also be the same between messages with the same EMAILID.
EMAILIDデータ項目は、単一のメッセージのコンテンツを一意に識別するObjectIDです。 {name、uidvalidity、uid}トリプルで不変である必要があるものは、同じEMAILIDを持つメッセージ間でも同じである必要があります。
The server MUST return the same EMAILID for the same triple; hence, EMAILID is immutable.
サーバーは同じトリプルの同じメールIDを返さなければなりません。したがって、EMAIL IDは不変です。
The server MUST return the same EMAILID as the source message for the matching destination message in the COPYUID pairing after a COPY or MOVE command [RFC6851].
サーバーは、COPYまたはMOVEコマンド[RFC6851]の後、COPYUIDペアで一致する宛先メッセージのソースメッセージと同じEMAILIDを返さなければなりません（MUST）。
The server MAY assign the same EMAILID as an existing message upon APPEND (e.g., if it detects that the new message has exactly identical content to that of an existing message).
サーバーは、APPEND時に既存のメッセージと同じEMAILIDを割り当てることができます（たとえば、新しいメッセージが既存のメッセージとまったく同じ内容であることを検出した場合）。
NOTE: EMAILID only identifies the immutable content of the message. In particular, it is possible for different messages with the same EMAILID to have different keywords. This document does not specify a way to STORE by EMAILID.
注：EMAILIDは、メッセージの不変のコンテンツのみを識別します。特に、同じEMAILIDを持つ異なるメッセージが異なるキーワードを持つ可能性があります。このドキュメントでは、EMAILIDでSTOREする方法を指定していません。
The THREADID data item is an ObjectID that uniquely identifies a set of messages that the server believes should be grouped together when presented.
THREADIDデータ項目は、サーバーが提示されたときにグループ化する必要があるとサーバーが信じるメッセージのセットを一意に識別するObjectIDです。
THREADID calculation is generally based on some combination of References, In-Reply-To, and Subject, but the exact logic is left up to the server implementation. [RFC5256] describes some algorithms that could be used; however, this specification does not mandate any particular strategy.
THREADIDの計算は通常、参照、In-Reply-To、Subjectのいくつかの組み合わせに基づいていますが、正確なロジックはサーバーの実装に任されています。 [RFC5256]は、使用できるいくつかのアルゴリズムについて説明しています。ただし、この仕様は特定の戦略を義務付けていません。
The server MUST return the same THREADID for all messages with the same EMAILID.
サーバーは、同じEMAILIDを持つすべてのメッセージに対して同じTHREADIDを返す必要があります。
The server SHOULD return the same THREADID for related messages, even if they are in different mailboxes; for example, messages that would appear in the same thread if they were in the same mailbox SHOULD have the same THREADID, even if they are in different mailboxes.
サーバーは、それらが異なるメールボックスにある場合でも、関連するメッセージに対して同じTHREADIDを返す必要があります（SHOULD）。たとえば、同じメールボックスにある場合に同じスレッドに表示されるメッセージは、異なるメールボックスにある場合でも、同じTHREADIDを持つ必要があります。
The server MUST NOT change the THREADID of a message once reported.
サーバーは、一度報告されたメッセージのTHREADIDを変更してはなりません（MUST NOT）。
THREADID is OPTIONAL; if the server doesn't support THREADID or is unable to calculate relationships between messages, it MUST return NIL to all FETCH responses for the THREADID data item, and a SEARCH for THREADID MUST NOT match any messages.
THREADIDはオプションです。サーバーがTHREADIDをサポートしていないか、メッセージ間の関係を計算できない場合、サーバーはTHREADIDデータ項目のすべてのFETCH応答にNILを返さなければならず（MUST）、THREADIDの検索はどのメッセージとも一致してはなりません（MUST NOT）。
The server MUST NOT use the same ObjectID value for both EMAILIDs and THREADIDs. If they are stored with the same value internally, the server can generate prefixed values (as shown in the examples below with M and T prefixes) to avoid clashes.
サーバーは、EMAILIDとTHREADIDの両方に同じObjectID値を使用してはなりません（MUST NOT）。それらが同じ値で内部的に格納されている場合、サーバーはプレフィックス値を生成して（以下の例でMおよびTプレフィックスを使用して）、衝突を回避できます。
This document defines two FETCH items:
このドキュメントでは、2つのFETCHアイテムを定義しています。
Syntax: "EMAILID"
構文： "EMAILID"
The EMAILID message data item causes the server to return EMAILID FETCH response data items.
EMAIL IDメッセージデータ項目により、サーバーはEMAIL ID FETCH応答データ項目を返します。
Syntax: "THREADID"
構文： "THREADID"
The THREADID message data item causes the server to return THREADID FETCH response data items.
THREADIDメッセージデータ項目により、サーバーはTHREADID FETCH応答データ項目を返します。
This document defines the following responses:
このドキュメントでは、次の応答を定義しています。
Syntax: "EMAILID" SP "(" objectid ")"
構文： "EMAILID" SP "（" objectid "）"
The EMAILID response data item contains the server-assigned ObjectID for each message.
EMAILID応答データ項目には、各メッセージにサーバーが割り当てたObjectIDが含まれています。
Syntax: "THREADID" SP "(" objectid ")"
構文： "THREADID" SP "（" objectid "）"
The THREADID response data item contains the server-assigned ObjectID for the set of related messages to which this message belongs.
THREADID応答データ項目には、このメッセージが属する一連の関連メッセージにサーバーが割り当てたObjectIDが含まれています。
Syntax: "THREADID" SP nil
構文： "THREADID" SP nil
The NIL value is returned for the THREADID response data item when the server mailbox does not support THREADID calculation.
サーバーのメールボックスがTHREADID計算をサポートしていない場合、THREADID応答データ項目のNIL値が返されます。
Example:
例：
C: 5 append inbox "20-Mar-2018 03:07:37 +1100" {733}
[...]
Subject: Message A
Message-ID: <fake.1521475657.54797@example.com>
[...]
S: 5 OK [APPENDUID 1521475658 1] Completed
C: 11 append inbox "20-Mar-2018 03:07:37 +1100" {793}
[...]
Subject: Re: Message A
Message-ID: <fake.1521475657.21213@example.org>
References: <fake.1521475657.54797@example.com>
[...]
S: 11 OK [APPENDUID 1521475658 2] Completed
C: 17 append inbox "20-Mar-2018 03:07:37 +1100" {736}
[...]
Subject: Message C
Message-ID: <fake.1521475657.60280@example.com>
[...]
S: 17 OK [APPENDUID 1521475658 3] Completed
C: 22 fetch 1:* (emailid threadid)
S: * 1 FETCH (EMAILID (M6d99ac3275bb4e) THREADID (T64b478a75b7ea9))
S: * 2 FETCH (EMAILID (M288836c4c7a762) THREADID (T64b478a75b7ea9))
S: * 3 FETCH (EMAILID (M5fdc09b49ea703) THREADID (T11863d02dd95b5))
S: 22 OK Completed (0.000 sec)
C: 23 move 2 foo
S: * OK [COPYUID 1521475659 2 1] Completed
S: * 2 EXPUNGE
S: 23 OK Completed
C: 24 fetch 1:* (emailid threadid)
S: * 1 FETCH (EMAILID (M6d99ac3275bb4e) THREADID (T64b478a75b7ea9))
S: * 2 FETCH (EMAILID (M5fdc09b49ea703) THREADID (T11863d02dd95b5))
S: 24 OK Completed (0.000 sec)
C: 25 select "foo"
C: 25 select "foo"
[...]
S: 25 OK [READ-WRITE] Completed
C: 26 fetch 1:* (emailid threadid)
S: * 1 FETCH (EMAILID (M288836c4c7a762) THREADID (T64b478a75b7ea9))
S: 26 OK Completed (0.000 sec)
Example: (no THREADID support)
例：（THREADIDサポートなし）
C: 26 fetch 1:* (emailid threadid)
S: * 1 FETCH (EMAILID (M00000001) THREADID NIL)
S: * 2 FETCH (EMAILID (M00000002) THREADID NIL)
S: 26 OK Completed (0.000 sec)
This document defines the filters EMAILID and THREADID on the SEARCH command.
このドキュメントでは、SEARCHコマンドのフィルターEMAIL IDとTHREAD IDを定義します。
Syntax: "EMAILID" SP objectid
構文： "EMAILID" SPオブジェクトID
Messages whose EMAILID is exactly the specified ObjectID.
EMAILIDが指定されたObjectIDと完全に一致するメッセージ。
Syntax: "THREADID" SP objectid
構文： "THREADID" SPオブジェクトID
Messages whose THREADID is exactly the specified ObjectID.
THREADIDが指定されたObjectIDと完全に一致するメッセージ。
Example: (as if run before the MOVE shown above when the mailbox had three messages)
例：（メールボックスに3つのメッセージがあったときに、上記のMOVEの前に実行されたかのように）
C: 27 search emailid M6d99ac3275bb4e
S: * SEARCH 1
S: 27 OK Completed (1 msgs in 0.000 secs)
C: 28 search threadid T64b478a75b7ea9
S: * SEARCH 1 2
S: 28 OK Completed (2 msgs in 0.000 secs)
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) [RFC5234] notation. Elements not defined here can be found in the formal syntax of the ABNF [RFC5234], IMAP [RFC3501], and IMAP ABNF extensions [RFC4466] specifications.
次の構文仕様では、拡張バッカスナウアフォーム（ABNF）[RFC5234]表記を使用しています。ここで定義されていない要素は、ABNF [RFC5234]、IMAP [RFC3501]、およびIMAP ABNF拡張[RFC4466]仕様の正式な構文にあります。
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.
特に明記しない限り、すべてのアルファベット文字は大文字と小文字を区別しません。トークン文字列を定義するための大文字または小文字の使用は、編集上の明確さのためだけです。実装は、大文字と小文字を区別しない方法でこれらの文字列を受け入れる必要があります。
Please note specifically that ObjectID values are case sensitive.
特に、ObjectID値は大文字と小文字が区別されることに注意してください。
capability =/ "OBJECTID"
機能= / "OBJECTID"
fetch-att =/ "EMAILID" / "THREADID"
fetch-emailid-resp = "EMAILID" SP "(" objectid ")" ; follows tagged-ext production from [RFC4466]
fetch-emailid-resp = "EMAILID" SP "（" objectid "）"; [RFC4466]からタグ付けされたextプロダクションに従います
fetch-threadid-resp = "THREADID" SP ( "(" objectid ")" / nil )
; follows tagged-ext production from [RFC4466]
msg-att-static =/ fetch-emailid-resp / fetch-threadid-resp
objectid = 1*255(ALPHA / DIGIT / "_" / "-")
; characters in object identifiers are case
; significant
resp-text-code =/ "MAILBOXID" SP "(" objectid ")"
; incorporated before the expansion rule of
; atom [SP 1*<any TEXT-CHAR except "]">]
; that appears in [RFC3501]
search-key =/ "EMAILID" SP objectid / "THREADID" SP objectid
status-att =/ "MAILBOXID"
status-att = / "MAILBOXID"
status-att-val =/ "MAILBOXID" SP "(" objectid ")"
; follows tagged-ext production from [RFC4466]
All ObjectID values are allocated by the server.
すべてのObjectID値はサーバーによって割り当てられます。
In the interest of reducing the possibilities of encoding mistakes, ObjectIDs are restricted to a safe subset of possible byte values; in order to allow clients to allocate storage, they are restricted in length.
エンコードの誤りの可能性を減らすために、ObjectIDは可能なバイト値の安全なサブセットに制限されています。クライアントがストレージを割り当てることができるようにするために、長さに制限があります。
An ObjectID is a string of 1 to 255 characters from the following set of 64 codepoints: a-z, A-Z, 0-9, _, -. These characters are safe to use in almost any context (e.g., filesystems, URIs, IMAP atoms). These are the same characters defined as base64url in [RFC4648].
ObjectIDは、64個のコードポイントのセット（a-z、A-Z、0-9、_、-）の1〜255文字の文字列です。これらの文字は、ほぼすべてのコンテキスト（ファイルシステム、URI、IMAPアトムなど）で安全に使用できます。これらは、[RFC4648]でbase64urlとして定義されているのと同じ文字です。
For maximum safety, servers should also follow defensive allocation strategies to avoid creating risks where glob completion or data type detection may be present (e.g., on filesystems or in spreadsheets). In particular, it is wise to avoid:
安全性を最大にするために、サーバーは防御的な割り当て戦略にも従う必要があります。これにより、グロブの完了やデータタイプの検出が存在する可能性があるリスクが発生しなくなります（たとえば、ファイルシステムやスプレッドシート）。特に、次のことは避けるのが賢明です。
o IDs starting with a dash
o ダッシュで始まるID
o IDs starting with digits
o 数字で始まるID
o IDs that contain only digits
o 数字のみを含むID
o IDs that differ only by ASCII case (for example, A vs. a)
o ASCIIケースのみが異なるID（たとえば、Aとa）
o the specific sequence of three characters NIL in any case (because this sequence can be confused with the IMAP protocol expression of the null value)
o いずれの場合も3文字のNILの特定のシーケンス（このシーケンスは、null値のIMAPプロトコル式と混同される可能性があるため）
A good solution to these issues is to prefix every ID with a single alphabetical character.
これらの問題に対する適切な解決策は、すべてのIDの前に単一のアルファベット文字を付けることです。
The case of RENAME INBOX may need special handling because it has special behavior, as defined in [RFC3501], Section 6.3.5.
[受信トレイの名前を変更]のケースは、[RFC3501]のセクション6.3.5で定義されているように、特別な動作をするため、特別な処理が必要になる場合があります。
It is advisable (though not required) to have MAILBOXID be globally unique, but it is only required to be unique within messages offered to a single client login to a single server hostname. For example, a proxy that aggregates multiple independent servers MUST NOT advertise the OBJECTID capability unless it can guarantee that different objects will never use the same identifiers, even if backend object identifiers collide.
MAILBOXIDをグローバルに一意にすることをお勧めします（必須ではありません）が、単一のサーバーホスト名への単一のクライアントログインに提供されるメッセージ内でのみ一意である必要があります。たとえば、複数の独立したサーバーを集約するプロキシは、たとえバックエンドオブジェクト識別子が衝突したとしても、異なるオブジェクトが同じ識別子を使用しないことを保証できない限り、OBJECTID機能をアドバタイズしてはなりません。
Servers that implement both RFC 6154 and this specification should optimize their execution of commands like UID SEARCH OR EMAILID 1234 EMAILID 4321.
RFC 6154とこの仕様の両方を実装するサーバーは、UID SEARCH OR EMAILID 1234 EMAILID 4321などのコマンドの実行を最適化する必要があります。
Clients can assume that searching the all-mail mailbox using OR/ EMAILID or OR/THREADID is a fast way to find messages again if some other client has moved them out of the mailbox where they were previously seen.
クライアントは、OR / EMAILIDまたはOR / THREADIDを使用して全メールのメールボックスを検索すると、以前に表示されていたメールボックスから他のクライアントがメッセージを移動した場合に、メッセージをすばやく見つけることができると想定できます。
Clients that cache data offline should fetch the EMAILID of all new messages to avoid redownloading already-cached message details.
データをオフラインでキャッシュするクライアントは、すべての新しいメッセージのEMAIL IDをフェッチして、すでにキャッシュされているメッセージの詳細を再ダウンロードしないようにする必要があります。
Clients should fetch the MAILBOXID for any new mailboxes before discarding cache data for any mailbox that is no longer present on the server so that they can detect renames and avoid redownloading data.
クライアントは、サーバーに存在しないメールボックスのキャッシュデータを破棄する前に、新しいメールボックスのMAILBOXIDをフェッチして、名前の変更を検出し、データの再ダウンロードを回避する必要があります。
In cases of server failure and disaster recovery, or misbehaving servers, it is possible that a client will be sent invalid information, e.g., identical ObjectIDs or ObjectIDs that have changed where they MUST NOT change according to this document.
サーバーの障害や災害復旧、またはサーバーの動作に問題がある場合、クライアントに無効な情報が送信される可能性があります。
In a case where a client detects inconsistent ObjectID responses from a server, it SHOULD fall back to relying on the guarantees of RFC 3501. For simplicity, a client MAY instead choose to discard its entire cache and resync all state from the server.
クライアントがサーバーから一貫性のないObjectID応答を検出した場合、クライアントはRFC 3501の保証に依存してフォールバックする必要があります。簡単にするために、クライアントは代わりにキャッシュ全体を破棄し、サーバーからすべての状態を再同期することを選択できます（MAY）。
Client authors protecting against server misbehavior MUST ensure that their design cannot get into an infinite loop of discarding cache and fetching the same data repeatedly without user interaction.
サーバーの誤動作から保護するクライアントの作成者は、ユーザーの操作なしに、キャッシュを破棄して同じデータを繰り返しフェッチする無限ループに入らないようにする必要があります。
This extension is intentionally defined to be compatible with the data model in [JMAP-MAIL].
この拡張は、[JMAP-MAIL]のデータモデルと互換性があるように意図的に定義されています。
A future extension could be proposed to give a way to SELECT a mailbox by MAILBOXID rather than name.
名前ではなくMAILBOXIDでメールボックスを選択する方法を提供するために、将来の拡張が提案される可能性があります。
A future extension to [RFC5228] could allow fileinto by MAILBOXID rather than name.
[RFC5228]の将来の拡張では、名前ではなくMAILBOXIDによるファイルへのアクセスを許可する可能性があります。
An extension to allow fetching message content directly via EMAILID and message listings by THREADID could be proposed.
EMAIL IDを介してメッセージコンテンツを直接取得できる拡張機能と、THREAD IDによるメッセージリストを提案できます。
IANA has added "OBJECTID" to the "IMAP Capabilities" registry located at <https://www.iana.org/assignments/imap-capabilities> with a reference to this document.
IANAは、このドキュメントへの参照とともに、<OBJECTID "を<https://www.iana.org/assignments/imap-capabilities>にある" IMAP Capabilities "レジストリに追加しました。
IANA has added "MAILBOXID" to the "IMAP Response Codes" registry located at <https://www.iana.org/assignments/imap-response-codes> with a reference to this document.
IANAは、このドキュメントを参照して、<MAILBOXID "を<https://www.iana.org/assignments/imap-response-codes>にある" IMAP Response Codes "レジストリに追加しました。
It is strongly advised that servers generate ObjectIDs that are safe to use as filesystem names and unlikely to be autodetected as numbers. See implementation considerations.
サーバーは、ファイルシステム名として安全に使用でき、数値として自動検出される可能性が低いObjectIDを生成することを強くお勧めします。実装に関する考慮事項を参照してください。
If a digest is used for ID generation, it must have a collision-resistant property, so server implementations are advised to monitor current security research and choose secure digests. As the IDs are generated by the server, it will be possible to migrate to a new hash by just using the new algorithm when creating new IDs. This is particularly true if a prefix is used on each ID, which can be changed when the algorithm changes.
IDの生成にダイジェストを使用する場合は、耐衝突性を備えている必要があるため、サーバーの実装では、現在のセキュリティ調査を監視し、安全なダイジェストを選択することをお勧めします。 IDはサーバーによって生成されるため、新しいIDを作成するときに新しいアルゴリズムを使用するだけで、新しいハッシュに移行できます。これは、各IDでプレフィックスが使用されている場合に特に当てはまります。これは、アルゴリズムが変更されたときに変更できます。
The use of a digest for ID generation may be used as proof that a particular sequence of bytes was seen by the server. However, this is only a risk if IDs are leaked to clients who don't have permission to fetch the data directly. Servers that are expected to handle highly sensitive data should consider this when choosing how to create IDs.
ID生成にダイジェストを使用することは、特定のバイトシーケンスがサーバーによって認識されたことの証明として使用できます。ただし、これは、データを直接フェッチする権限を持たないクライアントにIDが漏洩した場合のリスクにすぎません。非常に機密性の高いデータを処理することが予想されるサーバーは、IDの作成方法を選択するときにこれを考慮する必要があります。
See also the security considerations in [RFC3501], Section 11.
[RFC3501]のセクション11のセキュリティに関する考慮事項もご覧ください。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https://www.rfc-editor.org/info/ rfc2119>。
[RFC3501] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, <https://www.rfc-editor.org/info/rfc3501>.
[RFC3501] Crispin、M。、「インターネットメッセージアクセスプロトコル-バージョン4rev1」、RFC 3501、DOI 10.17487 / RFC3501、2003年3月、<https://www.rfc-editor.org/info/rfc3501>。
[RFC4315] Crispin, M., "Internet Message Access Protocol (IMAP) - UIDPLUS extension", RFC 4315, DOI 10.17487/RFC4315, December 2005, <https://www.rfc-editor.org/info/rfc4315>.
[RFC4315] Crispin、M。、「インターネットメッセージアクセスプロトコル（IMAP）-UIDPLUS拡張」、RFC 4315、DOI 10.17487 / RFC4315、2005年12月、<https://www.rfc-editor.org/info/rfc4315>。
[RFC4466] Melnikov, A. and C. Daboo, "Collected Extensions to IMAP4 ABNF", RFC 4466, DOI 10.17487/RFC4466, April 2006, <https://www.rfc-editor.org/info/rfc4466>.
[RFC4466] Melnikov、A。およびC. Daboo、「IMAP4 ABNFに対する収集された拡張機能」、RFC 4466、DOI 10.17487 / RFC4466、2006年4月、<https://www.rfc-editor.org/info/rfc4466>。
[RFC5228] Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email Filtering Language", RFC 5228, DOI 10.17487/RFC5228, January 2008, <https://www.rfc-editor.org/info/rfc5228>.
[RFC5228] Guenther、P.、Ed。 T. Showalter、Ed。、「Sieve：An Email Filtering Language」、RFC 5228、DOI 10.17487 / RFC5228、2008年1月、<https://www.rfc-editor.org/info/rfc5228>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234]クロッカー、D。、エド。およびP. Overell、「構文仕様の拡張BNF：ABNF」、STD 68、RFC 5234、DOI 10.17487 / RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。
[RFC5256] Crispin, M. and K. Murchison, "Internet Message Access Protocol - SORT and THREAD Extensions", RFC 5256, DOI 10.17487/RFC5256, June 2008, <https://www.rfc-editor.org/info/rfc5256>.
[RFC5256] Crispin、M。およびK. Murchison、「インターネットメッセージアクセスプロトコル-SORTおよびTHREAD拡張機能」、RFC 5256、DOI 10.17487 / RFC5256、2008年6月、<https://www.rfc-editor.org/info/ rfc5256>。
[RFC5819] Melnikov, A. and T. Sirainen, "IMAP4 Extension for Returning STATUS Information in Extended LIST", RFC 5819, DOI 10.17487/RFC5819, March 2010, <https://www.rfc-editor.org/info/rfc5819>.
[RFC5819] Melnikov、A。およびT. Sirainen、「拡張リストでステータス情報を返すためのIMAP4拡張機能」、RFC 5819、DOI 10.17487 / RFC5819、2010年3月、<https://www.rfc-editor.org/info/ rfc5819>。
[RFC6851] Gulbrandsen, A. and N. Freed, Ed., "Internet Message Access Protocol (IMAP) - MOVE Extension", RFC 6851, DOI 10.17487/RFC6851, January 2013, <https://www.rfc-editor.org/info/rfc6851>.
[RFC6851] Gulbrandsen、A。およびN. Freed、編、「インターネットメッセージアクセスプロトコル（IMAP）-MOVE拡張機能」、RFC 6851、DOI 10.17487 / RFC6851、2013年1月、<https：//www.rfc-editor。 org / info / rfc6851>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https://www.rfc-editor.org/info/ rfc8174>。
[JMAP-MAIL] Jenkins, N. and C. Newman, "JMAP for Mail", Work in Progress, draft-ietf-jmap-mail-07, August 2018.
[JMAP-MAIL] Jenkins、N。およびC. Newman、「JMAP for Mail」、Work in Progress、draft-ietf-jmap-mail-07、2018年8月。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <https://www.rfc-editor.org/info/rfc4122>.
[RFC4122] Leach、P.、Mealling、M。、およびR. Salz、「Universally Unique IDentifier（UUID）URN Namespace」、RFC 4122、DOI 10.17487 / RFC4122、2005年7月、<https：//www.rfc- editor.org/info/rfc4122>。
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/info/rfc4648>.
[RFC4648] Josefsson、S。、「The Base16、Base32、およびBase64データエンコーディング」、RFC 4648、DOI 10.17487 / RFC4648、2006年10月、<https://www.rfc-editor.org/info/rfc4648>。
Ideas for calculating MAILBOXID:
MAILBOXIDを計算するためのアイデア：
o Universally Unique Identifier (UUID) [RFC4122]
o Universally Unique Identifier（UUID）[RFC4122]
o Server-assigned sequence number (guaranteed not to be reused)
o サーバーが割り当てたシーケンス番号（再利用されないことが保証されています）
Ideas for implementing EMAILID:
メールIDの実装に関するアイデア：
o Digest of message content (RFC822 bytes) -- expensive unless cached
o メッセージコンテンツのダイジェスト（RFC822バイト）-キャッシュしない限り高コスト
o UUID [RFC4122]
o UUID [RFC4122]
o Server-assigned sequence number (guaranteed not to be reused)
o サーバーが割り当てたシーケンス番号（再利用されないことが保証されています）
Ideas for implementing THREADID:
THREADIDを実装するためのアイデア：
o Derive from EMAILID of first seen message in the thread.
o スレッドで最初に見つかったメッセージの電子メールIDから派生します。
o UUID [RFC4122]
o UUID [RFC4122]
o Server-assigned sequence number (guaranteed not to be reused)
o サーバーが割り当てたシーケンス番号（再利用されないことが保証されています）
There is a need to index and look up reference/in-reply-to data at message creation to efficiently find matching messages for threading. Threading may be either across mailboxes or within each mailbox only. The server has significant leeway here.
スレッド化に一致するメッセージを効率的に見つけるには、メッセージの作成時に参照/返信先データにインデックスを付けて検索する必要があります。スレッド化は、メールボックス全体または各メールボックス内でのみ可能です。ここではサーバーにかなりの余裕があります。
Acknowledgments
謝辞
The author would like to thank the EXTRA working group at IETF for feedback and advice -- in particular, Arnt Gulbrandsen, Brandon Long, Chris Newman, and Josef Sipek.
著者は、フィードバックとアドバイスを提供してくれたIETFのEXTRAワーキンググループ、特にArnt Gulbrandsen、Brandon Long、Chris Newman、およびJosef Sipekに感謝します。
This document drew inspiration from the Gmail X-GM-THRID and X-GM-MSGID implementations as currently defined at <https://developers.google.com/gmail/imap/imap-extensions>, as well as the X-GUID implementation in the Dovecot server.
このドキュメントは、現在<https://developers.google.com/gmail/imap/imap-extensions>で定義されているGmailのX-GM-THRIDとX-GM-MSGIDの実装、およびX-GUIDから着想を得ていますDovecotサーバーでの実装。
Author's Address
著者のアドレス
Bron Gondwana (editor) FastMail Level 2, 114 William St Melbourne VIC 3000 Australia
Bron Gondwana（editor）FastMail Level 2、114 William St Melbourne VIC 3000 Australia
Email: brong@fastmailteam.com
URI: https://www.fastmail.com