[要約] RFC 8620は、JMAP（JSON Meta Application Protocol）に関する規格であり、メールやカレンダーなどのアプリケーションデータの同期や操作を効率的に行うためのプロトコルです。目的は、既存のプロトコルよりもシンプルで効率的なデータ同期を実現し、開発者に使いやすいAPIを提供することです。
Internet Engineering Task Force (IETF) N. Jenkins
Request for Comments: 8620 Fastmail
Category: Standards Track C. Newman
ISSN: 2070-1721 Oracle
July 2019
The JSON Meta Application Protocol (JMAP)
JSONメタアプリケーションプロトコル（JMAP）
Abstract
概要
This document specifies a protocol for clients to efficiently query, fetch, and modify JSON-based data objects, with support for push notification of changes and fast resynchronisation and for out-of-band binary data upload/download.
このドキュメントは、クライアントがJSONベースのデータオブジェクトを効率的にクエリ、フェッチ、および変更するためのプロトコルを示しています。変更のプッシュ通知と高速再同期、および帯域外のバイナリデータのアップロード/ダウンロードがサポートされています。
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/rfc8620.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8620で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Notational Conventions . . . . . . . . . . . . . . . . . 4
1.2. The Id Data Type . . . . . . . . . . . . . . . . . . . . 6
1.3. The Int and UnsignedInt Data Types . . . . . . . . . . . 6
1.4. The Date and UTCDate Data Types . . . . . . . . . . . . . 7
1.5. JSON as the Data Encoding Format . . . . . . . . . . . . 7
1.6. Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
1.6.1. User . . . . . . . . . . . . . . . . . . . . . . . . 7
1.6.2. Accounts . . . . . . . . . . . . . . . . . . . . . . 7
1.6.3. Data Types and Records . . . . . . . . . . . . . . . 8
1.7. The JMAP API Model . . . . . . . . . . . . . . . . . . . 8
1.8. Vendor-Specific Extensions . . . . . . . . . . . . . . . 9
2. The JMAP Session Resource . . . . . . . . . . . . . . . . . . 9
2.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2. Service Autodiscovery . . . . . . . . . . . . . . . . . . 15
3. Structured Data Exchange . . . . . . . . . . . . . . . . . . 16
3.1. Making an API Request . . . . . . . . . . . . . . . . . . 16
3.2. The Invocation Data Type . . . . . . . . . . . . . . . . 16
3.3. The Request Object . . . . . . . . . . . . . . . . . . . 16
3.3.1. Example Request . . . . . . . . . . . . . . . . . . . 18
3.4. The Response Object . . . . . . . . . . . . . . . . . . . 18
3.4.1. Example Response . . . . . . . . . . . . . . . . . . 19
3.5. Omitting Arguments . . . . . . . . . . . . . . . . . . . 19
3.6. Errors . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.6.1. Request-Level Errors . . . . . . . . . . . . . . . . 20
3.6.2. Method-Level Errors . . . . . . . . . . . . . . . . . 21
3.7. References to Previous Method Results . . . . . . . . . . 22
3.8. Localisation of User-Visible Strings . . . . . . . . . . 27
3.9. Security . . . . . . . . . . . . . . . . . . . . . . . . 28
3.10. Concurrency . . . . . . . . . . . . . . . . . . . . . . . 28
4. The Core/echo Method . . . . . . . . . . . . . . . . . . . . 28
4.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 28
5. Standard Methods and Naming Convention . . . . . . . . . . . 29
5.1. /get . . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.2. /changes . . . . . . . . . . . . . . . . . . . . . . . . 30
5.3. /set . . . . . . . . . . . . . . . . . . . . . . . . . . 34
5.4. /copy . . . . . . . . . . . . . . . . . . . . . . . . . . 40
5.5. /query . . . . . . . . . . . . . . . . . . . . . . . . . 42
5.6. /queryChanges . . . . . . . . . . . . . . . . . . . . . . 48
5.7. Examples . . . . . . . . . . . . . . . . . . . . . . . . 51
5.8. Proxy Considerations . . . . . . . . . . . . . . . . . . 58
6. Binary Data . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.1. Uploading Binary Data . . . . . . . . . . . . . . . . . . 59
6.2. Downloading Binary Data . . . . . . . . . . . . . . . . . 60
6.3. Blob/copy . . . . . . . . . . . . . . . . . . . . . . . . 61
7. Push . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
7.1. The StateChange Object . . . . . . . . . . . . . . . . . 63
7.1.1. Example . . . . . . . . . . . . . . . . . . . . . . . 64
7.2. PushSubscription . . . . . . . . . . . . . . . . . . . . 64
7.2.1. PushSubscription/get . . . . . . . . . . . . . . . . 67
7.2.2. PushSubscription/set . . . . . . . . . . . . . . . . 68
7.2.3. Example . . . . . . . . . . . . . . . . . . . . . . . 69
7.3. Event Source . . . . . . . . . . . . . . . . . . . . . . 71
8. Security Considerations . . . . . . . . . . . . . . . . . . . 73
8.1. Transport Confidentiality . . . . . . . . . . . . . . . . 73
8.2. Authentication Scheme . . . . . . . . . . . . . . . . . . 73
8.3. Service Autodiscovery . . . . . . . . . . . . . . . . . . 73
8.4. JSON Parsing . . . . . . . . . . . . . . . . . . . . . . 74
8.5. Denial of Service . . . . . . . . . . . . . . . . . . . . 74
8.6. Connection to Unknown Push Server . . . . . . . . . . . . 74
8.7. Push Encryption . . . . . . . . . . . . . . . . . . . . . 75
8.8. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 76
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 76
9.1. Assignment of jmap Service Name . . . . . . . . . . . . . 76
9.2. Registration of Well-Known URI Suffix for JMAP . . . . . 76
9.3. Registration of the jmap URN Sub-namespace . . . . . . . 77
9.4. Creation of "JMAP Capabilities" Registry . . . . . . . . 77
9.4.1. Preliminary Community Review . . . . . . . . . . . . 77
9.4.2. Submit Request to IANA . . . . . . . . . . . . . . . 78
9.4.3. Designated Expert Review . . . . . . . . . . . . . . 78
9.4.4. Change Procedures . . . . . . . . . . . . . . . . . . 78
9.4.5. JMAP Capabilities Registry Template . . . . . . . . . 79
9.4.6. Initial Registration for JMAP Core . . . . . . . . . 79
9.4.7. Registration for JMAP Error Placeholder in JMAP
Capabilities Registry . . . . . . . . . . . . . . . . 80
9.5. Creation of "JMAP Error Codes" Registry . . . . . . . . . 80
9.5.1. Expert Review . . . . . . . . . . . . . . . . . . . . 80
9.5.2. JMAP Error Codes Registry Template . . . . . . . . . 81
9.5.3. Initial Contents for the JMAP Error Codes Registry . 81
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 86
10.1. Normative References . . . . . . . . . . . . . . . . . . 86
10.2. Informative References . . . . . . . . . . . . . . . . . 89
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 90
The JSON Meta Application Protocol (JMAP) is used for synchronising data, such as mail, calendars, or contacts, between a client and a server. It is optimised for mobile and web environments and aims to provide a consistent interface to different data types.
JSONメタアプリケーションプロトコル（JMAP）は、クライアントとサーバー間でメール、カレンダー、連絡先などのデータを同期するために使用されます。これは、モバイル環境およびWeb環境用に最適化されており、さまざまなデータ型への一貫したインターフェースを提供することを目的としています。
This specification is for the generic mechanism of data synchronisation. Further specifications define the data models for different data types that may be synchronised via JMAP.
この仕様は、データ同期の一般的なメカニズムのためのものです。詳細な仕様では、JMAPを介して同期できるさまざまなデータ型のデータモデルを定義しています。
JMAP is designed to make efficient use of limited network resources. Multiple API calls may be batched in a single request to the server, reducing round trips and improving battery life on mobile devices. Push connections remove the need for polling, and an efficient delta update mechanism ensures a minimum amount of data is transferred.
JMAPは、限られたネットワークリソースを効率的に使用するように設計されています。サーバーへの単一のリクエストで複数のAPI呼び出しをバッチ処理して、ラウンドトリップを減らし、モバイルデバイスのバッテリー寿命を向上させることができます。プッシュ接続により、ポーリングの必要がなくなり、効率的なデルタ更新メカニズムにより、最小限のデータ転送が保証されます。
JMAP is designed to be horizontally scalable to a very large number of users. This is facilitated by separate endpoints for users after login, the separation of binary and structured data, and a data model for sharing that does not allow data dependencies between accounts.
JMAPは、非常に多数のユーザーに対して水平方向に拡張できるように設計されています。これは、ログイン後のユーザー用の個別のエンドポイント、バイナリデータと構造化データの分離、アカウント間のデータ依存性を許可しない共有用のデータモデルによって促進されます。
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]で説明されているように解釈されます。
The underlying format used for this specification is JSON. Consequently, the terms "object" and "array" as well as the four primitive types (strings, numbers, booleans, and null) are to be interpreted as described in Section 1 of [RFC8259]. Unless otherwise noted, all the property names and values are case sensitive.
この仕様で使用される基本的な形式はJSONです。したがって、「オブジェクト」と「配列」という用語、および4つのプリミティブ型（文字列、数値、ブール値、およびnull）は、[RFC8259]のセクション1で説明されているように解釈されます。特に明記しない限り、すべてのプロパティ名と値は大文字と小文字が区別されます。
Some examples in this document contain "partial" JSON documents used for illustrative purposes. In these examples, three periods "..." are used to indicate a portion of the document that has been removed for compactness.
このドキュメントのいくつかの例には、例示の目的で使用される「部分的な」JSONドキュメントが含まれています。これらの例では、コンパクトにするために削除されたドキュメントの一部を示すために、3つのピリオド「...」が使用されています。
For compatibility with publishing requirements, line breaks have been inserted inside long JSON strings, with the following continuation lines indented. To form the valid JSON example, any line breaks inside a string must be replaced with a space and any other white space after the line break removed.
公開要件との互換性のために、長いJSON文字列内に改行が挿入され、次の継続行がインデントされています。有効なJSONの例を形成するには、文字列内の改行をスペースと他の空白で置き換え、改行を削除する必要があります。
Unless otherwise specified, examples of API exchanges only show the methodCalls array of the Request object or the methodResponses array of the Response object. For compactness, the rest of the Request/ Response object is omitted.
特に指定のない限り、API交換の例では、RequestオブジェクトのmethodCalls配列またはResponseオブジェクトのmethodResponses配列のみが表示されます。簡潔にするために、残りのRequest / Responseオブジェクトは省略されています。
Type signatures are given for all JSON values in this document. The following conventions are used:
このドキュメントでは、すべてのJSON値に型シグネチャが与えられています。次の規則が使用されます。
o "*" - The type is undefined (the value could be any type, although permitted values may be constrained by the context of this value).
o "*"-タイプは未定義です（値はどのタイプでもかまいませんが、許可された値はこの値のコンテキストによって制約される場合があります）。
o "String" - The JSON string type.
o 「文字列」-JSON文字列タイプ。
o "Number" - The JSON number type.
o "数値"-JSON数値タイプ。
o "Boolean" - The JSON boolean type.
o 「ブール」-JSONブール型。
o "A[B]" - A JSON object where the keys are all of type "A", and the values are all of type "B".
o 「A [B]」-キーがすべて「A」型で、値がすべて「B」型のJSONオブジェクト。
o "A[]" - An array of values of type "A".
o "A []"-タイプ "A"の値の配列。
o "A|B" - The value is either of type "A" or of type "B".
o "A | B"-値はタイプ "A"またはタイプ "B"のいずれかです。
Other types may also be given, with their representation defined elsewhere in this document.
他のタイプも指定でき、その表現はこのドキュメントの他の場所で定義されています。
Object properties may also have a set of attributes defined along with the type signature. These have the following meanings:
オブジェクトプロパティには、型シグネチャと共に定義された一連の属性も含まれます。これらの意味は次のとおりです。
o "server-set" -- Only the server can set the value for this property. The client MUST NOT send this property when creating a new object of this type.
o "server-set"-サーバーのみがこのプロパティの値を設定できます。このタイプの新しいオブジェクトを作成するとき、クライアントはこのプロパティを送信してはなりません（MUST NOT）。
o "immutable" -- The value MUST NOT change after the object is created.
o 「不変」-オブジェクトの作成後に値を変更してはなりません（MUST NOT）。
o "default" -- (This is followed by a JSON value). The value that will be used for this property if it is omitted in an argument or when creating a new object of this type.
o 「デフォルト」-（これにはJSON値が続きます）。引数で省略された場合、またはこのタイプの新しいオブジェクトを作成するときに、このプロパティに使用される値。
All record ids are assigned by the server and are immutable.
すべてのレコードIDはサーバーによって割り当てられ、不変です。
Where "Id" is given as a data type, it means a "String" of at least 1 and a maximum of 255 octets in size, and it MUST only contain characters from the "URL and Filename Safe" base64 alphabet, as defined in Section 5 of [RFC4648], excluding the pad character ("="). This means the allowed characters are the ASCII alphanumeric characters ("A-Za-z0-9"), hyphen ("-"), and underscore ("_").
「Id」がデータ型として指定されている場合、それはサイズが少なくとも1で最大255オクテットの「文字列」を意味し、「URLおよびファイル名セーフ」のbase64アルファベットからの文字のみを含める必要があります。 [RFC4648]のセクション5。ただし、パッド文字（ "="）は除きます。つまり、使用できる文字は、ASCII英数字（ "A-Za-z0-9"）、ハイフン（ "-"）、およびアンダースコア（ "_"）です。
These characters are safe to use in almost any context (e.g., filesystems, URIs, and IMAP atoms). 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:
これらの文字は、ほぼすべてのコンテキスト（ファイルシステム、URI、IMAPアトムなど）で安全に使用できます。安全性を最大にするために、サーバーは、グロブの完了やデータ型の検出が存在する可能性がある（ファイルシステムやスプレッドシートなど）リスクを回避するために、防御的な割り当て戦略にも従う必要があります（SHOULD）。特に、次のことは避けるのが賢明です。
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" (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の前に1つのアルファベット文字を付けることです。
Where "Int" is given as a data type, it means an integer in the range -2^53+1 <= value <= 2^53-1, the safe range for integers stored in a floating-point double, represented as a JSON "Number".
"Int"がデータ型として指定されている場合、これは-2 ^ 53 + 1 <=値<= 2 ^ 53-1の範囲の整数を意味します。浮動小数点doubleに格納される整数の安全な範囲は、次のように表されますJSON「番号」。
Where "UnsignedInt" is given as a data type, it means an "Int" where the value MUST be in the range 0 <= value <= 2^53-1.
「UnsignedInt」がデータ型として指定されている場合、これは「Int」を意味し、値は0 <=値<= 2 ^ 53-1の範囲でなければなりません。
Where "Date" is given as a type, it means a string in "date-time" format [RFC3339]. To ensure a normalised form, the "time-secfrac" MUST always be omitted if zero, and any letters in the string (e.g., "T" and "Z") MUST be uppercase. For example, "2014-10-30T14:12:00+08:00".
タイプとして「日付」が指定されている場合、それは「日時」形式の文字列を意味します[RFC3339]。正規化された形式を確実にするには、ゼロの場合は常に「time-secfrac」を省略し、文字列内のすべての文字（「T」や「Z」など）は大文字にする必要があります。たとえば、「2014-10-30T14：12：00 + 08：00」です。
Where "UTCDate" is given as a type, it means a "Date" where the "time-offset" component MUST be "Z" (i.e., it must be in UTC time). For example, "2014-10-30T06:12:00Z".
「UTCDate」がタイプとして指定されている場合、「日付」を意味し、「time-offset」コンポーネントは「Z」でなければなりません（つまり、UTC時間である必要があります）。たとえば、「2014-10-30T06：12：00Z」です。
JSON is a text-based data interchange format as specified in [RFC8259]. The Internet JSON (I-JSON) format defined in [RFC7493] is a strict subset of this, adding restrictions to avoid potentially confusing scenarios (for example, it mandates that an object MUST NOT have two members with the same name).
JSONは、[RFC8259]で指定されているテキストベースのデータ交換フォーマットです。 [RFC7493]で定義されているインターネットJSON（I-JSON）形式は、これの厳密なサブセットであり、混乱を招く可能性のあるシナリオを回避するために制限を追加します（たとえば、オブジェクトに同じ名前の2つのメンバーを含めることはできません）。
All data sent from the client to the server or from the server to the client (except binary file upload/download) MUST be valid I-JSON according to the RFC and is therefore case sensitive and encoded in UTF-8 [RFC3629].
クライアントからサーバーに、またはサーバーからクライアントに送信されるすべてのデータ（バイナリファイルのアップロード/ダウンロードを除く）は、RFCに従って有効なI-JSONである必要があるため、大文字と小文字が区別され、UTF-8 [RFC3629]でエンコードされます。
A user is a person accessing data via JMAP. A user has a set of permissions determining the data that they can see.
ユーザーとは、JMAPを介してデータにアクセスする人です。ユーザーには、表示できるデータを決定する一連の権限があります。
An account is a collection of data. A single account may contain an arbitrary set of data types, for example, a collection of mail, contacts, and calendars. Most JMAP methods take a mandatory "accountId" argument that specifies on which account the operations are to take place.
アカウントはデータのコレクションです。単一のアカウントには、メール、連絡先、カレンダーのコレクションなど、データタイプの任意のセットを含めることができます。ほとんどのJMAPメソッドは、操作を実行するアカウントを指定する必須の「accountId」引数を取ります。
An account is not the same as a user, although it is common for a primary account to directly belong to the user. For example, you may have an account that contains data for a group or business, to which multiple users have access.
アカウントはユーザーと同じではありませんが、プライマリアカウントがユーザーに直接属していることはよくあります。たとえば、複数のユーザーがアクセスできるグループまたはビジネスのデータを含むアカウントがあるとします。
A single set of credentials may provide access to multiple accounts, for example, if another user is sharing their work calendar with the authenticated user or if there is a group mailbox for a support-desk inbox.
資格情報の単一のセットは、たとえば、別のユーザーが認証されたユーザーと仕事のカレンダーを共有している場合や、サポートデスクの受信ボックス用のグループメールボックスがある場合など、複数のアカウントへのアクセスを提供します。
In the event of a severe internal error, a server may have to reallocate ids or do something else that violates standard JMAP data constraints for an account. In this situation, the data on the server is no longer compatible with cached data the client may have from before. The server MUST treat this as though the account has been deleted and then recreated with a new account id. Clients will then be forced to throw away any data with the old account id and refetch all data from scratch.
重大な内部エラーが発生した場合、サーバーはIDを再割り当てするか、アカウントの標準のJMAPデータ制約に違反する何かを行う必要があります。この状況では、サーバー上のデータは、クライアントが以前に持っていたキャッシュデータと互換性がなくなります。サーバーは、アカウントが削除され、新しいアカウントIDで再作成されたかのようにこれを処理する必要があります。その後、クライアントは古いアカウントIDのデータを破棄し、すべてのデータを最初から再フェッチする必要があります。
JMAP provides a uniform interface for creating, retrieving, updating, and deleting various types of objects. A "data type" is a collection of named, typed properties, just like the schema for a database table. Each instance of a data type is called a "record".
JMAPは、さまざまなタイプのオブジェクトを作成、取得、更新、および削除するための統一されたインターフェースを提供します。 「データ型」は、データベーステーブルのスキーマと同様に、名前付きの型付きプロパティのコレクションです。データ型の各インスタンスは「レコード」と呼ばれます。
The id of a record is immutable and assigned by the server. The id MUST be unique among all records of the *same type* within the *same account*. Ids may clash across accounts or for two records of different types within the same account.
レコードのIDは不変であり、サーバーによって割り当てられます。 IDは、*同じアカウント*内の*同じタイプ*のすべてのレコード間で一意である必要があります。 IDがアカウント間で、または同じアカウント内の異なるタイプの2つのレコードで競合する可能性があります。
JMAP uses HTTP [RFC7230] to expose API, push, upload, and download resources. All HTTP requests MUST use the "https://" scheme (HTTP over TLS [RFC2818]). All HTTP requests MUST be authenticated.
JMAPはHTTP [RFC7230]を使用して、APIを公開し、リソースをプッシュ、アップロード、ダウンロードします。すべてのHTTPリクエストは「https：//」スキーム（HTTP over TLS [RFC2818]）を使用する必要があります。すべてのHTTPリクエストは認証される必要があります。
An authenticated client can fetch the user's Session object with details about the data and capabilities the server can provide as shown in Section 2. The client may then exchange data with the server in the following ways:
認証されたクライアントは、セクション2に示すように、サーバーが提供できるデータと機能に関する詳細を含むユーザーのSessionオブジェクトをフェッチできます。クライアントは、次の方法でサーバーとデータを交換できます。
1. The client may make an API request to the server to get or set structured data. This request consists of an ordered series of method calls. These are processed by the server, which then returns an ordered series of responses. This is described in Sections 3, 4, and 5.
1. クライアントは、構造化データを取得または設定するために、サーバーにAPI要求を行うことができます。このリクエストは、順序付けられた一連のメソッド呼び出しで構成されています。これらはサーバーによって処理され、サーバーは順序付けられた一連の応答を返します。これについては、セクション3、4、および5で説明します。
2. The client may download or upload binary files from/to the server. This is detailed in Section 6.
2. クライアントは、サーバーとの間でバイナリファイルをダウンロードまたはアップロードできます。これについてはセクション6で詳しく説明します
3. The client may connect to a push channel on the server, to be notified when data has changed. This is explained in Section 7.
3. クライアントはサーバー上のプッシュチャネルに接続して、データが変更されたときに通知を受けることができます。これについては、セクション7で説明します。
Individual services will have custom features they wish to expose over JMAP. This may take the form of extra data types and/or methods not in the spec, extra arguments to JMAP methods, or extra properties on existing data types (which may also appear in arguments to methods that take property names).
個々のサービスには、JMAPで公開するカスタム機能があります。これは、仕様にない追加のデータ型やメソッド、JMAPメソッドへの追加の引数、または既存のデータ型の追加のプロパティ（プロパティ名を受け取るメソッドへの引数にも表示される場合があります）の形を取る場合があります。
The server can advertise custom extensions it supports by including the identifiers in the capabilities object. Identifiers for vendor extensions MUST be a URL belonging to a domain owned by the vendor, to avoid conflict. The URL SHOULD resolve to documentation for the changes the extension makes.
サーバーは、機能オブジェクトに識別子を含めることで、サポートするカスタム拡張をアドバタイズできます。競合を避けるために、ベンダー拡張の識別子は、ベンダーが所有するドメインに属するURLでなければなりません。 URLは、拡張が行う変更についてのドキュメントに解決する必要があります（SHOULD）。
The client MUST opt in to use an extension by passing the appropriate capability identifier in the "using" array of the Request object, as described in Section 3.3. The server MUST only follow the specifications that are opted into and behave as though it does not implement anything else when processing a request. This is to ensure compatibility with clients that don't know about a specific custom extension and for compatibility with future versions of JMAP.
セクション3.3で説明されているように、クライアントは、Requestオブジェクトの「using」配列で適切な機能識別子を渡すことにより、拡張機能の使用をオプトインする必要があります。サーバーは、オプトインされた仕様にのみ従わなければならず、リクエストを処理するときに他の何も実装していないかのように動作します。これは、特定のカスタム拡張について知らないクライアントとの互換性を確保し、JMAPの将来のバージョンとの互換性を確保するためです。
You need two things to connect to a JMAP server:
JMAPサーバーに接続するには、次の2つが必要です。
1. The URL for the JMAP Session resource. This may be requested directly from the user or discovered automatically based on a username domain (see Section 2.2 below).
1. JMAPセッションリソースのURL。これは、ユーザーから直接要求することも、ユーザー名ドメインに基づいて自動的に検出することもできます（以下のセクション2.2を参照）。
2. Credentials to authenticate with. How to obtain credentials is out of scope for this document.
2. 認証に使用する資格情報。資格情報を取得する方法は、このドキュメントの範囲外です。
A successful authenticated GET request to the JMAP Session resource MUST return a JSON-encoded *Session* object, giving details about the data and capabilities the server can provide to the client given those credentials. It has the following properties:
JMAPセッションリソースへの認証されたGETリクエストが成功すると、JSONエンコードされた* Session *オブジェクトを返さなければならず、これらのクレデンシャルを与えられたサーバーがクライアントに提供できるデータと機能に関する詳細を提供します。次のプロパティがあります。
o capabilities: "String[Object]"
o 機能：「文字列[オブジェクト]」
An object specifying the capabilities of this server. Each key is a URI for a capability supported by the server. The value for each of these keys is an object with further information about the server's capabilities in relation to that capability.
このサーバーの機能を指定するオブジェクト。各キーは、サーバーがサポートする機能のURIです。これらの各キーの値は、その機能に関連するサーバーの機能に関する詳細情報を持つオブジェクトです。
The client MUST ignore any properties it does not understand.
クライアントは、理解できないプロパティを無視する必要があります。
The capabilities object MUST include a property called "urn:ietf:params:jmap:core". The value of this property is an object that MUST contain the following information on server capabilities (suggested minimum values for limits are supplied that allow clients to make efficient use of the network):
機能オブジェクトには、「urn：ietf：params：jmap：core」と呼ばれるプロパティを含める必要があります。このプロパティの値は、サーバー機能に関する次の情報を含む必要があるオブジェクトです（クライアントがネットワークを効率的に使用できるようにするための制限の推奨最小値が提供されます）：
* maxSizeUpload: "UnsignedInt"
* maxSizeUpload： "UnsignedInt"
The maximum file size, in octets, that the server will accept for a single file upload (for any purpose). Suggested minimum: 50,000,000.
サーバーが（任意の目的で）1つのファイルのアップロードで受け入れる最大ファイルサイズ（オクテット単位）。推奨される最小値：50,000,000。
* maxConcurrentUpload: "UnsignedInt"
* maxConcurrentUpload： "UnsignedInt"
The maximum number of concurrent requests the server will accept to the upload endpoint. Suggested minimum: 4.
サーバーがアップロードエンドポイントに受け入れる同時リクエストの最大数。推奨される最小値：4。
* maxSizeRequest: "UnsignedInt"
* maxSizeRequest： "UnsignedInt"
The maximum size, in octets, that the server will accept for a single request to the API endpoint. Suggested minimum: 10,000,000.
サーバーがAPIエンドポイントへの1つのリクエストに対して受け入れる最大サイズ（オクテット単位）。推奨される最小値：10,000,000。
* maxConcurrentRequests: "UnsignedInt"
* maxConcurrentRequests： "UnsignedInt"
The maximum number of concurrent requests the server will accept to the API endpoint. Suggested minimum: 4.
サーバーがAPIエンドポイントに受け入れる同時リクエストの最大数。推奨される最小値：4。
* maxCallsInRequest: "UnsignedInt"
* maxCallsInRequest： "UnsignedInt"
The maximum number of method calls the server will accept in a single request to the API endpoint. Suggested minimum: 16.
サーバーがAPIエンドポイントへの1つのリクエストで受け入れるメソッド呼び出しの最大数。推奨される最小値：16。
* maxObjectsInGet: "UnsignedInt"
* maxObjectsInGet： "UnsignedInt"
The maximum number of objects that the client may request in a single /get type method call. Suggested minimum: 500.
クライアントが単一の/ getタイプのメソッド呼び出しで要求できるオブジェクトの最大数。推奨される最小値：500。
* maxObjectsInSet: "UnsignedInt"
* maxObjectsInSet： "UnsignedInt"
The maximum number of objects the client may send to create, update, or destroy in a single /set type method call. This is the combined total, e.g., if the maximum is 10, you could not create 7 objects and destroy 6, as this would be 13 actions, which exceeds the limit. Suggested minimum: 500.
単一の/ setタイプのメソッド呼び出しでクライアントが作成、更新、または破棄するために送信できるオブジェクトの最大数。これは合計された合計です。たとえば、最大が10の場合、7つのオブジェクトを作成して6つを破棄することはできません。これは、13のアクションであり、制限を超えているためです。推奨される最小値：500。
* collationAlgorithms: "String[]"
* collationAlgorithms： "文字列[]"
A list of identifiers for algorithms registered in the collation registry, as defined in [RFC4790], that the server supports for sorting when querying records.
[RFC4790]で定義されている、照合レジストリに登録されているアルゴリズムの識別子のリスト。サーバーは、レコードのクエリ時にソートをサポートしています。
Specifications for future capabilities will define their own properties on the capabilities object.
将来の機能の仕様は、機能オブジェクトで独自のプロパティを定義します。
Servers MAY advertise vendor-specific JMAP extensions, as described in Section 1.8. To avoid conflict, an identifier for a vendor-specific extension MUST be a URL with a domain owned by the vendor. Clients MUST opt in to any capability it wishes to use (see Section 3.3).
セクション1.8で説明されているように、サーバーはベンダー固有のJMAP拡張をアドバタイズしてもよい（MAY）。競合を回避するために、ベンダー固有の拡張の識別子は、ベンダーが所有するドメインのURLである必要があります。クライアントは、使用したい機能を選択する必要があります（セクション3.3を参照）。
o accounts: "Id[Account]"
o アカウント：「Id [アカウント]」
A map of an account id to an Account object for each account (see Section 1.6.2) the user has access to. An *Account* object has the following properties:
ユーザーがアクセスできる各アカウント（セクション1.6.2を参照）のアカウントオブジェクトへのアカウントIDのマップ。 * Account *オブジェクトには次のプロパティがあります：
* name: "String"
* 名前：「文字列」
A user-friendly string to show when presenting content from this account, e.g., the email address representing the owner of the account.
このアカウントのコンテンツを提示するときに表示するユーザーフレンドリーな文字列（アカウントの所有者を表すメールアドレスなど）。
* isPersonal: "Boolean"
* isPersonal： "ブール"
This is true if the account belongs to the authenticated user rather than a group account or a personal account of another user that has been shared with them.
これは、アカウントが、共有されている別のユーザーのグループアカウントや個人アカウントではなく、認証されたユーザーに属している場合に当てはまります。
* isReadOnly: "Boolean"
* isReadOnly： "ブール値"
This is true if the entire account is read-only.
これは、アカウント全体が読み取り専用の場合に当てはまります。
* accountCapabilities: "String[Object]"
* accountCapabilities： "文字列[オブジェクト]"
The set of capability URIs for the methods supported in this account. Each key is a URI for a capability that has methods you can use with this account. The value for each of these keys is an object with further information about the account's permissions and restrictions with respect to this capability, as defined in the capability's specification.
このアカウントでサポートされているメソッドの機能URIのセット。各キーは、このアカウントで使用できるメソッドを持つ機能のURIです。これらの各キーの値は、機能の仕様で定義されているように、この機能に関するアカウントの権限と制限に関する詳細情報を持つオブジェクトです。
The client MUST ignore any properties it does not understand.
クライアントは、理解できないプロパティを無視する必要があります。
The server advertises the full list of capabilities it supports in the capabilities object, as defined above. If the capability defines new methods, the server MUST include it in the accountCapabilities object if the user may use those methods with this account. It MUST NOT include it in the accountCapabilities object if the user cannot use those methods with this account.
サーバーは、上記で定義したように、機能オブジェクトでサポートする機能の完全なリストをアドバタイズします。機能が新しいメソッドを定義する場合、ユーザーがこのアカウントでそれらのメソッドを使用できる場合、サーバーはそれをaccountCapabilitiesオブジェクトに含める必要があります。ユーザーがこのアカウントでこれらのメソッドを使用できない場合は、それをaccountCapabilitiesオブジェクトに含めてはなりません（MUST NOT）。
For example, you may have access to your own account with mail, calendars, and contacts data and also a shared account that only has contacts data (a business address book, for example). In this case, the accountCapabilities property on the first account would include something like "urn:ietf:params:jmap:mail", "urn:ietf:params:jmap:calendars", and "urn:ietf:params:jmap:contacts", while the second account would just have the last of these.
たとえば、メール、カレンダー、連絡先データを含む自分のアカウント、および連絡先データのみを含む共有アカウント（たとえば、ビジネスアドレス帳）にアクセスできます。この場合、最初のアカウントのaccountCapabilitiesプロパティには、「urn：ietf：params：jmap：mail」、「urn：ietf：params：jmap：calendars」、「urn：ietf：params：jmap：contacts」などが含まれます。 「2番目のアカウントにはこれらの最後のアカウントしかありません。
Attempts to use the methods defined in a capability with one of the accounts that does not support that capability are rejected with an "accountNotSupportedByMethod" error (see "Method-Level Errors", Section 3.6.2).
その機能をサポートしていないアカウントの1つで機能に定義されているメソッドを使用しようとすると、「accountNotSupportedByMethod」エラー（「メソッドレベルのエラー」のセクション3.6.2を参照）で拒否されます。
o primaryAccounts: "String[Id]"
o primaryAccounts：「String [Id]」
A map of capability URIs (as found in accountCapabilities) to the account id that is considered to be the user's main or default account for data pertaining to that capability. If no account being returned belongs to the user, or in any other way there is no appropriate way to determine a default account, there MAY be no entry for a particular URI, even though that capability is supported by the server (and in the capabilities object). "urn:ietf:params:jmap:core" SHOULD NOT be present.
機能URI（accountCapabilitiesにあります）から、その機能に関連するデータのユーザーのメインアカウントまたはデフォルトアカウントと見なされるアカウントIDへのマップ。返されるアカウントがユーザーに属していない場合、または他の方法でデフォルトアカウントを決定する適切な方法がない場合、その機能がサーバー（および機能）でサポートされていても、特定のURIのエントリがない場合がありますオブジェクト）。 "urn：ietf：params：jmap：core"は存在すべきではありません。
o username: "String"
o ユーザー名：「文字列」
The username associated with the given credentials, or the empty string if none.
指定された資格情報に関連付けられているユーザー名。存在しない場合は空の文字列。
o apiUrl: "String"
o apiUrl： "文字列"
The URL to use for JMAP API requests.
JMAP APIリクエストに使用するURL。
o downloadUrl: "String"
o downloadUrl： "文字列"
The URL endpoint to use when downloading files, in URI Template (level 1) format [RFC6570]. The URL MUST contain variables called "accountId", "blobId", "type", and "name". The use of these variables is described in Section 6.2. Due to potential encoding issues with slashes in content types, it is RECOMMENDED to put the "type" variable in the query section of the URL.
ファイルをダウンロードするときに使用するURLエンドポイント。URIテンプレート（レベル1）形式[RFC6570]。 URLには、「accountId」、「blobId」、「type」、および「name」という変数を含める必要があります。これらの変数の使用については、セクション6.2で説明します。コンテンツタイプのスラッシュに関する潜在的なエンコーディングの問題のため、「type」変数をURLのクエリセクションに配置することをお勧めします。
o uploadUrl: "String"
o uploadUrl： "文字列"
The URL endpoint to use when uploading files, in URI Template (level 1) format [RFC6570]. The URL MUST contain a variable called "accountId". The use of this variable is described in Section 6.1.
URIテンプレート（レベル1）形式[RFC6570]でファイルをアップロードするときに使用するURLエンドポイント。 URLには、「accountId」という変数を含める必要があります。この変数の使用については、セクション6.1で説明しています。
o eventSourceUrl: "String"
o eventSourceUrl： "文字列"
The URL to connect to for push events, as described in Section 7.3, in URI Template (level 1) format [RFC6570]. The URL MUST contain variables called "types", "closeafter", and "ping". The use of these variables is described in Section 7.3.
セクション7.3で説明されているように、URIテンプレート（レベル1）形式[RFC6570]でプッシュイベントに接続するためのURL。 URLには、「types」、「closeafter」、「ping」と呼ばれる変数を含める必要があります。これらの変数の使用については、7.3節で説明します。
o state: "String"
o 状態：「文字列」
A (preferably short) string representing the state of this object on the server. If the value of any other property on the Session object changes, this string will change. The current value is also returned on the API Response object (see Section 3.4), allowing clients to quickly determine if the session information has changed (e.g., an account has been added or removed), so they need to refetch the object.
サーバー上のこのオブジェクトの状態を表す（できれば短い）文字列。 Sessionオブジェクトの他のプロパティの値が変更されると、この文字列が変更されます。現在の値はAPI Responseオブジェクトでも返され（セクション3.4を参照）、クライアントはセッション情報が変更されたか（アカウントが追加または削除されたかなど）をすばやく判断できるため、オブジェクトを再フェッチする必要があります。
To ensure future compatibility, other properties MAY be included on the Session object. Clients MUST ignore any properties they are not expecting.
将来の互換性を確保するために、他のプロパティがSessionオブジェクトに含まれる場合があります。クライアントは、予期しないプロパティを無視する必要があります。
Implementors must take care to avoid inappropriate caching of the Session object at the HTTP layer. Since the client should only refetch when it detects there is a change (via the sessionState property of an API response), it is RECOMMENDED to disable HTTP caching altogether, for example, by setting "Cache-Control: no-cache, no-store, must-revalidate" on the response.
実装者は、HTTPレイヤーでのSessionオブジェクトの不適切なキャッシュを回避するように注意する必要があります。クライアントは、変更があることを検出した場合にのみ再フェッチする必要があるため（API応答のsessionStateプロパティを介して）、たとえば、 "Cache-Control：no-cache、no-store 、応答の再検証が必要」。
In the following example Session object, the user has access to their own mail and contacts via JMAP, as well as read-only access to shared mail from another user. The server is advertising a custom "https://example.com/apis/foobar" capability.
次の例のSessionオブジェクトでは、ユーザーはJMAPを介して自分のメールと連絡先にアクセスでき、他のユーザーからの共有メールには読み取り専用アクセス権があります。サーバーはカスタムの「https://example.com/apis/foobar」機能をアドバタイズしています。
{
"capabilities": {
"urn:ietf:params:jmap:core": {
"maxSizeUpload": 50000000,
"maxConcurrentUpload": 8,
"maxSizeRequest": 10000000,
"maxConcurrentRequest": 8,
"maxCallsInRequest": 32,
"maxObjectsInGet": 256,
"maxObjectsInSet": 128,
"collationAlgorithms": [
"i;ascii-numeric",
"i;ascii-casemap",
"i;unicode-casemap"
]
},
"urn:ietf:params:jmap:mail": {}
"urn:ietf:params:jmap:contacts": {},
"https://example.com/apis/foobar": {
"maxFoosFinangled": 42
}
},
"accounts": {
"A13824": {
"name": "john@example.com",
"isPersonal": true,
"isReadOnly": false,
"accountCapabilities": {
"urn:ietf:params:jmap:mail": {
"maxMailboxesPerEmail": null,
"maxMailboxDepth": 10,
...
},
"urn:ietf:params:jmap:contacts": {
...
}
}
},
"A97813": {
"name": "jane@example.com",
"isPersonal": false,
"isReadOnly": true,
"accountCapabilities": {
"urn:ietf:params:jmap:mail": {
"maxMailboxesPerEmail": 1,
"maxMailboxDepth": 10,
...
}
}
}
},
"primaryAccounts": {
"urn:ietf:params:jmap:mail": "A13824",
"urn:ietf:params:jmap:contacts": "A13824"
},
"username": "john@example.com",
"apiUrl": "https://jmap.example.com/api/",
"downloadUrl": "https://jmap.example.com
/download/{accountId}/{blobId}/{name}?accept={type}",
"uploadUrl": "https://jmap.example.com/upload/{accountId}/",
"eventSourceUrl": "https://jmap.example.com
/eventsource/?types={types}&closeafter={closeafter}&ping={ping}",
"state": "75128aab4b1b"
}
There are two standardised autodiscovery methods in use for Internet protocols:
インターネットプロトコルで使用されている2つの標準化された自動検出方法があります。
o DNS SRV (see [RFC2782], [RFC6186], and [RFC6764])
o DNS SRV（[RFC2782]、[RFC6186]、および[RFC6764]を参照）
o .well-known/servicename (see [RFC8615])
o .well-known / servicename（[RFC8615]を参照）
A JMAP-supporting host for the domain "example.com" SHOULD publish a SRV record "_jmap._tcp.example.com" that gives a hostname and port (usually port "443"). The JMAP Session resource is then "https://${hostname}[:${port}]/.well-known/jmap" (following any redirects).
ドメイン「example.com」のJMAPサポートホストは、ホスト名とポート（通常はポート「443」）を提供するSRVレコード「_jmap._tcp.example.com」を公開する必要があります（SHOULD）。その場合、JMAPセッションリソースは "https：// $ {hostname} [：$ {port}] /.well-known/jmap"になります（リダイレクトに従います）。
If the client has a username in the form of an email address, it MAY use the domain portion of this to attempt autodiscovery of the JMAP server.
クライアントがメールアドレスの形式のユーザー名を持っている場合、クライアントはこのドメイン部分を使用してJMAPサーバーの自動検出を試みることができます。
The client may make an API request to the server to get or set structured data. This request consists of an ordered series of method calls. These are processed by the server, which then returns an ordered series of responses.
クライアントは、構造化データを取得または設定するために、サーバーにAPI要求を行うことができます。このリクエストは、順序付けられた一連のメソッド呼び出しで構成されています。これらはサーバーによって処理され、サーバーは順序付けられた一連の応答を返します。
To make an API request, the client makes an authenticated POST request to the API resource, which is defined by the "apiUrl" property in the Session object (see Section 2).
APIリクエストを行うために、クライアントは認証されたPOSTリクエストをAPIリソースに行います。これは、Sessionオブジェクトの「apiUrl」プロパティで定義されます（セクション2を参照）。
The request MUST be of type "application/json" and consist of a single JSON-encoded "Request" object, as defined in Section 3.3. If successful, the response MUST also be of type "application/json" and consist of a single "Response" object, as defined in Section 3.4.
リクエストは、「application / json」タイプである必要があり、セクション3.3で定義されているように、単一のJSONエンコードされた「Request」オブジェクトで構成されている必要があります。成功した場合、レスポンスは「application / json」タイプである必要があり、セクション3.4で定義されているように、単一の「Response」オブジェクトで構成されている必要があります。
Method calls and responses are represented by the *Invocation* data type. This is a tuple, represented as a JSON array containing three elements:
メソッドの呼び出しと応答は、* Invocation *データ型で表されます。これはタプルであり、3つの要素を含むJSON配列として表されます。
1. A "String" *name* of the method to call or of the response.
1. 呼び出すメソッドまたは応答の「文字列」*名前*。
2. A "String[*]" object containing named *arguments* for that method or response.
2. そのメソッドまたは応答の名前付き*引数*を含む「String [*]」オブジェクト。
3. A "String" *method call id*: an arbitrary string from the client to be echoed back with the responses emitted by that method call (a method may return 1 or more responses, as it may make implicit calls to other methods; all responses initiated by this method call get the same method call id in the response).
3. 「文字列」*メソッドコールID *：クライアントからの任意の文字列で、そのメソッドコールによって発行された応答でエコーバックされます（他のメソッドを暗黙的に呼び出すため、メソッドは1つ以上の応答を返す場合があります。すべての応答このメソッド呼び出しによって開始された場合、応答で同じメソッド呼び出しIDを取得します）。
A *Request* object has the following properties:
* Request *オブジェクトには次のプロパティがあります：
o using: "String[]"
o 使用： "String []"
The set of capabilities the client wishes to use. The client MAY include capability identifiers even if the method calls it makes do not utilise those capabilities. The server advertises the set of specifications it supports in the Session object (see Section 2), as keys on the "capabilities" property.
クライアントが使用したい機能のセット。クライアントは、それが行うメソッド呼び出しがそれらの機能を利用しない場合でも、機能識別子を含めることができます。サーバーは、Sessionオブジェクト（セクション2を参照）でサポートする一連の仕様を「機能」プロパティのキーとして通知します。
o methodCalls: "Invocation[]"
o methodCalls： "呼び出し[]"
An array of method calls to process on the server. The method calls MUST be processed sequentially, in order.
サーバーで処理するメソッド呼び出しの配列。メソッド呼び出しは、順番に順番に処理する必要があります。
o createdIds: "Id[Id]" (optional)
o createdIds： "Id [Id]"（オプション）
A map of a (client-specified) creation id to the id the server assigned when a record was successfully created.
（クライアント指定の）作成IDの、レコードが正常に作成されたときにサーバーが割り当てたIDへのマップ。
As described later in this specification, some records may have a property that contains the id of another record. To allow more efficient network usage, you can set this property to reference a record created earlier in the same API request. Since the real id is unknown when the request is created, the client can instead specify the creation id it assigned, prefixed with a "#" (see Section 5.3 for more details).
この仕様の後半で説明するように、一部のレコードには、別のレコードのIDを含むプロパティがある場合があります。より効率的なネットワーク使用を可能にするために、同じAPIリクエストで以前に作成されたレコードを参照するようにこのプロパティを設定できます。リクエストの作成時には実際のIDは不明であるため、クライアントは代わりに、「＃」で始まる割り当てられた作成IDを指定できます（詳細については、セクション5.3を参照）。
As the server processes API requests, any time it successfully creates a new record, it adds the creation id to this map (see the "create" argument to /set in Section 5.3), with the server-assigned real id as the value. If it comes across a reference to a creation id in a create/update, it looks it up in the map and replaces the reference with the real id, if found.
サーバーはAPIリクエストを処理するときに、新しいレコードを正常に作成するたびに、サーバーが割り当てた実際のIDを値として、このマップに作成IDを追加します（セクション5.3の/ setの「create」引数を参照）。作成/更新で作成IDへの参照に遭遇した場合、マップでそれを検索し、見つかった場合は参照を実際のIDに置き換えます。
The client can pass an initial value for this map as the "createdIds" property of the Request object. This may be an empty object. If given in the request, the response will also include a createdIds property. This allows proxy servers to easily split a JMAP request into multiple JMAP requests to send to different servers. For example, it could send the first two method calls to server A, then the third to server B, before sending the fourth to server A again. By passing the createdIds of the previous response to the next request, it can ensure all of these still resolve. See Section 5.8 for further discussion of proxy considerations.
クライアントは、このマップの初期値をRequestオブジェクトの「createdIds」プロパティとして渡すことができます。これは空のオブジェクトである可能性があります。リクエストで指定された場合、レスポンスにはcreatedIdsプロパティも含まれます。これにより、プロキシサーバーはJMAP要求を複数のJMAP要求に簡単に分割して、異なるサーバーに送信できます。たとえば、最初の2つのメソッド呼び出しをサーバーAに送信し、3番目のメソッド呼び出しをサーバーBに送信してから、4番目のメソッド呼び出しをサーバーAに送信します。前の応答のcreatedIdsを次のリクエストに渡すことにより、これらすべてが確実に解決されるようにすることができます。プロキシの考慮事項の詳細については、セクション5.8を参照してください。
Future specifications MAY add further properties to the Request object to extend the semantics. To ensure forwards compatibility, a server MUST ignore any other properties it does not understand on the JMAP Request object.
将来の仕様では、セマンティクスを拡張するために、Requestオブジェクトにさらにプロパティを追加する場合があります。前方互換性を確保するために、サーバーはJMAPリクエストオブジェクトで理解できない他のプロパティを無視する必要があります。
{
"using": [ "urn:ietf:params:jmap:core", "urn:ietf:params:jmap:mail" ],
"methodCalls": [
[ "method1", {
"arg1": "arg1data",
"arg2": "arg2data"
}, "c1" ],
[ "method2", {
"arg1": "arg1data"
}, "c2" ],
[ "method3", {}, "c3" ]
]
}
A *Response* object has the following properties:
* Response *オブジェクトには次のプロパティがあります。
o methodResponses: "Invocation[]"
o methodResponses： "呼び出し[]"
An array of responses, in the same format as the "methodCalls" on the Request object. The output of the methods MUST be added to the "methodResponses" array in the same order that the methods are processed.
Requestオブジェクトの「methodCalls」と同じ形式の応答の配列。メソッドの出力は、メソッドが処理されるのと同じ順序で「methodResponses」配列に追加する必要があります。
o createdIds: "Id[Id]" (optional; only returned if given in the request)
o createdIds： "Id [Id]"（オプション。リクエストで指定された場合にのみ返されます）
A map of a (client-specified) creation id to the id the server assigned when a record was successfully created. This MUST include all creation ids passed in the original createdIds parameter of the Request object, as well as any additional ones added for newly created records.
（クライアント指定の）作成IDの、レコードが正常に作成されたときにサーバーが割り当てたIDへのマップ。これには、Requestオブジェクトの元のcreatedIdsパラメータで渡されたすべての作成IDと、新しく作成されたレコードに追加された追加のIDを含める必要があります。
o sessionState: "String"
o sessionState： "文字列"
The current value of the "state" string on the Session object, as described in Section 2. Clients may use this to detect if this object has changed and needs to be refetched.
セクション2で説明されているように、Sessionオブジェクトの「状態」文字列の現在の値。クライアントはこれを使用して、このオブジェクトが変更され、再フェッチする必要があるかどうかを検出できます。
Unless otherwise specified, if the method call completed successfully, its response name is the same as the method name in the request.
特に指定がない限り、メソッド呼び出しが正常に完了した場合、その応答名は要求内のメソッド名と同じです。
{
"methodResponses": [
[ "method1", {
"arg1": 3,
"arg2": "foo"
}, "c1" ],
[ "method2", {
"isBlah": true
}, "c2" ],
[ "anotherResponseFromMethod2", {
"data": 10,
"yetmoredata": "Hello"
}, "c2"],
[ "error", {
"type":"unknownMethod"
}, "c3" ]
],
"sessionState": "75128aab4b1b"
}
An argument to a method may be specified to have a default value. If omitted by the client, the server MUST treat the method call the same as if the default value had been specified. Similarly, the server MAY omit any argument in a response that has the default value.
メソッドへの引数は、デフォルト値を持つように指定できます。クライアントによって省略された場合、サーバーはメソッド呼び出しをデフォルト値が指定された場合と同じように扱う必要があります。同様に、サーバーは、デフォルト値を持つ応答の引数を省略してもよい（MAY）。
Unless otherwise specified in a method description, null is the default value for any argument in a request or response where this is allowed by the type signature. Other arguments may only be omitted if an explicit default value is defined in the method description.
メソッドの説明で特に指定されていない限り、タイプシグネチャで許可されているリクエストまたはレスポンスの引数のデフォルト値はnullです。その他の引数は、メソッドの説明で明示的なデフォルト値が定義されている場合にのみ省略できます。
There are three different levels of granularity at which an error may be returned in JMAP.
JMAPでエラーが返される可能性のある粒度には3つの異なるレベルがあります。
When an API request is made, the request as a whole may be rejected due to rate limiting, malformed JSON, request for an unknown capability, etc. In this case, the entire request is rejected with an appropriate HTTP error response code and an additional JSON body with more detail for the client.
APIリクエストが行われると、レート制限、不正なJSON、不明な機能のリクエストなどにより、リクエスト全体が拒否される場合があります。この場合、リクエスト全体が適切なHTTPエラー応答コードと追加のリクエストで拒否されますクライアントの詳細を含むJSON本文。
Provided the request itself is syntactically valid (the JSON is valid and when decoded, it matches the type signature of a Request object), the methods within it are executed sequentially by the server. Each method may individually fail, for example, if invalid arguments are given or an unknown method name is called.
リクエスト自体が構文的に有効である場合（JSONは有効であり、デコードされると、Requestオブジェクトのタイプシグネチャと一致します）、リクエスト内のメソッドはサーバーによって順次実行されます。たとえば、無効な引数が指定された場合や不明なメソッド名が呼び出された場合など、各メソッドは個別に失敗する可能性があります。
Finally, methods that make changes to the server state often act upon a number of different records within a single call. Each record change may be separately rejected with a SetError, as described in Section 5.3.
最後に、サーバーの状態を変更するメソッドは、多くの場合、1回の呼び出しでさまざまなレコードに作用します。セクション5.3で説明されているように、各レコード変更はSetErrorで個別に拒否される場合があります。
When an HTTP error response is returned to the client, the server SHOULD return a JSON "problem details" object as the response body, as per [RFC7807].
HTTPエラー応答がクライアントに返されると、サーバーは[RFC7807]に従って、JSONの「問題の詳細」オブジェクトを応答本文として返す必要があります（SHOULD）。
The following problem types are defined:
次の問題タイプが定義されています。
o "urn:ietf:params:jmap:error:unknownCapability" The client included a capability in the "using" property of the request that the server does not support.
o "urn：ietf：params：jmap：error：unknownCapability"クライアントは、サーバーがサポートしていない要求の "using"プロパティに機能を含めました。
o "urn:ietf:params:jmap:error:notJSON" The content type of the request was not "application/json" or the request did not parse as I-JSON.
o 「urn：ietf：params：jmap：error：notJSON」リクエストのコンテンツタイプが「application / json」ではなかったか、リクエストがI-JSONとして解析されませんでした。
o "urn:ietf:params:jmap:error:notRequest" The request parsed as JSON but did not match the type signature of the Request object.
o "urn：ietf：params：jmap：error：notRequest"リクエストはJSONとして解析されましたが、Requestオブジェクトのタイプシグネチャと一致しませんでした。
o "urn:ietf:params:jmap:error:limit" The request was not processed as it would have exceeded one of the request limits defined on the capability object, such as maxSizeRequest, maxCallsInRequest, or maxConcurrentRequests. A "limit" property MUST also be present on the "problem details" object, containing the name of the limit being applied.
o "urn：ietf：params：jmap：error：limit" maxSizeRequest、maxCallsInRequest、maxConcurrentRequestsなど、機能オブジェクトで定義されたリクエスト制限の1つを超えたため、リクエストは処理されませんでした。 「制限」プロパティは、適用される制限の名前を含む「問題の詳細」オブジェクトにも存在する必要があります。
{
"type": "urn:ietf:params:jmap:error:unknownCapability",
"status": 400,
"detail": "The Request object used capability
'https://example.com/apis/foobar', which is not supported
by this server."
}
Another example:
もう一つの例：
{
"type": "urn:ietf:params:jmap:error:limit",
"limit": "maxSizeRequest",
"status": 400,
"detail": "The request is larger than the server is willing to
process."
}
If a method encounters an error, the appropriate "error" response MUST be inserted at the current point in the "methodResponses" array and, unless otherwise specified, further processing MUST NOT happen within that method call.
メソッドでエラーが発生した場合は、「methodResponses」配列の現在の位置に適切な「エラー」応答を挿入する必要があり、特に指定がない限り、そのメソッド呼び出し内でそれ以上の処理を行わないでください。
Any further method calls in the request MUST then be processed as normal. Errors at the method level MUST NOT generate an HTTP-level error.
リクエスト内のそれ以降のメソッド呼び出しは、通常どおりに処理される必要があります。メソッドレベルのエラーは、HTTPレベルのエラーを生成してはなりません。
An "error" response looks like this:
「エラー」応答は次のようになります。
[ "error", {
"type": "unknownMethod"
}, "call-id" ]
The response name is "error", and it MUST have a type property. Other properties may be present with further information; these are detailed in the error type descriptions where appropriate.
応答名は「エラー」であり、typeプロパティが必要です。その他のプロパティが詳細情報とともに表示される場合があります。これらは、必要に応じてエラータイプの説明で詳しく説明されています。
With the exception of when the "serverPartialFail" error is returned, the externally visible state of the server MUST NOT have changed if an error is returned at the method level.
「serverPartialFail」エラーが返された場合を除いて、メソッドレベルでエラーが返された場合、サーバーの外部から見える状態が変更されてはなりません。
The following error types are defined, which may be returned for any method call where appropriate:
以下のエラータイプが定義されており、必要に応じてメソッド呼び出しで返される場合があります。
"serverUnavailable": Some internal server resource was temporarily unavailable. Attempting the same operation later (perhaps after a backoff with a random factor) may succeed.
"serverUnavailable"：一部の内部サーバーリソースが一時的に利用できませんでした。同じ操作を後で（おそらくランダムな要因によるバックオフの後で）試行すると、成功する可能性があります。
"serverFail": An unexpected or unknown error occurred during the processing of the call. A "description" property should provide more details about the error. The method call made no changes to the server's state. Attempting the same operation again is expected to fail again. Contacting the service administrator is likely necessary to resolve this problem if it is persistent.
"serverFail"：呼び出しの処理中に予期しないまたは不明なエラーが発生しました。 "description"プロパティは、エラーに関する詳細を提供する必要があります。メソッドの呼び出しによってサーバーの状態は変更されませんでした。同じ操作を再試行すると、失敗することが予想されます。この問題が解決しない場合は、この問題を解決するためにサービス管理者に連絡する必要があります。
"serverPartialFail": Some, but not all, expected changes described by the method occurred. The client MUST resynchronise impacted data to determine server state. Use of this error is strongly discouraged.
"serverPartialFail"：メソッドによって記述された、すべてではなく一部の予期された変更が発生しました。クライアントは、影響を受けるデータを再同期して、サーバーの状態を判断する必要があります。このエラーの使用はお勧めしません。
"unknownMethod": The server does not recognise this method name.
"unknownMethod"：サーバーはこのメソッド名を認識しません。
"invalidArguments": One of the arguments is of the wrong type or is otherwise invalid, or a required argument is missing. A "description" property MAY be present to help debug with an explanation of what the problem was. This is a non-localised string, and it is not intended to be shown directly to end users.
"invalidArguments"：引数の1つが間違ったタイプであるか、それ以外の場合は無効であるか、必要な引数がありません。 「説明」プロパティは、問題が何であったかの説明でデバッグするのを助けるために存在するかもしれません。これはローカライズされていない文字列であり、エンドユーザーに直接表示することは意図されていません。
"invalidResultReference": The method used a result reference for one of its arguments (see Section 3.7), but this failed to resolve.
"invalidResultReference"：メソッドは引数の1つに結果参照を使用しましたが（3.7節を参照）、これは解決できませんでした。
"forbidden": The method and arguments are valid, but executing the method would violate an Access Control List (ACL) or other permissions policy.
「禁止」：メソッドと引数は有効ですが、メソッドを実行すると、アクセス制御リスト（ACL）またはその他のアクセス許可ポリシーに違反します。
"accountNotFound": The accountId does not correspond to a valid account.
「accountNotFound」：accountIdが有効なアカウントに対応していません。
"accountNotSupportedByMethod": The accountId given corresponds to a valid account, but the account does not support this method or data type.
"accountNotSupportedByMethod"：指定されたaccountIdは有効なアカウントに対応していますが、アカウントはこのメソッドまたはデータ型をサポートしていません。
"accountReadOnly": This method modifies state, but the account is read-only (as returned on the corresponding Account object in the JMAP Session resource).
"accountReadOnly"：このメソッドは状態を変更しますが、アカウントは読み取り専用です（JMAPセッションリソースの対応するAccountオブジェクトで返されます）。
Further possible errors for a particular method are specified in the method descriptions.
特定のメソッドでさらに発生する可能性のあるエラーは、メソッドの説明で指定されています。
Further general errors MAY be defined in future RFCs. Should a client receive an error type it does not understand, it MUST treat it the same as the "serverFail" type.
さらに一般的なエラーは、将来のRFCで定義される可能性があります。クライアントが理解できないエラータイプを受け取った場合、クライアントはそれを「serverFail」タイプと同じように扱う必要があります。
To allow clients to make more efficient use of the network and avoid round trips, an argument to one method can be taken from the result of a previous method call in the same request.
クライアントがネットワークをより効率的に使用してラウンドトリップを回避できるようにするために、1つのメソッドへの引数を、同じリクエスト内の以前のメソッド呼び出しの結果から取得できます。
To do this, the client prefixes the argument name with "#" (an octothorpe). The value is a ResultReference object as described below. When processing a method call, the server MUST first check the arguments object for any names beginning with "#". If found, the result reference should be resolved and the value used as the "real" argument. The method is then processed as normal. If any result reference fails to resolve, the whole method MUST be rejected with an "invalidResultReference" error. If an arguments object contains the same argument name in normal and referenced form (e.g., "foo" and "#foo"), the method MUST return an "invalidArguments" error.
これを行うには、クライアントは引数名の前に "＃"（八角形）を付けます。以下で説明するように、値はResultReferenceオブジェクトです。メソッド呼び出しを処理するとき、サーバーは最初に「＃」で始まる名前の引数オブジェクトを確認する必要があります。見つかった場合、結果参照を解決し、その値を「実際の」引数として使用する必要があります。その後、メソッドは通常どおり処理されます。結果参照の解決に失敗した場合、メソッド全体を「invalidResultReference」エラーで拒否する必要があります。引数オブジェクトに通常の参照形式で同じ引数名が含まれている場合（「foo」や「#foo」など）、メソッドは「invalidArguments」エラーを返す必要があります。
A *ResultReference* object has the following properties:
* ResultReference *オブジェクトには次のプロパティがあります。
o resultOf: "String"
o resultOf： "文字列"
The method call id (see Section 3.2) of a previous method call in the current request.
現在のリクエストでの前のメソッド呼び出しのメソッド呼び出しID（セクション3.2を参照）。
o name: "String"
o 名前：「文字列」
The required name of a response to that method call.
そのメソッド呼び出しへの応答に必要な名前。
o path: "String"
o パス：「文字列」
A pointer into the arguments of the response selected via the name and resultOf properties. This is a JSON Pointer [RFC6901], except it also allows the use of "*" to map through an array (see the description below).
nameおよびresultOfプロパティを介して選択された応答の引数へのポインター。これはJSONポインター[RFC6901]ですが、 "*"を使用して配列をマッピングすることもできます（以下の説明を参照）。
To resolve:
解決する：
1. Find the first response with a method call id identical to the "resultOf" property of the ResultReference in the "methodResponses" array from previously processed method calls in the same request. If none, evaluation fails.
1. 同じリクエストで以前に処理されたメソッド呼び出しからの "methodResponses"配列のResultReferenceの "resultOf"プロパティと同じメソッド呼び出しIDを持つ最初の応答を見つけます。存在しない場合、評価は失敗します。
2. If the response name is not identical to the "name" property of the ResultReference, evaluation fails.
2. 応答名がResultReferenceの「name」プロパティと同一でない場合、評価は失敗します。
3. Apply the "path" to the arguments object of the response (the second item in the response array) following the JSON Pointer algorithm [RFC6901], except with the following addition in "Evaluation" (see Section 4):
3. JSONポインターアルゴリズム[RFC6901]に従って、応答の引数オブジェクト（応答配列の2番目の項目）に「パス」を適用します。ただし、「評価」（セクション4を参照）に以下を追加します。
If the currently referenced value is a JSON array, the reference token may be exactly the single character "*", making the new referenced value the result of applying the rest of the JSON Pointer tokens to every item in the array and returning the results in the same order in a new array. If the result of applying the rest of the pointer tokens to each item was itself an array, the contents of this array are added to the output rather than the array itself (i.e., the result is flattened from an array of arrays to a single array). If the result of applying the rest of the pointer tokens to a value was itself an array, its items should be included individually in the output rather than including the array itself (i.e., the result is flattened from an array of arrays to a single array).
現在参照されている値がJSON配列の場合、参照トークンは正確に1文字の「*」であり、新しい参照値は、残りのJSONポインタートークンを配列内のすべての項目に適用し、結果を返す結果になります。新しい配列で同じ順序。残りのポインタートークンを各アイテムに適用した結果がそれ自体が配列である場合、この配列の内容が配列自体ではなく出力に追加されます（つまり、結果は配列の配列から単一の配列にフラット化されます） ）。残りのポインタートークンを値に適用した結果がそれ自体が配列である場合、その項目は配列自体を含めるのではなく、出力に個別に含める必要があります（つまり、結果は配列の配列から単一の配列にフラット化されます。 ）。
As a simple example, suppose we have the following API request "methodCalls":
簡単な例として、次のAPIリクエスト「methodCalls」があるとします。
[[ "Foo/changes", {
"accountId": "A1",
"sinceState": "abcdef"
}, "t0" ],
[ "Foo/get", {
"accountId": "A1",
"#ids": {
"resultOf": "t0",
"name": "Foo/changes",
"path": "/created"
}
}, "t1" ]]
After executing the first method call, the "methodResponses" array is:
最初のメソッド呼び出しを実行した後の「methodResponses」配列は次のとおりです。
[[ "Foo/changes", {
"accountId": "A1",
"oldState": "abcdef",
"newState": "123456",
"hasMoreChanges": false,
"created": [ "f1", "f4" ],
"updated": [],
"destroyed": []
}, "t0" ]]
To execute the "Foo/get" call, we look through the arguments and find there is one with a "#" prefix. To resolve this, we apply the algorithm above:
「Foo / get」呼び出しを実行するには、引数を調べて、「＃」プレフィックスが付いた引数があることを確認します。これを解決するには、上記のアルゴリズムを適用します。
1. Find the first response with method call id "t0". The "Foo/ changes" response fulfils this criterion.
1. メソッド呼び出しID "t0"の最初の応答を見つけます。 「Foo / changes」応答はこの基準を満たしています。
2. Check that the response name is the same as in the result reference. It is, so this is fine.
2. 応答名が結果参照と同じであることを確認してください。ですので、これで結構です。
3. Apply the "path" as a JSON Pointer to the arguments object. This simply selects the "created" property, so the result of evaluating is: [ "f1", "f4" ].
3. JSONポインターとして「パス」を引数オブジェクトに適用します。これは単に「作成された」プロパティを選択するだけなので、評価の結果は[[f1]、 "f4"]になります。
The JMAP server now continues to process the "Foo/get" call as though the arguments were:
JMAPサーバーは、引数が次のように "Foo / get"呼び出しの処理を続行します。
{
"accountId": "A1",
"ids": [ "f1", "f4" ]
}
Now, a more complicated example using the JMAP Mail data model: fetch the "from"/"date"/"subject" for every Email in the first 10 Threads in the inbox (sorted newest first):
次に、JMAPメールデータモデルを使用したより複雑な例：受信トレイの最初の10個のスレッド内のすべてのメールの「from」/「date」/「subject」をフェッチします（新しいものが最初にソートされます）。
[[ "Email/query", {
"accountId": "A1",
"filter": { "inMailbox": "id_of_inbox" },
"sort": [{ "property": "receivedAt", "isAscending": false }],
"collapseThreads": true,
"position": 0,
"limit": 10,
"calculateTotal": true
}, "t0" ],
[ "Email/get", {
"accountId": "A1",
"#ids": {
"resultOf": "t0",
"name": "Email/query",
"path": "/ids"
},
"properties": [ "threadId" ]
}, "t1" ],
[ "Thread/get", {
"accountId": "A1",
"#ids": {
"resultOf": "t1",
"name": "Email/get",
"path": "/list/*/threadId"
}
}, "t2" ],
[ "Email/get", {
"accountId": "A1",
"#ids": {
"resultOf": "t2",
"name": "Thread/get",
"path": "/list/*/emailIds"
},
"properties": [ "from", "receivedAt", "subject" ]
}, "t3" ]]
After executing the first 3 method calls, the "methodResponses" array might be:
最初の3つのメソッド呼び出しを実行すると、「methodResponses」配列は次のようになります。
[[ "Email/query", {
"accountId": "A1",
"queryState": "abcdefg",
"canCalculateChanges": true,
"position": 0,
"total": 101,
"ids": [ "msg1023", "msg223", "msg110", "msg93", "msg91",
"msg38", "msg36", "msg33", "msg11", "msg1" ]
}, "t0" ],
[ "Email/get", {
"accountId": "A1",
"state": "123456",
"list": [{
"id": "msg1023",
"threadId": "trd194"
}, {
"id": "msg223",
"threadId": "trd114"
},
...
],
"notFound": []
}, "t1" ],
[ "Thread/get", {
"accountId": "A1",
"state": "123456",
"list": [{
"id": "trd194",
"emailIds": [ "msg1020", "msg1021", "msg1023" ]
}, {
"id": "trd114",
"emailIds": [ "msg201", "msg223" ]
},
...
],
"notFound": []
}, "t2" ]]
To execute the final "Email/get" call, we look through the arguments and find there is one with a "#" prefix. To resolve this, we apply the algorithm:
最後の「Email / get」呼び出しを実行するには、引数を調べて、「＃」プレフィックスが付いた引数があることを確認します。これを解決するには、アルゴリズムを適用します。
1. Find the first response with method call id "t2". The "Thread/ get" response fulfils this criterion.
1. メソッド呼び出しID「t2」の最初の応答を見つけます。 「スレッド/取得」応答はこの基準を満たしています。
2. "Thread/get" is the name specified in the result reference, so this is fine.
2. 「スレッド/取得」は結果参照で指定された名前なので、これで問題ありません。
3. Apply the "path" as a JSON Pointer to the arguments object. Token by token:
3. JSONポインターとして「パス」を引数オブジェクトに適用します。トークンごとのトークン：
1. "list": get the array of thread objects
1. "list"：スレッドオブジェクトの配列を取得
2. "*": for each of the items in the array:
2. "*"：配列の各アイテム：
a. "emailIds": get the array of Email ids
a. "emailIds"：メールIDの配列を取得
b. Concatenate these into a single array of all the ids in the result.
b. これらを結果のすべてのIDの単一配列に連結します。
The JMAP server now continues to process the "Email/get" call as though the arguments were:
JMAPサーバーは、引数が次のように "Email / get"呼び出しの処理を続行します。
{
"accountId": "A1",
"ids": [ "msg1020", "msg1021", "msg1023", "msg201", "msg223", ... ],
"properties": [ "from", "receivedAt", "subject" ]
}
The ResultReference performs a similar role to that of the creation id, in that it allows a chained method call to refer to information not available when the request is generated. However, they are different things and not interchangeable; the only commonality is the octothorpe used to indicate them.
ResultReferenceは、作成されたIDの役割と同様の役割を果たします。これにより、要求が生成されたときに使用できない情報をチェーンメソッド呼び出しで参照できるようになります。ただし、これらは異なるものであり、互換性はありません。唯一の共通点は、それらを示すために使用されるオクトソープです。
If returning a custom string to be displayed to the user, for example, an error message, the server SHOULD use information from the Accept-Language header of the request (as defined in Section 5.3.5 of [RFC7231]) to choose the best available localisation. The Content-Language header of the response (see Section 3.1.3.2 of [RFC7231]) SHOULD indicate the language being used for user-visible strings.
エラーメッセージなど、ユーザーに表示するカスタム文字列を返す場合、サーバーはリクエストのAccept-Languageヘッダーからの情報を使用する必要があります（[RFC7231]のセクション5.3.5で定義）。利用可能なローカリゼーション。応答のContent-Languageヘッダー（[RFC7231]のセクション3.1.3.2を参照）は、ユーザーに表示される文字列に使用されている言語を示す必要があります（SHOULD）。
For example, suppose a request was made with the following header:
たとえば、次のヘッダーを使用してリクエストが行われたとします。
Accept-Language: fr-CH, fr;q=0.9, de;q=0.8, en;q=0.7, *;q=0.5
and a method generated an error to display to the user. The server has translations of the error message in English and German. Looking at the Accept-Language header, the user's preferred language is French. Since we don't have a translation for this, we look at the next most preferred, which is German. We have a German translation, so the server returns this and indicates the language chosen in a Content-Language header like so:
そして、メソッドはユーザーに表示するエラーを生成しました。サーバーには、英語とドイツ語のエラーメッセージの翻訳があります。 Accept-Languageヘッダーを見ると、ユーザーの優先言語はフランス語です。このための翻訳がないため、次に優先されるドイツ語を調べます。ドイツ語の翻訳があるため、サーバーはこれを返し、次のようにContent-Languageヘッダーで選択された言語を示します。
Content-Language: de
コンテンツ言語：de
As always, the server must be strict about data received from the client. Arguments need to be checked for validity; a malicious user could attempt to find an exploit through the API. In case of invalid arguments (unknown/insufficient/wrong type for data, etc.), the method MUST return an "invalidArguments" error and terminate.
いつものように、サーバーはクライアントから受信したデータについて厳密でなければなりません。引数の妥当性をチェックする必要があります。悪意のあるユーザーがAPIを介してエクスプロイトを見つけようとする可能性があります。無効な引数（データの不明/不十分/間違ったタイプなど）の場合、メソッドは「invalidArguments」エラーを返して終了する必要があります。
Method calls within a single request MUST be executed in order. However, method calls from different concurrent API requests may be interleaved. This means that the data on the server may change between two method calls within a single API request.
単一のリクエスト内のメソッド呼び出しは、順番に実行する必要があります。ただし、異なる同時APIリクエストからのメソッド呼び出しはインターリーブされる場合があります。つまり、サーバー上のデータは、1つのAPIリクエスト内の2つのメソッド呼び出し間で変更される可能性があります。
The "Core/echo" method returns exactly the same arguments as it is given. It is useful for testing if you have a valid authenticated connection to a JMAP API endpoint.
「Core / echo」メソッドは、指定されたものとまったく同じ引数を返します。 JMAP APIエンドポイントへの有効な認証済み接続があるかどうかをテストするのに役立ちます。
Request:
リクエスト：
[[ "Core/echo", {
"hello": true,
"high": 5
}, "b3ff" ]]
Response:
応答：
[[ "Core/echo", {
"hello": true,
"high": 5
}, "b3ff" ]]
JMAP provides a uniform interface for creating, retrieving, updating, and deleting objects of a particular type. For a "Foo" data type, records of that type would be fetched via a "Foo/get" call and modified via a "Foo/set" call. Delta updates may be fetched via a "Foo/changes" call. These methods all follow a standard format as described below.
JMAPは、特定のタイプのオブジェクトを作成、取得、更新、および削除するための統一されたインターフェースを提供します。 「Foo」データタイプの場合、そのタイプのレコードは「Foo / get」呼び出しを介してフェッチされ、「Foo / set」呼び出しを介して変更されます。差分更新は、「Foo / changes」呼び出しを介してフェッチできます。これらのメソッドはすべて、以下に説明する標準形式に従います。
Some types may not have all these methods. Specifications defining types MUST specify which methods are available for the type.
一部のタイプには、これらのメソッドがすべて含まれていない場合があります。タイプを定義する仕様では、タイプに使用できるメソッドを指定する必要があります。
Objects of type Foo are fetched via a call to "Foo/get".
タイプFooのオブジェクトは、「Foo / get」の呼び出しを介してフェッチされます。
It takes the following arguments:
次の引数を取ります。
o accountId: "Id"
o accountId： "Id"
The id of the account to use.
使用するアカウントのID。
o ids: "Id[]|null"
o ids： "Id [] | null"
The ids of the Foo objects to return. If null, then *all* records of the data type are returned, if this is supported for that data type and the number of records does not exceed the "maxObjectsInGet" limit.
返すFooオブジェクトのID。 nullの場合、データ型の*すべての*レコードが返されます。これがそのデータ型でサポートされており、レコード数が「maxObjectsInGet」の制限を超えていない場合。
o properties: "String[]|null"
o プロパティ： "String [] | null"
If supplied, only the properties listed in the array are returned for each Foo object. If null, all properties of the object are returned. The id property of the object is *always* returned, even if not explicitly requested. If an invalid property is requested, the call MUST be rejected with an "invalidArguments" error.
指定すると、配列にリストされているプロパティのみが各Fooオブジェクトに対して返されます。 nullの場合、オブジェクトのすべてのプロパティが返されます。明示的に要求されていなくても、オブジェクトのidプロパティは*常に*返されます。無効なプロパティが要求された場合、 "invalidArguments"エラーで呼び出しを拒否する必要があります。
The response has the following arguments:
応答には次の引数があります。
o accountId: "Id"
o accountId： "Id"
The id of the account used for the call.
呼び出しに使用されたアカウントのID。
o state: "String"
o 状態：「文字列」
A (preferably short) string representing the state on the server for *all* the data of this type in the account (not just the objects returned in this call). If the data changes, this string MUST change. If the Foo data is unchanged, servers SHOULD return the same state string on subsequent requests for this data type. When a client receives a response with a different state string to a previous call, it MUST either throw away all currently cached objects for the type or call "Foo/changes" to get the exact changes.
アカウント内のこのタイプのデータ（この呼び出しで返されるオブジェクトだけではない）の*すべて*のサーバーの状態を表す（できれば短い）文字列。データが変更された場合、この文字列も変更する必要があります。 Fooデータが変更されていない場合、サーバーは、このデータ型の後続のリクエストで同じ状態文字列を返す必要があります（SHOULD）。クライアントが前の呼び出しとは異なる状態文字列の応答を受け取った場合、そのタイプの現在キャッシュされているオブジェクトをすべて破棄するか、「Foo / changes」を呼び出して正確な変更を取得する必要があります。
o list: "Foo[]"
o リスト：「Foo []」
An array of the Foo objects requested. This is the *empty array* if no objects were found or if the "ids" argument passed in was also an empty array. The results MAY be in a different order to the "ids" in the request arguments. If an identical id is included more than once in the request, the server MUST only include it once in either the "list" or the "notFound" argument of the response.
リクエストされたFooオブジェクトの配列。オブジェクトが見つからなかった場合、または渡された "ids"引数も空の配列だった場合、これは*空の配列*です。結果は、リクエスト引数の「ID」とは異なる順序になる場合があります。同一のIDがリクエストに2回以上含まれている場合、サーバーはそれをレスポンスの「list」または「notFound」引数のいずれかに1回だけ含める必要があります。
o notFound: "Id[]"
o notFound： "Id []"
This array contains the ids passed to the method for records that do not exist. The array is empty if all requested ids were found or if the "ids" argument passed in was either null or an empty array.
この配列には、存在しないレコードのメソッドに渡されたIDが含まれています。要求されたすべてのIDが見つかった場合、または渡された「ids」引数がnullまたは空の配列であった場合、配列は空です。
The following additional error may be returned instead of the "Foo/ get" response:
「Foo / get」応答の代わりに、次の追加エラーが返される場合があります。
"requestTooLarge": The number of ids requested by the client exceeds the maximum number the server is willing to process in a single method call.
"requestTooLarge"：クライアントから要求されたIDの数が、サーバーが単一のメソッド呼び出しで処理する最大数を超えています。
When the state of the set of Foo records in an account changes on the server (whether due to creation, updates, or deletion), the "state" property of the "Foo/get" response will change. The "Foo/changes" method allows a client to efficiently update the state of its Foo cache to match the new state on the server. It takes the following arguments:
アカウント内のFooレコードのセットの状態がサーバー上で（作成、更新、または削除のために）変更されると、「Foo / get」応答の「state」プロパティが変更されます。 「Foo / changes」メソッドを使用すると、クライアントはFooキャッシュの状態を効率的に更新して、サーバーの新しい状態と一致させることができます。次の引数を取ります。
o accountId: "Id"
o accountId： "Id"
The id of the account to use.
使用するアカウントのID。
o sinceState: "String"
o sinceState： "文字列"
The current state of the client. This is the string that was returned as the "state" argument in the "Foo/get" response. The server will return the changes that have occurred since this state.
クライアントの現在の状態。これは、「Foo / get」応答で「状態」引数として返された文字列です。サーバーは、この状態以降に発生した変更を返します。
o maxChanges: "UnsignedInt|null"
o maxChanges： "UnsignedInt | null"
The maximum number of ids to return in the response. The server MAY choose to return fewer than this value but MUST NOT return more. If not given by the client, the server may choose how many to return. If supplied by the client, the value MUST be a positive integer greater than 0. If a value outside of this range is given, the server MUST reject the call with an "invalidArguments" error.
応答で返すIDの最大数。サーバーは、この値よりも少ない値を返すことを選択できますが、それ以上は返してはなりません。クライアントが指定しない場合、サーバーは返す数を選択できます。クライアントから提供される場合、値は0より大きい正の整数でなければなりません。この範囲外の値が指定された場合、サーバーは「invalidArguments」エラーで呼び出しを拒否する必要があります。
The response has the following arguments:
応答には次の引数があります。
o accountId: "Id"
o accountId： "Id"
The id of the account used for the call.
呼び出しに使用されたアカウントのID。
o oldState: "String"
o oldState： "文字列"
This is the "sinceState" argument echoed back; it's the state from which the server is returning changes.
これはエコーバックされる「sinceState」引数です。これは、サーバーが変更を返す状態です。
o newState: "String"
o newState： "文字列"
This is the state the client will be in after applying the set of changes to the old state.
これは、一連の変更を古い状態に適用した後のクライアントの状態です。
o hasMoreChanges: "Boolean"
o hasMoreChanges： "ブール"
If true, the client may call "Foo/changes" again with the "newState" returned to get further updates. If false, "newState" is the current server state.
trueの場合、クライアントは「Foo / changes」を再度呼び出し、「newState」を返してさらに更新を取得できます。 falseの場合、「newState」は現在のサーバーの状態です。
o created: "Id[]"
o 作成：「Id []」
An array of ids for records that have been created since the old state.
古い状態以降に作成されたレコードのIDの配列。
o updated: "Id[]"
o 更新：「Id []」
An array of ids for records that have been updated since the old state.
古い状態以降に更新されたレコードのIDの配列。
o destroyed: "Id[]"
o 破壊：「Id []」
An array of ids for records that have been destroyed since the old state.
古い状態以降に破棄されたレコードのIDの配列。
If a record has been created AND updated since the old state, the server SHOULD just return the id in the "created" list but MAY return it in the "updated" list as well.
レコードが作成され、以前の状態以降に更新された場合、サーバーは「作成済み」リストでIDを返すだけでなく、「更新済み」リストでもIDを返す必要があります。
If a record has been updated AND destroyed since the old state, the server SHOULD just return the id in the "destroyed" list but MAY return it in the "updated" list as well.
レコードが古い状態以降に更新および破棄されている場合、サーバーは「破棄された」リストにIDを返すだけでなく、「更新された」リストにもIDを返す必要があります（MAY）。
If a record has been created AND destroyed since the old state, the server SHOULD remove the id from the response entirely. However, it MAY include it in just the "destroyed" list or in both the "destroyed" and "created" lists.
古い状態以降にレコードが作成および破棄されている場合、サーバーは応答からIDを完全に削除する必要があります（SHOULD）。ただし、「破棄」リストのみ、または「破棄」リストと「作成」リストの両方に含めることはできます（MAY）。
If a "maxChanges" is supplied, or set automatically by the server, the server MUST ensure the number of ids returned across "created", "updated", and "destroyed" does not exceed this limit. If there are more changes than this between the client's state and the current server state, the server SHOULD generate an update to take the client to an intermediate state, from which the client can continue to call "Foo/changes" until it is fully up to date. If it is unable to calculate an intermediate state, it MUST return a "cannotCalculateChanges" error response instead.
「maxChanges」が提供されるか、サーバーによって自動的に設定される場合、サーバーは、「作成」、「更新」、および「破棄」にわたって返されるIDの数がこの制限を超えないようにする必要があります。クライアントの状態と現在のサーバーの状態の間にこれよりも多くの変更がある場合、サーバーは更新を生成してクライアントを中間状態にし、クライアントが「Foo / changes」を完全に起動するまで呼び出しを続けることができるようにします現在まで。中間状態を計算できない場合は、代わりに「cannotCalculateChanges」エラー応答を返す必要があります。
When generating intermediate states, the server may choose how to divide up the changes. For many types, it will provide a better user experience to return the more recent changes first, as this is more likely to be what the user is most interested in. The client can then continue to page in the older changes while the user is viewing the newer data. For example, suppose a server went through the following states:
中間状態を生成するとき、サーバーは変更を分割する方法を選択できます。多くのタイプでは、ユーザーが最も関心を持っている可能性が高いので、最新の変更を最初に返す方がユーザーエクスペリエンスが向上します。クライアントは、ユーザーが表示している間、古い変更を引き続きページインできます。新しいデータ。たとえば、サーバーが次の状態になったとします。
A -> B -> C -> D -> E
And a client asks for changes from state "B". The server might first get the ids of records created, updated, or destroyed between states D and E, returning them with:
そして、クライアントは状態「B」からの変更を要求します。サーバーはまず、状態DとEの間で作成、更新、または破棄されたレコードのIDを取得し、次のようにそれらを返します。
state: "B-D-E" hasMoreChanges: true
状態： "B-D-E" hasMoreChanges：true
The client will then ask for the change from state "B-D-E", and the server can return the changes between states C and D, returning:
次に、クライアントは状態「B-D-E」からの変更を要求し、サーバーは状態CとDの間の変更を返すことができます。
state: "B-C-E" hasMoreChanges: true
状態： "B-C-E" hasMoreChanges：true
Finally, the client will request the changes from "B-C-E", and the server can return the changes between states B and C, returning:
最後に、クライアントは「B-C-E」からの変更を要求し、サーバーは状態BとCの間の変更を返すことができます。
state: "E" hasMoreChanges: false
状態： "E" hasMoreChanges：false
Should the state on the server be modified in the middle of all this (to "F"), the server still does the same, but now when the update to state "E" is returned, it would indicate that it still has more changes for the client to fetch.
このすべての途中でサーバーの状態が（ "F"に）変更された場合でも、サーバーは同じことを行いますが、状態 "E"への更新が返されたときに、まだ変更があることを示しています。クライアントがフェッチするため。
Where multiple changes to a record are split across different intermediate states, the server MUST NOT return a record as created after a response that deems it as updated or destroyed, and it MUST NOT return a record as destroyed before a response that deems it as created or updated. The server may have to coalesce multiple changes to a record to satisfy this requirement.
レコードへの複数の変更が異なる中間状態にまたがっている場合、サーバーは、更新または破棄されたと見なす応答の後に作成されたレコードを返さないでください。または更新されました。サーバーは、この要件を満たすために、レコードへの複数の変更を結合する必要がある場合があります。
The following additional errors may be returned instead of the "Foo/ changes" response:
「Foo / changes」応答の代わりに、次の追加エラーが返される場合があります。
"cannotCalculateChanges": The server cannot calculate the changes from the state string given by the client. Usually, this is due to the client's state being too old or the server being unable to produce an update to an intermediate state when there are too many updates. The client MUST invalidate its Foo cache.
「cannotCalculateChanges」：サーバーは、クライアントによって指定された状態文字列からの変更を計算できません。通常、これはクライアントの状態が古すぎるか、更新が多すぎる場合にサーバーが中間状態への更新を生成できないことが原因です。クライアントはFooキャッシュを無効化する必要があります。
Maintaining state to allow calculation of "Foo/changes" can be expensive for the server, but always returning "cannotCalculateChanges" severely increases network traffic and resource usage for the client. To allow efficient sync, servers SHOULD be able to calculate changes from any state string that was given to a client within the last 30 days (but of course may support calculating updates from states older than this).
"Foo / changes"の計算を許可する状態を維持すると、サーバーの負荷が高くなりますが、常に "cannotCalculateChanges"を返すと、クライアントのネットワークトラフィックとリソースの使用量が大幅に増加します。効率的な同期を可能にするために、サーバーは過去30日以内にクライアントに与えられたすべての状態文字列からの変更を計算できる必要があります（もちろん、これより古い状態からの更新の計算をサポートする場合があります）。
Modifying the state of Foo objects on the server is done via the "Foo/set" method. This encompasses creating, updating, and destroying Foo records. This allows the server to sort out ordering and dependencies that may exist if doing multiple operations at once (for example, to ensure there is always a minimum number of a certain record type).
サーバー上のFooオブジェクトの状態を変更するには、「Foo / set」メソッドを使用します。これには、Fooレコードの作成、更新、破棄が含まれます。これにより、サーバーは、複数の操作を同時に実行する場合に存在する可能性のある順序と依存関係を整理できます（たとえば、特定のレコードタイプの数が常に最小になるようにします）。
The "Foo/set" method takes the following arguments:
「Foo / set」メソッドは次の引数を取ります。
o accountId: "Id"
o accountId： "Id"
The id of the account to use.
使用するアカウントのID。
o ifInState: "String|null"
o ifInState： "文字列| null"
This is a state string as returned by the "Foo/get" method (representing the state of all objects of this type in the account). If supplied, the string must match the current state; otherwise, the method will be aborted and a "stateMismatch" error returned. If null, any changes will be applied to the current state.
これは、「Foo / get」メソッドによって返される状態文字列です（アカウント内のこのタイプのすべてのオブジェクトの状態を表します）。指定する場合、文字列は現在の状態と一致する必要があります。そうでない場合、メソッドは中止され、「stateMismatch」エラーが返されます。 nullの場合、変更は現在の状態に適用されます。
o create: "Id[Foo]|null"
o 作成：「Id [Foo] | null」
A map of a *creation id* (a temporary id set by the client) to Foo objects, or null if no objects are to be created.
*作成ID *（クライアントによって設定された一時的なID）のFooオブジェクトへのマップ。オブジェクトが作成されない場合はnull。
The Foo object type definition may define default values for properties. Any such property may be omitted by the client.
Fooオブジェクトタイプの定義では、プロパティのデフォルト値を定義できます。このようなプロパティは、クライアントによって省略される場合があります。
The client MUST omit any properties that may only be set by the server (for example, the "id" property on most object types).
クライアントは、サーバーのみが設定できるプロパティ（たとえば、ほとんどのオブジェクトタイプの「id」プロパティ）を省略しなければなりません（MUST）。
o update: "Id[PatchObject]|null"
o 更新： "Id [PatchObject] | null"
A map of an id to a Patch object to apply to the current Foo object with that id, or null if no objects are to be updated.
そのIDを持つ現在のFooオブジェクトに適用するためのPatchオブジェクトへのIDのマップ。更新するオブジェクトがない場合はnull。
A *PatchObject* is of type "String[*]" and represents an unordered set of patches. The keys are a path in JSON Pointer format [RFC6901], with an implicit leading "/" (i.e., prefix each key with "/" before applying the JSON Pointer evaluation algorithm).
* PatchObject *のタイプは「String [*]」で、順序付けされていない一連のパッチを表します。キーは、JSONポインター形式[RFC6901]のパスで、暗黙的に先頭に「/」が付きます（つまり、JSONポインター評価アルゴリズムを適用する前に、各キーの先頭に「/」を付けます）。
All paths MUST also conform to the following restrictions; if there is any violation, the update MUST be rejected with an "invalidPatch" error:
すべてのパスは、次の制限にも準拠する必要があります。違反がある場合は、「invalidPatch」エラーで更新を拒否する必要があります。
* The pointer MUST NOT reference inside an array (i.e., you MUST NOT insert/delete from an array; the array MUST be replaced in its entirety instead).
* ポインタは配列内を参照してはなりません（つまり、配列から挿入/削除してはいけません。代わりに配列全体を置き換えなければなりません）。
* All parts prior to the last (i.e., the value after the final slash) MUST already exist on the object being patched.
* 最後の前のすべての部分（つまり、最後のスラッシュの後の値）は、パッチが適用されるオブジェクトにすでに存在している必要があります。
* There MUST NOT be two patches in the PatchObject where the pointer of one is the prefix of the pointer of the other, e.g., "alerts/1/offset" and "alerts".
* PatchObjectに2つのパッチがあってはなりません。一方のポインタが他方のポインタのプレフィックスです（たとえば、「alerts / 1 / offset」と「alerts」）。
The value associated with each pointer determines how to apply that patch:
各ポインタに関連付けられている値によって、そのパッチの適用方法が決まります。
* If null, set to the default value if specified for this property; otherwise, remove the property from the patched object. If the key is not present in the parent, this a no-op.
* nullの場合、このプロパティに指定されていればデフォルト値に設定されます。それ以外の場合は、パッチを適用したオブジェクトからプロパティを削除します。キーが親に存在しない場合、これはノーオペレーションです。
* Anything else: The value to set for this property (this may be a replacement or addition to the object being patched).
* その他：このプロパティに設定する値（これは、パッチが適用されるオブジェクトの置換または追加の場合があります）。
Any server-set properties MAY be included in the patch if their value is identical to the current server value (before applying the patches to the object). Otherwise, the update MUST be rejected with an "invalidProperties" SetError.
サーバーに設定されたプロパティは、それらの値が現在のサーバーの値（オブジェクトにパッチを適用する前）と同じである場合、パッチに含めることができます（MAY）。それ以外の場合、「invalidProperties」SetErrorで更新を拒否する必要があります。
This patch definition is designed such that an entire Foo object is also a valid PatchObject. The client may choose to optimise network usage by just sending the diff or may send the whole object; the server processes it the same either way.
このパッチ定義は、Fooオブジェクト全体が有効なPatchObjectになるように設計されています。クライアントは、差分を送信するだけでネットワークの使用を最適化するか、オブジェクト全体を送信するかを選択できます。サーバーはどちらの方法でも同じように処理します。
o destroy: "Id[]|null"
o destroy： "Id [] | null"
A list of ids for Foo objects to permanently delete, or null if no objects are to be destroyed.
完全に削除するFooオブジェクトのIDのリスト。破棄するオブジェクトがない場合はnull。
Each creation, modification, or destruction of an object is considered an atomic unit. It is permissible for the server to commit changes to some objects but not others; however, it MUST NOT only commit part of an update to a single record (e.g., update a "name" property but not a "count" property, if both are supplied in the update object).
オブジェクトの作成、変更、または破棄はそれぞれ、アトミックユニットと見なされます。サーバーが一部のオブジェクトへの変更をコミットし、他のオブジェクトへのコミットは許可されていません。ただし、単一のレコードへの更新の一部のみをコミットしてはなりません（たとえば、「name」プロパティを更新しますが、両方が更新オブジェクトで提供されている場合、「count」プロパティは更新しません）。
The final state MUST be valid after the "Foo/set" is finished; however, the server may have to transition through invalid intermediate states (not exposed to the client) while processing the individual create/update/destroy requests. For example, suppose there is a "name" property that must be unique. A single method call could rename an object A => B and simultaneously rename another object B => A. If the final state is valid, this is allowed. Otherwise, each creation, modification, or destruction of an object should be processed sequentially and accepted/rejected based on the current server state.
最終的な状態は、「Foo / set」が終了した後に有効でなければなりません。ただし、サーバーは、個々の作成/更新/破棄リクエストの処理中に、無効な中間状態（クライアントに公開されない）を経由して移行する必要がある場合があります。たとえば、一意である必要がある「名前」プロパティがあるとします。単一のメソッド呼び出しで、オブジェクトの名前をA => Bに変更し、同時に別のオブジェクトの名前をB => Aに変更できます。最終状態が有効な場合、これは許可されます。それ以外の場合は、オブジェクトの作成、変更、または破棄のそれぞれを順次処理し、現在のサーバーの状態に基づいて受け入れ/拒否する必要があります。
If a create, update, or destroy is rejected, the appropriate error MUST be added to the notCreated/notUpdated/notDestroyed property of the response, and the server MUST continue to the next create/update/ destroy. It does not terminate the method.
作成、更新、または破棄が拒否された場合、適切なエラーを応答のnotCreated / notUpdated / notDestroyedプロパティに追加する必要があり、サーバーは次の作成/更新/破棄を続行する必要があります。メソッドは終了しません。
If an id given cannot be found, the update or destroy MUST be rejected with a "notFound" set error.
指定されたIDが見つからない場合、「notFound」設定エラーで更新または破棄を拒否する必要があります。
The server MAY skip an update (rejecting it with a "willDestroy" SetError) if that object is destroyed in the same /set request.
オブジェクトが同じ/ setリクエストで破棄された場合、サーバーは更新をスキップできます（ "willDestroy" SetErrorで拒否されます）。
Some records may hold references to other records (foreign keys). That reference may be set (via create or update) in the same request as the referenced record is created. To do this, the client refers to the new record using its creation id prefixed with a "#". The order of the method calls in the request by the client MUST be such that the record being referenced is created in the same or an earlier call. Thus, the server never has to look ahead. Instead, while processing a request, the server MUST keep a simple map for the duration of the request of creation id to record id for each newly created record, so it can substitute in the correct value if necessary in later method calls. In the case of records with references to the same type, the server MUST order the creates and updates within a single method call so that creates happen before their creation ids are referenced by another create/update/destroy in the same call.
一部のレコードは、他のレコード（外部キー）への参照を保持する場合があります。その参照は、参照レコードが作成されるのと同じ要求で（作成または更新を介して）設定できます。これを行うために、クライアントは、「＃」で始まる作成IDを使用して新しいレコードを参照します。クライアントによるリクエストでのメソッド呼び出しの順序は、参照されるレコードが同じまたは以前の呼び出しで作成されるようなものでなければなりません。したがって、サーバーが先を見ることはありません。代わりに、リクエストを処理している間、サーバーは、新しく作成された各レコードの作成IDからレコードIDへのリクエストの期間中、単純なマップを保持する必要があるため、後のメソッド呼び出しで必要に応じて正しい値に置き換えることができます。同じタイプへの参照を持つレコードの場合、サーバーは単一のメソッド呼び出し内で作成と更新を順序付けする必要があるため、同じ呼び出しで別の作成/更新/破棄によって作成IDが参照される前に作成が行われます。
Creation ids are not scoped by type but are a single map for all types. A client SHOULD NOT reuse a creation id anywhere in the same API request. If a creation id is reused, the server MUST map the creation id to the most recently created item with that id. To allow easy proxying of API requests, an initial set of creation id to real id values may be passed with a request (see "The Request Object", Section 3.3) and the final state of the map passed out with the response (see "The Response Object", Section 3.4).
作成IDはタイプによってスコープされませんが、すべてのタイプに対する単一のマップです。クライアントは、同じAPIリクエスト内のどこでも作成IDを再利用しないでください。作成IDが再利用される場合、サーバーはその作成IDを、そのIDで最後に作成されたアイテムにマップする必要があります。 APIリクエストを簡単にプロキシできるようにするために、作成IDから実際のID値への初期セットをリクエスト（「リクエストオブジェクト」、セクション3.3を参照）で渡し、マップの最終状態をレスポンスで渡すことができます（「応答オブジェクト」、セクション3.4）。
The response has the following arguments:
応答には次の引数があります。
o accountId: "Id"
o accountId： "Id"
The id of the account used for the call.
呼び出しに使用されたアカウントのID。
o oldState: "String|null"
o oldState： "文字列| null"
The state string that would have been returned by "Foo/get" before making the requested changes, or null if the server doesn't know what the previous state string was.
リクエストされた変更を行う前に "Foo / get"によって返されるはずの状態文字列。サーバーが前の状態文字列が何であるかをサーバーが知らない場合はnull。
o newState: "String"
o newState： "文字列"
The state string that will now be returned by "Foo/get".
「Foo / get」によって返される状態文字列。
o created: "Id[Foo]|null"
o 作成：「Id [Foo] | null」
A map of the creation id to an object containing any properties of the created Foo object that were not sent by the client. This includes all server-set properties (such as the "id" in most object types) and any properties that were omitted by the client and thus set to a default by the server.
クライアントによって送信されなかった、作成されたFooオブジェクトのプロパティを含むオブジェクトへの作成IDのマップ。これには、すべてのサーバー設定プロパティ（ほとんどのオブジェクトタイプの「id」など）と、クライアントによって省略され、サーバーによってデフォルトに設定されたプロパティが含まれます。
This argument is null if no Foo objects were successfully created.
Fooオブジェクトが正常に作成されなかった場合、この引数はnullです。
o updated: "Id[Foo|null]|null"
o 更新：「Id [Foo | null] | null」
The keys in this map are the ids of all Foos that were successfully updated.
このマップのキーは、正常に更新されたすべての食品のIDです。
The value for each id is a Foo object containing any property that changed in a way *not* explicitly requested by the PatchObject sent to the server, or null if none. This lets the client know of any changes to server-set or computed properties.
各IDの値は、サーバーに送信されたPatchObjectによって明示的に要求されなかった方法で変更されたプロパティを含むFooオブジェクトです。ない場合はnullです。これにより、クライアントはサーバーセットまたは計算されたプロパティへの変更を知ることができます。
This argument is null if no Foo objects were successfully updated.
Fooオブジェクトが正常に更新されなかった場合、この引数はnullです。
o destroyed: "Id[]|null"
o 破壊：「Id [] | null」
A list of Foo ids for records that were successfully destroyed, or null if none.
正常に破棄されたレコードのFoo IDのリスト。ない場合はnull。
o notCreated: "Id[SetError]|null"
o notCreated： "Id [SetError] | null"
A map of the creation id to a SetError object for each record that failed to be created, or null if all successful.
作成に失敗した各レコードのSetErrorオブジェクトへの作成IDのマップ、またはすべてが成功した場合はnull。
o notUpdated: "Id[SetError]|null"
o notUpdated： "Id [SetError] | null"
A map of the Foo id to a SetError object for each record that failed to be updated, or null if all successful.
更新に失敗した各レコードのFoo idからSetErrorオブジェクトへのマップ、またはすべてが成功した場合はnull。
o notDestroyed: "Id[SetError]|null"
o notDestroyed： "Id [SetError] | null"
A map of the Foo id to a SetError object for each record that failed to be destroyed, or null if all successful.
破棄に失敗した各レコードのFoo IDからSetErrorオブジェクトへのマップ、またはすべてが成功した場合はnull。
A *SetError* object has the following properties:
* SetError *オブジェクトには次のプロパティがあります：
o type: "String"
o タイプ：「文字列」
The type of error.
エラーのタイプ。
o description: "String|null"
o 説明：「文字列| null」
A description of the error to help with debugging that includes an explanation of what the problem was. This is a non-localised string and is not intended to be shown directly to end users.
デバッグに役立つエラーの説明。問題の説明も含まれます。これはローカライズされていない文字列であり、エンドユーザーに直接表示することは意図されていません。
The following SetError types are defined and may be returned for set operations on any record type where appropriate:
次のSetError型が定義されており、必要に応じて、任意のレコード型の集合演算で返される場合があります。
o "forbidden": (create; update; destroy). The create/update/destroy would violate an ACL or other permissions policy.
o 「禁止」：（作成、更新、破棄）。作成/更新/破棄は、ACLまたはその他のアクセス許可ポリシーに違反します。
o "overQuota": (create; update). The create would exceed a server-defined limit on the number or total size of objects of this type.
o "overQuota"：（作成、更新）。作成は、このタイプのオブジェクトの数または合計サイズに対するサーバー定義の制限を超えます。
o "tooLarge": (create; update). The create/update would result in an object that exceeds a server-defined limit for the maximum size of a single object of this type.
o "tooLarge"：（作成、更新）。作成/更新の結果、オブジェクトは、このタイプの単一オブジェクトの最大サイズに関するサーバー定義の制限を超えます。
o "rateLimit": (create). Too many objects of this type have been created recently, and a server-defined rate limit has been reached. It may work if tried again later.
o "rateLimit"：（作成）。このタイプのオブジェクトが多すぎて最近作成されておらず、サーバー定義のレート制限に達しています。後で再試行すると機能する場合があります。
o "notFound": (update; destroy). The id given to update/destroy cannot be found.
o 「notFound」：（更新、破棄）。 update / destroyに指定されたIDが見つかりません。
o "invalidPatch": (update). The PatchObject given to update the record was not a valid patch (see the patch description).
o 「invalidPatch」：（更新）。レコードを更新するために指定されたPatchObjectは有効なパッチではありませんでした（パッチの説明を参照）。
o "willDestroy": (update). The client requested that an object be both updated and destroyed in the same /set request, and the server has decided to therefore ignore the update.
o "willDestroy"：（更新）。クライアントはオブジェクトを同じ/ set要求で更新および破棄するように要求し、サーバーは更新を無視することを決定しました。
o "invalidProperties": (create; update). The record given is invalid in some way. For example:
o "invalidProperties"：（作成、更新）。指定されたレコードは何らかの方法で無効です。例えば：
* It contains properties that are invalid according to the type specification of this record type.
* このレコードタイプのタイプ仕様に応じて無効なプロパティが含まれています。
* It contains a property that may only be set by the server (e.g., "id") and is different to the current value. Note, to allow clients to pass whole objects back, it is not an error to include a server-set property in an update as long as the value is identical to the current value on the server.
* これには、サーバーによってのみ設定できるプロパティ（「id」など）が含まれており、現在の値とは異なります。クライアントがオブジェクト全体を戻すことを許可するために、値がサーバー上の現在の値と同一である限り、サーバーセットプロパティを更新に含めることはエラーではありません。
* There is a reference to another record (foreign key), and the given id does not correspond to a valid record.
* 別のレコード（外部キー）への参照があり、指定されたIDは有効なレコードに対応していません。
The SetError object SHOULD also have a property called "properties" of type "String[]" that lists *all* the properties that were invalid.
SetErrorオブジェクトは、タイプが「String []」の「properties」と呼ばれるプロパティも持っている必要があります。
Individual methods MAY specify more specific errors for certain conditions that would otherwise result in an invalidProperties error. If the condition of one of these is met, it MUST be returned instead of the invalidProperties error.
個々のメソッドは、それ以外の場合はinvalidPropertiesエラーとなる特定の条件に対して、より具体的なエラーを指定する場合があります。これらのいずれかの条件が満たされている場合は、invalidPropertiesエラーの代わりに条件を返す必要があります。
o "singleton": (create; destroy). This is a singleton type, so you cannot create another one or destroy the existing one.
o "シングルトン"：（作成;破壊）。これはシングルトンタイプであるため、別のタイプを作成したり、既存のタイプを破棄したりすることはできません。
Other possible SetError types MAY be given in specific method descriptions. Other properties MAY also be present on the SetError object, as described in the relevant methods.
他の可能なSetError型は、特定のメソッドの説明で与えられるかもしれません。関連するメソッドで説明されているように、SetErrorオブジェクトには他のプロパティも存在する場合があります。
The following additional errors may be returned instead of the "Foo/ set" response:
「Foo / set」応答の代わりに、次の追加エラーが返される場合があります。
"requestTooLarge": The total number of objects to create, update, or destroy exceeds the maximum number the server is willing to process in a single method call.
"requestTooLarge"：作成、更新、または破棄するオブジェクトの総数が、サーバーが単一のメソッド呼び出しで処理する最大数を超えています。
"stateMismatch": An "ifInState" argument was supplied, and it does not match the current state.
"stateMismatch"： "ifInState"引数が指定されましたが、現在の状態と一致しません。
The only way to move Foo records *between* two different accounts is to copy them using the "Foo/copy" method; once the copy has succeeded, delete the original. The "onSuccessDestroyOriginal" argument allows you to try to do this in one method call; however, note that the two different actions are not atomic, so it is possible for the copy to succeed but the original not to be destroyed for some reason.
2つの異なるアカウント間でFooレコードを移動する唯一の方法は、「Foo / copy」メソッドを使用してそれらをコピーすることです。コピーが成功したら、オリジナルを削除します。 「onSuccessDestroyOriginal」引数を使用すると、これを1つのメソッド呼び出しで実行できます。ただし、2つの異なるアクションはアトミックではないため、コピーは成功する可能性がありますが、元のアクションは何らかの理由で破棄されない可能性があります。
The copy is conceptually in three phases:
コピーは概念的には3つのフェーズにあります。
1. Reading the current values from the "from" account.
1. 「from」アカウントから現在の値を読み取る。
2. Writing the new copies to the other account.
2. 新しいコピーを他のアカウントに書き込む。
3. Destroying the originals in the "from" account, if requested.
3. 要求された場合、「from」アカウントのオリジナルを破棄します。
Data may change in between phases due to concurrent requests.
同時リクエストにより、データはフェーズ間で変更される場合があります。
The "Foo/copy" method takes the following arguments:
「Foo / copy」メソッドは次の引数を取ります。
o fromAccountId: "Id"
o fromAccountId： "Id"
The id of the account to copy records from.
レコードのコピー元のアカウントのID。
o ifFromInState: "String|null"
o ifFromInState： "文字列| null"
This is a state string as returned by the "Foo/get" method. If supplied, the string must match the current state of the account referenced by the fromAccountId when reading the data to be copied; otherwise, the method will be aborted and a "stateMismatch" error returned. If null, the data will be read from the current state.
これは、「Foo / get」メソッドによって返される状態文字列です。指定する場合、文字列は、コピーするデータを読み取るときに、fromAccountIdによって参照されるアカウントの現在の状態と一致する必要があります。そうでない場合、メソッドは中止され、「stateMismatch」エラーが返されます。 nullの場合、データは現在の状態から読み取られます。
o accountId: "Id"
o accountId： "Id"
The id of the account to copy records to. This MUST be different to the "fromAccountId".
レコードのコピー先のアカウントのID。これは「fromAccountId」とは異なる必要があります。
o ifInState: "String|null"
o ifInState： "文字列| null"
This is a state string as returned by the "Foo/get" method. If supplied, the string must match the current state of the account referenced by the accountId; otherwise, the method will be aborted and a "stateMismatch" error returned. If null, any changes will be applied to the current state.
これは、「Foo / get」メソッドによって返される状態文字列です。指定する場合、文字列は、accountIdによって参照されるアカウントの現在の状態と一致する必要があります。そうでない場合、メソッドは中止され、「stateMismatch」エラーが返されます。 nullの場合、変更は現在の状態に適用されます。
o create: "Id[Foo]"
o 作成：「Id [Foo]」
A map of the *creation id* to a Foo object. The Foo object MUST contain an "id" property, which is the id (in the fromAccount) of the record to be copied. When creating the copy, any other properties included are used instead of the current value for that property on the original.
* creation id *のFooオブジェクトへのマップ。 Fooオブジェクトには、コピーするレコードの（fromAccount内の）IDである「id」プロパティを含める必要があります。コピーを作成すると、元のプロパティの現在の値の代わりに、含まれている他のプロパティが使用されます。
o onSuccessDestroyOriginal: "Boolean" (default: false)
o onSuccessDestroyOriginal： "ブール値"（デフォルト：false）
If true, an attempt will be made to destroy the original records that were successfully copied: after emitting the "Foo/copy" response, but before processing the next method, the server MUST make a single call to "Foo/set" to destroy the original of each successfully copied record; the output of this is added to the responses as normal, to be returned to the client.
trueの場合、正常にコピーされた元のレコードを破棄する試みが行われます。「Foo / copy」応答を発行した後、次のメソッドを処理する前に、サーバーは「Foo / set」を1回呼び出して破棄する必要があります正常にコピーされた各レコードのオリジナル。この出力は通常どおり応答に追加され、クライアントに返されます。
o destroyFromIfInState: "String|null"
o destroyFromIfInState： "文字列| null"
This argument is passed on as the "ifInState" argument to the implicit "Foo/set" call, if made at the end of this request to destroy the originals that were successfully copied.
この引数は、このリクエストの最後にコピーが正常にコピーされたオリジナルを破棄する場合に、暗黙の「Foo / set」呼び出しの「ifInState」引数として渡されます。
Each record copy is considered an atomic unit that may succeed or fail individually.
各レコードコピーは、個別に成功または失敗する可能性があるアトミックユニットと見なされます。
The response has the following arguments:
応答には次の引数があります。
o fromAccountId: "Id"
o fromAccountId： "Id"
The id of the account records were copied from.
取引先レコードのIDがコピーされました。
o accountId: "Id"
o accountId： "Id"
The id of the account records were copied to.
取引先レコードのIDがコピーされました。
o oldState: "String|null"
o oldState： "文字列| null"
The state string that would have been returned by "Foo/get" on the account records that were copied to before making the requested changes, or null if the server doesn't know what the previous state string was.
リクエストされた変更を行う前にコピーされたアカウントレコードで「Foo / get」によって返されるはずの状態文字列。サーバーが前の状態文字列が何であるかをサーバーが知らない場合はnull。
o newState: "String"
o newState： "文字列"
The state string that will now be returned by "Foo/get" on the account records were copied to.
アカウントレコードの "Foo / get"によって返される状態文字列がコピーされました。
o created: "Id[Foo]|null"
o 作成：「Id [Foo] | null」
A map of the creation id to an object containing any properties of the copied Foo object that are set by the server (such as the "id" in most object types; note, the id is likely to be different to the id of the object in the account it was copied from).
サーバーによって設定された、コピーされたFooオブジェクトのプロパティを含むオブジェクトへの作成IDのマップ（ほとんどのオブジェクトタイプの「ID」など）。IDはオブジェクトのIDとは異なる可能性が高いことに注意してくださいコピー元のアカウント）。
This argument is null if no Foo objects were successfully copied.
Fooオブジェクトが正常にコピーされなかった場合、この引数はnullです。
o notCreated: "Id[SetError]|null"
o notCreated： "Id [SetError] | null"
A map of the creation id to a SetError object for each record that failed to be copied, or null if none.
コピーに失敗した各レコードのSetErrorオブジェクトへの作成IDのマップ。コピーがない場合はnull。
The SetError may be any of the standard set errors returned for a create or update. In addition, the following SetError is defined:
SetErrorは、作成または更新で返される標準のセットエラーのいずれかです。さらに、次のSetErrorが定義されています。
"alreadyExists": The server forbids duplicates, and the record already exists in the target account. An "existingId" property of type "Id" MUST be included on the SetError object with the id of the existing record.
「alreadyExists」：サーバーは重複を禁止し、レコードはターゲットアカウントにすでに存在します。タイプ「Id」の「existingId」プロパティは、既存のレコードのIDを持つSetErrorオブジェクトに含める必要があります。
The following additional errors may be returned instead of the "Foo/ copy" response:
「Foo /コピー」応答の代わりに、次の追加エラーが返される場合があります。
"fromAccountNotFound": The "fromAccountId" does not correspond to a valid account.
「fromAccountNotFound」：「fromAccountId」は有効なアカウントに対応していません。
"fromAccountNotSupportedByMethod": The "fromAccountId" given corresponds to a valid account, but the account does not support this data type.
"fromAccountNotSupportedByMethod"：指定された "fromAccountId"は有効なアカウントに対応していますが、アカウントはこのデータ型をサポートしていません。
"stateMismatch": An "ifInState" argument was supplied and it does not match the current state, or an "ifFromInState" argument was supplied and it does not match the current state in the from account.
"stateMismatch"： "ifInState"引数が指定され、現在の状態と一致しないか、 "ifFromInState"引数が指定され、fromアカウントの現在の状態と一致しません。
For data sets where the total amount of data is expected to be very small, clients can just fetch the complete set of data and then do any sorting/filtering locally. However, for large data sets (e.g., multi-gigabyte mailboxes), the client needs to be able to search/sort/window the data type on the server.
データの総量が非常に少ないと予想されるデータセットの場合、クライアントはデータの完全なセットをフェッチし、ローカルで並べ替え/フィルタリングを実行できます。ただし、大きなデータセット（たとえば、マルチギガバイトのメールボックス）の場合、クライアントはサーバー上でデータ型を検索、並べ替え、ウィンドウ処理できる必要があります。
A query on the set of Foos in an account is made by calling "Foo/ query". This takes a number of arguments to determine which records to include, how they should be sorted, and which part of the result should be returned (the full list may be *very* long). The result is returned as a list of Foo ids.
アカウント内のFoosのセットに対するクエリは、「Foo / query」を呼び出すことによって行われます。これはいくつかの引数を取り、どのレコードを含めるか、それらをどのようにソートするか、結果のどの部分を返すかを決定します（完全なリストは*非常に*長い場合があります）。結果はFoo idのリストとして返されます。
A call to "Foo/query" takes the following arguments:
「Foo / query」の呼び出しは、次の引数を取ります。
o accountId: "Id"
o accountId： "Id"
The id of the account to use.
使用するアカウントのID。
o filter: "FilterOperator|FilterCondition|null"
o フィルター： "FilterOperator | FilterCondition | null"
Determines the set of Foos returned in the results. If null, all objects in the account of this type are included in the results. A *FilterOperator* object has the following properties:
結果で返されるFoodのセットを決定します。 nullの場合、このタイプのアカウントのすべてのオブジェクトが結果に含まれます。 * FilterOperator *オブジェクトには次のプロパティがあります。
* operator: "String"
* 演算子：「文字列」
This MUST be one of the following strings:
これは次の文字列のいずれかである必要があります。
+ "AND": All of the conditions must match for the filter to match.
+ 「AND」：フィルターが一致するには、すべての条件が一致する必要があります。
+ "OR": At least one of the conditions must match for the filter to match.
+ 「OR」：フィルターが一致するには、少なくとも1つの条件が一致する必要があります。
+ "NOT": None of the conditions must match for the filter to match.
+ 「NOT」：フィルターが一致するためには、どの条件も一致する必要はありません。
* conditions: "(FilterOperator|FilterCondition)[]"
* 条件：「（FilterOperator | FilterCondition）[]」
The conditions to evaluate against each record.
各レコードに対して評価する条件。
A *FilterCondition* is an "object" whose allowed properties and semantics depend on the data type and is defined in the /query method specification for that type. It MUST NOT have an "operator" property.
* FilterCondition *は「オブジェクト」であり、許可されるプロパティとセマンティクスはデータ型に依存し、その型の/ queryメソッド仕様で定義されています。 「演算子」プロパティがあってはなりません。
o sort: "Comparator[]|null"
o 並べ替え：「コンパレータ[] | null」
Lists the names of properties to compare between two Foo records, and how to compare them, to determine which comes first in the sort. If two Foo records have an identical value for the first comparator, the next comparator will be considered, and so on. If all comparators are the same (this includes the case where an empty array or null is given as the "sort" argument), the sort order is server dependent, but it MUST be stable between calls to "Foo/query". A *Comparator* has the following properties:
2つのFooレコードを比較するプロパティの名前と、それらを比較して、ソートで最初に来るレコードを判別する方法を一覧表示します。 2つのFooレコードの最初のコンパレータの値が同じである場合、次のコンパレータが考慮されます。すべてのコンパレーターが同じである場合（これには、空の配列またはnullが「sort」引数として指定されている場合が含まれます）、ソート順はサーバーに依存しますが、「Foo / query」の呼び出し間で安定している必要があります。 *コンパレータ*には以下のプロパティがあります：
* property: "String"
* プロパティ：「文字列」
The name of the property on the Foo objects to compare.
比較するFooオブジェクトのプロパティの名前。
* isAscending: "Boolean" (optional; default: true)
* isAscending： "ブール値"（オプション、デフォルト：true）
If true, sort in ascending order. If false, reverse the comparator's results to sort in descending order.
trueの場合、昇順で並べ替えます。 falseの場合、コンパレータの結果を逆にして降順で並べ替えます。
* collation: "String" (optional; default is server-dependent)
* 照合： "文字列"（オプション、デフォルトはサーバーに依存）
The identifier, as registered in the collation registry defined in [RFC4790], for the algorithm to use when comparing the order of strings. The algorithms the server supports are advertised in the capabilities object returned with the Session object (see Section 2).
[RFC4790]で定義されている照合レジストリに登録されている、文字列の順序を比較するときにアルゴリズムが使用する識別子。サーバーがサポートするアルゴリズムは、Sessionオブジェクトで返される機能オブジェクトで宣伝されます（セクション2を参照）。
If omitted, the default algorithm is server dependent, but:
省略した場合、デフォルトのアルゴリズムはサーバーに依存しますが、次のようになります。
1. It MUST be unicode-aware.
1. ユニコードに対応している必要があります。
2. It MAY be selected based on an Accept-Language header in the request (as defined in [RFC7231], Section 5.3.5) or out-of-band information about the user's language/locale.
2. リクエストのAccept-Languageヘッダー（[RFC7231]、セクション5.3.5で定義）またはユーザーの言語/ロケールに関する帯域外情報に基づいて選択される場合があります。
3. It SHOULD be case insensitive where such a concept makes sense for a language/locale. Where the user's language is unknown, it is RECOMMENDED to follow the advice in Section 5.2.3 of [RFC8264].
3. そのような概念が言語/ロケールにとって意味がある場合は、大文字と小文字を区別しないでください。ユーザーの言語が不明な場合は、[RFC8264]のセクション5.2.3のアドバイスに従うことをお勧めします。
The "i;unicode-casemap" collation [RFC5051] and the Unicode Collation Algorithm (<http://www.unicode.org/reports/tr10/>) are two examples that fulfil these criterion and provide reasonable behaviour for a large number of languages.
「i; unicode-casemap」照合[RFC5051]とUnicode照合アルゴリズム（<http://www.unicode.org/reports/tr10/>）は、これらの基準を満たし、多数の場合に適切な動作を提供する2つの例です言語の。
When the property being compared is not a string, the "collation" property is ignored, and the following comparison rules apply based on the type. In ascending order:
比較されるプロパティが文字列でない場合、「照合」プロパティは無視され、タイプに基づいて次の比較ルールが適用されます。昇順：
+ "Boolean": false comes before true.
+ 「ブール」：falseはtrueの前に来ます。
+ "Number": A lower number comes before a higher number.
+ 「数」：小さい数が大きい数の前に来ます。
+ "Date"/"UTCDate": The earlier date comes first.
+ 「日付」/「UTCDate」：早いほうの日付が最初になります。
The Comparator object may also have additional properties as required for specific sort operations defined in a type's /query method.
Comparatorオブジェクトには、型の/ queryメソッドで定義された特定の並べ替え操作に必要な追加のプロパティも含まれる場合があります。
o position: "Int" (default: 0)
o 位置： "Int"（デフォルト：0）
The zero-based index of the first id in the full list of results to return.
返される結果の完全なリストの最初のIDのゼロから始まるインデックス。
If a negative value is given, it is an offset from the end of the list. Specifically, the negative value MUST be added to the total number of results given the filter, and if still negative, it's clamped to "0". This is now the zero-based index of the first id to return.
負の値を指定すると、リストの最後からのオフセットになります。具体的には、フィルターに指定された結果の総数に負の値を追加する必要があります。それでも負の場合は、「0」にクランプされます。これは、返される最初のIDのゼロから始まるインデックスです。
If the index is greater than or equal to the total number of objects in the results list, then the "ids" array in the response will be empty, but this is not an error.
インデックスが結果リストのオブジェクトの総数以上である場合、応答の「ids」配列は空になりますが、これはエラーではありません。
o anchor: "Id|null"
o アンカー：「Id | null」
A Foo id. If supplied, the "position" argument is ignored. The index of this id in the results will be used in combination with the "anchorOffset" argument to determine the index of the first result to return (see below for more details).
Foo id。指定された場合、「position」引数は無視されます。結果内のこのIDのインデックスは、「anchorOffset」引数と組み合わせて使用され、返される最初の結果のインデックスを決定します（詳細については、以下を参照してください）。
o anchorOffset: "Int" (default: 0)
o anchorOffset： "Int"（デフォルト：0）
The index of the first result to return relative to the index of the anchor, if an anchor is given. This MAY be negative. For example, "-1" means the Foo immediately preceding the anchor is the first result in the list returned (see below for more details).
アンカーが指定されている場合に、アンカーのインデックスを基準にして返す最初の結果のインデックス。これはマイナスになるかもしれません。たとえば、「-1」は、アンカーの直前のFooが、返されるリストの最初の結果であることを意味します（詳細については、以下を参照してください）。
o limit: "UnsignedInt|null"
o 制限： "UnsignedInt | null"
The maximum number of results to return. If null, no limit presumed. The server MAY choose to enforce a maximum "limit" argument. In this case, if a greater value is given (or if it is null), the limit is clamped to the maximum; the new limit is returned with the response so the client is aware. If a negative value is given, the call MUST be rejected with an "invalidArguments" error.
返す結果の最大数。 nullの場合、推定される制限はありません。サーバーは最大の「制限」引数を強制することを選択できます。この場合、より大きな値が指定された場合（またはnullの場合）、制限は最大にクランプされます。新しい制限が応答で返されるため、クライアントはそれを認識します。負の値が指定された場合、呼び出しは「invalidArguments」エラーで拒否される必要があります。
o calculateTotal: "Boolean" (default: false)
o calculateTotal： "Boolean"（デフォルト：false）
Does the client wish to know the total number of results in the query? This may be slow and expensive for servers to calculate, particularly with complex filters, so clients should take care to only request the total when needed.
クライアントはクエリの結果の総数を知りたいですか？これは、サーバーが計算するのに時間がかかり、特に複雑なフィルターを使用すると高価になる可能性があるため、クライアントは必要なときにのみ合計を要求するように注意する必要があります。
If an "anchor" argument is given, the anchor is looked for in the results after filtering and sorting. If found, the "anchorOffset" is then added to its index. If the resulting index is now negative, it is clamped to 0. This index is now used exactly as though it were supplied as the "position" argument. If the anchor is not found, the call is rejected with an "anchorNotFound" error.
"anchor"引数が指定されている場合、フィルター処理と並べ替えの結果、アンカーが検索されます。見つかった場合は、「anchorOffset」がそのインデックスに追加されます。結果のインデックスが負の値になると、0にクランプされます。このインデックスは、 "position"引数として指定された場合とまったく同じように使用されます。アンカーが見つからない場合、呼び出しは "anchorNotFound"エラーで拒否されます。
If an "anchor" is specified, any position argument supplied by the client MUST be ignored. If no "anchor" is supplied, any "anchorOffset" argument MUST be ignored.
「アンカー」が指定されている場合、クライアントから提供された位置引数はすべて無視する必要があります。 "anchor"が指定されていない場合、 "anchorOffset"引数は無視する必要があります。
A client can use "anchor" instead of "position" to find the index of an id within a large set of results.
クライアントは、「位置」の代わりに「アンカー」を使用して、大量の結果セット内のIDのインデックスを見つけることができます。
The response has the following arguments:
応答には次の引数があります。
o accountId: "Id"
o accountId： "Id"
The id of the account used for the call.
呼び出しに使用されたアカウントのID。
o queryState: "String"
o queryState： "文字列"
A string encoding the current state of the query on the server. This string MUST change if the results of the query (i.e., the matching ids and their sort order) have changed. The queryState string MAY change if something has changed on the server, which means the results may have changed but the server doesn't know for sure.
サーバー上のクエリの現在の状態をエンコードする文字列。クエリの結果（つまり、一致するIDとそのソート順）が変更された場合、この文字列を変更する必要があります。サーバーで何かが変更された場合、queryState文字列が変更される可能性があります。つまり、結果は変更された可能性がありますが、サーバーは確実に認識しません。
The queryState string only represents the ordered list of ids that match the particular query (including its sort/filter). There is no requirement for it to change if a property on an object matching the query changes but the query results are unaffected (indeed, it is more efficient if the queryState string does not change in this case). The queryState string only has meaning when compared to future responses to a query with the same type/sort/ filter or when used with /queryChanges to fetch changes.
queryState文字列は、特定のクエリ（ソート/フィルターを含む）に一致するIDの順序付きリストのみを表します。クエリに一致するオブジェクトのプロパティが変更された場合に変更する必要はありませんが、クエリ結果は影響を受けません（実際、この場合、queryState文字列が変更されない方が効率的です）。 queryState文字列は、同じtype / sort /フィルターを使用したクエリへの今後の応答と比較する場合、または/ queryChangesと一緒に使用して変更をフェッチする場合にのみ意味があります。
Should a client receive back a response with a different queryState string to a previous call, it MUST either throw away the currently cached query and fetch it again (note, this does not require fetching the records again, just the list of ids) or call "Foo/queryChanges" to get the difference.
クライアントが前の呼び出しとは異なるqueryState文字列を含む応答を受け取った場合、現在キャッシュされているクエリを破棄して再度フェッチする必要があります（注：これは、レコードを再度フェッチする必要はなく、IDのリストのみ）。 "Foo / queryChanges"で違いを取得します。
o canCalculateChanges: "Boolean"
o canCalculateChanges： "ブール値"
This is true if the server supports calling "Foo/queryChanges" with these "filter"/"sort" parameters. Note, this does not guarantee that the "Foo/queryChanges" call will succeed, as it may only be possible for a limited time afterwards due to server internal implementation details.
これは、サーバーがこれらの「フィルター」/「ソート」パラメーターを指定した「Foo / queryChanges」の呼び出しをサポートしている場合に当てはまります。サーバーの内部実装の詳細により、その後の限られた時間にのみ可能である可能性があるため、これは「Foo / queryChanges」呼び出しが成功することを保証するものではないことに注意してください。
o position: "UnsignedInt"
o 位置： "UnsignedInt"
The zero-based index of the first result in the "ids" array within the complete list of query results.
クエリ結果の完全なリスト内の「ids」配列の最初の結果のゼロから始まるインデックス。
o ids: "Id[]"
o ids： "Id []"
The list of ids for each Foo in the query results, starting at the index given by the "position" argument of this response and continuing until it hits the end of the results or reaches the "limit" number of ids. If "position" is >= "total", this MUST be the empty list.
クエリ結果の各FooのIDのリスト。この応答の「position」引数で指定されたインデックスから始まり、結果の最後に到達するか、IDの「制限」数に達するまで続きます。 "position"が> = "total"の場合、これは空のリストでなければなりません。
o total: "UnsignedInt" (only if requested)
o 合計： "UnsignedInt"（リクエストされた場合のみ）
The total number of Foos in the results (given the "filter"). This argument MUST be omitted if the "calculateTotal" request argument is not true.
結果内の食品の総数（「フィルター」が与えられた場合）。 「計算された合計」リクエスト引数が真でない場合、この引数は省略されなければなりません。
o limit: "UnsignedInt" (if set by the server)
o 制限： "UnsignedInt"（サーバーによって設定されている場合）
The limit enforced by the server on the maximum number of results to return. This is only returned if the server set a limit or used a different limit than that given in the request.
返される結果の最大数にサーバーが適用する制限。これは、サーバーが制限を設定した場合、またはリクエストで指定された制限とは異なる制限を使用した場合にのみ返されます。
The following additional errors may be returned instead of the "Foo/ query" response:
「Foo /クエリ」応答の代わりに、次の追加エラーが返される場合があります。
"anchorNotFound": An anchor argument was supplied, but it cannot be found in the results of the query.
"anchorNotFound"：アンカー引数が指定されましたが、クエリの結果で見つかりません。
"unsupportedSort": The "sort" is syntactically valid, but it includes a property the server does not support sorting on or a collation method it does not recognise.
"unsupportedSort"： "sort"は構文的には有効ですが、サーバーがソートをサポートしていないプロパティ、またはサーバーが認識しない照合方法が含まれています。
"unsupportedFilter": The "filter" is syntactically valid, but the server cannot process it. If the filter was the result of a user's search input, the client SHOULD suggest that the user simplify their search.
"unsupportedFilter"： "filter"は構文的には有効ですが、サーバーはそれを処理できません。フィルターがユーザーの検索入力の結果である場合、クライアントはユーザーが検索を簡略化することを提案する必要があります。
The "Foo/queryChanges" method allows a client to efficiently update the state of a cached query to match the new state on the server. It takes the following arguments:
「Foo / queryChanges」メソッドを使用すると、クライアントはキャッシュされたクエリの状態を効率的に更新して、サーバーの新しい状態と一致させることができます。次の引数を取ります。
o accountId: "Id"
o accountId： "Id"
The id of the account to use.
使用するアカウントのID。
o filter: "FilterOperator|FilterCondition|null"
o フィルター： "FilterOperator | FilterCondition | null"
The filter argument that was used with "Foo/query".
「Foo / query」で使用されたフィルター引数。
o sort: "Comparator[]|null"
o 並べ替え：「コンパレータ[] | null」
The sort argument that was used with "Foo/query".
「Foo / query」で使用されたソート引数。
o sinceQueryState: "String"
o sinceQueryState： "文字列"
The current state of the query in the client. This is the string that was returned as the "queryState" argument in the "Foo/query" response with the same sort/filter. The server will return the changes made to the query since this state.
クライアントでのクエリの現在の状態。これは、同じ並べ替え/フィルターで「Foo / query」応答の「queryState」引数として返された文字列です。サーバーは、この状態以降にクエリに加えられた変更を返します。
o maxChanges: "UnsignedInt|null"
o maxChanges： "UnsignedInt | null"
The maximum number of changes to return in the response. See error descriptions below for more details.
応答で返す変更の最大数。詳細については、以下のエラーの説明を参照してください。
o upToId: "Id|null"
o upToId： "Id | null"
The last (highest-index) id the client currently has cached from the query results. When there are a large number of results, in a common case, the client may have only downloaded and cached a small subset from the beginning of the results. If the sort and filter are both only on immutable properties, this allows the server to omit changes after this point in the results, which can significantly increase efficiency. If they are not immutable, this argument is ignored.
クライアントがクエリ結果から現在キャッシュしている最後の（最高インデックス）ID。結果が多数ある場合、一般的なケースでは、クライアントは結果の最初から小さなサブセットのみをダウンロードしてキャッシュした可能性があります。並べ替えとフィルターの両方が不変のプロパティのみに基づいている場合、これにより、サーバーは結果のこの時点以降の変更を省略できるため、効率が大幅に向上します。それらが不変でない場合、この引数は無視されます。
o calculateTotal: "Boolean" (default: false)
o calculateTotal： "Boolean"（デフォルト：false）
Does the client wish to know the total number of results now in the query? This may be slow and expensive for servers to calculate, particularly with complex filters, so clients should take care to only request the total when needed.
クライアントはクエリの結果の総数を知りたいですか？これは、サーバーが計算するのに時間がかかり、特に複雑なフィルターを使用すると高価になる可能性があるため、クライアントは必要なときにのみ合計を要求するように注意する必要があります。
The response has the following arguments:
応答には次の引数があります。
o accountId: "Id"
o accountId： "Id"
The id of the account used for the call.
呼び出しに使用されたアカウントのID。
o oldQueryState: "String"
o oldQueryState： "文字列"
This is the "sinceQueryState" argument echoed back; that is, the state from which the server is returning changes.
これはエコーバックされる「sinceQueryState」引数です。つまり、サーバーが返す状態が変化します。
o newQueryState: "String"
o newQueryState： "文字列"
This is the state the query will be in after applying the set of changes to the old state.
これは、一連の変更を古い状態に適用した後のクエリの状態です。
o total: "UnsignedInt" (only if requested)
o 合計： "UnsignedInt"（リクエストされた場合のみ）
The total number of Foos in the results (given the "filter"). This argument MUST be omitted if the "calculateTotal" request argument is not true.
結果内の食品の総数（「フィルター」が与えられた場合）。 「計算された合計」リクエスト引数が真でない場合、この引数は省略されなければなりません。
o removed: "Id[]"
o 削除：「Id []」
The "id" for every Foo that was in the query results in the old state and that is not in the results in the new state.
クエリに含まれるすべてのFooの「id」は古い状態になり、新しい状態の結果には含まれません。
If the server cannot calculate this exactly, the server MAY return the ids of extra Foos in addition that may have been in the old results but are not in the new results.
サーバーがこれを正確に計算できない場合、サーバーは、古い結果に含まれていた可能性があるが、新しい結果には含まれていない追加のFoosのIDを返す場合があります。
If the sort and filter are both only on immutable properties and an "upToId" is supplied and exists in the results, any ids that were removed but have a higher index than "upToId" SHOULD be omitted.
並べ替えとフィルタの両方が不変プロパティのみであり、 "upToId"が指定され、結果に存在する場合、削除されたが "upToId"より高いインデックスを持つIDは省略してください。
If the "filter" or "sort" includes a mutable property, the server MUST include all Foos in the current results for which this property may have changed. The position of these may have moved in the results, so they must be reinserted by the client to ensure its query cache is correct.
「filter」または「sort」に変更可能なプロパティが含まれている場合、サーバーは、このプロパティが変更された可能性がある現在の結果にすべてのFoosを含める必要があります。これらの位置は結果内で移動している可能性があるため、クエリキャッシュが正しいことを確認するには、クライアントがこれらを再挿入する必要があります。
o added: "AddedItem[]"
o 追加：「AddedItem []」
The id and index in the query results (in the new state) for every Foo that has been added to the results since the old state AND every Foo in the current results that was included in the "removed" array (due to a filter or sort based upon a mutable property).
古い状態以降の結果に追加されたすべてのFooのクエリ結果（新しい状態）のIDとインデックス、および「削除された」配列に含まれていた現在の結果のすべてのFoo（フィルターまたは変更可能なプロパティに基づいてソートします）。
If the sort and filter are both only on immutable properties and an "upToId" is supplied and exists in the results, any ids that were added but have a higher index than "upToId" SHOULD be omitted.
並べ替えとフィルタの両方が不変プロパティのみであり、 "upToId"が指定され、結果に存在する場合、追加されたが "upToId"より高いインデックスを持つIDは省略してください。
The array MUST be sorted in order of index, with the lowest index first.
配列は、インデックスの順序でソートする必要があります。最小のインデックスが最初になります。
An *AddedItem* object has the following properties:
* AddedItem *オブジェクトには次のプロパティがあります。
* id: "Id"
* やった"
* index: "UnsignedInt"
* インデックス： "UnsignedInt"
The result of this is that if the client has a cached sparse array of Foo ids corresponding to the results in the old state, then:
この結果は、クライアントに、古い状態の結果に対応するFoo IDのキャッシュされた疎配列がある場合、次のようになります。
fooIds = [ "id1", "id2", null, null, "id3", "id4", null, null, null ]
If it *splices out* all ids in the removed array that it has in its cached results, then:
キャッシュされた結果に含まれている、削除された配列のすべてのIDを*スプライスアウト*する場合：
removed = [ "id2", "id31", ... ];
fooIds => [ "id1", null, null, "id3", "id4", null, null, null ]
and *splices in* (one by one in order, starting with the lowest index) all of the ids in the added array:
追加された配列内のすべてのIDを*スプライス*（最小のインデックスから順番に1つずつ）：
added = [{ id: "id5", index: 0, ... }];
fooIds => [ "id5", "id1", null, null, "id3", "id4", null, null, null ]
and *truncates* or *extends* to the new total length, then the results will now be in the new state.
そして、*全長*または*全長*を新しい全長にすると、結果は新しい状態になります。
Note: splicing in adds the item at the given index, incrementing the index of all items previously at that or a higher index. Splicing out is the inverse, removing the item and decrementing the index of every item after it in the array.
注：スプライスインは、指定されたインデックスにアイテムを追加し、そのインデックスまたはそれより高いインデックスにあるすべてのアイテムのインデックスを増分します。スプライスアウトはその逆であり、アイテムを削除し、配列内のそれ以降のすべてのアイテムのインデックスをデクリメントします。
The following additional errors may be returned instead of the "Foo/ queryChanges" response:
「Foo / queryChanges」応答の代わりに、次の追加エラーが返される場合があります。
"tooManyChanges": There are more changes than the client's "maxChanges" argument. Each item in the removed or added array is considered to be one change. The client may retry with higher max changes or invalidate its cache of the query results.
"tooManyChanges"：クライアントの "maxChanges"引数よりも多くの変更があります。削除または追加された配列の各項目は、1つの変更と見なされます。クライアントは、より高い最大変更で再試行するか、クエリ結果のキャッシュを無効にする場合があります。
"cannotCalculateChanges": The server cannot calculate the changes from the queryState string given by the client, usually due to the client's state being too old. The client MUST invalidate its cache of the query results.
「cannotCalculateChanges」：サーバーは、クライアントが指定したqueryState文字列からの変更を計算できません。通常、クライアントの状態が古すぎるためです。クライアントは、クエリ結果のキャッシュを無効にする必要があります。
Suppose we have a type *Todo* with the following properties:
次のプロパティを持つ* Todo *型があるとします。
o id: "Id" (immutable; server-set)
o id： "Id"（不変、サーバーセット）
The id of the object.
オブジェクトのID。
o title: "String"
o タイトル：「文字列」
A brief summary of what is to be done.
何をすべきかについての簡単な要約。
o keywords: "String[Boolean]" (default: {})
o キーワード： "String [Boolean]"（デフォルト：{}）
A set of keywords that apply to the Todo. The set is represented as an object, with the keys being the "keywords". The value for each key in the object MUST be true. (This format allows you to update an individual key using patch syntax rather than having to update the whole set of keywords as one, which a "String[]" representation would require.)
Todoに適用されるキーワードのセット。セットはオブジェクトとして表され、キーは「キーワード」です。オブジェクトの各キーの値はtrueでなければなりません。 （この形式では、「String []」表現が必要とするキーワードのセット全体を1つとして更新する必要がなく、パッチ構文を使用して個々のキーを更新できます。）
o neuralNetworkTimeEstimation: "Number" (server-set)
o neuroNetworkTimeEstimation： "Number"（サーバーセット）
The title and keywords are fed into the server's state-of-the-art neural network to get an estimation of how long this Todo will take, in seconds.
タイトルとキーワードは、サーバーの最先端のニューラルネットワークに送られ、このTodoにかかる時間を秒単位で推定します。
o subTodoIds: "Id[]|null"
o subTodoIds： "Id [] | null"
The ids of a list of other Todos to complete as part of this Todo.
このTodoの一部として完了する他のTodoのリストのID。
Suppose also that all the standard methods are defined for this type and the FilterCondition object supports a "hasKeyword" property to match Todos with the given keyword.
また、このタイプに対してすべての標準メソッドが定義されており、FilterConditionオブジェクトが「hasKeyword」プロパティをサポートして、Todoを指定されたキーワードと照合するとします。
A client might want to display the list of Todos with either a "music" keyword or a "video" keyword, so it makes the following method call:
クライアントは、「music」キーワードまたは「video」キーワードを使用してTodosのリストを表示したい場合があるため、次のメソッド呼び出しを行います。
[[ "Todo/query", {
"accountId": "x",
"filter": {
"operator": "OR",
"conditions": [
{ "hasKeyword": "music" },
{ "hasKeyword": "video" }
]
},
"sort": [{ "property": "title" }],
"position": 0,
"limit": 10
}, "0" ],
[ "Todo/get", {
"accountId": "x",
"#ids": {
"resultOf": "0",
"name": "Todo/query",
"path": "/ids"
}
}, "1" ]]
This would query the server for the set of Todos with a keyword of either "music" or "video", sorted by title, and limited to the first 10 results. It fetches the full object for each of these Todos using back-references to reference the result of the query. The response might look something like:
これは、「音楽」または「ビデオ」のいずれかのキーワードを使用してTodoのセットをサーバーに照会し、タイトルでソートされ、最初の10件の結果に限定されます。クエリの結果を参照する逆参照を使用して、これらの各Todoの完全なオブジェクトをフェッチします。応答は次のようになります。
[[ "Todo/query", {
"accountId": "x",
"queryState": "y13213",
"canCalculateChanges": true,
"position": 0,
"ids": [ "a", "b", "c", "d", "e", "f", "g", "h", "i", "j" ]
}, "0" ],
[ "Todo/get", {
"accountId": "x",
"state": "10324",
"list": [{
"id": "a",
"title": "Practise Piano",
"keywords": {
"music": true,
"beethoven": true,
"mozart": true,
"liszt": true,
"rachmaninov": true
},
"neuralNetworkTimeEstimation": 3600
}, {
"id": "b",
"title": "Watch Daft Punk music video",
"keywords": {
"music": true,
"video": true,
"trance": true
},
"neuralNetworkTimeEstimation": 18000
},
...
]
}, "1" ]]
Now, suppose the user adds a keyword "chopin" and removes the keyword "mozart" from the "Practise Piano" task. The client may send the whole object to the server, as this is a valid PatchObject:
ここで、ユーザーが「ショパン」というキーワードを追加し、「練習ピアノ」タスクから「mozart」というキーワードを削除したとします。これは有効なPatchObjectであるため、クライアントはオブジェクト全体をサーバーに送信できます。
[[ "Todo/set", {
"accountId": "x",
"ifInState": "10324",
"update": {
"a": {
"id": "a",
"title": "Practise Piano",
"keywords": {
"music": true,
"beethoven": true,
"chopin": true,
"liszt": true,
"rachmaninov": true
},
"neuralNetworkTimeEstimation": 360
}
}
}, "0" ]]
or it may send a minimal patch:
またはそれは最小限のパッチを送るかもしれません：
[[ "Todo/set", {
"accountId": "x",
"ifInState": "10324",
"update": {
"a": {
"keywords/chopin": true,
"keywords/mozart": null
}
}
}, "0" ]]
The effect is exactly the same on the server in either case, and presuming the server is still in state "10324", it will probably return success:
どちらの場合でも、サーバーでの効果はまったく同じで、サーバーがまだ「10324」の状態であると想定すると、おそらく成功を返します。
[[ "Todo/set", {
"accountId": "x",
"oldState": "10324",
"newState": "10329",
"updated": {
"a": {
"neuralNetworkTimeEstimation": 5400
}
}
}, "0" ]]
The server changed the "neuralNetworkTimeEstimation" property on the object as part of this change; as this changed in a way *not* explicitly requested by the PatchObject sent to the server, it is returned with the "updated" confirmation.
サーバーは、この変更の一部としてオブジェクトの "neuralNetworkTimeEstimation"プロパティを変更しました。これは、サーバーに送信されたPatchObjectによって明示的に要求されない方法で変更されたため、「更新された」確認とともに返されます。
Let us now add a sub-Todo to our new "Practise Piano" Todo. In this example, we can see the use of a reference to a creation id to allow us to set a foreign key reference to a record created in the same request:
次に、新しい「練習用ピアノ」TodoにサブTodoを追加します。この例では、作成IDへの参照を使用して、同じリクエストで作成されたレコードに外部キー参照を設定できるようにしています。
[[ "Todo/set", {
"accountId": "x",
"create": {
"k15": {
"title": "Warm up with scales"
}
},
"update": {
"a": {
"subTodoIds": [ "#k15" ]
}
}
}, "0" ]]
Now, suppose another user deleted the "Listen to Daft Punk" Todo. The first user will receive a push notification (see Section 7) with the changed state string for the "Todo" type. Since the new string does not match its current state, it knows it needs to check for updates. It may make a request like:
ここで、別のユーザーが「Listen to Daft Punk」Todoを削除したとします。最初のユーザーは、 "Todo"タイプの状態文字列が変更されたプッシュ通知（セクション7を参照）を受け取ります。新しい文字列は現在の状態と一致しないため、更新を確認する必要があることがわかります。次のようなリクエストを行う場合があります。
[[ "Todo/changes", {
"accountId": "x",
"sinceState": "10324",
"maxChanges": 50
}, "0" ],
[ "Todo/queryChanges", {
"accountId": "x",
"filter": {
"operator": "OR",
"conditions": [
{ "hasKeyword": "music" },
{ "hasKeyword": "video" }
]
},
"sort": [{ "property": "title" }],
"sinceQueryState": "y13213",
"maxChanges": 50
}, "1" ]]
and receive in response:
それに応じて受け取ります：
[[ "Todo/changes", {
"accountId": "x",
"oldState": "10324",
"newState": "871903",
"hasMoreChanges": false,
"created": [],
"updated": [],
"destroyed": ["b"]
}, "0" ],
[ "Todo/queryChanges", {
"accountId": "x",
"oldQueryState": "y13213",
"newQueryState": "y13218",
"removed": ["b"],
"added": null
}, "1" ]]
Suppose the user has access to another account "y", for example, a team account shared between multiple users. To move an existing Todo from account "x", the client would call:
ユーザーが別のアカウント "y"、たとえば複数のユーザー間で共有されているチームアカウントにアクセスできるとします。既存のTodoをアカウント "x"から移動するには、クライアントは次を呼び出します。
[[ "Todo/copy", {
"fromAccountId": "x",
"accountId": "y",
"create": {
"k5122": {
"id": "a"
}
},
"onSuccessDestroyOriginal": true
}, "0" ]]
The server successfully copies the Todo to a new account (where it receives a new id) and deletes the original. Due to the implicit call to "Todo/set", there are two responses to the single method call, both with the same method call id:
サーバーは、Todoを新しいアカウント（新しいIDを受け取る場所）に正常にコピーし、元のアカウントを削除します。 "Todo / set"への暗黙の呼び出しにより、単一のメソッド呼び出しに対して2つの応答があり、どちらも同じメソッド呼び出しIDを持っています。
[[ "Todo/copy", {
"fromAccountId": "x",
"accountId": "y",
"created": {
"k5122": {
"id": "DAf97"
}
},
"oldState": "c1d64ecb038c",
"newState": "33844835152b"
}, "0" ],
[ "Todo/set", {
"accountId": "x",
"oldState": "871903",
"newState": "871909",
"destroyed": [ "a" ],
...
}, "0" ]]
JMAP has been designed to allow an API endpoint to easily proxy through to one or more JMAP servers. This may be useful for load balancing, augmenting capabilities, or presenting a single endpoint to accounts hosted on different JMAP servers (splitting the request based on each method's "accountId" argument). The proxy need only understand the general structure of a JMAP Request object; it does not need to know anything specifically about the methods and arguments it will pass through to other servers.
JMAPは、APIエンドポイントが1つ以上のJMAPサーバーに簡単にプロキシできるように設計されています。これは、負荷分散、拡張機能、または異なるJMAPサーバーでホストされているアカウントへの単一のエンドポイントの提示（各メソッドの「accountId」引数に基づいてリクエストを分割する）に役立つ場合があります。プロキシは、JMAPリクエストオブジェクトの一般的な構造を理解するだけで済みます。他のサーバーに渡されるメソッドと引数について特に知る必要はありません。
If splitting up the methods in a request to call them on different backend servers, the proxy must do two things to ensure back-references and creation-id references resolve the same as if the entire request were processed on a single server:
リクエスト内のメソッドを分割して異なるバックエンドサーバーで呼び出す場合、プロキシは2つのことを実行して、バックリファレンスとcreation-idリファレンスがリクエスト全体が単一のサーバーで処理された場合と同じように解決されるようにする必要があります。
1. It must pass a "createdIds" property with each subrequest. If this is not given by the client, an empty object should be used for the first subrequest. The "createdIds" property of each subresponse should be passed on in the next subrequest.
1. 各サブリクエストで「createdIds」プロパティを渡す必要があります。これがクライアントによって与えられない場合、空のオブジェクトが最初のサブリクエストに使用されるべきです。各サブレスポンスの「createdIds」プロパティは、次のサブリクエストで渡される必要があります。
2. It must resolve back-references to previous method results that were processed on a different server. This is a relatively simple syntactic substitution, described in Section 3.7.
2. 別のサーバーで処理された以前のメソッド結果への後方参照を解決する必要があります。これは、セクション3.7で説明する比較的単純な構文の置換です。
When splitting a request based on accountId, proxy implementors do need to be aware of "/copy" methods that copy between accounts. If the accounts are on different servers, the proxy will have to implement this functionality directly.
accountIdに基づいてリクエストを分割する場合、プロキシ実装者はアカウント間でコピーする「/ copy」メソッドを認識する必要があります。アカウントが異なるサーバーにある場合、プロキシはこの機能を直接実装する必要があります。
Binary data is referenced by a *blobId* in JMAP and uploaded/ downloaded separately to the core API. The blobId solely represents the raw bytes of data, not any associated metadata such as a file name or content type. Such metadata is stored alongside the blobId in the object referencing it. The data represented by a blobId is immutable.
バイナリデータはJMAPの* blobId *によって参照され、コアAPIに個別にアップロード/ダウンロードされます。 blobIdはデータの生のバイトのみを表し、ファイル名やコンテンツタイプなどの関連するメタデータは表しません。このようなメタデータは、それを参照するオブジェクトのblobIdと一緒に保存されます。 blobIdで表されるデータは不変です。
Any blobId that exists within an account may be used when creating/ updating another object in that account. For example, an Email type may have a blobId that represents the object in Internet Message Format [RFC5322]. A client could create a new Email object with an attachment and use this blobId, in effect attaching the old message to the new one. Similarly, it could attach any existing attachment of an old message without having to download and upload it again.
アカウント内に存在するblobIdは、そのアカウントで別のオブジェクトを作成/更新するときに使用できます。たとえば、電子メールタイプには、インターネットメッセージ形式[RFC5322]のオブジェクトを表すblobIdが含まれる場合があります。クライアントは、添付ファイル付きの新しい電子メールオブジェクトを作成し、このblobIdを使用して、実際には古いメッセージを新しいメッセージに添付できます。同様に、古いメッセージの既存の添付ファイルをダウンロードして再度アップロードしなくても添付できます。
When the client uses a blobId in a create/update, the server MAY assign a new blobId to refer to the same binary data within the new/ updated object. If it does so, it MUST return any properties that contain a changed blobId in the created/updated response, so the client gets the new ids.
クライアントが作成/更新でblobIdを使用する場合、サーバーは新しいblobIdを割り当てて、新しい/更新されたオブジェクト内の同じバイナリデータを参照する場合があります。そうする場合、クライアントは、作成/更新された応答で変更されたblobIdを含むすべてのプロパティを返さなければなりません。そのため、クライアントは新しいIDを取得します。
A blob that is not referenced by a JMAP object (e.g., as a message attachment) MAY be deleted by the server to free up resources. Uploads (see below) are initially unreferenced blobs. To ensure interoperability:
JMAPオブジェクト（メッセージの添付ファイルなど）によって参照されていないblobは、リソースを解放するためにサーバーによって削除される場合があります。アップロード（下記参照）は、最初は参照されていないblobです。相互運用性を確保するには：
o The server SHOULD use a separate quota for unreferenced blobs to the account's usual quota. In the case of shared accounts, this quota SHOULD be separate per user.
o サーバーは、アカウントの通常の割り当てに対して、参照されていないblobに対して個別の割り当てを使用する必要があります（SHOULD）。共有アカウントの場合、このクォータはユーザーごとに個別にする必要があります（SHOULD）。
o This quota SHOULD be at least the maximum total size that a single object can reference on this server. For example, if supporting JMAP Mail, this should be at least the maximum total attachments size for a message.
o この割り当ては、少なくとも、このサーバーで単一のオブジェクトが参照できる最大合計サイズである必要があります（SHOULD）。たとえば、JMAPメールをサポートする場合、これは少なくともメッセージの最大合計添付ファイルサイズである必要があります。
o When an upload would take the user over quota, the server MUST delete unreferenced blobs in date order, oldest first, until there is room for the new blob.
o アップロードによってユーザーが割り当て量を超える場合、サーバーは、新しいBLOBのスペースができるまで、参照されていないBLOBを日付順に古いものから削除する必要があります。
o Except where quota restrictions force early deletion, an unreferenced blob MUST NOT be deleted for at least 1 hour from the time of upload; if reuploaded, the same blobId MAY be returned, but this SHOULD reset the expiry time.
o 割り当て制限により早期の削除が強制される場合を除き、参照されていないBLOBは、アップロード時から少なくとも1時間は削除してはなりません。再アップロードした場合、同じblobIdが返される場合がありますが、これは有効期限をリセットする必要があります（SHOULD）。
o A blob MUST NOT be deleted during the method call that removed the last reference, so that a client can issue a create and a destroy that both reference the blob within the same method call.
o 最後の参照を削除したメソッド呼び出し中にBLOBを削除してはなりません（MUST NOT）。これにより、クライアントは同じメソッド呼び出し内でBLOBを参照する作成と破棄を発行できます。
There is a single endpoint that handles all file uploads for an account, regardless of what they are to be used for. The Session object (see Section 2) has an "uploadUrl" property in URI Template (level 1) format [RFC6570], which MUST contain a variable called "accountId". The client may use this template in combination with an "accountId" to get the URL of the file upload resource.
使用目的に関係なく、アカウントのすべてのファイルのアップロードを処理する単一のエンドポイントがあります。 Sessionオブジェクト（セクション2を参照）には、URIテンプレート（レベル1）形式[RFC6570]の「uploadUrl」プロパティがあり、「accountId」という変数を含める必要があります。クライアントは、このテンプレートを「accountId」と組み合わせて使用して、ファイルアップロードリソースのURLを取得できます。
To upload a file, the client submits an authenticated POST request to the file upload resource.
ファイルをアップロードするには、クライアントは認証されたPOSTリクエストをファイルアップロードリソースに送信します。
A successful request MUST return a single JSON object with the following properties as the response:
リクエストが成功すると、レスポンスとして次のプロパティを持つ単一のJSONオブジェクトを返す必要があります。
o accountId: "Id"
o accountId： "Id"
The id of the account used for the call.
呼び出しに使用されたアカウントのID。
o blobId: "Id"
o blobId： "Id"
The id representing the binary data uploaded. The data for this id is immutable. The id *only* refers to the binary data, not any metadata.
アップロードされたバイナリデータを表すID。このIDのデータは不変です。 id * only *は、メタデータではなくバイナリデータを指します。
o type: "String"
o タイプ：「文字列」
The media type of the file (as specified in [RFC6838], Section 4.2) as set in the Content-Type header of the upload HTTP request.
アップロードHTTPリクエストのContent-Typeヘッダーで設定されたファイルのメディアタイプ（[RFC6838]、セクション4.2で指定）。
o size: "UnsignedInt"
o サイズ：「UnsignedInt」
The size of the file in octets.
オクテット単位のファイルのサイズ。
If identical binary content to an existing blob in the account is uploaded, the existing blobId MAY be returned.
アカウントの既存のblobと同じバイナリコンテンツがアップロードされた場合、既存のblobIdが返される場合があります。
Clients should use the blobId returned in a timely manner. Under rare circumstances, the server may have deleted the blob before the client uses it; the client should keep a reference to the local file so it can upload it again in such a situation.
クライアントは、タイムリーに返されたblobIdを使用する必要があります。まれな状況では、クライアントが使用する前にサーバーがblobを削除した可能性があります。クライアントはローカルファイルへの参照を保持する必要があるため、このような状況で再びアップロードできます。
When an HTTP error response is returned to the client, the server SHOULD return a JSON "problem details" object as the response body, as per [RFC7807].
HTTPエラー応答がクライアントに返されると、サーバーは[RFC7807]に従って、JSONの「問題の詳細」オブジェクトを応答本文として返す必要があります（SHOULD）。
As access controls are often determined by the object holding the reference to a blob, unreferenced blobs MUST only be accessible to the uploader, even in shared accounts.
多くの場合、アクセス制御はblobへの参照を保持するオブジェクトによって決定されるため、参照されていないblobは、共有アカウントであっても、アップローダーのみがアクセスできる必要があります。
The Session object (see Section 2) has a "downloadUrl" property, which is in URI Template (level 1) format [RFC6570]. The URL MUST contain variables called "accountId", "blobId", "type", and "name".
Sessionオブジェクト（セクション2を参照）には「downloadUrl」プロパティがあり、これはURIテンプレート（レベル1）形式[RFC6570]です。 URLには、「accountId」、「blobId」、「type」、および「name」という変数を含める必要があります。
To download a file, the client makes an authenticated GET request to the download URL with the appropriate variables substituted in:
ファイルをダウンロードするために、クライアントは適切な変数を次のように置き換えて、ダウンロードURLに認証済みのGETリクエストを送信します。
o "accountId": The id of the account to which the record with the blobId belongs.
o "accountId"：blobIdを持つレコードが属するアカウントのID。
o "blobId": The blobId representing the data of the file to download.
o "blobId"：ダウンロードするファイルのデータを表すblobId。
o "type": The type for the server to set in the "Content-Type" header of the response; the blobId only represents the binary data and does not have a content-type innately associated with it.
o "type"：応答の "Content-Type"ヘッダーに設定するサーバーのタイプ。 blobIdはバイナリデータのみを表し、コンテンツタイプが元々関連付けられていません。
o "name": The name for the file; the server MUST return this as the filename if it sets a "Content-Disposition" header.
o "name"：ファイルの名前。 「Content-Disposition」ヘッダーを設定する場合、サーバーはこれをファイル名として返す必要があります。
As the data for a particular blobId is immutable, and thus the response in the generated download URL is too, implementors are recommended to set long cache times and use the "immutable" Cache-Control extension [RFC8246] for successful responses, for example, "Cache-Control: private, immutable, max-age=31536000".
特定のblobIdのデータは不変であり、したがって生成されたダウンロードURLの応答も不変であるため、成功した応答のために、長いキャッシュ時間を設定し、「不変」のCache-Control拡張[RFC8246]を使用することをお勧めします。 「Cache-Control：private、immutable、max-age = 31536000」。
When an HTTP error response is returned to the client, the server SHOULD return a JSON "problem details" object as the response body, as per [RFC7807].
HTTPエラー応答がクライアントに返されると、サーバーは[RFC7807]に従って、JSONの「問題の詳細」オブジェクトを応答本文として返す必要があります（SHOULD）。
Binary data may be copied *between* two different accounts using the "Blob/copy" method rather than having to download and then reupload on the client.
バイナリデータは、クライアントでダウンロードしてから再アップロードするのではなく、「Blob / copy」メソッドを使用して2つの異なるアカウント間でコピーできます。
The "Blob/copy" method takes the following arguments:
「Blob / copy」メソッドは次の引数を取ります。
o fromAccountId: "Id"
o fromAccountId： "Id"
The id of the account to copy blobs from.
BLOBのコピー元のアカウントのID。
o accountId: "Id"
o accountId： "Id"
The id of the account to copy blobs to.
blobのコピー先のアカウントのID。
o blobIds: "Id[]"
o blobIds： "Id []"
A list of ids of blobs to copy to the other account.
他のアカウントにコピーするblobのIDのリスト。
The response has the following arguments:
応答には次の引数があります。
o fromAccountId: "Id"
o fromAccountId： "Id"
The id of the account blobs were copied from.
コピー元のアカウントBLOBのID。
o accountId: "Id"
o accountId： "Id"
The id of the account blobs were copied to.
アカウントblobのIDがコピーされました。
o copied: "Id[Id]|null"
o コピー：「Id [Id] | null」
A map of the blobId in the fromAccount to the id for the blob in the account it was copied to, or null if none were successfully copied.
fromAccountのblobIdの、コピー先のアカウントのblobのIDへのマップ。正常にコピーされなかった場合はnull。
o notCopied: "Id[SetError]|null"
o notCopied： "Id [SetError] | null"
A map of blobId to a SetError object for each blob that failed to be copied, or null if none.
コピーに失敗した各blobのSetErrorオブジェクトへのblobIdのマップ。コピーがない場合はnull。
The SetError may be any of the standard set errors that may be returned for a create, as defined in Section 5.3. In addition, the "notFound" SetError error may be returned if the blobId to be copied cannot be found.
SetErrorは、セクション5.3で定義されているように、作成時に返される可能性のある標準のセットエラーのいずれかです。さらに、コピーするblobIdが見つからない場合、「notFound」SetErrorエラーが返されることがあります。
The following additional method-level error may be returned instead of the "Blob/copy" response:
「Blob / copy」応答の代わりに、次の追加のメソッドレベルエラーが返される場合があります。
"fromAccountNotFound": The "fromAccountId" included with the request does not correspond to a valid account.
「fromAccountNotFound」：リクエストに含まれる「fromAccountId」が有効なアカウントに対応していません。
Push notifications allow clients to efficiently update (almost) instantly to stay in sync with data changes on the server. The general model for push is simple and sends minimal data over the push channel: just enough for the client to know whether it needs to resync. The format allows multiple changes to be coalesced into a single push update and the frequency of pushes to be rate limited by the server. It doesn't matter if some push events are dropped before they reach the client; the next time it gets/sets any records of a changed type, it will discover the data has changed and still sync all changes.
プッシュ通知により、クライアントは（ほぼ）瞬時に効率的に更新し、サーバー上のデータ変更と同期を保つことができます。プッシュの一般的なモデルはシンプルで、プッシュチャネルを介して最小限のデータを送信します。クライアントが再同期する必要があるかどうかを知るのに十分なだけです。この形式では、複数の変更を1つのプッシュ更新に統合し、プッシュの頻度をサーバーによってレート制限することができます。一部のプッシュイベントがクライアントに到達する前にドロップされてもかまいません。次に変更されたタイプのレコードを取得/設定すると、データが変更されたことが検出され、すべての変更が同期されます。
There are two different mechanisms by which a client can receive push notifications, to allow for the different environments in which a client may exist. An event source resource (see Section 7.3) allows clients that can hold transport connections open to receive push notifications directly from the JMAP server. This is simple and avoids third parties, but it is often not feasible on constrained platforms such as mobile devices. Alternatively, clients can make use of any push service supported by their environment. A URL for the push service is registered with the JMAP server (see Section 7.2); the server then POSTs each notification to that URL. The push service is then responsible for routing these to the client.
クライアントがプッシュ通知を受信できるメカニズムは2つあり、クライアントが存在するさまざまな環境に対応できます。イベントソースリソース（7.3を参照）により、トランスポート接続を開いたままにできるクライアントは、JMAPサーバーから直接プッシュ通知を受信できます。これは簡単で、サードパーティを回避しますが、モバイルデバイスなどの制約のあるプラットフォームでは実現できないことがよくあります。または、クライアントは、環境でサポートされている任意のプッシュサービスを利用できます。プッシュサービスのURLはJMAPサーバーに登録されています（セクション7.2を参照）。次に、サーバーは各通知をそのURLにPOSTします。プッシュサービスは、これらをクライアントにルーティングする役割を果たします。
When something changes on the server, the server pushes a StateChange object to the client. A *StateChange* object has the following properties:
サーバーで何かが変更されると、サーバーはStateChangeオブジェクトをクライアントにプッシュします。 * StateChange *オブジェクトには次のプロパティがあります。
o @type: "String"
o @type： "文字列"
This MUST be the string "StateChange".
これは文字列「StateChange」でなければなりません。
o changed: "Id[TypeState]"
o 変更：「Id [TypeState]」
A map of an "account id" to an object encoding the state of data types that have changed for that account since the last StateChange object was pushed, for each of the accounts to which the user has access and for which something has changed.
ユーザーがアクセス権を持ち、何かが変更されたアカウントごとに、最後のStateChangeオブジェクトがプッシュされてからそのアカウントで変更されたデータ型の状態をエンコードするオブジェクトへの「アカウントID」のマップ。
A *TypeState* object is a map. The keys are the type name "Foo" (e.g., "Mailbox" or "Email"), and the value is the "state" property that would currently be returned by a call to "Foo/get".
* TypeState *オブジェクトはマップです。キーはタイプ名「Foo」（「Mailbox」や「Email」など）で、値は「Foo / get」の呼び出しによって現在返される「state」プロパティです。
The client can compare the new state strings with its current values to see whether it has the current data for these types. If not, the changes can then be efficiently fetched in a single standard API request (using the /changes type methods).
クライアントは、新しい状態文字列を現在の値と比較して、これらのタイプの現在のデータがあるかどうかを確認できます。そうでない場合、変更は単一の標準APIリクエストで効率的にフェッチできます（/ changesタイプのメソッドを使用）。
In this example, the server has amalgamated a few changes together across two different accounts the user has access to, before pushing the following StateChange object to the client:
この例では、サーバーは、次のStateChangeオブジェクトをクライアントにプッシュする前に、ユーザーがアクセスできる2つの異なるアカウント間でいくつかの変更を統合しています。
{
"@type": "StateChange",
"changed": {
"a3123": {
"Email": "d35ecb040aab",
"EmailDelivery": "428d565f2440",
"CalendarEvent": "87accfac587a"
},
"a43461d": {
"Mailbox": "0af7a512ce70",
"CalendarEvent": "7a4297cecd76"
}
}
}
The client can compare the state strings with its current state for the Email, CalendarEvent, etc., object types in the appropriate accounts to see if it needs to fetch changes.
クライアントは、Email、CalendarEventなどのオブジェクトタイプの現在の状態と状態文字列を比較して、変更をフェッチする必要があるかどうかを確認できます。
If the client is itself making changes, it may receive a StateChange object while the /set API call is in flight. It can wait until the call completes and then compare if the new state string after the /set is the same as was pushed in the StateChange object; if so, and the old state of the /set response matches the client's previous state, it does not need to waste a request asking for changes it already knows.
クライアント自体が変更を行っている場合、/ set API呼び出しの実行中にStateChangeオブジェクトを受け取ることがあります。呼び出しが完了するまで待機してから、/ setの後の新しい状態文字列がStateChangeオブジェクトでプッシュされたものと同じかどうかを比較できます。そうであれば、/ set応答の古い状態がクライアントの以前の状態と一致していれば、すでに知っている変更を求める要求を無駄にする必要はありません。
Clients may create a PushSubscription to register a URL with the JMAP server. The JMAP server will then make an HTTP POST request to this URL for each push notification it wishes to send to the client.
クライアントはPushSubscriptionを作成して、JMAPサーバーにURLを登録できます。次に、JMAPサーバーは、クライアントに送信したいプッシュ通知ごとに、このURLにHTTP POSTリクエストを送信します。
As a push subscription causes the JMAP server to make a number of requests to a previously unknown endpoint, it can be used as a vector for launching a denial-of-service attack. To prevent this, when a subscription is created, the JMAP server immediately sends a PushVerification object to that URL (see Section 7.2.2). The JMAP server MUST NOT make any further requests to the URL until the client receives the push and updates the subscription with the correct verification code.
プッシュサブスクリプションにより、JMAPサーバーは以前は不明であったエンドポイントに多数のリクエストを送信するため、サービス拒否攻撃を開始するためのベクトルとして使用できます。これを防ぐために、サブスクリプションが作成されると、JMAPサーバーはすぐにPushVerificationオブジェクトをそのURLに送信します（セクション7.2.2を参照）。 JMAPサーバーは、クライアントがプッシュを受信してサブスクリプションを正しい検証コードで更新するまで、URLに対してそれ以上のリクエストを行わないでください。
A *PushSubscription* object has the following properties:
* PushSubscription *オブジェクトには次のプロパティがあります。
o id: "Id" (immutable; server-set)
o id： "Id"（不変、サーバーセット）
The id of the push subscription.
プッシュサブスクリプションのID。
o deviceClientId: "String" (immutable)
o deviceClientId： "String"（不変）
An id that uniquely identifies the client + device it is running on. The purpose of this is to allow clients to identify which PushSubscription objects they created even if they lose their local state, so they can revoke or update them. This string MUST be different on different devices and be different from apps from other vendors. It SHOULD be easy to regenerate and not depend on persisted state. It is RECOMMENDED to use a secure hash of a string that contains:
実行しているクライアント+デバイスを一意に識別するID。これの目的は、クライアントがローカル状態を失っても、作成したPushSubscriptionオブジェクトを識別できるようにすることです。これにより、クライアントはそれらを取り消したり更新したりできます。この文字列は、デバイスによって異なり、他のベンダーのアプリとは異なる必要があります。再生成が容易であり、永続化された状態に依存しない必要があります。以下を含む文字列の安全なハッシュを使用することをお勧めします。
1. A unique identifier associated with the device where the JMAP client is running, normally supplied by the device's operating system.
1. JMAPクライアントが実行されているデバイスに関連付けられた一意の識別子。通常、デバイスのオペレーティングシステムによって提供されます。
2. A custom vendor/app id, including a domain controlled by the vendor of the JMAP client.
2. JMAPクライアントのベンダーによって制御されるドメインを含む、カスタムベンダー/アプリID。
To protect the privacy of the user, the deviceClientId id MUST NOT contain an unobfuscated device id.
ユーザーのプライバシーを保護するために、deviceClientId IDには難読化されていないデバイスIDを含めてはなりません。
o url: "String" (immutable)
o url： "文字列"（不変）
An absolute URL where the JMAP server will POST the data for the push message. This MUST begin with "https://".
JMAPサーバーがプッシュメッセージのデータをPOSTする絶対URL。これは「https：//」で始まる必要があります。
o keys: "Object|null" (immutable)
o keys： "Object | null"（不変）
Client-generated encryption keys. If supplied, the server MUST use them as specified in [RFC8291] to encrypt all data sent to the push subscription. The object MUST have the following properties:
クライアントが生成した暗号化キー。提供される場合、サーバーは[RFC8291]で指定されているようにそれらを使用して、プッシュサブスクリプションに送信されるすべてのデータを暗号化する必要があります。オブジェクトには次のプロパティが必要です。
* p256dh: "String"
* p256dh：「文字列」
The P-256 Elliptic Curve Diffie-Hellman (ECDH) public key as described in [RFC8291], encoded in URL-safe base64 representation as defined in [RFC4648].
[RFC4648]で定義されているURLセーフなbase64表現でエンコードされた、[RFC8291]で説明されているP-256楕円曲線Diffie-Hellman（ECDH）公開鍵。
* auth: "String"
* auth： "文字列"
The authentication secret as described in [RFC8291], encoded in URL-safe base64 representation as defined in [RFC4648].
[RFC4648]で定義されているURLセーフのbase64表現でエンコードされた、[RFC8291]で説明されている認証シークレット。
o verificationCode: "String|null"
o validationCode： "文字列| null"
This MUST be null (or omitted) when the subscription is created. The JMAP server then generates a verification code and sends it in a push message, and the client updates the PushSubscription object with the code; see Section 7.2.2 for details.
これは、サブスクリプションの作成時にnull（または省略）にする必要があります。次に、JMAPサーバーは検証コードを生成してプッシュメッセージで送信し、クライアントはコードでPushSubscriptionオブジェクトを更新します。詳細については、セクション7.2.2を参照してください。
o expires: "UTCDate|null"
o 有効期限：「UTCDate | null」
The time this push subscription expires. If specified, the JMAP server MUST NOT make further requests to this resource after this time. It MAY automatically destroy the push subscription at or after this time.
このプッシュサブスクリプションの有効期限。指定されている場合、JMAPサーバーは、この時間以降、このリソースにそれ以上のリクエストを行わないでください。この時点以降、プッシュサブスクリプションは自動的に破棄される場合があります。
The server MAY choose to set an expiry if none is given by the client or modify the expiry time given by the client to a shorter duration.
サーバーは、クライアントによって何も指定されていない場合に有効期限を設定するか、クライアントによって指定された有効期限をより短い期間に変更することを選択できます。
o types: "String[]|null"
o タイプ：「String [] | null」
A list of types the client is interested in (using the same names as the keys in the TypeState object defined in the previous section). A StateChange notification will only be sent if the data for one of these types changes. Other types are omitted from the TypeState object. If null, changes will be pushed for all types.
クライアントが関心を持っているタイプのリスト（前のセクションで定義したTypeStateオブジェクトのキーと同じ名前を使用）。 StateChange通知は、これらのタイプのいずれかのデータが変更された場合にのみ送信されます。 TypeStateオブジェクトから他のタイプは省略されます。 nullの場合、すべてのタイプの変更がプッシュされます。
The POST request MUST have a content type of "application/json" and contain the UTF-8 JSON-encoded object as the body. The request MUST have a "TTL" header and MAY have "Urgency" and/or "Topic" headers, as specified in Section 5 of [RFC8030]. The JMAP server is expected to understand and handle HTTP status responses in a reasonable manner. A "429" (Too Many Requests) response MUST cause the JMAP server to reduce the frequency of pushes; the JMAP push structure allows multiple changes to be coalesced into a single minimal StateChange object. See the security considerations in Section 8.6 for a discussion of the risks in connecting to unknown servers.
POSTリクエストには、コンテンツタイプ「application / json」が含まれ、本文としてUTF-8 JSONエンコードオブジェクトが含まれている必要があります。 [RFC8030]のセクション5で指定されているように、リクエストには「TTL」ヘッダーが必要であり、「緊急」ヘッダーや「トピック」ヘッダー、あるいはその両方が含まれる場合があります。 JMAPサーバーは、合理的な方法でHTTPステータス応答を理解して処理することが期待されています。 "429"（Too Many Requests）応答は、JMAPサーバーがプッシュの頻度を減らすようにしなければなりません。 JMAPプッシュ構造により、複数の変更を単一の最小限のStateChangeオブジェクトに合体させることができます。不明なサーバーに接続する際のリスクについては、セクション8.6のセキュリティに関する考慮事項を参照してください。
The JMAP server acts as an application server as defined in [RFC8030]. A client MAY use the rest of [RFC8030] in combination with its own push service to form a complete end-to-end solution, or it MAY rely on alternative mechanisms to ensure the delivery of the pushed data after it leaves the JMAP server.
JMAPサーバーは、[RFC8030]で定義されているアプリケーションサーバーとして機能します。クライアントは、独自のプッシュサービスと組み合わせて[RFC8030]の残りの部分を使用して完全なエンドツーエンドソリューションを形成するか、JMAPサーバーを離れた後のプッシュデータの配信を保証するために代替メカニズムに依存してもよい（MAY）。
The push subscription is tied to the credentials used to authenticate the API request that created it. Should these credentials expire or be revoked, the push subscription MUST be destroyed by the JMAP server. Only subscriptions created by these credentials are returned when the client fetches existing subscriptions.
プッシュサブスクリプションは、それを作成したAPIリクエストの認証に使用される認証情報に関連付けられています。これらの資格情報が期限切れになるか取り消される場合、プッシュサブスクリプションはJMAPサーバーによって破棄される必要があります。クライアントが既存のサブスクリプションをフェッチすると、これらの資格情報によって作成されたサブスクリプションのみが返されます。
When these credentials have their own expiry (i.e., it is a session with a timeout), the server SHOULD NOT set or bound the expiry time for the push subscription given by the client but MUST expire it when the session expires.
これらの資格情報に独自の有効期限がある場合（つまり、タイムアウトのあるセッションである場合）、サーバーは、クライアントによって指定されたプッシュサブスクリプションの有効期限を設定またはバインドしてはいけません（SHOULD NOT）。
When these credentials are not time bounded (e.g., Basic authentication [RFC7617]), the server SHOULD set an expiry time for the push subscription if none is given and limit the expiry time if set too far in the future. This maximum expiry time MUST be at least 48 hours in the future and SHOULD be at least 7 days in the future. An app running on a mobile device may only be able to refresh the push subscription lifetime when it is in the foreground, so this gives a reasonable time frame to allow this to happen.
これらの資格情報に時間制限がない場合（たとえば、基本認証[RFC7617]）、サーバーは、何も指定されていない場合はプッシュサブスクリプションに有効期限を設定し、将来設定しすぎると有効期限を制限する必要があります（SHOULD）。この最大有効期限は、少なくとも48時間先である必要があり、少なくとも7日先である必要があります。モバイルデバイスで実行されているアプリは、プッシュサブスクリプションの有効期間をフォアグラウンドでしか更新できない場合があるため、これにより、これが発生するのに十分な時間枠が与えられます。
In the case of separate access and refresh credentials, as in Oauth 2.0 [RFC6749], the server SHOULD tie the push subscription to the validity of the refresh token rather than the access token and behave according to whether this is time-limited or not.
Oauth 2.0 [RFC6749]のように、別々のアクセスと更新の認証情報の場合、サーバーはプッシュサブスクリプションをアクセストークンではなく更新トークンの有効性に結び付け、これが時間制限があるかどうかに応じて動作する必要があります。
When a push subscription is destroyed, the server MUST securely erase the URL and encryption keys from memory and storage as soon as possible.
プッシュサブスクリプションが破棄されると、サーバーはメモリとストレージからURLと暗号化キーをできるだけ早く安全に消去する必要があります。
Standard /get method as described in Section 5.1, except it does *not* take or return an "accountId" argument, as push subscriptions are not tied to specific accounts. It also does *not* return a "state" argument. The "ids" argument may be null to fetch all at once.
プッシュサブスクリプションは特定のアカウントに関連付けられていないため、「accountId」引数を取得または返さないことを除いて、セクション5.1で説明されている標準の/ getメソッド。また、「状態」引数を返しません。 「ids」引数は、一度にすべてフェッチするためにnullにすることができます。
The server MUST only return push subscriptions that were created using the same authentication credentials as for this "PushSubscription/get" request.
サーバーは、この「PushSubscription / get」リクエストと同じ認証資格情報を使用して作成されたプッシュサブスクリプションのみを返す必要があります。
As the "url" and "keys" properties may contain data that is private to a particular device, the values for these properties MUST NOT be returned. If the "properties" argument is null or omitted, the server MUST default to all properties excluding these two. If one of them is explicitly requested, the method call MUST be rejected with a "forbidden" error.
「url」および「keys」プロパティには特定のデバイスにプライベートなデータが含まれている可能性があるため、これらのプロパティの値を返してはなりません。 「プロパティ」引数がnullまたは省略されている場合、サーバーはこれら2つを除くすべてのプロパティをデフォルトにする必要があります。それらの1つが明示的に要求された場合、メソッド呼び出しは「禁止」エラーで拒否される必要があります。
Standard /set method as described in Section 5.3, except it does *not* take or return an "accountId" argument, as push subscriptions are not tied to specific accounts. It also does *not* take an "ifInState" argument or return "oldState" or "newState" arguments.
プッシュサブスクリプションは特定のアカウントに関連付けられていないため、「accountId」引数を取得または返さないことを除いて、セクション5.3で説明されている標準の/ setメソッド。また、「ifInState」引数を取ったり、「oldState」引数や「newState」引数を返したりしません。
The "url" and "keys" properties are immutable; if the client wishes to change these, it must destroy the current push subscription and create a new one.
「url」および「keys」プロパティは不変です。クライアントがこれらを変更したい場合は、現在のプッシュサブスクリプションを破棄して、新しいサブスクリプションを作成する必要があります。
When a PushSubscription is created, the server MUST immediately push a *PushVerification* object to the URL. It has the following properties:
PushSubscriptionが作成されると、サーバーは* PushVerification *オブジェクトをすぐにURLにプッシュする必要があります。次のプロパティがあります。
o @type: "String"
o @type： "文字列"
This MUST be the string "PushVerification".
これは文字列「PushVerification」でなければなりません。
o pushSubscriptionId: "String"
o pushSubscriptionId： "文字列"
The id of the push subscription that was created.
作成されたプッシュサブスクリプションのID。
o verificationCode: "String"
o validationCode： "文字列"
The verification code to add to the push subscription. This MUST contain sufficient entropy to avoid the client being able to guess the code via brute force.
プッシュサブスクリプションに追加する検証コード。これは、クライアントがブルートフォースを介してコードを推測できないように、十分なエントロピーを含んでいる必要があります。
The client MUST update the push subscription with the correct verification code before the server makes any further requests to the subscription's URL. Attempts to update the subscription with an invalid verification code MUST be rejected by the server with an "invalidProperties" SetError.
クライアントは、サーバーがサブスクリプションのURLにさらにリクエストを行う前に、正しいサブスクリプションコードでプッシュサブスクリプションを更新する必要があります。無効な検証コードでサブスクリプションを更新しようとする試みは、 "invalidProperties" SetErrorでサーバーによって拒否されなければなりません（MUST）。
The client may update the "expires" property to extend (or, less commonly, shorten) the lifetime of a push subscription. The server MAY modify the proposed new expiry time to enforce server-defined limits. Extending the lifetime does not require the subscription to be verified again.
クライアントは「expires」プロパティを更新して、プッシュサブスクリプションの存続期間を延長（または一般的には短縮）できます。サーバーは、サーバー定義の制限を適用するために、提案された新しい有効期限を変更する場合があります。ライフタイムを延長するために、サブスクリプションを再度確認する必要はありません。
Clients SHOULD NOT update or destroy a push subscription that they did not create (i.e., has a "deviceClientId" that they do not recognise).
クライアントは、自分が作成しなかった（つまり、認識できない「deviceClientId」を持っている）プッシュサブスクリプションを更新または破棄しないでください。
At "2018-07-06T02:14:29Z", a client with deviceClientId "a889-ffea-910" fetches the set of push subscriptions currently on the server, making an API request with:
「2018-07-06T02：14：29Z」で、deviceClientIdが「a889-ffea-910」のクライアントは、現在サーバー上にあるプッシュサブスクリプションのセットをフェッチして、次のAPIリクエストを作成します。
[[ "PushSubscription/get", { "ids": null }, "0" ]]
[["PushSubscription / get"、{"ids"：null}、 "0"]]
Which returns:
どちらが戻ります：
[[ "PushSubscription/get", {
"list": [{
"id": "e50b2c1d-9553-41a3-b0a7-a7d26b599ee1",
"deviceClientId": "b37ff8001ca0",
"verificationCode": "b210ef734fe5f439c1ca386421359f7b",
"expires": "2018-07-31T00:13:21Z",
"types": [ "Todo" ]
}, {
"id": "f2d0aab5-e976-4e8b-ad4b-b380a5b987e4",
"deviceClientId": "X8980fc",
"verificationCode": "f3d4618a9ae15c8b7f5582533786d531",
"expires": "2018-07-12T05:55:00Z",
"types": [ "Mailbox", "Email", "EmailDelivery" ]
}],
"notFound": []
}, "0" ]]
Since neither of the returned push subscription objects have the client's deviceClientId, it knows it does not have a current push subscription active on the server. So it creates one, sending this request:
返されたプッシュサブスクリプションオブジェクトのどちらにもクライアントのdeviceClientIdがないため、サーバー上でアクティブな現在のプッシュサブスクリプションがないことがわかります。したがって、それを作成し、次のリクエストを送信します。
[[ "PushSubscription/set", {
"create": {
"4f29": {
"deviceClientId": "a889-ffea-910",
"url": "https://example.com/push/?device=X8980fc&client=12c6d086",
"types": null
}
}
}, "0" ]]
The server creates the push subscription but limits the expiry time to 7 days in the future, returning this response:
サーバーはプッシュサブスクリプションを作成しますが、有効期限を7日間に制限し、次の応答を返します。
[[ "PushSubscription/set", {
"created": {
"4f29": {
"id": "P43dcfa4-1dd4-41ef-9156-2c89b3b19c60",
"keys": null,
"expires": "2018-07-13T02:14:29Z"
}
}
}, "0" ]]
The server also immediately makes a POST request to "https://example.com/push/?device=X8980fc&client=12c6d086" with the data:
また、サーバーはすぐに次のデータを使用して「https://example.com/push/?device=X8980fc&client=12c6d086」にPOSTリクエストを送信します。
{
"@type": "PushVerification",
"pushSubscriptionId": "P43dcfa4-1dd4-41ef-9156-2c89b3b19c60",
"verificationCode": "da1f097b11ca17f06424e30bf02bfa67"
}
The client receives this and updates the subscription with the verification code (note there is a potential race condition here; the client MUST be able to handle receiving the push while the request creating the subscription is still in progress):
クライアントはこれを受信し、確認コードでサブスクリプションを更新します（ここで潜在的な競合状態があることに注意してください。サブスクリプションを作成する要求がまだ進行中の間、クライアントはプッシュの受信を処理できなければなりません）：
[[ "PushSubscription/set", {
"update": {
"P43dcfa4-1dd4-41ef-9156-2c89b3b19c60": {
"verificationCode": "da1f097b11ca17f06424e30bf02bfa67"
}
}
}, "0" ]]
The server confirms the update was successful and will now make requests to the registered URL when the state changes.
サーバーは更新が成功したことを確認し、状態が変化したときに登録されたURLにリクエストを送信します。
Two days later, the client updates the subscription to extend its lifetime, sending this request:
2日後、クライアントはサブスクリプションを更新して有効期間を延長し、次のリクエストを送信します。
[[ "PushSubscription/set", {
"update": {
"P43dcfa4-1dd4-41ef-9156-2c89b3b19c60": {
"expires": "2018-08-13T00:00:00Z"
}
}
}, "0" ]]
The server extends the expiry time, but only again to its maximum limit of 7 days in the future, returning this response:
サーバーは有効期限を延長しますが、今後も7日間の最大制限まで延長し、この応答を返します。
[[ "PushSubscription/set", {
"updated": {
"P43dcfa4-1dd4-41ef-9156-2c89b3b19c60": {
"expires": "2018-07-15T02:22:50Z"
}
}
}, "0" ]]
Clients that can hold transport connections open can connect directly to the JMAP server to receive push notifications via a "text/event-stream" resource, as described in [EventSource]. This is a long running HTTP request, where the server can push data to the client by appending data without ending the response.
[EventSource]で説明されているように、トランスポート接続を開いたままにできるクライアントは、JMAPサーバーに直接接続して、「text / event-stream」リソースを介してプッシュ通知を受信できます。これは長時間実行されるHTTPリクエストであり、サーバーは応答を終了せずにデータを追加することにより、クライアントにデータをプッシュできます。
When a change occurs in the data on the server, it pushes an event called "state" to any connected clients, with the StateChange object as the data.
サーバー上のデータに変更が発生すると、StateChangeオブジェクトをデータとして、接続されているクライアントに「状態」と呼ばれるイベントをプッシュします。
The server SHOULD also send a new event id that encodes the entire server state visible to the user immediately after sending a "state" event. When a new connection is made to the event-source endpoint, a client following the server-sent events specification will send a Last-Event-ID HTTP header field with the last id it saw, which the server can use to work out whether the client has missed some changes. If so, it SHOULD send these changes immediately on connection.
サーバーは、「状態」イベントを送信した直後にユーザーに表示されるサーバー状態全体をエンコードする新しいイベントIDを送信する必要があります（SHOULD）。イベントソースエンドポイントへの新しい接続が確立されると、サーバー送信イベント仕様に従うクライアントは、Last-Event-ID HTTPヘッダーフィールドを最後に確認したIDとともに送信します。サーバーはこれを使用して、クライアントはいくつかの変更を見逃しています。その場合、接続時にこれらの変更をすぐに送信する必要があります。
The Session object (see Section 2) has an "eventSourceUrl" property, which is in URI Template (level 1) format [RFC6570]. The URL MUST contain variables called "types", "closeafter", and "ping".
Sessionオブジェクト（セクション2を参照）には「eventSourceUrl」プロパティがあり、これはURIテンプレート（レベル1）形式[RFC6570]です。 URLには、「types」、「closeafter」、「ping」と呼ばれる変数を含める必要があります。
To connect to the resource, the client makes an authenticated GET request to the event-source URL with the appropriate variables substituted in:
リソースに接続するために、クライアントは、適切な変数を次のように置き換えて、イベントソースURLへの認証済みGETリクエストを作成します。
o "types": This MUST be either:
o 「タイプ」：これは次のいずれかである必要があります。
* A comma-separated list of type names, e.g., "Email,CalendarEvent". The server MUST only push changes for the types in this list.
* タイプ名のコンマ区切りリスト（例： "Email、CalendarEvent"）。サーバーは、このリストのタイプの変更のみをプッシュする必要があります。
* The single character: "*". Changes to all types are pushed.
* 単一文字：「*」。すべてのタイプへの変更がプッシュされます。
o "closeafter": This MUST be one of the following values:
o "closeafter"：これは次のいずれかの値でなければなりません：
* "state": The server MUST end the HTTP response after pushing a state event. This can be used by clients in environments where buffering proxies prevent the pushed data from arriving immediately, or indeed at all, when operating in the usual mode.
* 「状態」：サーバーは、状態イベントをプッシュした後、HTTP応答を終了する必要があります。これは、バッファリングプロキシが通常のモードで動作しているときに、プッシュされたデータがすぐに、またはまったく到着しないようにする環境でクライアントが使用できます。
* "no": The connection is persisted by the server as a standard event-source resource.
* "no"：接続は、サーバーによって標準のイベントソースリソースとして保持されます。
o "ping": A positive integer value representing a length of time in seconds, e.g., "300". If non-zero, the server MUST send an event called "ping" whenever this time elapses since the previous event was sent. This MUST NOT set a new event id. If the value is "0", the server MUST NOT send ping events.
o 「ping」：時間の長さを秒単位で表す正の整数値（「300」など）。ゼロ以外の場合、サーバーは、前のイベントが送信されてからこの時間が経過するたびに、「ping」と呼ばれるイベントを送信する必要があります。新しいイベントIDを設定してはなりません。値が「0」の場合、サーバーはpingイベントを送信してはなりません（MUST NOT）。
The server MAY modify a requested ping interval to be subject to a minimum and/or maximum value. For interoperability, servers MUST NOT have a minimum allowed value higher than 30 or a maximum allowed value less than 300.
サーバーは、最小値および/または最大値の対象となるように、要求されたping間隔を変更してもよい（MAY）。相互運用性のために、サーバーは30より大きい最小許容値または300より小さい最大許容値を持っていてはなりません。
The data for the ping event MUST be a JSON object containing an "interval" property, the value (type "UnsignedInt") being the interval in seconds the server is using to send pings (this may be different to the requested value if the server clamped it to be within a min/max value).
pingイベントのデータは、「間隔」プロパティを含むJSONオブジェクトである必要があります。値（「UnsignedInt」タイプ）は、サーバーがpingの送信に使用している秒単位の間隔です（サーバーが要求した値と異なる場合があります）最小値/最大値内に収まるようにクランプされます）。
Clients can monitor for the ping event to help determine when the closeafter mode may be required.
クライアントはpingイベントを監視して、closeafterモードがいつ必要になるかを判断するのに役立ちます。
A client MAY hold open multiple connections to the event-source resource, although it SHOULD try to use a single connection for efficiency.
クライアントは、イベントソースリソースへの複数の接続を開いたままにすることができます（MAY）が、効率のために単一の接続を使用する必要があります（SHOULD）。
To ensure the confidentiality and integrity of data sent and received via JMAP, all requests MUST use TLS 1.2 [RFC5246] [RFC8446] or later, following the recommendations in [RFC7525]. Servers SHOULD support TLS 1.3 [RFC8446] or later.
JMAPを介して送受信されるデータの機密性と整合性を確保するために、すべてのリクエストは[RFC7525]の推奨事項に従って、TLS 1.2 [RFC5246] [RFC8446]以降を使用する必要があります。サーバーはTLS 1.3 [RFC8446]以降をサポートする必要があります（SHOULD）。
Clients MUST validate TLS certificate chains to protect against man-in-the-middle attacks [RFC5280].
クライアントは、中間者攻撃[RFC5280]から保護するためにTLS証明書チェーンを検証する必要があります。
A number of HTTP authentication schemes have been standardised (see <https://www.iana.org/assignments/http-authschemes/>). Servers should take care to assess the security characteristics of different schemes in relation to their needs when deciding what to implement.
多くのHTTP認証方式が標準化されています（<https://www.iana.org/assignments/http-authschemes/>を参照）。サーバーは、何を実装するかを決定するとき、ニーズに関連してさまざまなスキームのセキュリティ特性を評価するように注意する必要があります。
Use of the Basic authentication scheme is NOT RECOMMENDED. Services that choose to use it are strongly recommended to require generation of a unique "app password" via some external mechanism for each client they wish to connect. This allows connections from different devices to be differentiated by the server and access to be individually revoked.
基本認証スキームの使用は推奨されません。これを使用することを選択したサービスでは、接続するクライアントごとに、外部メカニズムを介して一意の「アプリパスワード」の生成を要求することを強くお勧めします。これにより、さまざまなデバイスからの接続をサーバーで区別し、アクセスを個別に取り消すことができます。
Unless secured by something like DNSSEC, autodiscovery of server details using SRV DNS records is vulnerable to a DNS poisoning attack, which can lead to the client talking to an attacker's server instead of the real JMAP server. The attacker may then intercept requests to execute man-in-the-middle attacks and, depending on the authentication scheme, steal credentials to generate its own requests.
DNSSECなどで保護されていない限り、SRV DNSレコードを使用したサーバー詳細の自動検出はDNSポイズニング攻撃に対して脆弱であり、クライアントが実際のJMAPサーバーではなく攻撃者のサーバーと通信する可能性があります。次に、攻撃者は要求を傍受して中間者攻撃を実行し、認証スキームに応じて、資格情報を盗んで独自の要求を生成します。
Clients that do not support SRV lookups are likely to try just using the "/.well-known/jmap" path directly against the domain of the username over HTTPS. Servers SHOULD ensure this path resolves or redirects to the correct JMAP Session resource to allow this to work. If this is not feasible, servers MUST ensure this path cannot be controlled by an attacker, as again it may be used to steal credentials.
SRVルックアップをサポートしないクライアントは、 "/。well-known / jmap"パスをHTTPS経由でユーザー名のドメインに対して直接使用することを試みる可能性があります。サーバーは、このパスが正しく機能するように、このパスが正しいJMAPセッションリソースに解決またはリダイレクトするようにする必要があります（SHOULD）。これが実行できない場合、サーバーはこのパスが資格情報を盗むために使用される可能性があるため、攻撃者がこのパスを制御できないようにする必要があります。
The Security Considerations of [RFC8259] apply to the use of JSON as the data interchange format.
[RFC8259]のセキュリティに関する考慮事項は、データ交換形式としてのJSONの使用に適用されます。
As for any serialization format, parsers need to thoroughly check the syntax of the supplied data. JSON uses opening and closing tags for several types and structures, and it is possible that the end of the supplied data will be reached when scanning for a matching closing tag; this is an error condition, and implementations need to stop scanning at the end of the supplied data.
シリアル化形式については、パーサーは提供されたデータの構文を徹底的にチェックする必要があります。 JSONはいくつかのタイプと構造に開始タグと終了タグを使用します。一致する終了タグをスキャンするときに、提供されたデータの最後に到達する可能性があります。これはエラー状態であり、実装は提供されたデータの最後でスキャンを停止する必要があります。
JSON also uses a string encoding with some escape sequences to encode special characters within a string. Care is needed when processing these escape sequences to ensure that they are fully formed before the special processing is triggered, with special care taken when the escape sequences appear adjacent to other (non-escaped) special characters or adjacent to the end of data (as in the previous paragraph).
JSONは、いくつかのエスケープシーケンスで文字列エンコーディングを使用して、文字列内の特殊文字をエンコードします。これらのエスケープシーケンスを処理するときは、特別な処理がトリガーされる前に完全に形成されるように注意する必要があります。エスケープシーケンスが他の（エスケープされていない）特殊文字に隣接している場合、またはデータの終わりに隣接している場合（前の段落で）。
If parsing JSON into a non-textual structured data format, implementations may need to allocate storage to hold JSON string elements. Since JSON does not use explicit string lengths, the risk of denial of service due to resource exhaustion is small, but implementations may still wish to place limits on the size of allocations they are willing to make in any given context, to avoid untrusted data causing excessive memory allocation.
JSONを非テキスト構造化データ形式に解析する場合、実装はJSON文字列要素を保持するためにストレージを割り当てる必要がある場合があります。 JSONは明示的な文字列長を使用しないため、リソースの枯渇によるサービス拒否のリスクはわずかですが、信頼できないデータが原因となるのを防ぐために、実装では、特定のコンテキストで作成する割り当てのサイズに制限を設けることもできます。過剰なメモリ割り当て。
A small request may result in a very large response and require considerable work on the server if resource limits are not enforced. JMAP provides mechanisms for advertising and enforcing a wide variety of limits for mitigating this threat, including limits on the number of objects fetched in a single method call, number of methods in a single request, number of concurrent requests, etc.
リソースの制限が適用されていない場合、小さな要求では非常に大きな応答が発生し、サーバーでかなりの作業が必要になることがあります。 JMAPは、この脅威を緩和するためのさまざまな制限をアドバタイズおよび適用するメカニズムを提供します。これには、単一のメソッド呼び出しでフェッチされるオブジェクトの数、単一のリクエストのメソッドの数、同時リクエストの数などの制限が含まれます。
JMAP servers MUST implement sensible limits to mitigate against resource exhaustion attacks.
JMAPサーバーは、リソース枯渇攻撃を軽減するために、賢明な制限を実装する必要があります。
When a push subscription is registered, the application server will make POST requests to the given URL. There are a number of security considerations that MUST be considered when implementing this.
プッシュサブスクリプションが登録されると、アプリケーションサーバーは指定されたURLにPOSTリクエストを送信します。これを実装する際に考慮しなければならないセキュリティ上の考慮事項がいくつかあります。
The server MUST ensure the URL is externally resolvable to avoid server-side request forgery, where the server makes a request to a resource on its internal network.
サーバーは、サーバー側のリクエストフォージェリを回避するために、URLが外部的に解決可能であることを確認する必要があります。この場合、サーバーは内部ネットワーク上のリソースにリクエストを行います。
A malicious client may use the push subscription to attempt to flood a third party server with requests, creating a denial-of-service attack and masking the attacker's true identity. There is no guarantee that the URL given to the JMAP server is actually a valid push server. Upon creation of a push subscription, the JMAP server sends a PushVerification object to the URL and MUST NOT send any further requests until the client verifies it has received the initial push. The verification code MUST contain sufficient entropy to prevent the client from being able to verify the subscription via brute force.
悪意のあるクライアントは、プッシュサブスクリプションを使用してサードパーティのサーバーに要求をあふれさせ、サービス拒否攻撃を作成し、攻撃者の本当の身元を隠す可能性があります。 JMAPサーバーに指定されたURLが実際に有効なプッシュサーバーである保証はありません。プッシュサブスクリプションの作成時に、JMAPサーバーはPushVerificationオブジェクトをURLに送信し、クライアントが初期プッシュを受信したことを確認するまで、それ以上のリクエストを送信してはなりません（MUST NOT）。検証コードには、クライアントがブルートフォースを介してサブスクリプションを検証できないようにするのに十分なエントロピーが含まれている必要があります。
The verification code does not guarantee the URL is a valid push server, only that the client is able to access the data submitted to it. While the verification step significantly reduces the set of potential targets, there is still a risk that the server is unrelated to the client and being targeted for a denial-of-service attack.
検証コードは、URLが有効なプッシュサーバーであることを保証するものではなく、クライアントが送信されたデータにアクセスできることのみを保証します。検証手順により、潜在的なターゲットのセットが大幅に削減されますが、サーバーがクライアントと無関係であり、サービス拒否攻撃の対象となるリスクが依然としてあります。
The server MUST limit the number of push subscriptions any one user may have to ensure the user cannot cause the server to send a large number of push notifications at once, which could again be used as part of a denial-of-service attack. The rate of creation MUST also be limited to minimise the ability to abuse the verification request as an attack vector.
サーバーは、1人のユーザーがサーバーに一度に大量のプッシュ通知を送信させないようにするために、1人のユーザーがプッシュサブスクリプションの数を制限する必要があります。これは、サービス拒否攻撃の一部として再び使用される可能性があります。検証要求を攻撃ベクトルとして悪用する能力を最小限に抑えるために、作成速度も制限する必要があります。
When data changes, a small object is pushed with the new state strings for the types that have changed. While the data here is minimal, a passive man-in-the-middle attacker may be able to gain useful information. To ensure confidentiality and integrity, if the push is sent via a third party outside of the control of the client and JMAP server, the client MUST specify encryption keys when establishing the PushSubscription and ignore any push notification received that is not encrypted with those keys.
データが変更されると、小さなオブジェクトが、変更されたタイプの新しい状態文字列とともにプッシュされます。ここでのデータは最小限ですが、受動的な中間者攻撃者が有用な情報を入手できる可能性があります。機密性と整合性を確保するために、クライアントとJMAPサーバーの制御外のサードパーティを介してプッシュが送信される場合、クライアントはPushSubscriptionを確立するときに暗号化キーを指定し、それらのキーで暗号化されていない受信したプッシュ通知を無視する必要があります。
The privacy and security considerations of [RFC8030] and [RFC8291] also apply to the use of the PushSubscription mechanism.
[RFC8030]と[RFC8291]のプライバシーとセキュリティに関する考慮事項は、PushSubscriptionメカニズムの使用にも適用されます。
As there is no crypto algorithm agility in Web Push Encryption [RFC8291], a new specification will be needed to provide this if new algorithms are required in the future.
Web Push Encryption [RFC8291]には暗号アルゴリズムの俊敏性がないため、将来新しいアルゴリズムが必要になる場合、これを提供するには新しい仕様が必要になります。
While the data is encrypted, a passive observer with the ability to monitor network traffic may be able to glean information from the timing of API requests and push notifications. For example, suppose an email or calendar invitation is sent from User A (hosted on Server X) to User B (hosted on Server Y). If Server X hosts data for many users, a passive observer can see that the two servers connected but does not know who the data was for. However, if a push notification is immediately sent to User B and the attacker can observe this as well, they may reasonably conclude that someone on Server X is connecting to User B.
データは暗号化されていますが、ネットワークトラフィックを監視する能力を持つパッシブオブザーバーは、APIリクエストとプッシュ通知のタイミングから情報を収集できる場合があります。たとえば、電子メールまたはカレンダーの招待状がユーザーA（サーバーXでホスト）からユーザーB（サーバーYでホスト）に送信されたとします。サーバーXが多くのユーザーのデータをホストしている場合、パッシブオブザーバーは2つのサーバーが接続されていることを確認できますが、データの送信先はわかりません。ただし、プッシュ通知がすぐにユーザーBに送信され、攻撃者がこれも確認できる場合、サーバーXの誰かがユーザーBに接続していると合理的に結論付ける可能性があります。
IANA has assigned the 'jmap' service name in the "Service Name and Transport Protocol Port Number Registry" [RFC6335].
IANAは、「サービス名とトランスポートプロトコルのポート番号レジストリ」[RFC6335]で「jmap」サービス名を割り当てました。
Service Name: jmap
サービス名：jmap
Transport Protocol(s): tcp
トランスポートプロトコル：tcp
Assignee: IESG
譲受人：IESG
Contact: IETF Chair
連絡先：IETF議長
Description: JSON Meta Application Protocol
説明：JSONメタアプリケーションプロトコル
Reference: RFC 8620
リファレンス：RFC 8620
Assignment Notes: This service name was previously assigned under the name "JSON Mail Access Protocol". This has been de-assigned and re-assigned with the approval of the previous assignee.
割り当てメモ：このサービス名は、以前は「JSONメールアクセスプロトコル」という名前で割り当てられていました。これは、前の譲受人の承認を得て割り当てが解除され、再割り当てされました。
IANA has registered the following suffix in the "Well-Known URIs" registry for JMAP, as described in [RFC8615]:
[RFC8615]で説明されているように、IANAはJMAPの「既知のURI」レジストリに次のサフィックスを登録しています。
URI Suffix: jmap
URIサフィックス：jmap
Change Controller: IETF
コントローラの変更：IETF
Specification Document: RFC 8620, Section 2.2.
仕様書：RFC 8620、セクション2.2。
IANA has registered the following URN sub-namespace in the "IETF URN Sub-namespace for Registered Protocol Parameter Identifiers" registry within the "Uniform Resource Name (URN) Namespace for IETF Use" registry as described in [RFC3553].
[RFC3553]で説明されているように、IANAは次のURNサブ名前空間を「Uniform Resource Name（URN）Namespace for IETF Use」レジストリ内の「IETF URN Sub-namespace for Registered Protocol Parameter Identifiers」レジストリに登録しました。
Registered Parameter Identifier: jmap
登録されたパラメーター識別子：jmap
Reference: RFC 8620, Section 9.4
参照：RFC 8620、セクション9.4
IANA Registry Reference: http://www.iana.org/assignments/jmap
IANA has created the "JMAP Capabilities" registry as described in Section 2. JMAP capabilities are advertised in the "capabilities" property of the JMAP Session resource. They are used to extend the functionality of a JMAP server. A capability is referenced by a URI. The JMAP capability URI can be a URN starting with "urn:ietf:params:jmap:" plus a unique suffix that is the index value in the jmap URN sub-namespace. Registration of a JMAP capability with another form of URI has no impact on the jmap URN sub-namespace.
IANAは、セクション2で説明されているように「JMAP機能」レジストリを作成しました。JMAP機能は、JMAPセッションリソースの「機能」プロパティで通知されます。これらは、JMAPサーバーの機能を拡張するために使用されます。機能はURIによって参照されます。 JMAP機能URIは、「urn：ietf：params：jmap：」で始まるURNに、jmap URNサブ名前空間のインデックス値である一意のサフィックスを加えたものにすることができます。別の形式のURIでJMAP機能を登録しても、jmap URNサブ名前空間には影響しません。
This registry follows the expert review process unless the "intended use" field is "common" or "placeholder", in which case registration follows the specification required process.
このレジストリは、「使用目的」フィールドが「共通」または「プレースホルダ」でない限り、専門家によるレビュープロセスに従います。この場合、登録は仕様に必要なプロセスに従います。
A JMAP capability registration can have an intended use of "common", "placeholder", "limited", or "obsolete". IANA will list common-use registrations prominently and separately from those with other intended use values.
JMAP機能の登録には、「共通」、「プレースホルダー」、「制限付き」、または「廃止」の使用目的があります。 IANAは、他の使用目的の値を持つものとは別に、目立つように、共通使用の登録をリストします。
The JMAP capability registration procedure is not a formal standards process but rather an administrative procedure intended to allow community comment and sanity checking without excessive time delay.
JMAP機能の登録手順は、正式な標準プロセスではなく、過度の時間遅延なしにコミュニティのコメントと健全性チェックを可能にすることを目的とした管理手順です。
A "placeholder" registration reserves part of the jmap URN namespace for another purpose but is typically not included in the "capabilities" property of the JMAP Session resource.
「プレースホルダー」登録は、別の目的のためにjmap URN名前空間の一部を予約しますが、通常、JMAPセッションリソースの「機能」プロパティには含まれていません。
Notice of a potential JMAP common-use registration SHOULD be sent to the JMAP mailing list <jmap@ietf.org> for review. This mailing list is appropriate to solicit community feedback on a proposed JMAP capability. Registrations that are not intended for common use MAY be sent to the list for review as well; doing so is entirely OPTIONAL, but is encouraged.
潜在的なJMAP共通使用登録の通知は、レビューのためにJMAPメーリングリスト<jmap@ietf.org>に送信する必要があります（SHOULD）。このメーリングリストは、提案されたJMAP機能に関するコミュニティフィードバックを求めるのに適しています。一般的な使用を目的としていない登録も、レビューのためにリストに送信される場合があります。そうすることは完全にオプションですが、推奨されます。
The intent of the public posting to this list is to solicit comments and feedback on the choice of the capability name, the unambiguity of the specification document, and a review of any interoperability or security considerations. The submitter may submit a revised registration proposal or abandon the registration completely at any time.
このリストへの公開投稿の目的は、機能名の選択、仕様ドキュメントの明確性、および相互運用性またはセキュリティの考慮事項のレビューに関するコメントとフィードバックを求めることです。提出者は、改訂された登録提案を提出するか、いつでも完全に登録を破棄することができます。
Registration requests can be sent to <iana@iana.org>.
登録リクエストは<iana@iana.org>に送信できます。
For a limited-use registration, the primary concern of the designated expert (DE) is preventing name collisions and encouraging the submitter to document security and privacy considerations; a published specification is not required. For a common-use registration, the DE is expected to confirm that suitable documentation, as described in Section 4.6 of [RFC8126], is available. The DE should also verify that the capability does not conflict with work that is active or already published within the IETF.
限定使用登録の場合、指定されたエキスパート（DE）の主な関心事は、名前の衝突を防ぎ、提出者にセキュリティとプライバシーの考慮事項を文書化するよう促すことです。公開された仕様は必要ありません。共同使用登録の場合、DEは、[RFC8126]のセクション4.6で説明されているように、適切なドキュメントが利用可能であることを確認する必要があります。 DEは、機能が、IETF内でアクティブまたは既に公開されている作業と競合しないことも確認する必要があります。
Before a period of 30 days has passed, the DE will either approve or deny the registration request and publish a notice of the decision to the JMAP WG mailing list or its successor, as well as inform IANA. A denial notice must be justified by an explanation, and, in the cases where it is possible, concrete suggestions on how the request can be modified so as to become acceptable should be provided.
30日が経過する前に、DEは登録要求を承認または拒否し、決定の通知をJMAP WGメーリングリストまたはその後継者に公開するとともに、IANAに通知します。拒否通知は説明で正当化する必要があり、可能な場合は、要求が受け入れ可能になるように変更する方法に関する具体的な提案を提供する必要があります。
If the DE does not respond within 30 days, the registrant may request the IESG take action to process the request in a timely manner.
DEが30日以内に応答しない場合、登録者はIESGに要求をタイムリーに処理するためのアクションを要求することができます。
Once a JMAP capability has been published by the IANA, the change controller may request a change to its definition. The same procedure that would be appropriate for the original registration request is used to process a change request.
JMAP機能がIANAによって公開されると、変更コントローラはその定義の変更を要求できます。変更リクエストの処理には、元の登録リクエストに適したものと同じ手順が使用されます。
JMAP capability registrations may not be deleted; capabilities that are no longer believed appropriate for use can be declared obsolete by a change to their "intended use" field; such capabilities will be clearly marked in the lists published by the IANA.
JMAP機能の登録は削除できません。使用に適しているとは考えられなくなった機能は、「使用目的」フィールドを変更することで廃止と宣言できます。そのような機能は、IANAによって公開されたリストで明確にマークされます。
Significant changes to a capability's definition should be requested only when there are serious omissions or errors in the published specification. When review is required, a change request may be denied if it renders entities that were valid under the previous definition invalid under the new definition.
機能の定義の大幅な変更は、公開された仕様に重大な欠落またはエラーがある場合にのみ要求する必要があります。確認が必要な場合、以前の定義では有効だったエンティティが新しい定義では無効になると、変更リクエストが拒否されることがあります。
The owner of a JMAP capability may pass responsibility to another person or agency by informing the IANA; this can be done without discussion or review.
JMAP機能の所有者は、IANAに通知することにより、責任を別の人または機関に渡すことができます。これは、ディスカッションやレビューなしで行うことができます。
The IESG may reassign responsibility for a JMAP capability. The most common case of this will be to enable changes to be made to capabilities where the author of the registration has died, moved out of contact, or is otherwise unable to make changes that are important to the community.
IESGは、JMAP機能の責任を再割り当てする場合があります。これの最も一般的なケースは、登録の作成者が死亡した、連絡が取れなくなった、またはコミュニティにとって重要な変更を行うことができない機能を変更できるようにすることです。
Capability name: (see capability property in Section 2)
機能名：（セクション2の機能プロパティを参照）
Specification document:
仕様書：
Intended use: (one of common, limited, placeholder, or obsolete)
使用目的：（一般的、制限付き、プレースホルダー、廃止のいずれか）
Change controller: ("IETF" for Standards Track / BCP RFCs)
コントローラの変更：（Standards Track / BCP RFCの「IETF」）
Security and privacy considerations:
セキュリティとプライバシーに関する考慮事項：
Capability Name: "urn:ietf:params:jmap:core"
Specification document: RFC 8620, Section 2
仕様書：RFC 8620、セクション2
Intended use: common
使用目的：一般
Change Controller: IETF
コントローラの変更：IETF
Security and privacy considerations: RFC 8620, Section 8.
セキュリティとプライバシーに関する考慮事項：RFC 8620、セクション8。
9.4.7. Registration for JMAP Error Placeholder in JMAP Capabilities Registry
9.4.7. JMAP Capabilities RegistryのJMAPエラープレースホルダーの登録
Capability Name: "urn:ietf:params:jmap:error:"
Specification document: RFC 8620, Section 9.5
仕様書：RFC 8620、セクション9.5
Intended use: placeholder
使用目的：プレースホルダー
Change Controller: IETF
コントローラの変更：IETF
Security and privacy considerations: RFC 8620, Section 8.
セキュリティとプライバシーに関する考慮事項：RFC 8620、セクション8。
IANA has created the "JMAP Error Codes" registry. JMAP error codes appear in the "type" member of a JSON problem details object (as described in Section 3.6.1), the "type" member in a JMAP error object (as described in Section 3.6.2), or the "type" member of a JMAP method-specific error object (such as SetError in Section 5.3). When used in a problem details object, the prefix "urn:ietf:params:jmap:error:" is always included; when used in JMAP objects, the prefix is always omitted.
IANAは「JMAPエラーコード」レジストリを作成しました。 JMAPエラーコードは、JSON問題詳細オブジェクトの「type」メンバー（セクション3.6.1で説明）、JMAPエラーオブジェクトの「type」メンバー（セクション3.6.2で説明）、または「type "JMAPメソッド固有のエラーオブジェクト（5.3節のSetErrorなど）のメンバー。問題詳細オブジェクトで使用する場合、接頭辞「urn：ietf：params：jmap：error：」が常に含まれます。 JMAPオブジェクトで使用する場合、プレフィックスは常に省略されます。
This registry follows the expert review process. Preliminary community review for this registry follows the same procedures as the "JMAP Capabilities" registry, but it is optional. The change procedures for this registry are the same as the change procedures for the "JMAP Capabilities" registry.
このレジストリは、エキスパートレビュープロセスに従います。このレジストリの予備的なコミュニティレビューは、「JMAP機能」レジストリと同じ手順に従いますが、オプションです。このレジストリの変更手順は、「JMAP機能」レジストリの変更手順と同じです。
The designated expert should review the following aspects of the registration:
指定された専門家は、登録の以下の側面を確認する必要があります。
1. Verify the error code does not conflict with existing names.
1. エラーコードが既存の名前と競合していないことを確認します。
2. Verify the error code follows the syntax limitations (does not require URI encoding).
2. エラーコードが構文の制限に従っていることを確認します（URIエンコードは必要ありません）。
3. Encourage the submitter to follow the naming convention of previously registered errors.
3. 以前に登録されたエラーの命名規則に従うようサブミッターに奨励します。
4. Encourage the submitter to describe client behaviours that are recommended in response to the error code. These may distinguish the error code from other error codes.
4. エラーコードに応じて推奨されるクライアントの動作を説明するように提出者を促します。これらにより、エラーコードが他のエラーコードと区別される場合があります。
5. Encourage the submitter to describe when the server should issue the error as opposed to some other error code.
5. 他のエラーコードではなく、サーバーがエラーを発行するタイミングを送信者に説明するように勧めます。
6. Encourage the submitter to note any security considerations associated with the error, if any (e.g., an error code that might disclose existence of data the authenticated user does not have permission to know about).
6. エラーに関連するセキュリティ上の考慮事項がある場合はそれを記録するように送信者を促します（たとえば、認証されたユーザーが知る権限のないデータの存在を開示する可能性があるエラーコード）。
Steps 3-6 are meant to promote a higher-quality registry. However, the expert is encouraged to approve any registration that would not actively harm JMAP interoperability to make this a relatively lightweight process.
手順3〜6は、より高品質のレジストリを促進するためのものです。ただし、専門家は、JMAPの相互運用性を積極的に損なうことのない登録を承認して、これを比較的軽量なプロセスにすることをお勧めします。
JMAP Error Code:
JMAPエラーコード：
Intended use: (one of "common", "limited", "obsolete")
使用目的：（「共通」、「制限付き」、「廃止」のいずれか）
Change Controller: ("IETF" for Standards Track / BCP RFCs)
変更管理者：（Standards Track / BCP RFCの「IETF」）
Reference: (Optional. Only required if defined in an RFC.)
参照：（オプション。RFCで定義されている場合にのみ必要です。）
Description:
説明：
o JMAP Error Code: accountNotFound Intended Use: Common Change Controller: IETF Reference: RFC 8620, Section 3.6.2 Description: The accountId does not correspond to a valid account.
o JMAPエラーコード：accountNotFound使用目的：共通変更コントローラー：IETFリファレンス：RFC 8620、セクション3.6.2説明：accountIdが有効なアカウントに対応していません。
o JMAP Error Code: accountNotSupportedByMethod Intended Use: Common Change Controller: IETF Reference: RFC 8620, Section 3.6.2 Description: The accountId given corresponds to a valid account, but the account does not support this method or data type.
o JMAPエラーコード：accountNotSupportedByMethod使用目的：共通変更コントローラー：IETFリファレンス：RFC 8620、セクション3.6.2説明：指定されたaccountIdは有効なアカウントに対応していますが、このアカウントはこのメソッドまたはデータタイプをサポートしていません。
o JMAP Error Code: accountReadOnly Intended Use: Common Change Controller: IETF Reference: RFC 8620, Section 3.6.2 Description: This method modifies state, but the account is read-only (as returned on the corresponding Account object in the JMAP Session resource).
o JMAPエラーコード：accountReadOnly使用目的：共通変更コントローラー：IETFリファレンス：RFC 8620、セクション3.6.2説明：このメソッドは状態を変更しますが、アカウントは読み取り専用です（JMAPセッションリソースの対応するアカウントオブジェクトで返されます） 。
o JMAP Error Code: anchorNotFound Intended Use: Common Change Controller: IETF Reference: RFC 8620, Section 5.5 Description: An anchor argument was supplied, but it cannot be found in the results of the query.
o JMAPエラーコード：anchorNotFound使用目的：共通変更コントローラー：IETFリファレンス：RFC 8620、セクション5.5説明：アンカー引数が指定されましたが、クエリの結果で見つかりません。
o JMAP Error Code: alreadyExists Intended Use: Common Change Controller: IETF Reference: RFC 8620, Section 5.4 Description: The server forbids duplicates, and the record already exists in the target account. An existingId property of type Id MUST be included on the SetError object with the id of the existing record.
o JMAPエラーコード：alreadyExists使用目的：共通変更コントローラー：IETFリファレンス：RFC 8620、セクション5.4説明：サーバーは重複を禁止し、レコードはターゲットアカウントにすでに存在します。タイプIdのexistingIdプロパティは、既存のレコードのIDと共にSetErrorオブジェクトに含まれている必要があります。
o JMAP Error Code: cannotCalculateChanges Intended Use: Common Change Controller: IETF Reference: RFC 8620, Sections 5.2 and 5.6 Description: The server cannot calculate the changes from the state string given by the client.
o JMAPエラーコード：cannotCalculateChanges使用目的：共通変更コントローラー：IETFリファレンス：RFC 8620、セクション5.2および5.6説明：サーバーは、クライアントから指定された状態文字列から変更を計算できません。
o JMAP Error Code: forbidden Intended Use: Common Change Controller: IETF Reference: RFC 8620, Sections 3.6.2, 5.3, and 7.2.1 Description: The action would violate an ACL or other permissions policy.
o JMAPエラーコード：禁止使用目的：共通変更コントローラー：IETFリファレンス：RFC 8620、セクション3.6.2、5.3、7.2.1説明：アクションは、ACLまたは他のアクセス許可ポリシーに違反します。
o JMAP Error Code: fromAccountNotFound Intended Use: Common Change Controller: IETF Reference: RFC 8620, Sections 5.4 and 6.3 Description: The fromAccountId does not correspond to a valid account.
o JMAPエラーコード：fromAccountNotFound使用目的：共通変更コントローラー：IETFリファレンス：RFC 8620、セクション5.4および6.3説明：fromAccountIdが有効なアカウントに対応していません。
o JMAP Error Code: fromAccountNotSupportedByMethod Intended Use: Common Change Controller: IETF Reference: RFC 8620, Section 5.4 Description: The fromAccountId given corresponds to a valid account, but the account does not support this data type.
o JMAPエラーコード：fromAccountNotSupportedByMethod使用目的：共通変更コントローラー：IETFリファレンス：RFC 8620、セクション5.4説明：指定されたfromAccountIdは有効なアカウントに対応していますが、アカウントはこのデータタイプをサポートしていません。
o JMAP Error Code: invalidArguments Intended Use: Common Change Controller: IETF Reference: RFC 8620, Section 3.6.2 Description: One of the arguments is of the wrong type or otherwise invalid, or a required argument is missing.
o JMAPエラーコード：invalidArguments使用目的：Common Change Controller：IETFリファレンス：RFC 8620、セクション3.6.2説明：引数の1つがタイプが正しくないか無効であるか、必要な引数がありません。
o JMAP Error Code: invalidPatch Intended Use: Common Change Controller: IETF Reference: RFC 8620, Section 5.3 Description: The PatchObject given to update the record was not a valid patch.
o JMAPエラーコード：invalidPatch使用目的：共通変更コントローラー：IETFリファレンス：RFC 8620、セクション5.3説明：レコードを更新するために指定されたPatchObjectは、有効なパッチではありませんでした。
o JMAP Error Code: invalidProperties Intended Use: Common Change Controller: IETF Reference: RFC 8620, Section 5.3 Description: The record given is invalid.
o JMAPエラーコード：invalidProperties使用目的：共通変更コントローラー：IETFリファレンス：RFC 8620、セクション5.3説明：指定されたレコードは無効です。
o JMAP Error Code: notFound Intended Use: Common Change Controller: IETF Reference: RFC 8620, Section 5.3 Description: The id given cannot be found.
o JMAPエラーコード：notFound使用目的：共通変更コントローラー：IETFリファレンス：RFC 8620、セクション5.3説明：指定されたIDが見つかりません。
o JMAP Error Code: notJSON Intended Use: Common Change Controller: IETF Reference: RFC 8620, Section 3.6.1 Description: The content type of the request was not application/ json, or the request did not parse as I-JSON.
o JMAPエラーコード：notJSON使用目的：共通変更コントローラー：IETFリファレンス：RFC 8620、セクション3.6.1説明：リクエストのコンテンツタイプがapplication / jsonでなかったか、リクエストがI-JSONとして解析されませんでした。
o JMAP Error Code: notRequest Intended Use: Common Change Controller: IETF Reference: RFC 8620, Section 3.6.1 Description: The request parsed as JSON but did not match the type signature of the Request object.
o JMAPエラーコード：notRequest使用目的：一般的な変更コントローラー：IETFリファレンス：RFC 8620、セクション3.6.1説明：リクエストはJSONとして解析されましたが、リクエストオブジェクトのタイプシグネチャと一致しませんでした。
o JMAP Error Code: overQuota Intended Use: Common Change Controller: IETF Reference: RFC 8620, Section 5.3 Description: The create would exceed a server-defined limit on the number or total size of objects of this type.
o JMAPエラーコード：overQuota使用目的：共通変更コントローラー：IETFリファレンス：RFC 8620、セクション5.3説明：このタイプのオブジェクトの数または合計サイズに対するサーバー定義の制限を超えます。
o JMAP Error Code: rateLimit Intended Use: Common Change Controller: IETF Reference: RFC 8620, Section 5.3 Description: Too many objects of this type have been created recently, and a server-defined rate limit has been reached. It may work if tried again later.
o JMAPエラーコード：rateLimit使用目的：共通変更コントローラー：IETFリファレンス：RFC 8620、セクション5.3説明：最近作成されたこのタイプのオブジェクトが多すぎ、サーバー定義のレート制限に達しています。後で再試行すると機能する場合があります。
o JMAP Error Code: requestTooLarge Intended Use: Common Change Controller: IETF Reference: RFC 8620, Sections 5.1 and 5.3 Description: The total number of actions exceeds the maximum number the server is willing to process in a single method call.
o JMAPエラーコード：requestTooLarge使用目的：共通変更コントローラー：IETFリファレンス：RFC 8620、セクション5.1および5.3説明：アクションの総数が、サーバーが単一のメソッド呼び出しで処理する最大数を超えています。
o JMAP Error Code: invalidResultReference Intended Use: Common Change Controller: IETF Reference: RFC 8620, Section 3.6.2 Description: The method used a result reference for one of its arguments, but this failed to resolve.
o JMAPエラーコード：invalidResultReference使用目的：Common Change Controller：IETF Reference：RFC 8620、Section 3.6.2説明：このメソッドは、引数の1つに結果参照を使用しましたが、これは解決できませんでした。
o JMAP Error Code: serverFail Intended Use: Common Change Controller: IETF Reference: RFC 8620, Section 3.6.2 Description: An unexpected or unknown error occurred during the processing of the call. The method call made no changes to the server's state.
o JMAPエラーコード：serverFail使用目的：共通変更コントローラー：IETFリファレンス：RFC 8620、セクション3.6.2説明：呼び出しの処理中に予期しないまたは不明なエラーが発生しました。メソッドの呼び出しによってサーバーの状態は変更されませんでした。
o JMAP Error Code: serverPartialFail Intended Use: Limited Change Controller: IETF Reference: RFC 8620, Section 3.6.2 Description: Some, but not all, expected changes described by the method occurred. The client MUST resynchronise impacted data to determine the server state. Use of this error is strongly discouraged.
o JMAPエラーコード：serverPartialFail使用目的：制限付き変更コントローラ：IETFリファレンス：RFC 8620、セクション3.6.2説明：メソッドで説明されている予期された変更のすべてではなく一部が発生しました。クライアントは、影響を受けるデータを再同期して、サーバーの状態を判断する必要があります。このエラーの使用はお勧めしません。
o JMAP Error Code: serverUnavailable Intended Use: Common Change Controller: IETF Reference: RFC 8620, Section 3.6.2 Description: Some internal server resource was temporarily unavailable. Attempting the same operation later (perhaps after a backoff with a random factor) may succeed.
o JMAPエラーコード：serverUnavailable用途：Common Change Controller：IETF Reference：RFC 8620、Section 3.6.2説明：一部の内部サーバーリソースが一時的に利用できませんでした。同じ操作を後で（おそらくランダムな要因によるバックオフの後で）試行すると、成功する可能性があります。
o JMAP Error Code: singleton Intended Use: Common Change Controller: IETF Reference: RFC 8620, Section 5.3 Description: This is a singleton type, so you cannot create another one or destroy the existing one.
o JMAPエラーコード：シングルトン使用目的：共通変更コントローラ：IETFリファレンス：RFC 8620、セクション5.3説明：これはシングルトンタイプであるため、別のタイプを作成したり、既存のタイプを破棄したりすることはできません。
o JMAP Error Code: stateMismatch Intended Use: Common Change Controller: IETF Reference: RFC 8620, Section 5.3 Description: An ifInState argument was supplied, and it does not match the current state.
o JMAPエラーコード：stateMismatch使用目的：共通変更コントローラー：IETFリファレンス：RFC 8620、セクション5.3説明：ifInState引数が指定されましたが、現在の状態と一致しません。
o JMAP Error Code: tooLarge Intended Use: Common Change Controller: IETF Reference: RFC 8620, Section 5.3 Description: The action would result in an object that exceeds a server-defined limit for the maximum size of a single object of this type.
o JMAPエラーコード：tooLarge使用目的：共通変更コントローラー：IETFリファレンス：RFC 8620、セクション5.3説明：このアクションにより、このタイプの単一オブジェクトの最大サイズに関するサーバー定義の制限を超えるオブジェクトが生成されます。
o JMAP Error Code: tooManyChanges Intended Use: Common Change Controller: IETF Reference: RFC 8620, Section 5.6 Description: There are more changes than the client's maxChanges argument.
o JMAPエラーコード：tooManyChanges使用目的：一般的な変更コントローラー：IETFリファレンス：RFC 8620、セクション5.6説明：クライアントのmaxChanges引数よりも多くの変更があります。
o JMAP Error Code: unknownCapability Intended Use: Common Change Controller: IETF Reference: RFC 8620, Section 3.6.1 Description: The client included a capability in the "using" property of the request that the server does not support.
o JMAPエラーコード：unknownCapability使用目的：共通変更コントローラー：IETFリファレンス：RFC 8620、セクション3.6.1説明：クライアントが、サーバーがサポートしていない要求の "using"プロパティに機能を含めました。
o JMAP Error Code: unknownMethod Intended Use: Common Change Controller: IETF Reference: RFC 8620, Section 3.6.2 Description: The server does not recognise this method name.
o JMAPエラーコード：unknownMethod使用目的：共通変更コントローラー：IETFリファレンス：RFC 8620、セクション3.6.2説明：サーバーはこのメソッド名を認識しません。
o JMAP Error Code: unsupportedFilter Intended Use: Common Change Controller: IETF Reference: RFC 8620, Section 5.5 Description: The filter is syntactically valid, but the server cannot process it.
o JMAPエラーコード：unsupportedFilter使用目的：一般的な変更コントローラー：IETFリファレンス：RFC 8620、セクション5.5説明：フィルターは構文的には有効ですが、サーバーは処理できません。
o JMAP Error Code: unsupportedSort Intended Use: Common Change Controller: IETF Reference: RFC 8620, Section 5.5 Description: The sort is syntactically valid but includes a property the server does not support sorting on or a collation method it does not recognise.
o JMAPエラーコード：unsupportedSort用途：Common Change Controller：IETF Reference：RFC 8620、Section 5.5説明：ソートは構文的には有効ですが、サーバーがソートをサポートしていないプロパティまたは認識できない照合方法が含まれています。
o JMAP Error Code: willDestroy Intended Use: Common Change Controller: IETF Reference: RFC 8620, Section 5.3 Description: The client requested an object be both updated and destroyed in the same /set request, and the server has decided to therefore ignore the update.
o JMAPエラーコード：willDestroy使用目的：共通変更コントローラー：IETFリファレンス：RFC 8620、セクション5.3説明：クライアントが同じ/ setリクエストでオブジェクトの更新と破棄の両方を要求したため、サーバーは更新を無視することにしました。
[EventSource] Hickson, I., "Server-Sent Events", World Wide Web Consortium Recommendation REC-eventsource-20150203, February 2015, <https://www.w3.org/TR/eventsource/>.
[EventSource] Hickson、I。、「Server-Sent Events」、World Wide Web Consortium Recommendation REC-eventsource-20150203、2015年2月、<https://www.w3.org/TR/eventsource/>。
[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>。
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <https://www.rfc-editor.org/info/rfc2782>.
[RFC2782] Gulbrandsen、A.、Vixie、P。、およびL. Esibov、「サービスの場所を指定するためのDNS RR（DNS SRV）」、RFC 2782、DOI 10.17487 / RFC2782、2000年2月、<https：// www.rfc-editor.org/info/rfc2782>。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <https://www.rfc-editor.org/info/rfc2818>.
[RFC2818] Rescorla、E。、「HTTP Over TLS」、RFC 2818、DOI 10.17487 / RFC2818、2000年5月、<https://www.rfc-editor.org/info/rfc2818>。
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.
[RFC3339] Klyne、G。およびC. Newman、「インターネット上の日付と時刻：タイムスタンプ」、RFC 3339、DOI 10.17487 / RFC3339、2002年7月、<https://www.rfc-editor.org/info/rfc3339 >。
[RFC3553] Mealling, M., Masinter, L., Hardie, T., and G. Klyne, "An IETF URN Sub-namespace for Registered Protocol Parameters", BCP 73, RFC 3553, DOI 10.17487/RFC3553, June 2003, <https://www.rfc-editor.org/info/rfc3553>.
[RFC3553] Mealling、M.、Masinter、L.、Hardie、T。、およびG. Klyne、「An Registered Protocol Parameters for IETF URN Sub-namespace for Registered Protocol Parameters」、BCP 73、RFC 3553、DOI 10.17487 / RFC3553、2003年6月、 <https://www.rfc-editor.org/info/rfc3553>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https://www.rfc-editor.org/info/ rfc3629>。
[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>。
[RFC4790] Newman, C., Duerst, M., and A. Gulbrandsen, "Internet Application Protocol Collation Registry", RFC 4790, DOI 10.17487/RFC4790, March 2007, <https://www.rfc-editor.org/info/rfc4790>.
[RFC4790]ニューマン、C。、デュエルスト、M。、およびA.グルブランドセン、「インターネットアプリケーションプロトコル照合レジストリ」、RFC 4790、DOI 10.17487 / RFC4790、2007年3月、<https://www.rfc-editor.org/ info / rfc4790>。
[RFC5051] Crispin, M., "i;unicode-casemap - Simple Unicode Collation Algorithm", RFC 5051, DOI 10.17487/RFC5051, October 2007, <https://www.rfc-editor.org/info/rfc5051>.
[RFC5051] Crispin、M。、「i; unicode-casemap-Simple Unicode Collation Algorithm」、RFC 5051、DOI 10.17487 / RFC5051、2007年10月、<https://www.rfc-editor.org/info/rfc5051>。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、DOI 10.17487 / RFC5246、2008年8月、<https://www.rfc-editor.org/info / rfc5246>。
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, <https://www.rfc-editor.org/info/rfc5280>.
[RFC5280] Cooper、D.、Santesson、S.、Farrell、S.、Boeyen、S.、Housley、R。、およびW. Polk、「Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List（CRL）Profile "、RFC 5280、DOI 10.17487 / RFC5280、2008年5月、<https://www.rfc-editor.org/info/rfc5280>。
[RFC5322] Resnick, P., Ed., "Internet Message Format", RFC 5322, DOI 10.17487/RFC5322, October 2008, <https://www.rfc-editor.org/info/rfc5322>.
[RFC5322] Resnick、P。、編、「インターネットメッセージ形式」、RFC 5322、DOI 10.17487 / RFC5322、2008年10月、<https://www.rfc-editor.org/info/rfc5322>。
[RFC6186] Daboo, C., "Use of SRV Records for Locating Email Submission/Access Services", RFC 6186, DOI 10.17487/RFC6186, March 2011, <https://www.rfc-editor.org/info/rfc6186>.
[RFC6186] Daboo、C。、「電子メールの送信/アクセスサービスを特定するためのSRVレコードの使用」、RFC 6186、DOI 10.17487 / RFC6186、2011年3月、<https://www.rfc-editor.org/info/rfc6186> 。
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>.
[RFC6335]綿、M。、エガート、L。、タッチ、J。、ウェスターランド、M。、およびS.チェシャー、「サービス名とトランスポートプロトコルのポート番号レジストリの管理のためのInternet Assigned Numbers Authority（IANA）手順"、BCP 165、RFC 6335、DOI 10.17487 / RFC6335、2011年8月、<https://www.rfc-editor.org/info/rfc6335>。
[RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., and D. Orchard, "URI Template", RFC 6570, DOI 10.17487/RFC6570, March 2012, <https://www.rfc-editor.org/info/rfc6570>.
[RFC6570]グレゴリオ、J。、フィールディング、R。、ハドリー、M。、ノッティンガム、M。、およびD.オーチャード、「URIテンプレート」、RFC 6570、DOI 10.17487 / RFC6570、2012年3月、<https：// www .rfc-editor.org / info / rfc6570>。
[RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, <https://www.rfc-editor.org/info/rfc6749>.
[RFC6749] Hardt、D。、編、「The OAuth 2.0 Authorization Framework」、RFC 6749、DOI 10.17487 / RFC6749、2012年10月、<https://www.rfc-editor.org/info/rfc6749>。
[RFC6764] Daboo, C., "Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)", RFC 6764, DOI 10.17487/RFC6764, February 2013, <https://www.rfc-editor.org/info/rfc6764>.
[RFC6764] Daboo、C。、「Locating Services for Calendaring Extensions to WebDAV（CalDAV）and vCard Extensions to WebDAV（CardDAV）」、RFC 6764、DOI 10.17487 / RFC6764、2013年2月、<https：//www.rfc-editor .org / info / rfc6764>。
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/info/rfc6838>.
[RFC6838] Freed、N.、Klensin、J。、およびT. Hansen、「メディアタイプの仕様と登録手順」、BCP 13、RFC 6838、DOI 10.17487 / RFC6838、2013年1月、<https：//www.rfc- editor.org/info/rfc6838>。
[RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., "JavaScript Object Notation (JSON) Pointer", RFC 6901, DOI 10.17487/RFC6901, April 2013, <https://www.rfc-editor.org/info/rfc6901>.
[RFC6901]ブライアン、P。、編、Zyp、K。、およびM.ノッティンガム、編、「JavaScript Object Notation（JSON）ポインタ」、RFC 6901、DOI 10.17487 / RFC6901、2013年4月、<https：// www.rfc-editor.org/info/rfc6901>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Message Syntax and Routing」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<https://www.rfc-editor.org/info/ rfc7230>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231]フィールディング、R。、エド。およびJ. Reschke編、「Hypertext Transfer Protocol（HTTP / 1.1）：Semantics and Content」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<https://www.rfc-editor.org/info/rfc7231 >。
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, <https://www.rfc-editor.org/info/rfc7493>.
[RFC7493]ブレイ、T。、編、「The I-JSON Message Format」、RFC 7493、DOI 10.17487 / RFC7493、2015年3月、<https://www.rfc-editor.org/info/rfc7493>。
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, "Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 2015, <https://www.rfc-editor.org/info/rfc7525>.
[RFC7525] Sheffer、Y.、Holz、R。、およびP. Saint-Andre、「Transport Layer Security（TLS）およびDatagram Transport Layer Security（DTLS）の安全な使用に関する推奨事項」、BCP 195、RFC 7525、DOI 10.17487 / RFC7525、2015年5月、<https://www.rfc-editor.org/info/rfc7525>。
[RFC7617] Reschke, J., "The 'Basic' HTTP Authentication Scheme", RFC 7617, DOI 10.17487/RFC7617, September 2015, <https://www.rfc-editor.org/info/rfc7617>.
[RFC7617] Reschke、J。、「The 'Basic' HTTP Authentication Scheme」、RFC 7617、DOI 10.17487 / RFC7617、2015年9月、<https://www.rfc-editor.org/info/rfc7617>。
[RFC7807] Nottingham, M. and E. Wilde, "Problem Details for HTTP APIs", RFC 7807, DOI 10.17487/RFC7807, March 2016, <https://www.rfc-editor.org/info/rfc7807>.
[RFC7807]ノッティンガム、M。およびE.ワイルド、「HTTP APIの問題の詳細」、RFC 7807、DOI 10.17487 / RFC7807、2016年3月、<https://www.rfc-editor.org/info/rfc7807>。
[RFC8030] Thomson, M., Damaggio, E., and B. Raymor, Ed., "Generic Event Delivery Using HTTP Push", RFC 8030, DOI 10.17487/RFC8030, December 2016, <https://www.rfc-editor.org/info/rfc8030>.
[RFC8030] Thomson、M.、Damaggio、E。、およびB. Raymor、編、「HTTPプッシュを使用した一般的なイベント配信」、RFC 8030、DOI 10.17487 / RFC8030、2016年12月、<https：//www.rfc- editor.org/info/rfc8030>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]コットン、M。、レイバ、B。、およびT.ナルテン、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<https：// www .rfc-editor.org / info / rfc8126>。
[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>。
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259]ブレイ、T。、編、「JavaScript Object Notation（JSON）データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、<https://www.rfc-editor.org / info / rfc8259>。
[RFC8264] Saint-Andre, P. and M. Blanchet, "PRECIS Framework: Preparation, Enforcement, and Comparison of Internationalized Strings in Application Protocols", RFC 8264, DOI 10.17487/RFC8264, October 2017, <https://www.rfc-editor.org/info/rfc8264>.
[RFC8264] Saint-Andre、P。およびM. Blanchet、「PRECIS Framework：Preparation、Enforcement、and Comparison of Internationalized Strings in Application Protocols」、RFC 8264、DOI 10.17487 / RFC8264、2017年10月、<https：// www。 rfc-editor.org/info/rfc8264>。
[RFC8291] Thomson, M., "Message Encryption for Web Push", RFC 8291, DOI 10.17487/RFC8291, November 2017, <https://www.rfc-editor.org/info/rfc8291>.
[RFC8291] Thomson、M。、「Message Push for Web Push」、RFC 8291、DOI 10.17487 / RFC8291、2017年11月、<https://www.rfc-editor.org/info/rfc8291>。
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446] Rescorla、E。、「The Transport Layer Security（TLS）Protocol Version 1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https://www.rfc-editor.org/info/rfc8446>。
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019, <https://www.rfc-editor.org/info/rfc8615>.
[RFC8615]ノッティンガム、M。、「既知のUniform Resource Identifiers（URIs）」、RFC 8615、DOI 10.17487 / RFC8615、2019年5月、<https://www.rfc-editor.org/info/rfc8615>。
[RFC8246] McManus, P., "HTTP Immutable Responses", RFC 8246, DOI 10.17487/RFC8246, September 2017, <https://www.rfc-editor.org/info/rfc8246>.
[RFC8246] McManus、P。、「HTTP Immutable Responses」、RFC 8246、DOI 10.17487 / RFC8246、2017年9月、<https://www.rfc-editor.org/info/rfc8246>。
Authors' Addresses
著者のアドレス
Neil Jenkins Fastmail PO Box 234, Collins St. West Melbourne, VIC 8007 Australia
Neil Jenkins Fastmail PO Box 234、Collins St. West Melbourne、VIC 8007 Australia
Email: neilj@fastmailteam.com
URI: https://www.fastmail.com
Chris Newman Oracle 440 E. Huntington Dr., Suite 400 Arcadia, CA 91006 United States of America
クリスニューマンオラクル440 E. Huntington Dr.、Suite 400 Arcadia、CA 91006アメリカ合衆国
Email: chris.newman@oracle.com