[要約] RFC 9290 は、制約のある環境向けのREST APIにおいて新しいエラー応答形式を定義する必要を避けるため、機械可読なエラー詳細を運ぶ方法として簡潔な "problem detail" を定義します。HTTP API向けのRFC 7807で定義された問題の詳細に着想を得ていますが、より簡潔であることを意図しています。
Internet Engineering Task Force (IETF) T. Fossati
Request for Comments: 9290 Arm Limited
Category: Standards Track C. Bormann
ISSN: 2070-1721 Universität Bremen TZI
October 2022
Concise Problem Details for Constrained Application Protocol (CoAP) APIs
制約付きアプリケーションプロトコル（COAP）APIの簡潔な問題の詳細
Abstract
概要
This document defines a concise "problem detail" as a way to carry machine-readable details of errors in a Representational State Transfer (REST) response to avoid the need to define new error response formats for REST APIs for constrained environments. The format is inspired by, but intended to be more concise than, the problem details for HTTP APIs defined in RFC 7807.
このドキュメントでは、制約された環境のREST APIの新しいエラー応答形式を定義する必要性を回避するために、代表的な状態転送（REST）応答でエラーの機械読み取り可能な詳細を運ぶ方法として、簡潔な「問題の詳細」を定義します。この形式はインスピレーションを受けていますが、RFC 7807で定義されているHTTP APIの問題の詳細よりも簡潔にすることを目的としています。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
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）の製品です。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/rfc9290.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9290で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
1.1. Terminology and Requirements Language
2. Basic Problem Details
3. Extending Concise Problem Details
3.1. Standard Problem Detail Entries
3.1.1. Standard Problem Detail Entry: Unprocessed CoAP Option
3.2. Custom Problem Detail Entries
4. Privacy Considerations
5. Security Considerations
6. IANA Considerations
6.1. Standard Problem Detail Keys Registry
6.2. Custom Problem Detail Keys Registry
6.3. Media Type
6.4. Content-Format
6.5. CBOR Tag 38
7. References
7.1. Normative References
7.2. Informative References
Appendix A. Language-Tagged Strings
A.1. Introduction
A.2. Detailed Semantics
A.3. Examples
Appendix B. Interworking with RFC 7807
Acknowledgments
Contributors
Authors' Addresses
REST response status information such as Constrained Application Protocol (CoAP) response codes (Section 5.9 of [RFC7252]) is sometimes not sufficient to convey enough information about an error to be helpful. This specification defines a simple and extensible framework to define Concise Binary Object Representation (CBOR) [STD94] data items to suit this purpose. This framework is designed to be reused by REST APIs, which can identify distinct "shapes" of these data items specific to their needs. Thus, API clients can be informed of both the high-level error class (using the response code) and the finer-grained details of the problem (using the vocabulary defined here). This pattern of communication is illustrated in Figure 1.
REST応答のステータス制約付きアプリケーションプロトコル（COAP）応答コード（[RFC7252]のセクション5.9）などの情報は、エラーに関する十分な情報を提供するのに十分ではない場合があります。この仕様は、この目的に合わせて簡潔なバイナリオブジェクト表現（CBOR）[STD94]データ項目を定義するシンプルで拡張可能なフレームワークを定義します。このフレームワークは、REST APIによって再利用されるように設計されており、これらのデータ項目の明確な「形状」をニーズに固有の項目に識別できます。したがって、APIクライアントは、高レベルのエラークラス（応答コードを使用）と問題のより細かい詳細（ここで定義されている語彙を使用）の両方を通知することができます。この通信パターンを図1に示します。
.--------. .--------.
| CoAP | | CoAP |
| Client | | Server |
'----+---' '---+----'
| |
| Request |
o----------------->|
| | (failure)
|<-----------------o
| Error Response |
| with a CBOR |
| data item giving |
| Problem Details |
| |
Figure 1: Problem Details: Example with CoAP
図1：問題の詳細：COAPの例
The framework presented is largely inspired by the problem details for HTTP APIs defined in [RFC7807]. Appendix B discusses applications where interworking with [RFC7807] is required.
提示されたフレームワークは、[RFC7807]で定義されているHTTP APIの問題の詳細に大きく触発されています。付録Bでは、[RFC7807]との相互作用が必要なアプリケーションについて説明します。
The terminology from [RFC7252], [STD94], and [RFC8610] applies; in particular, CBOR diagnostic notation is defined in Section 8 of RFC 8949 [STD94] and Appendix G of [RFC8610]. Readers are also expected to be familiar with the terminology from [RFC7807].
[RFC7252]、[STD94]、および[RFC8610]の用語が適用されます。特に、CBOR診断表記は、RFC 8949 [STD94]のセクション8および[RFC8610]の付録Gで定義されています。読者は、[RFC7807]の用語に精通していることも期待されています。
In this document, the structure of data is specified in Concise Data Definition Language (CDDL) [RFC8610] [RFC9165].
このドキュメントでは、データの構造は簡潔なデータ定義言語（CDDL）[RFC8610] [RFC9165]で指定されています。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
A Concise Problem Details data item is a CBOR data item with the following structure (rules named starting with tag38 are defined in Appendix A):
簡潔な問題の詳細データ項目は、次の構造を持つCBORデータ項目です（TAG38から始まるルールは付録Aで定義されています）：
problem-details = non-empty<{
? &(title: -1) => oltext
? &(detail: -2) => oltext
? &(instance: -3) => ~uri
? &(response-code: -4) => uint .size 1
? &(base-uri: -5) => ~uri
? &(base-lang: -6) => tag38-ltag
? &(base-rtl: -7) => tag38-direction
standard-problem-detail-entries
custom-problem-detail-entries
}>
standard-problem-detail-entries = (
* nint => any
)
custom-problem-detail-entries = (
* (uint/~uri) => { + any => any }
)
non-empty<M> = (M) .and ({ + any => any })
oltext = text / tag38
Figure 2: Structure of Concise Problem Details Data Item
図2：簡潔な問題の詳細データ項目の構造
(Examples of elaborated Concise Problem Details data items can be found later in the document, e.g., Figure 3.)
（詳細な簡潔な問題の詳細の例データ項目は、ドキュメントの後半で見つけることができます。たとえば、図3.）
A number of problem detail entries, the Standard Problem Detail entries, are predefined (more predefined details can be registered, see Section 3.1).
多くの問題の詳細エントリ、標準の問題の詳細エントリは事前に定義されています（より事前定義された詳細を登録できます。セクション3.1を参照）。
Note that, unlike [RFC7807], Concise Problem Details data items have no explicit "problem type". Instead, the category (or, one could say, Gestalt) of the problem can be understood from the shape of the problem details offered. We talk of a "problem shape" for short.
[RFC7807]とは異なり、簡潔な問題の詳細データ項目には明示的な「問題タイプ」がないことに注意してください。代わりに、問題のカテゴリ（またはゲシュタルト）は、提供されている問題の詳細の形状から理解できます。略して「問題の形」について話します。
The title (key -1): A short, human-readable summary of the problem shape. Beyond the shape of the problem, it is not intended to summarize all the specific information given with the problem details. For instance, the summary might include that an account does not have enough money for a transaction to succeed but not the detailed information such as the account number, how much money that account has, and how much would be needed.
タイトル（キー-1）：問題の形状の短い、人間が読みやすい要約。問題の形を超えて、問題の詳細とともに与えられたすべての特定の情報を要約することを意図したものではありません。たとえば、要約には、アカウントが成功するのに十分なお金がないが、アカウント番号、アカウントの金額、必要な金額などの詳細情報は含まれていないことが含まれる場合があります。
The detail (key -2): A human-readable explanation specific to this occurrence of the problem.
詳細（キー-2）：問題のこの発生に固有の人間読み取り可能な説明。
The instance (key -3): A URI reference that identifies the specific occurrence of the problem. It may or may not yield further information if dereferenced.
インスタンス（キー-3）：問題の特定の発生を識別するURI参照。控除された場合、さらなる情報が得られる場合とそうでない場合があります。
The response-code (key -4): The CoAP response code (Sections 5.9 and 12.1.2 of [RFC7252]) generated by the origin server for this occurrence of the problem.
応答コード（キー-4）：問題の発生のためにOrigin Serverによって生成されたCOAP応答コード（[RFC7252]のセクション5.9および12.1.2）。
The base-uri (key -5): The base URI (see Section 5.1 of RFC 3986 [STD66]) that should be used to resolve relative URI references embedded in this Concise Problem Details data item.
ベースURI（キー-5）：ベースURI（RFC 3986 [STD66]のセクション5.1を参照）。
The base-lang (key -6): The language-tag (tag38-ltag) that applies to the presentation of unadorned text strings (not using tag 38) in this Concise Problem Details data item; see Appendix A.
ベースラング（キー-6）：この簡潔な問題の詳細データ項目で飾られていないテキスト文字列（タグ38を使用していない）のプレゼンテーションに適用される言語タグ（Tag38-LTAG）。付録Aを参照してください。
The base-rtl (key -7): The writing-direction (tag38-direction) that applies to the presentation of unadorned text strings (not using tag 38) in this Concise Problem Details data item; see Appendix A.
ベースRTL（キー-7）：この簡潔な問題の詳細データ項目で飾られていないテキスト文字列（タグ38を使用していない）のプレゼンテーションに適用されるライティング方向（TAG38方向）。付録Aを参照してください。
Both "title" and "detail" can use either an unadorned CBOR text string (text) or a language-tagged text string (tag38); see Appendix A for the definition of the latter. Language tag and writing direction information for unadorned text strings is intended to be obtained from context; if that context needs to be saved or forwarded with a Concise Problem Details data item, "base-lang" and "base-rtl" can be used. If no such (explicitly saved or implicit) context information is available, unadorned text is interpreted with language-tag "en" and writing-direction "false" (ltr).
「タイトル」と「詳細」の両方が、装飾されていないCBORテキスト文字列（テキスト）または言語タグ付きテキスト文字列（TAG38）のいずれかを使用できます。後者の定義については、付録Aを参照してください。言語タグと書き込み指示の飾られていないテキスト文字列の情報は、コンテキストから取得することを目的としています。そのコンテキストを簡潔な問題で保存または転送する必要がある場合は、データ項目の詳細を「ベースラング」と「ベースRTL」を使用できます。そのような（明示的に保存された、または暗黙的な）コンテキスト情報が利用できない場合、飾られていないテキストは、言語タグ「en」と書き込み方向「false」（LTR）で解釈されます。
The "title" string is advisory and included to give consumers a shorthand for the category (problem shape) of the error encountered.
「タイトル」文字列はアドバイザリーであり、消費者に遭遇したエラーのカテゴリ（問題形状）の速記を提供するために含まれています。
The "detail" member, if present, ought to focus on helping the client correct the problem rather than giving extensive server-side debugging information. Consumers SHOULD NOT parse the "detail" member for information; extensions (see Section 3) are more suitable and less error-prone ways to obtain such information. Note that the "instance" URI reference may be relative; this means that it must be resolved relative to the representation's base URI, as per Section 5 of RFC 3986 [STD66].
「詳細」メンバーは、存在する場合、広範なサーバー側のデバッグ情報を提供するのではなく、クライアントが問題を修正するのを支援することに焦点を当てるべきです。消費者は、情報について「詳細」メンバーを解析すべきではありません。拡張機能（セクション3を参照）は、そのような情報を取得するためのより適切でエラーが発生しない方法です。「インスタンス」URI参照は相対的である可能性があることに注意してください。これは、RFC 3986 [STD66]のセクション5に従って、表現のベースURIに対して解決する必要があることを意味します。
The "response-code" member, if present, is only advisory; it conveys the CoAP response code used for the convenience of the consumer. Generators MUST use the same response code here as in the actual CoAP response; the latter is needed to assure that generic CoAP software that does not understand the problem-details format still behaves correctly. Consumers can use the "response-code" member to determine what the original response code used by the generator was, in cases where it has been changed (e.g., by an intermediary or cache), and when message bodies persist without CoAP information (e.g., in an events log or analytics database). Generic CoAP software will still use the CoAP response code. To support the use case of message-body persistence without support by the problem-details generator, the entity that persists the Concise Problem Details data item can copy over the CoAP response code that it received on the CoAP level. Note that the "response-code" value is a numeric representation of the actual code (see Section 3 of [RFC7252]), so it does not take the usual presentation form that resembles an HTTP status code: 4.04 Not Found is represented by the number 132.
「応答コード」メンバーは、存在する場合、アドバイザリーのみです。消費者の利便性に使用されるCOAP応答コードを伝えます。ジェネレーターは、実際のCOAP応答と同じ応答コードをここで使用する必要があります。後者は、問題のある形式がまだ正しく動作していることを理解していない一般的なCOAPソフトウェアを保証するために必要です。消費者は、「応答コード」メンバーを使用して、ジェネレーターが使用した元の応答コードが変更された場合、それが変更された場合（たとえば、仲介者やキャッシュによって）、およびメッセージ本文がCOAP情報なしで持続する場合（例： 、イベントログまたは分析データベース）。 Generic Coapソフトウェアは引き続きCOAP応答コードを使用します。問題控除ジェネレーターによるサポートなしでメッセージボディの永続性のユースケースをサポートするために、簡潔な問題の詳細を持続させるエンティティは、データ項目がCOAPレベルで受け取ったCOAP応答コードをコピーできます。 「応答コード」値は、実際のコードの数値表現であることに注意してください（[RFC7252]のセクション3を参照）ので、HTTPステータスコードに似た通常のプレゼンテーションフォームを取得しません：4.04は見つかりません。番号132。
The "base-uri" member is usually not present in the initial request-response communication as it can be inferred as per Section 5.1.3 of RFC 3986 [STD66]. An entity that stores a Concise Problem Details data item or otherwise makes it available for consumers without this context might add in a "base-uri" member to allow those consumers to perform resolution of any relative URI references embedded in the data item.
「ベースURI」メンバーは通常、RFC 3986 [STD66]のセクション5.1.3に従って推測できるため、最初の要求応答通信には存在しません。簡潔な問題を保存するエンティティは、データ項目を詳細に説明するか、このコンテキストなしで消費者が利用できるようにするため、「基本-URI」メンバーを追加して、消費者がデータ項目に埋め込まれた相対的なURI参照の解決を実行できるようにします。
This specification defines a generic problem-details container with only a minimal set of attributes to make it usable.
この仕様では、一般的な問題セットの属性セットのみを備えた一般的な問題セットコンテナを定義して、使用可能にします。
It is expected that applications will extend the base format by defining new attributes.
アプリケーションは、新しい属性を定義することにより、ベース形式を拡張することが期待されます。
These new attributes fall into two categories: generic and application specific.
これらの新しい属性は、汎用とアプリケーション固有の2つのカテゴリに分類されます。
Generic attributes will be allocated in the standard-problem-detail-entries slot according to the registration procedure defined in Section 3.1.
ジェネリック属性は、セクション3.1で定義されている登録手順に従って、標準の問題 - ディテールエントリスロットに割り当てられます。
Application-specific attributes will be allocated in the custom-problem-detail-entries slot according to the procedure described in Section 3.2.
アプリケーション固有の属性は、セクション3.2で説明されている手順に従って、カスタムプロームディテールエントリスロットに割り当てられます。
Consumers of a Concise Problem Details data item MUST ignore any Standard Problem Detail entries or Custom Problem Detail entries, or keys inside the Custom Problem Detail entries, that they do not recognize ("ignore-unknown rule"); this allows problem details to evolve. When storing the data item for future use or forwarding it to other consumers, it is strongly RECOMMENDED to retain the unrecognized entries; exceptions might be when storage or forwarding occurs in a different format/protocol that cannot accommodate them or when the storage or forwarding function needs to filter out privacy-sensitive information and for that needs to assume unrecognized entries might be privacy-sensitive.
簡潔な問題の詳細データ項目は、標準の問題の詳細エントリまたはカスタム問題の詳細エントリ、またはカスタム問題の詳細エントリ内のキーを無視する必要があります。これにより、問題の詳細が進化することができます。将来の使用のためにデータ項目を保存したり、他の消費者に転送したりする場合、認識されていないエントリを保持することを強くお勧めします。例外は、ストレージまたは転送がそれらに対応できない別の形式/プロトコルで発生した場合、またはストレージまたは転送機能がプライバシーに敏感な情報をフィルタリングする必要がある場合、そのために認識されていないエントリがプライバシーに敏感であると仮定する必要がある場合があります。
Beyond the Standard Problem Detail keys defined in Figure 2, additional Standard Problem Detail keys can be registered for use in the standard-problem-detail-entries slot (see Section 6.1).
図2に定義されている標準の問題の詳細キーを超えて、追加の標準の問題詳細キーを標準の問題のあるデテールエントリスロットで使用するために登録できます（セクション6.1を参照）。
Standard Problem Detail keys are negative integers, so they can never conflict with Custom Problem Detail keys defined for a specific application domain (which are unsigned integers or URIs.)
標準の問題の詳細キーは負の整数であるため、特定のアプリケーションドメイン（署名されていない整数またはURI）で定義されているカスタム問題の詳細キーと競合することはありません。
In summary, the keys for Standard Problem Detail entries are in a global namespace that is not specific to a particular application domain.
要約すると、標準の問題の詳細エントリのキーは、特定のアプリケーションドメインに固有のグローバルネームスペースにあります。
Section 2 provides a number of generally applicable Standard Problem Detail entries. The present section both registers another useful Standard Problem Detail entry and serves as an example of a Standard Problem Detail Entry registration, in the registration template format that would be ready for registration.
セクション2では、一般的に適用可能な標準の問題の詳細エントリが多数提供されています。本セクションはどちらも別の有用な標準問題の詳細エントリを登録し、登録の準備が整った登録テンプレート形式の標準問題詳細エントリ登録の例として機能します。
Key value:
-8
Name:
unprocessed-coap-option
CDDL type:
one-or-more<uint>, where
one-or-more<T> = T / [ 2* T ]
Brief description:
Option number(s) of CoAP option(s) that were not understood
Specification reference:
Section 3.1.1 of RFC 9290
The specification of the Standard Problem Detail entry referenced by the above registration template follows:
上記の登録テンプレートで参照される標準問題の詳細エントリの仕様は次のとおりです。
The Standard Problem Detail entry unprocessed-coap-option provides the option number or numbers of any CoAP options present in the request that could not be processed by the server.
標準の問題の詳細エントリ未処理のコープオプションは、サーバーが処理できないリクエストに存在するCOAPオプションのオプション番号または番号を提供します。
This may be a critical option that the server is unaware of, or an option the server is aware of but could not process (and chose not to, or was not allowed to, ignore it).
これは、サーバーが気付いていない重要なオプションである可能性があるか、サーバーが認識しているが、処理できなかったが、それを無視することを選択しなかった、または許可されていないオプションである可能性があります。
The Concise Problem Details data item including this Standard Problem Detail Entry can be used in fulfillment of the "SHOULD" requirement in Section 5.4.1 of [RFC7252].
この標準問題の詳細データ項目は、[RFC7252]のセクション5.4.1の「必要」要件を満たすために使用できます。
Several option numbers may be given in a list (in no particular order), without any guarantee that the list is a complete representation of all the problems in the request (as the server might have stopped processing already at one of the problematic options). If an option with the given number was repeated, there is no indication which of the values caused the error.
リストがリクエスト内のすべての問題を完全に表現することを保証することなく、いくつかのオプション番号がリストに表示される場合があります（サーバーは問題のあるオプションの1つですでに処理を停止している可能性があるため）。指定された数値を持つオプションが繰り返された場合、どの値がエラーを引き起こしたかを示すものはありません。
Clients need to expect to see options in the list that they did not send in the request; this can happen if the request traversed a proxy that added the option but did not act on the problem-details response being returned by the origin server.
クライアントは、リクエストを送信しなかったオプションをリスト内に表示することを期待する必要があります。これは、リクエストがオプションを追加したが、Origin Serverによって返されている問題からの応答に作用しなかったプロキシを通過した場合に発生する可能性があります。
For a few special values of unprocessed CoAP options (such as Accept or Proxy-Uri), note that there are special response codes (4.06 Not Acceptable, 5.05 Proxying Not Supported, respectively) to be sent instead of 4.02 Bad Option.
未処理のCOAPオプションのいくつかの特別な値（AcceptまたはProxy-uriなど）については、4.02の悪いオプションではなく送信される特別な応答コード（それぞれ4.06、それぞれ5.05プロキシ）があることに注意してください。
Applications may extend the Concise Problem Details data item with additional entries to convey additional, application-specific information.
アプリケーションは、追加のアプリケーション固有の情報を伝えるための追加のエントリを使用して、簡潔な問題の詳細データ項目を拡張する場合があります。
Such new entries are allocated in the custom-problem-detail-entries slot and carry a nested map specific to that application. The map key can be either an (absolute!) URI (under control of the entity defining this extension) or an unsigned integer. Only the latter needs to be registered (Section 6.2).
このような新しいエントリは、カスタムプロームデテールエントリスロットに割り当てられ、そのアプリケーションに固有のネストされたマップを運びます。マップキーは、（絶対！）URI（この拡張機能を定義するエンティティの制御下）または署名されていない整数のいずれかです。後者のみを登録する必要があります（セクション6.2）。
Within the nested map, any number of attributes can be given for a single extension. The semantics of each custom attribute MUST be described in the documentation for the extension; for extensions that are registered (i.e., are identified by an unsigned int), that documentation goes along with the registration.
ネストされたマップ内では、単一の拡張子に対して任意の数の属性を指定できます。各カスタム属性のセマンティクスは、拡張機能のドキュメントで説明する必要があります。登録されている拡張機能の場合（つまり、署名されていないINTによって識別されます）、そのドキュメントは登録に伴います。
The unsigned integer form allows a more compact representation. In exchange, authors are expected to comply with the required registration and documentation process. In comparison, the URI form is less space efficient but requires no registration. Therefore, it is useful for experimenting during the development cycle and for applications deployed in environments where producers and consumers of Concise Problem Details are more tightly integrated. (Thus, the URI form covers the potential need we might otherwise have for a "Private Use" range for the unsigned integers.)
署名されていない整数フォームにより、よりコンパクトな表現が可能になります。引き換えに、著者は必要な登録およびドキュメントプロセスに準拠することが期待されています。それに比べて、URIフォームのスペース効率は低くなりますが、登録は必要ありません。したがって、開発サイクル中の実験や、簡潔な問題の詳細を持つ生産者と消費者がより密接に統合される環境に展開されるアプリケーションに役立ちます。（したがって、URIフォームは、署名されていない整数の「プライベート使用」範囲に対する潜在的なニーズをカバーしています。）
Note that the URI given for the extension is for identification purposes only and, even if dereferenceable in principle, it MUST NOT be dereferenced in the normal course of handling problem details (i.e., outside diagnostic or debugging procedures involving humans).
拡張のために与えられたURIは識別目的のみであり、原則として控除可能であっても、問題の詳細を通常の処理コース（つまり、人間が関与する外部診断またはデバッグ手順）で提示されてはならないことに注意してください。
Figure 3 shows an example (in CBOR diagnostic notation) of a custom extension using a (made-up) URI as the custom-problem-detail-entries key.
図3は、カスタムプロームデテールエントリキーとして（MADGUP）URIを使用したカスタム拡張機能の例（CBOR診断表記法）を示しています。
{
/ title / -1: "title of the error",
/ detail / -2: "detailed information about the error",
/ instance / -3: "coaps://pd.example/FA317434",
/ response-code / -4: 128, / 4.00 /
"tag:3gpp.org,2022-03:TS29112": {
/ cause / 0: "machine-readable error cause",
/ invalidParams / 1: [
[
/ param / "first parameter name",
/ reason / "must be a positive integer"
],
[
/ param / "second parameter name"
]
],
/ supportedFeatures / 2: "d34db33f"
}
}
Figure 3: Example Extension with URI Key
図3：URIキーを使用した例の拡張例
Obviously, a Standards Development Organization (SDO) like 3GPP can also easily register such a Custom Problem Detail entry to receive a more efficient unsigned integer key; Figure 4 shows how the same example would look using a (made-up) registered unsigned int as the custom-problem-detail-entries key:
明らかに、3GPPのような標準開発組織（SDO）は、このようなカスタム問題の詳細エントリを簡単に登録して、より効率的な署名のない整数キーを受け取ることもできます。図4は、カスタムプロームデテールエントリとして登録されていない（メイクアップ）登録されているunsigned intを使用して同じ例がどのように見えるかを示しています。
{
/ title / -1: "title of the error",
/ detail / -2: "detailed information about the error",
/ instance / -3: "coaps://pd.example/FA317434",
/ response-code / -4: 128, / 4.00 /
/4711 is made-up example key that is not actually registered:/
4711: {
/ cause / 0: "machine-readable error cause",
/ invalidParams / 1: [
[
/ param / "first parameter name",
/ reason / "must be a positive integer"
],
[
/ param / "second parameter name"
]
],
/ supportedFeatures / 2: "d34db33f"
}
}
Figure 4: Example Extension with Unsigned Int (Registered) Key
図4：署名されていないINT（登録）キーを使用した拡張機能の例
In summary, the keys for the maps used inside Custom Problem Detail entries are defined specifically for use with the identifier of that Custom Problem Detail entry, the documentation of which defines these internal entries, typically chosen to address a given application domain.
要約すると、カスタム問題の詳細エントリ内で使用されるマップのキーは、そのカスタム問題の詳細エントリの識別子で使用するために特別に定義されています。このドキュメントは、通常、特定のアプリケーションドメインに対処するために選択されるこれらの内部エントリを定義します。
When there is a need to evolve a Custom Problem Detail entry definition, the "ignore-unknown rule" discussed in Section 3 provides an easy way to include additional information. The assumption is that this is done in a backward- and forward-compatible way. Sometimes, Custom Problem Detail entries may need to evolve in a way where forward compatibility by applying the "ignore-unknown rule" would not be appropriate: for example, when adding a "must-understand" member, which can only be ignored at the peril of misunderstanding the Concise Problem Details data item ("false interoperability"). In this case, a new Custom Problem Detail key can simply be registered for this case, keeping the old key backward and forward compatible.
カスタム問題の詳細エントリ定義を進化させる必要がある場合、セクション3で説明されている「無知でないルール」は、追加情報を簡単に含める方法を提供します。仮定は、これが後方および前方互換の方法で行われるということです。カスタムの問題の詳細エントリは、「無視されていないルール」を適用することでフォワードの互換性が適切ではない方法で進化する必要がある場合があります。たとえば、「必須」メンバーを追加する場合、簡潔な問題の詳細データ項目（「虚偽の相互運用性」）の誤解の危険。この場合、新しいカスタム問題の詳細キーをこのケースに登録するだけで、古いキーを前後に互換性のあるものに保ちます。
Problem details may unintentionally disclose information. This can lead to both privacy and security problems. See Section 5 for more details that apply to both domains; particular attention needs to be given to unintentionally disclosing Personally Identifiable Information (PII).
問題の詳細は、意図せずに情報を開示する可能性があります。これにより、プライバシーとセキュリティの両方の問題につながる可能性があります。両方のドメインに適用される詳細については、セクション5を参照してください。意図せずに個人を特定できる情報（PII）を開示することに特に注意を払う必要があります。
Concise Problem Details can contain URIs that are not intended to be dereferenced (Section 3.2, Paragraph 5). One reason is that dereferencing these can lead to information disclosure (tracking). Information disclosure can also be caused by URIs in problem details that _are_ intended for dereferencing, e.g., the "instance" URI. Implementations need to consider which component of a client should perform the dereferencing and which servers are trusted with serving them. In any case, the security considerations of Section 7 of RFC 3986 [STD66] apply.
簡潔な問題の詳細には、参照されることを意図していないURIが含まれている場合があります（セクション3.2、パラグラフ5）。理由の1つは、これらを避難することで情報の開示（追跡）につながる可能性があることです。情報の開示は、_are_が「インスタンス」uriなどの_are_が控除を意図した問題の詳細のURIによって引き起こされる可能性があります。実装では、クライアントのどのコンポーネントが繰り返されるべきか、どのサーバーがそれらを提供することを信頼しているかを考慮する必要があります。いずれにせよ、RFC 3986 [STD66]のセクション7のセキュリティ上の考慮事項が適用されます。
The security and privacy considerations outlined in Section 5 of [RFC7807] apply in full. While these are phrased in terms of security considerations for new RFC 7807 problem types, they equally apply to the problem detail entry definitions used here (Section 3). In summary, both when defining new detail entries and when actually using them to generate a Concise Problem Details data item, care needs to be taken that they do not leak sensitive information. Entities storing or forwarding Concise Problem Details data items need to consider whether this leads to information being transferred out of the context within which access to sensitive information was acceptable. See also Section 3, Paragraph 6 (the last paragraph of the introduction to that section). Privacy-sensitive information in the problem details SHOULD NOT be obscured in ways that might lead to misclassification as non-sensitive (e.g., by base64-encoding).
[RFC7807]のセクション5で概説されているセキュリティとプライバシーの考慮事項は、完全に適用されます。これらは、新しいRFC 7807の問題タイプのセキュリティに関する考慮事項の観点から表現されていますが、ここで使用される問題の詳細エントリ定義に等しく適用されます（セクション3）。要約すると、新しい詳細エントリを定義するときと実際にそれらを使用して簡潔な問題の詳細データ項目を生成する場合、機密情報が漏れないように注意する必要があります。簡潔な問題の詳細の保存または転送のエンティティは、データ項目が機密情報へのアクセスが許容できるコンテキストから転送される情報につながるかどうかを考慮する必要があります。セクション3、パラグラフ6（そのセクションの紹介の最後の段落）も参照してください。問題の詳細のプライバシーに敏感な情報は、非感受性としての誤分類につながる可能性のある方法で不明瞭にされるべきではありません（例：Base64-Encoding）。
This specification defines a new subregistry titled "Standard Problem Detail Keys" in the "Constrained RESTful Environments (CoRE) Parameters" registry [IANA.core-parameters], with "Specification Required" as the Registration Procedure (Section 4.6 of [RFC8126]).
この仕様では、「制約付きのRESTFUL環境（CORE）パラメーター」レジストリ[IANA.CORE-PARAMETERS]の「標準問題詳細キー」というタイトルの新しいサブレジストリを定義します。。
Each entry in the registry must include:
レジストリ内の各エントリには以下を含める必要があります。
Key Value: a negative integer to be used as the value of the key
キー値：キーの値として使用される負の整数
Name: a name that could be used in implementations for the key
名前：キーの実装で使用できる名前
CDDL Type: type of the data associated with the key in CDDL notation
CDDLタイプ：CDDL表記のキーに関連付けられたデータのタイプ
Brief Description: a brief description
簡単な説明：簡単な説明
Reference: a reference document
参照：参照ドキュメント
Change Controller: (see Section 2.3 of [RFC8126])
Change Controller ：（ [RFC8126]のセクション2.3を参照）
The designated expert is requested to assign the shortest key values (1+0 and 1+1 encoding) to registrations that are likely to enjoy wide use and can benefit from short encodings.
指定された専門家は、幅広い使用を享受する可能性が高く、短いエンコーディングの恩恵を受ける可能性のある登録に最短のキー値（1 0および1 1エンコード）を割り当てるように要求されます。
To be immediately useful in CDDL and programming-language contexts, a name consists of a lowercase ASCII letter (a-z) and zero or more additional ASCII characters that are either lowercase letters, digits, or a hyphen-minus, i.e., it matches [a-z][-a-z0-9]*. As with the key values, names need to be unique.
CDDLおよびプログラミング言語のコンテキストですぐに役立つために、名前は小文字のASCII文字（A-Z）とゼロ以上の追加のASCII文字で構成されています。] [-A-Z0-9]*。重要な値と同様に、名前は一意である必要があります。
The specification in the reference document needs to provide a description of the Standard Problem Detail entry, replicating the CDDL description in "CDDL Type", and describing the semantics of the presence of this entry and the semantics of the value given with it.
参照ドキュメントの仕様では、標準の問題の詳細エントリの説明を提供し、「CDDLタイプ」のCDDL説明を複製し、このエントリの存在とそれに与えられた値のセマンティクスのセマンティクスを説明する必要があります。
Initial entries in this subregistry are as follows:
このサブレジストリの初期エントリは次のとおりです。
+=====+============+===============+===========+=========+==========+
|Key |Name |CDDL Type |Brief |Reference|Change |
|Value| | |Description| |Controller|
+=====+============+===============+===========+=========+==========+
|-1 |title |text / tag38 |Short, |RFC 9290 |IETF |
| | | |human- | | |
| | | |readable | | |
| | | |summary of | | |
| | | |the problem| | |
| | | |shape | | |
+-----+------------+---------------+-----------+---------+----------+
|-2 |detail |text / tag38 |Human- |RFC 9290 |IETF |
| | | |readable | | |
| | | |explanation| | |
| | | |specific to| | |
| | | |this | | |
| | | |occurrence | | |
| | | |of the | | |
| | | |problem | | |
+-----+------------+---------------+-----------+---------+----------+
|-3 |instance |~uri |URI |RFC 9290 |IETF |
| | | |reference | | |
| | | |identifying| | |
| | | |specific | | |
| | | |occurrence | | |
| | | |of the | | |
| | | |problem | | |
+-----+------------+---------------+-----------+---------+----------+
|-4 |response- |uint .size 1 |CoAP |RFC 9290 |IETF |
| |code | |response | | |
| | | |code | | |
+-----+------------+---------------+-----------+---------+----------+
|-5 |base-uri |~uri |Base URI |RFC 9290 |IETF |
+-----+------------+---------------+-----------+---------+----------+
|-6 |base-lang |tag38-ltag |Base |RFC 9290 |IETF |
| | | |language | | |
| | | |tag (see | | |
| | | |Appendix A)| | |
+-----+------------+---------------+-----------+---------+----------+
|-7 |base-rtl |tag38-direction|Base |RFC 9290 |IETF |
| | | |writing | | |
| | | |direction | | |
| | | |(see | | |
| | | |Appendix A)| | |
+-----+------------+---------------+-----------+---------+----------+
|-8 |unprocessed-|one-or- |Option |RFC 9290,|IETF |
| |coap-option |more<uint> |number(s) |Section | |
| | | |of CoAP |3.1.1 | |
| | | |option(s) | | |
| | | |that were | | |
| | | |not | | |
| | | |understood | | |
+-----+------------+---------------+-----------+---------+----------+
Table 1: Initial Entries in the Standard Problem Detail Keys Registry
表1：標準問題の詳細キーレジストリの初期エントリ
This specification defines a new subregistry titled "Custom Problem Detail Keys" in the "Constrained RESTful Environments (CoRE) Parameters" registry [IANA.core-parameters], with as "Expert Review" as the Registration Procedure (Section 4.5 of [RFC8126]).
この仕様では、「制約付きのRESTFUL環境（CORE）パラメーター」レジストリ[IANA.CORE-PARAMETERS]の「カスタム問題詳細キー」というタイトルの新しいサブレジストリを定義します。）。
The designated expert is instructed to attempt making the registration experience as close to First Come First Served as reasonably achievable, but checking that the reference document does provide a description as set out below. (This requirement is a relaxed version of "Specification Required" as defined in Section 4.6 of [RFC8126].)
指定された専門家は、登録エクスペリエンスを最初に最初に達成できるようにすることを試みるように指示されますが、参照ドキュメントが以下に記載されているように説明を提供することを確認します。（この要件は、[RFC8126]のセクション4.6で定義されている「必要な仕様」のリラックスバージョンです。）
Each entry in the registry must include:
レジストリ内の各エントリには以下を含める必要があります。
Key Value: an unsigned integer to be used as the value of the key
キー値：キーの値として使用される署名のない整数
Name: a name that could be used in implementations for the key
名前：キーの実装で使用できる名前
Brief Description: a brief description
簡単な説明：簡単な説明
Reference: a reference document that provides a description of the map, including a CDDL description, that describes all inside keys and values
参照：CDDLの説明を含むマップの説明を提供する参照ドキュメントでは、すべての内部キーと値を説明します
Change Controller (see Section 2.3 of [RFC8126])
コントローラーを変更します（[RFC8126]のセクション2.3を参照）
The designated expert is requested to assign the shortest key values (1+0 and 1+1 encoding) to registrations that are likely to enjoy wide use and can benefit from short encodings.
指定された専門家は、幅広い使用を享受する可能性が高く、短いエンコーディングの恩恵を受ける可能性のある登録に最短のキー値（1 0および1 1エンコード）を割り当てるように要求されます。
To be immediately useful in CDDL and programming-language contexts, a name consists of a lowercase ASCII letter (a-z) and zero or more additional ASCII characters that are either lowercase letters, digits, or a hyphen-minus, i.e., it matches [a-z][-a-z0-9]*. As with the key values, names need to be unique.
CDDLおよびプログラミング言語のコンテキストですぐに役立つために、名前は小文字のASCII文字（A-Z）とゼロ以上の追加のASCII文字で構成されています。] [-A-Z0-9]*。重要な値と同様に、名前は一意である必要があります。
Initial entries in this subregistry are as follows:
このサブレジストリの初期エントリは次のとおりです。
+=======+=============+====================+===========+============+
| Key | Name | Brief | Reference | Change |
| Value | | Description | | Controller |
+=======+=============+====================+===========+============+
| 7807 | tunnel-7807 | Carry RFC 7807 | RFC 9290, | IETF |
| | | problem details | Appendix | |
| | | in a Concise | B | |
| | | Problem Details | | |
| | | data item | | |
+-------+-------------+--------------------+-----------+------------+
Table 2: Initial Entries in the Custom Problem Detail Key Registry
表2：カスタム問題の詳細キーレジストリの初期エントリ
IANA has added the following media type to the "Media Types" registry [IANA.media-types].
IANAは、次のメディアタイプを「メディアタイプ」レジストリ[iana.media-types]に追加しました。
+============================+============================+=========+
|Name |Template |Reference|
+============================+============================+=========+
|concise-problem-details+cbor|application/concise-problem-|RFC 9290,|
| |details+cbor |Section |
| | |6.3 |
+----------------------------+----------------------------+---------+
Table 3: New Media Type 'application/concise-problem-details+cbor'
Type name: application
タイプ名：アプリケーション
Subtype name: concise-problem-details+cbor
サブタイプ名：Scise-Problem-Details Cbor
Required parameters: N/A
必要なパラメーター：n/a
Optional parameters: N/A
オプションのパラメーター：n/a
Encoding considerations: binary (CBOR data item)
考慮事項のエンコード：バイナリ（CBORデータ項目）
Security considerations: Section 5 of RFC 9290
セキュリティ上の考慮事項：RFC 9290のセクション5
Interoperability considerations: none
相互運用性の考慮事項：なし
Published specification: Section 6.3 of RFC 9290
公開された仕様：RFC 9290のセクション6.3
Applications that use this media type: Clients and servers in the Internet of Things
このメディアタイプを使用するアプリケーション：モノのインターネットのクライアントとサーバー
Fragment identifier considerations: The syntax and semantics of fragment identifiers is as specified for "application/cbor". (At publication of RFC 9290, there is no fragment identification syntax defined for "application/cbor".)
フラグメント識別子の考慮事項：フラグメント識別子の構文とセマンティクスは、「アプリケーション/CBOR」で指定されているとおりです。（RFC 9290の公開では、「アプリケーション/CBOR」に対して定義されたフラグメント識別構文はありません。）
Additional information:
追加情報：
Deprecated alias names for this type: N/A
Magic number(s): N/A
File extension(s): N/A
Macintosh file type code(s): N/A
Person & email address to contact for further information: CoRE WG mailing list (core@ietf.org) or IETF Applications and Real-Time Area (art@ietf.org)
詳細については、連絡先への個人およびメールアドレス：コアWGメーリングリスト（core@ietf.org）またはIETFアプリケーションとリアルタイムエリア（art@ietf.org）
Intended usage: COMMON
意図された使用法：共通
Restrictions on usage: none
使用に関する制限：なし
Author/Change controller: IETF
著者/変更コントローラー：IETF
Provisional registration: no
暫定登録：いいえ
IANA has registered a Content-Format number in the "CoAP Content-Formats" subregistry, within the "Constrained RESTful Environments (CoRE) Parameters" registry [IANA.core-parameters], as follows:
IANAは、「COAPコンテンツフォーマット」サブレジストリにコンテンツフォーマット番号を登録しています。「制約されたRESTFUL環境（CORE）パラメーター」レジストリ[IANA.CORE-PARAMETERS]、次のとおりです。
+==============================+==========+=====+===========+
| Media Type | Encoding | ID | Reference |
+==============================+==========+=====+===========+
| application/concise-problem- | - | 257 | RFC 9290 |
| details+cbor | | | |
+------------------------------+----------+-----+-----------+
Table 4: Content-Format Registration
表4：コンテンツフォーマット登録
In the registry "CBOR Tags" [IANA.cbor-tags], IANA has registered CBOR tag 38. IANA has updated the reference for CBOR tag 38 to point to RFC 9290, Appendix A.
レジストリ「CBORタグ」[IANA.CBOR-TAGS]で、IANAはCborタグ38を登録しました。IANAはCBORタグ38のリファレンスを更新して、RFC 9290、付録Aを指しています。
[IANA.cbor-tags] IANA, "Concise Binary Object Representation (CBOR) Tags", <https://www.iana.org/assignments/cbor-tags>.
[iana.cbor-tags] iana、 "Concise binary Object Lespressation（CBOR）Tags"、<https://www.iana.org/assignments/cbor-tags>。
[IANA.core-parameters] IANA, "Constrained RESTful Environments (CoRE) Parameters", <https://www.iana.org/assignments/core-parameters>.
[iana.core-parameters] iana、「制約付きの安らかな環境（コア）パラメーター」、<https://www.iana.org/assignments/core-parameters>。
[IANA.media-types] IANA, "Provisional Standard Media Type Registry", <https://www.iana.org/assignments/provisional-standard-media-types>.
[iana.media-types] iana、「暫定標準メディアタイプレジストリ」、<https://www.iana.org/assignments/provisional-standard-media-types>。
[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>。
[RFC4647] Phillips, A., Ed. and M. Davis, Ed., "Matching of Language Tags", BCP 47, RFC 4647, DOI 10.17487/RFC4647, September 2006, <https://www.rfc-editor.org/info/rfc4647>.
[RFC4647]フィリップス、A。、編およびM.デイビス編、「言語タグのマッチング」、BCP 47、RFC 4647、DOI 10.17487/RFC4647、2006年9月、<https://www.rfc-editor.org/info/rfc4647>。
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC5646]フィリップス、A。、編およびM.デイビス編、「言語を識別するためのタグ」、BCP 47、RFC 5646、DOI 10.17487/RFC5646、2009年9月、<https://www.rfc-editor.org/info/rfc5646>。
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, <https://www.rfc-editor.org/info/rfc7252>.
[RFC7252] Shelby、Z.、Hartke、K。、およびC. Bormann、「制約付きアプリケーションプロトコル（COAP）」、RFC 7252、DOI 10.17487/RFC7252、2014年6月、<https：//www.rfc-editor。org/info/rfc7252>。
[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>
[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] Cotton、M.、Leiba、B。、およびT. Narten、「RFCSでIANA考慮事項セクションを書くためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487/RFC8126、2017年6月、<https：// wwwwwwwwwwwwwwwwwwwwwww.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>。
[RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, DOI 10.17487/RFC8610, June 2019, <https://www.rfc-editor.org/info/rfc8610>.
[RFC8610] Birkholz、H.、Vigano、C。、およびC. Bormann、「Scise Data Definition Language（CDDL）：簡潔なバイナリオブジェクト表現（CBOR）およびJSONデータ構造を表現する表記規則」、RFC 8610、DOI 10.17487/RFC8610、2019年6月、<https://www.rfc-editor.org/info/rfc8610>。
[RFC9165] Bormann, C., "Additional Control Operators for the Concise Data Definition Language (CDDL)", RFC 9165, DOI 10.17487/RFC9165, December 2021, <https://www.rfc-editor.org/info/rfc9165>.
[RFC9165] Bormann、C。、「簡潔なデータ定義言語（CDDL）の追加制御演算子」、RFC 9165、DOI 10.17487/RFC9165、2021年12月、<https://www.rfc-editor.org/info/RFC916555165>。
[STD66] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[STD66] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、2005年1月。
<https://www.rfc-editor.org/info/std66>
[STD94] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, December 2020.
[STD94] Bormann、C。およびP. Hoffman、「Concise Binary Object Lespressation（CBOR）」、STD 94、RFC 8949、2020年12月。
<https://www.rfc-editor.org/info/std94>
[HTTPAPI] Nottingham, M., Wilde, E., and S. Dalal, "Problem Details for HTTP APIs", Work in Progress, Internet-Draft, draft-ietf-httpapi-rfc7807bis-04, 5 September 2022, <https://datatracker.ietf.org/doc/html/draft-ietf-httpapi-rfc7807bis-04>.
[httpapi]ノッティンガム、M。、ワイルド、E。、およびS.ダラル、「HTTP APIの問題の詳細」、進行中の作業、インターネットドラフト、ドラフト-ITTPAPI-RFC7807BIS-04、2022年9月5日、<https：//datatracker.ietf.org/doc/html/draft-ietf-httpapi-rfc7807bis-04>。
[RDF] Cyganiak, R., Wood, D., and M. Lanthaler, "RDF 1.1 Concepts and Abstract Syntax", W3C Recommendation, 25 February 2014, <http://www.w3.org/TR/2014/REC-rdf11-concepts-20140225/>.
[RDF] Cyganiak、R.、Wood、D。、およびM. Lanthaler、「RDF 1.1概念と抽象的構文」、W3C推奨、2014年2月25日、<http://www.w3.org/tr/2014/Rec-RDF11CONCEPTS-20140225/>。
[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。、「Base16、Base32、およびBase64 Data Encodings」、RFC 4648、DOI 10.17487/RFC4648、2006年10月、<https://www.rfc-editor.org/info/rfc4648>
[RFC6082] Whistler, K., Adams, G., Duerst, M., Presuhn, R., Ed., and J. Klensin, "Deprecating Unicode Language Tag Characters: RFC 2482 is Historic", RFC 6082, DOI 10.17487/RFC6082, November 2010, <https://www.rfc-editor.org/info/rfc6082>.
[RFC6082] Whistler、K.、Adams、G.、Duerst、M.、Presuhn、R.、ed。、およびJ. Klensin、「Unicode Languageタグ文字を非難する：RFC 2482は歴史的」、RFC 6082、DOI 10.17487/RFC6082、2010年11月、<https://www.rfc-editor.org/info/rfc6082>。
[Unicode-14.0.0] The Unicode Consortium, "The Unicode Standard, Version 14.0.0", Mountain View: The Unicode Consortium, ISBN 978-1-936213-29-0, September 2021, <https://www.unicode.org/versions/Unicode14.0.0/>.
[Unicode-14.0.0] Unicodeコンソーシアム、「Unicode Standard、バージョン14.0.0」、マウンテンビュー：Unicodeコンソーシアム、ISBN 978-1-936213-29-0、2021年9月、<https：// www。unicode.org/versions/unicode14.0.0/>。
[Unicode-14.0.0-bidi] The Unicode Consortium, "Unicode Standard Annex #9 --- Unicode Bidirectional Algorithm", 27 August 2021, <https://www.unicode.org/reports/ tr9/#Markup_And_Formatting>.
[Unicode-14.0.0-Bidi] Unicodeコンソーシアム、「Unicode Standard Annex＃9 --- Unicode Biderectional Algorithm」、2021年8月27日、<https://www.unicode.org/reports/ TR9/＃Markup_and_formatting>。
This appendix serves as the archival documentation for CBOR tag 38, a tag for serializing language-tagged text strings in CBOR. The text of this appendix is adapted from the specification text supplied for its initial registration. It has been extended to allow supplementing the language tag by a direction indication.
この付録は、CBORタグ38のアーカイブドキュメントとして機能します。これは、CBORの言語タグ付きテキスト文字列のシリアル化のタグです。この付録のテキストは、最初の登録のために提供された仕様テキストから採用されています。指示の表示によって言語タグを補充できるように拡張されています。
As with any IANA-registered item, a specification that further updates this registration needs to update the reference column of the IANA registry (see Section 6.5). Future specifications may update this appendix, other parts of this document, or both. (When updating this appendix, keep in mind that applications beyond Concise Problem Details data items may adopt the tag defined here.) Users of this tag are advised to consult the registry to obtain the most recent update for this appendix.
IANAが登録したアイテムと同様に、この登録をさらに更新する仕様は、IANAレジストリの参照列を更新する必要があります（セクション6.5を参照）。将来の仕様は、この付録、このドキュメントの他の部分、またはその両方を更新する場合があります。（この付録を更新する場合、簡潔な問題の詳細を超えたアプリケーションは、ここに定義されたタグを採用する可能性があることに留意してください。）このタグのユーザーは、この付録の最新の更新を取得するためにレジストリに相談することをお勧めします。
In some cases, it is useful to specify the natural language of a text string. This specification defines a tag that does just that. One technology that supports language-tagged strings is the Resource Description Framework (RDF) [RDF].
場合によっては、テキスト文字列の自然言語を指定すると便利です。この仕様は、まさにそれを行うタグを定義します。言語タグ付き文字列をサポートするテクノロジーの1つは、リソース説明フレームワーク（RDF）[RDF]です。
A language-tagged text string in CBOR has the tag 38 and consists of an array with a length of 2 or 3.
CBORの言語タグ付きテキスト文字列にはタグ38があり、長さ2または3の配列で構成されています。
The first element is a well-formed language tag described in BCP 47 ([RFC5646] and [RFC4647]), represented as a UTF-8 text string (major type 3).
最初の要素は、BCP 47（[RFC5646]および[RFC4647]）で説明されている適切に形成された言語タグで、UTF-8テキスト文字列（メジャータイプ3）として表されます。
The second element is an arbitrary UTF-8 text string (major type 3). Both the language tag and the arbitrary string can optionally be annotated with CBOR tags; this is not shown in the CDDL below.
2番目の要素は、任意のUTF-8テキスト文字列（メジャータイプ3）です。言語タグと任意の文字列の両方は、オプションでCBORタグで注釈を付けることができます。これは以下のCDDLには示されていません。
The optional third element, if present, represents a ternary value that indicates a direction, as follows:
存在する場合のオプションの3番目の要素は、次のように方向を示す三元値を表します。
* false: left-to-right direction ("ltr"). The text is expected to be displayed with left-to-right base direction if standalone and isolated with left-to-right direction (as if enclosed in LRI ... PDI or equivalent, see [Unicode-14.0.0-bidi]) in the context of a longer string or text.
* false：左から右への方向（ "LTR"）。テキストは、スタンドアロンで左から右の方向で表示され、左から右への方向で分離されている場合（まるでLRI ... PDIまたは同等のものであるかのように、[Unicode-14.0.0-Bidi]を参照）長い文字列またはテキストのコンテキストで。
* true: right-to-left direction ("rtl"). The text is expected to be displayed with right-to-left base direction if standalone and isolated with right-to-left direction (as if enclosed in RLI ... PDI or equivalent, see [Unicode-14.0.0-bidi]) in the context of a longer string or text.
* True：右から左への方向（ "rtl"）。テキストは、スタンドアロンで右から左への方向で分離されている場合、右から左のベース方向で表示されると予想されます（まるでrli ... pdiまたは同等のもので囲まれているかのように、[unicode-14.0.0-bidi]を参照）長い文字列またはテキストのコンテキストで。
* null: indicates that no indication is made about the direction ("auto"), enabling an internationalization library to make an auto-detection decision such as treating the string as if enclosed in FSI ... PDI or equivalent, see [Unicode-14.0.0-bidi].
* null：方向（ "auto"）について兆候がないことを示します。これは、国際化ライブラリがfsi ... pdiまたは等価物に囲まれているかのように文字列を扱うなどの自動検出決定を行うことを可能にします。[unicode-14.0を参照してください.0-bidi]。
If the third element is absent, directionality context may be applied (e.g., base-directionality information for an entire CBOR message or part thereof). If there is no directionality context applied, the default interpretation is the same as for null ("auto").
3番目の要素がない場合、方向性コンテキストを適用することができます（たとえば、CBORメッセージ全体またはその一部の基本方向性情報）。適用される方向性コンテキストがない場合、デフォルトの解釈はnull（ "auto"）の場合と同じです。
In CDDL:
CDDLで：
tag38 = #6.38([tag38-ltag, text, ?tag38-direction])
tag38-ltag = text .regexp "[a-zA-Z]{1,8}(-[a-zA-Z0-9]{1,8})*"
tag38-direction = &(ltr: false, rtl: true, auto: null)
NOTE: Language tags of any combination of case are allowed. But Section 2.1.1 of [RFC5646], part of BCP 47, recommends a case combination for language tags that encoders that support tag 38 may wish to follow when generating language tags.
注：ケースの任意の組み合わせの言語タグは許可されています。ただし、BCP 47の一部である[RFC5646]のセクション2.1.1は、タグ38をサポートするエンコーダーが言語タグを生成するときに従うことを望むエンコーダーのケースの組み合わせを推奨しています。
Data items with tag 38 that do not meet the criteria above are not valid (see Section 5.3.2 of RFC 8949 [STD94]).
上記の基準を満たさないタグ38のデータ項目は無効です（RFC 8949 [STD94]のセクション5.3.2を参照）。
NOTE: The Unicode Standard [Unicode-14.0.0] includes a set of characters designed for tagging text (including language tagging) in the range U+E0000 to U+E007F. Although many applications, including RDF, do not disallow these characters in text strings, the Unicode Consortium has deprecated these characters and recommends annotating language via a higher-level protocol instead. See the section "Deprecated Tag Characters" in Section 23.9 of [Unicode-14.0.0] as well as [RFC6082].
注：Unicode標準[Unicode-14.0.0]には、範囲U E0000からU E007Fのタグ付けテキスト（言語タグ付けを含む）用に設計された文字セットが含まれています。RDFを含む多くのアプリケーションは、これらの文字をテキスト文字列に禁止しないでください。UnicodeConsortiumはこれらのキャラクターを非難し、代わりに高レベルのプロトコルを介して言語を注釈することを推奨しています。[unicode-14.0.0]のセクション23.9のセクション「削除されたタグ文字」と[RFC6082]を参照してください。
NOTE: while this document references a version of Unicode that was recent at the time of writing, the statements made based on this version are expected to remain valid for future versions.
注：このドキュメントは、執筆時点で最近だったUnicodeのバージョンを参照していますが、このバージョンに基づいて作成されたステートメントは、将来のバージョンでは有効であると予想されます。
Examples in this section are given in CBOR diagnostic notation first and then as a pretty-printed hexadecimal representation of the encoded item.
このセクションの例は、最初にCBOR診断表記に記載されており、次にエンコードされたアイテムのかなり印刷された16進表現として示されています。
The following example shows how the English-language string "Hello" is represented.
次の例は、英語の文字列「Hello」がどのように表されているかを示しています。
38(["en", "Hello"])
38（["en"、 "hello"]）
D8 26 # tag(38)
82 # array(2)
62 # text(2)
656E # "en"
65 # text(5)
48656C6C6F # "Hello"
The following example shows how the French-language string "Bonjour" is represented.
次の例は、フランス語の文字列「Bonjour」がどのように表されているかを示しています。
38(["fr", "Bonjour"])
38（["fr"、 "bonjour"]）
D8 26 # tag(38)
82 # array(2)
62 # text(2)
6672 # "fr"
67 # text(7)
426F6E6A6F7572 # "Bonjour"
The following example uses right-to-left (RTL) script, which in the context of this specification may be rendered differently by different document presentation environments. The descriptive text may be more reliable to follow than the necessarily device- and application-specific rendering. The example shows how the Hebrew-language string
次の例では、右から左（RTL）スクリプトを使用します。これは、この仕様のコンテキストでは、ドキュメントのプレゼンテーション環境によって異なってレンダリングされる場合があります。記述テキストは、必然的にデバイスおよびアプリケーション固有のレンダリングよりも、従うことで信頼性が高い場合があります。この例は、ヘブライ語の文字列の文字列を示しています
שלום
שלשל
is represented, where in direction of reading, the sequence of characters is: "ש" (HEBREW LETTER SHIN, U+05E9), "ל" (HEBREW LETTER LAMED, U+05DC), "ו" (HEBREW LETTER VAV, U+05D5), "ם" (HEBREW LETTER FINAL MEM, U+05DD). Note the rtl direction expressed by setting the third element in the array to "true".
表現されている場所では、読み取りの方向では、文字のシーケンスは「ש」（ヘブライ文字Shin、u 05e9）、 "ל"（ヘブライ文字leall、u 05dc）、 "ו"（ヘブライ文字vav、u 05d5）です。、「ם」（ヘブライ文字最終Mem、u 05dd）。配列内の3番目の要素を「true」に設定することにより表されるRTL方向に注意してください。
38(["he", "שלום", true])
38（["he"、 "שלשל"、true]）
D8 26 # tag(38)
83 # array(3)
62 # text(2)
6865 # "he"
68 # text(8)
D7A9D79CD795D79D # "שלום"
F5 # primitive(21)
On certain occasions, it will be necessary to carry ("tunnel") [RFC7807] problem details in a Concise Problem Details data item.
特定の機会には、簡潔な問題の詳細データ項目の問題の詳細を運ぶ必要があります（ "トンネル"）[RFC7807]。
This appendix defines a Custom Problem Detail entry for that purpose. This is assigned Custom Problem Detail key 7807 in Section 6.2. Its structure is:
この付録は、その目的のためのカスタム問題の詳細エントリを定義しています。これには、セクション6.2にカスタム問題詳細キー7807が割り当てられます。その構造は次のとおりです。
tunnel-7807 = {
? &(type: 0) => ~uri
? &(status: 1) => 0..999
* text => any
}
To carry an [RFC7807] problem details JSON object in a Concise Problem Details data item, first convert the JSON object to CBOR as per Section 6.2 of RFC 8949 [STD94]. Create an empty Concise Problem Details data item.
[RFC7807]を運ぶには、問題の詳細を簡潔な問題の詳細データ項目でjsonオブジェクトを詳述するには、最初にJSONオブジェクトをRFC 8949 [STD94]のセクション6.2に従ってCBORに変換します。空の簡潔な問題の詳細データ項目を作成します。
Move the values for "title", "detail", and "instance", if present, from the [RFC7807] problem details to the equivalent Standard Problem Detail entries. Create a Custom Problem Detail entry with key 7807. Move the values for "type" and "status", if present, to the equivalent keys 0 and 1 of the Custom Problem Detail entry. Move all remaining key/value pairs (additional members as per Section 3.2 of [RFC7807]) in the converted [RFC7807] problem details object to the Custom Problem Detail map unchanged.
[rfc7807]の問題の詳細から存在する場合は、「タイトル」、「詳細」、および「インスタンス」の値を同等の標準問題の詳細エントリに移動します。キー7807でカスタム問題の詳細エントリを作成します。「タイプ」と「ステータス」の値を、存在する場合は、カスタム問題の詳細エントリの同等のキー0および1に移動します。変換された[RFC7807]の問題の詳細については、すべてのすべてのキー/値ペア（[RFC7807]のセクション3.2に従って追加メンバー）を動かします。
The inverse direction, carrying Concise Problem Details in an RFC 7807 problem details JSON object requires the additional support provided by [HTTPAPI], which is planned to create the HTTP Problem Types Registry. An HTTP Problem Type can then be registered that extracts top-level items from the Concise Problem Details data item in a similar way to the conversion described above and that carries the rest of the Concise Problem Details data item in an additional member via base64url encoding without padding (Section 5 of [RFC4648]). Details can be defined in a separate document when the work on [HTTPAPI] is completed.
逆方向、RFC 7807の問題の詳細の詳細の詳細は、JSONオブジェクトに[httpapi]によって提供される追加のサポートが必要です。これは、HTTP問題タイプのレジストリを作成する予定です。その後、HTTPの問題タイプを登録して、簡潔な問題からトップレベルのアイテムを抽出して、上記の変換と同様の方法でデータ項目を詳述し、簡潔な問題の詳細データ項目をBase64Urlを介して追加のメンバーのデータ項目を保持します。パディング（[RFC4648]のセクション5）。[httpapi]の作業が完了した場合、詳細は別のドキュメントで定義できます。
Acknowledgments
謝辞
The authors would like to thank Mark Nottingham and Erik Wilde, the authors of RFC 7807; Klaus Hartke and Jaime Jiménez, the coauthors of an earlier draft version of this specification; Christian Amsüss, Marco Tiloca, Ari Keränen, and Michael Richardson for review and comments on this document. Francesca Palombini for her review (and support) as responsible AD, and Joel Jaeggli for his OPSDIR review, both of which brought significant additional considerations to this document.
著者は、RFC 7807の著者であるマーク・ノッティンガムとエリック・ワイルドに感謝したいと思います。Klaus HartkeとJaimeJiménez、この仕様の以前のドラフトバージョンの共著者。この文書に関するレビューとコメントについては、クリスチャン・アムス、マルコ・ティロカ、アリ・ケラネン、マイケル・リチャードソン。責任ある広告としてのレビュー（およびサポート）についてのFrancesca Palombini、および彼のOpsDirレビューのJoel Jaeggliは、どちらもこの文書にかなりの追加の考慮事項をもたらしました。
For Appendix A, John Cowan and Doug Ewell are also to be acknowledged. The content of an earlier draft version of this appendix was also discussed in the "apps-discuss@ietf.org" and "ltru@ietf.org" mailing lists. More recently, the authors initiated a discussion about the handling of writing direction information in conjunction with language tags. That led to discussions within the W3C Internationalization Core Working Group. The authors would like to acknowledge that cross-organization cooperation and particular contributions from John Klensin and Addison Phillips and specific text proposals by Martin Dürst.
付録Aの場合、ジョン・コーワンとダグ・イーウェルも認められます。この付録の以前のドラフトバージョンの内容は、「apps-discuss@ietf.org」および「ltru@ietf.org」メーリングリストでも説明されています。最近では、著者は、言語タグと併せて方向情報を書くことについての議論を開始しました。これにより、W3C Internationalization Core Working Group内での議論につながりました。著者は、John KlensinとAddison Phillipsからの特定の貢献とMartinDürstによる特定のテキスト提案を認めたいと考えています。
Contributors
貢献者
Peter Occil
Email: poccil14@gmail.com
URI: http://peteroupc.github.io/CBOR/
Peter defined CBOR tag 38, basis of Appendix A.
ピーターはCBORタグ38を定義しました、付録Aの基礎
Christian Amsüss Email: christian@amsuess.com
ChristianAmsüss電子メール：churist@amsuess.com
Christian contributed what became Section 3.1.1.
クリスチャンはセクション3.1.1になったものに貢献しました。
Authors' Addresses
著者のアドレス
Thomas Fossati Arm Limited Email: thomas.fossati@arm.com
Thomas Fossati Arm Limited Email：thomas.fossati@arm.com
Carsten Bormann Universität Bremen TZI Postfach 330440 D-28359 Bremen Germany Phone: +49-421-218-63921 Email: cabo@tzi.org
Carsten BormannUniversitätBremenTziPostfach 330440 D-28359 Bremen Germany電話：49-421-218-63921メール：cabo@tzi.org