RFC 8710 - Multipart Content-Format for CoAP 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc8710.html
タイトル : RFC 8710 - CoAPのマルチパートコンテンツ形式
翻訳編集 : 自動生成

[要約] RFC 8710は、CoAPのためのマルチパートコンテンツフォーマットに関する仕様です。このRFCの目的は、CoAPメッセージ内の複数のコンテンツを効率的に扱うための標準化を提供することです。

Internet Engineering Task Force (IETF)                        T. Fossati
Request for Comments: 8710                                           ARM
Category: Standards Track                                      K. Hartke
ISSN: 2070-1721                                                 Ericsson
                                                              C. Bormann
                                                  Universität Bremen TZI
                                                           February 2020

Multipart Content-Format for the Constrained Application Protocol (CoAP)

制約付きアプリケーションプロトコル（CoAP）のマルチパートコンテンツ形式

Abstract

概要

This memo defines application/multipart-core, an application-independent media type that can be used to combine representations of zero or more different media types (each with a Constrained Application Protocol (CoAP) Content-Format identifier) into a single representation, with minimal framing overhead.

このメモは、アプリケーションに依存しないメディアタイプであるapplication / multipart-coreを定義します。これは、ゼロ以上の異なるメディアタイプ（それぞれがConstrained Application Protocol（CoAP）Content-Format識別子を持つ）の表現を単一の表現に組み合わせるために使用できます。最小限のフレーミングオーバーヘッド。

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/rfc8710.

このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8710で入手できます。

著作権表示

著作権（c）2020 IETFトラストおよびドキュメントの作成者として識別された人物。全著作権所有。

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
     1.1.  Requirements Language
   2.  Multipart Content-Format Encoding
   3.  Usage Example: Observing Resources
   4.  Implementation Hints
   5.  IANA Considerations
     5.1.  Registration of Media Type application/multipart-core
     5.2.  Registration of a Content-Format Identifier for
           application/multipart-core
   6.  Security Considerations
   7.  References
     7.1.  Normative References
     7.2.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction

1. はじめに

This memo defines application/multipart-core, an application-independent media type that can be used to combine representations of zero or more different media types (each with a CoAP Content-Format identifier [RFC7252]) into a single representation, with minimal framing overhead.

このメモは、アプリケーション/マルチパートコアを定義します。アプリケーションに依存しないメディアタイプを使用して、ゼロ以上の異なるメディアタイプ（それぞれがCoAP Content-Format識別子[RFC7252]を持つ）の表現を、最小限のフレーミングで単一の表現に組み合わせることができます。オーバーヘッド。

This simple and efficient binary framing mechanism can be employed to create application-specific message bodies that build on multiple already existing media types.

このシンプルで効率的なバイナリフレーミングメカニズムを使用して、複数の既存のメディアタイプに基づいて構築されるアプリケーション固有のメッセージ本文を作成できます。

As the name of the media type suggests, application/multipart-core was inspired by the multipart media types initially defined in the original set of MIME specifications [RFC2046] and later. However, while those needed to focus on the syntactic aspects of integrating multiple representations into one email, transfer protocols providing full data transparency such as CoAP as well as readily available encoding formats such as the Concise Binary Object Representation (CBOR) [RFC7049] shift the focus towards the intended use of the combined representations. In this respect, the basic intent of the application/multipart-core media type is like that of multipart/mixed (Section 5.1.3 of [RFC2046]); however, the semantics are relaxed to allow for both ordered and unordered collections of media types.

メディアタイプの名前が示すように、application / multipart-coreは、元のMIME仕様のセット[RFC2046]以降で最初に定義されたマルチパートメディアタイプに触発されました。ただし、複数の表現を1つの電子メールに統合する構文的側面に焦点を当てる必要がある一方で、CoAPなどの完全なデータ透過性を提供する転送プロトコルや、簡潔なバイナリオブジェクト表現（CBOR）[RFC7049]などのすぐに利用できるエンコード形式により、組み合わせた表現の使用目的に焦点を当てます。この点で、application / multipart-coreメディアタイプの基本的な意図は、multipart / mixedのそれと似ています（[RFC2046]のセクション5.1.3）。ただし、セマンティクスは緩和されており、メディアタイプの順序付きコレクションと順序なしコレクションの両方を使用できます。

Historical Note: Experience with multipart/mixed in email has shown that recipients that care about order of included body parts will process them in the order they are listed inside multipart/ mixed, and recipients that don't care about the order will ignore it anyway. The media type multipart/parallel that was intended for unordered collections didn't deploy.

過去のメモ：マルチパート/混合メールの経験から、含まれるボディパーツの順序に関心がある受信者は、マルチパート/混合にリストされている順序でそれらを処理し、順序に関心がない受信者はとにかくそれを無視することがわかりました。順序付けられていないコレクション用のメディアタイプmultipart / parallelはデプロイされませんでした。

The detailed semantics of the representations are refined by the context established by the application in the accompanying request parameters, e.g., the resource URI and any further options (header fields), but three usage scenarios are envisioned:

表現の詳細なセマンティクスは、リソースURIやその他のオプション（ヘッダーフィールド）など、付随する要求パラメーターでアプリケーションによって確立されたコンテキストによって調整されますが、3つの使用シナリオが想定されています。

In one case, the individual representations in an application/ multipart-core message body occur in a sequence, which may be employed by an application where such a sequence is natural, e.g., for a number of audio snippets in various formats to be played out in that sequence or search results returned in order of relevance.

ある場合では、アプリケーション/マルチパートコアメッセージ本文の個々の表現はシーケンスで発生します。これは、たとえば、さまざまな形式のオーディオスニペットを再生するなど、そのようなシーケンスが自然なアプリケーションで使用できます。その順序で、または関連性の順に返された検索結果。

In another case, an application may be more interested in a bag of representations (which are distinguished by their Content-Format identifiers), such as an audio snippet and a text representation accompanying it. In such a case, the sequence in which these occur may not be relevant to the application. This specification adds the option of substituting a null value for the representation of an optional part, which indicates that the part is not present.

別のケースでは、アプリケーションは、オーディオスニペットやそれに付随するテキスト表現など、表現のバッグ（Content-Format識別子によって区別される）にもっと関心を持つ場合があります。そのような場合、これらが発生する順序はアプリケーションに関連しない場合があります。この仕様は、オプションのパーツの表現をnull値に置き換えるオプションを追加します。これは、パーツが存在しないことを示します。

A third common situation only has a single representation in the sequence, and the sender selects just one of a set of formats possible for this situation. This kind of union "type" of formats may also make the presence of the actual representation optional, the omission of which leads to a zero-length array.

3番目の一般的な状況では、シーケンスの表現が1つだけであり、送信者は、この状況で可能な形式のセットの1つだけを選択します。この種類のフォーマットの和集合「タイプ」は、実際の表現の存在をオプションにすることもでき、その省略は長さがゼロの配列につながります。

Where these rules are not sufficient, an application might still use the general format defined here but register a new media type and an associated Content-Format identifier to associate the representation with these more specific semantics instead of using the application/ multipart-core media type.

これらのルールでは不十分な場合、アプリケーションはここで定義された一般的な形式を使用しますが、application / multipart-coreメディアタイプを使用する代わりに、新しいメディアタイプと関連するContent-Format識別子を登録して、これらのより具体的なセマンティクスに表現を関連付けます。。

Also, future specifications might want to define rough equivalents for other multipart media types with specific semantics not covered by the present specification, such as multipart/alternative (Section 5.1.4 of [RFC2046]), where several alternative representations are provided in the message body, but only one of those is to be selected by the recipient for its use (this is less likely to be useful in a constrained environment that has facilities for pre-flight discovery).

また、将来の仕様では、マルチパート/代替（[RFC2046]のセクション5.1.4）など、現在の仕様ではカバーされていない特定のセマンティクスを持つ他のマルチパートメディアタイプの大まかな同等物を定義する可能性があります。本文。ただし、受信者がその使用のために選択するのはそのうちの1つだけです（これは、飛行前の発見のための機能を持つ制約された環境ではあまり役に立ちません）。

1.1. Requirements Language

1.1. 要件言語

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]で説明されているように解釈されます。

2. Multipart Content-Format Encoding

2. マルチパートコンテンツ形式のエンコーディング

A representation of media type application/multipart-core contains a collection of zero or more representations, each along with their respective Content-Format.

メディアタイプapplication / multipart-coreの表現には、それぞれのContent-Formatとともに、0個以上の表現のコレクションが含まれます。

The collection is encoded as a CBOR [RFC7049] array with an even number of elements. Counting from zero, the odd-numbered elements are a byte string containing a representation or the value "null" (if an optional part is indicated as not given). The (even-numbered) element preceding each of these is an unsigned integer specifying the Content-Format ID of the representation following it.

コレクションは、要素数が偶数のCBOR [RFC7049]配列としてエンコードされます。奇数番号の要素は、ゼロから数えて、表現または値「null」を含むバイト文字列です（オプションの部分が指定されていない場合）。これらのそれぞれの前にある（偶数）要素は、それに続く表現のContent-Format IDを指定する符号なし整数です。

For example, a collection containing two representations, one with Content-Format ID 42 and one with Content-Format ID 0, looks like this in CBOR diagnostic notation:

たとえば、コンテンツ形式ID 42とコンテンツ形式ID 0の2つの表現を含むコレクションは、CBOR診断表記では次のようになります。

[42, h'0123456789abcdef', 0, h'3031323334']

[42、h'0123456789abcdef '、0、h'3031323334']

For illustration, the structure of an application/multipart-core representation can be described by the Concise Data Definition Language (CDDL) [RFC8610] specification in Figure 1:

説明のために、アプリケーション/マルチパートコア表現の構造は、図1の簡潔データ定義言語（CDDL）[RFC8610]仕様で説明できます。

   multipart-core = [* multipart-part]
   multipart-part = (type: uint .size 2, part: bytes / null)

Figure 1: CDDL for application/multipart-core

図1：application / multipart-coreのCDDL

This format is intended as a strict specification: an implementation MUST stop processing the representation if there is a CBOR well-formedness error, a deviation from the structure defined above, or any residual data left after processing the CBOR data item. (This generally means the representation is not processed at all unless some streaming processing has already happened.)

この形式は、厳密な仕様として意図されています。CBOR整形式エラー、上記で定義された構造からの逸脱、またはCBORデータ項目の処理後に残ったデータがある場合、実装は表現の処理を停止する必要があります。（これは一般に、何らかのストリーミング処理が既に行われていない限り、表現がまったく処理されないことを意味します。）

3. Usage Example: Observing Resources

3. 使用例：リソースの監視

This section illustrates a less obvious example for using application/multipart-core: combining it with observing a resource [RFC7641] to handle pending results.

このセクションでは、application / multipart-coreを使用するためのそれほど明白ではない例を示します。これをリソースの監視[RFC7641]と組み合わせて、保留中の結果を処理します。

When a client registers to observe a resource for which no representation is available yet, the server may send one or more 2.05 (Content) notifications that indicate the lack of an actual representation. Later on, when one becomes available, the server will send the first actual 2.05 (Content) or 2.03 (Valid) notification. A diagram depicting possible resulting sequences of notifications, identified by their respective response code, is shown in Figure 2.

クライアントが、まだ表現が利用できないリソースを監視するように登録すると、サーバーは、実際の表現がないことを示す1つ以上の2.05（コンテンツ）通知を送信します。その後、いずれかが利用可能になると、サーバーは最初の実際の2.05（コンテンツ）または2.03（有効）通知を送信します。それぞれの応答コードによって識別される、通知の結果として生じる可能性のあるシーケンスを示す図を図2に示します。

         __________       __________       __________
        |          |     |          |     |          |
   ---->|   2.05   |---->|  2.05 /  |---->|  4.xx /  |
        |  Pending |     |   2.03   |     |   5.xx   |
        |__________|     |__________|     |__________|
           ^   \ \          ^    \           ^
            \__/  \          \___/          /
                   \_______________________/

Figure 2: Sequence of Notifications

図2：通知のシーケンス

The specification of the Observe option requires that all notifications carry the same Content-Format. The application/ multipart-core media type can be used to provide that Content-Format, e.g., by carrying an empty list of representations in the case marked as "Pending" in Figure 2 and carrying a single representation specified as the target Content-Format in the case in the middle of the figure.

監視オプションの指定では、すべての通知が同じContent-Formatを持つ必要があります。 application / multipart-coreメディアタイプを使用して、そのContent-Formatを提供できます。たとえば、図2で「保留」とマークされている場合は、表現の空のリストを持ち、ターゲットのContent-Formatとして指定された単一の表現を持ちます。図の真ん中の場合。

4. Implementation Hints

4. 実装のヒント

This section describes the serialization for readers that may be new to CBOR. It does not contain any new information.

このセクションでは、CBORの新機能である可能性のあるリーダーのシリアル化について説明します。新しい情報は含まれていません。

An application/multipart-core representation carrying no representations is represented by an empty CBOR array, which is serialized as a single byte with the value 0x80.

表現を持たないアプリケーション/マルチパートコア表現は、値0x80のシングルバイトとしてシリアル化される空のCBOR配列で表されます。

An application/multipart-core representation carrying a single representation is represented by a two-element CBOR array, which is serialized as 0x82 followed by the two elements. The first element is an unsigned integer for the Content-Format value, which is represented as described in Table 1. The second element is the object as a byte string, which is represented as a length as described in Table 2 followed by the bytes of the object.

単一の表現を運ぶアプリケーション/マルチパートコア表現は、2つの要素のCBOR配列で表されます。これは、0x82としてシリアル化され、その後に2つの要素が続きます。最初の要素は、Content-Format値の符号なし整数であり、表1で説明されているように表されます。2番目の要素は、バイト文字列としてのオブジェクトで、表2で説明されている長さとして表され、その後にバイトが続きます。オブジェクト。

                      +----------------+------------+
                      | Serialization  | Value      |
                      +================+============+
                      | 0x00..0x17     | 0..23      |
                      +----------------+------------+
                      | 0x18 0xnn      | 24..255    |
                      +----------------+------------+
                      | 0x19 0xnn 0xnn | 256..65535 |
                      +----------------+------------+

Table 1: Serialization of Content-Format

表1：コンテンツ形式のシリアル化

            +-----------------------------+-------------------+
            | Serialization               | Length            |
            +=============================+===================+
            | 0x40..0x57                  | 0..23             |
            +-----------------------------+-------------------+
            | 0x58 0xnn                   | 24..255           |
            +-----------------------------+-------------------+
            | 0x59 0xnn 0xnn              | 256..65535        |
            +-----------------------------+-------------------+
            | 0x5a 0xnn 0xnn 0xnn 0xnn    | 65536..4294967295 |
            +-----------------------------+-------------------+
            | 0x5b 0xnn .. 0xnn (8 bytes) | 4294967296..      |
            +-----------------------------+-------------------+

Table 2: Serialization of Object Length

表2：オブジェクト長のシリアル化

For example, a single text/plain object (Content-Format 0) of value "Hello World" (11 characters) would be serialized as follows:

たとえば、値が「Hello World」（11文字）の単一のtext / plainオブジェクト（Content-Format 0）は、次のようにシリアル化されます。

0x82 0x00 0x4b H e l l o 0x20 W o r l d

0x82 0x00 0x4b H e l l 0 0x20 W o r l d

In effect, the serialization for a single object is done by prefixing the object with information that there is one object (here: 0x82), information about its Content-Format (here: 0x00), and information regarding its length (here: 0x4b).

実際、単一のオブジェクトのシリアル化は、1つのオブジェクトがあるという情報（ここでは0x82）、そのContent-Formatに関する情報（ここでは0x00）、およびその長さに関する情報（ここでは0x4b）をオブジェクトの前に付けることによって行われます。。

For more than one representation included in an application/ multipart-core representation, the head of the CBOR array is adjusted (0x84 for two representations, 0x86 for three, etc.), and the sequences of Content-Format and embedded representations follow.

application / multipart-core表現に含まれる複数の表現の場合、CBOR配列の先頭が調整され（2つの表現の場合は0x84、3つの場合は0x86など）、Content-Formatのシーケンスと埋め込まれた表現が続きます。

For instance, the example from Section 2 would be serialized as follows:

たとえば、セクション2の例は次のようにシリアル化されます。

0x84 (*) 0x182A 0x48 0x0123456789ABCDEF (+) 0x00 0x45 0x3031323334

0x84（*）0x182A 0x48 0x0123456789ABCDEF（+）0x00 0x45 0x3031323334

where (*) marks the start of the information about the first representation (Content-Format 42, byte string length 8), and (+) marks the start of the second representation (Content-Format 0, byte string length 5).

ここで、（*）は最初の表現（Content-Format 42、バイト文字列長8）に関する情報の始まりを示し、（+）は2番目の表現（Content-Format 0、バイト文字列長5）の始まりを示します。

5. IANA Considerations

5. IANAに関する考慮事項

5.1. Registration of Media Type application/multipart-core

5.1. メディアタイプアプリケーション/マルチパートコアの登録

IANA has registered the following media type [RFC6838]:

IANAは次のメディアタイプを登録しています[RFC6838]：

Type name: application

タイプ名：アプリケーション

Subtype name: multipart-core

サブタイプ名：multipart-core

Required parameters: N/A

必須パラメーター：なし

Optional parameters: N/A

オプションのパラメーター：N / A

Encoding considerations: binary

エンコーディングに関する考慮事項：バイナリ

Security considerations: See the Security Considerations section of RFC 8710.

セキュリティに関する考慮事項：RFC 8710のセキュリティに関する考慮事項のセクションを参照してください。

Interoperability considerations: N/A

相互運用性に関する考慮事項：N / A

Published specification: RFC 8710

公開された仕様：RFC 8710

Applications that use this media type: Applications that need to combine representations of zero or more different media types into one, e.g., EST over secure CoAP (EST-CoAP) [EST-COAPS]

このメディアタイプを使用するアプリケーション：ゼロ以上の異なるメディアタイプの表現を1つに組み合わせる必要があるアプリケーション。例：EST over Secure CoAP（EST-CoAP）[EST-COAPS]

Fragment identifier considerations: The syntax and semantics of fragment identifiers specified for application/multipart-core are as specified for application/cbor. (At publication of this document, there is no fragment identification syntax defined for application/cbor.)

フラグメント識別子の考慮事項：application / multipart-coreに指定されたフラグメント識別子の構文とセマンティクスは、application / cborに指定されたとおりです。（このドキュメントの公開時には、application / 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: iesg@ietf.org

詳細について連絡する人とメールアドレス：iesg@ietf.org

Intended usage: COMMON

使用目的：COMMON

Restrictions on usage: N/A

使用上の制限：N / A

Author: CoRE WG

作成者：CoRE WG

Change controller: IESG

コントローラーの変更：IESG

Provisional registration? (standards tree only): no

仮登録？（標準ツリーのみ）：いいえ

5.2. Registration of a Content-Format Identifier for application/ multipart-core

5.2. application / multipart-coreのコンテンツ形式識別子の登録

IANA has registered the following Content-Format in the "CoAP Content-Formats" subregistry within the "Constrained RESTful Environments (CoRE) Parameters" registry:

IANAは、「Constrained RESTful Environments（CoRE）Parameters」レジストリ内の「CoAP Content-Formats」サブレジストリに次のContent-Formatを登録しました。

        +----------------------------+----------+----+-----------+
        | Media Type                 | Encoding | ID | Reference |
        +============================+==========+====+===========+
        | application/multipart-core | -        | 62 | RFC 8710  |
        +----------------------------+----------+----+-----------+

Table 3: Addition to "CoAP Content-Formats" Registry

表3：「CoAP Content-Formats」レジストリへの追加

6. Security Considerations

6. セキュリティに関する考慮事項

The security considerations of [RFC7049] apply. In particular, resource exhaustion attacks may employ large values for the byte string size fields or employ deeply nested structures of recursively embedded application/multipart-core representations.

[RFC7049]のセキュリティに関する考慮事項が適用されます。特に、リソース枯渇攻撃では、バイト文字列サイズフィールドに大きな値を使用したり、再帰的に埋め込まれたアプリケーション/マルチパートコア表現の深くネストされた構造を使用したりする場合があります。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[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>。

[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, October 2013, <https://www.rfc-editor.org/info/rfc7049>.

[RFC7049] Bormann、C。およびP. Hoffman、「簡潔なバイナリオブジェクト表現（CBOR）」、RFC 7049、DOI 10.17487 / RFC7049、2013年10月、<https://www.rfc-editor.org/info/rfc7049> 。

[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、「The Constrained Application Protocol（CoAP）」、RFC 7252、DOI 10.17487 / RFC7252、2014年6月、<https：//www.rfc-editor。 org / info / rfc7252>。

[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>。

7.2. Informative References

7.2. 参考引用

[EST-COAPS] Stok, P., Kampanakis, P., Richardson, M., and S. Raza, "EST over secure CoAP (EST-coaps)", Work in Progress, Internet-Draft, draft-ietf-ace-coap-est-18, 6 January 2020, <https://tools.ietf.org/html/draft-ietf-ace-coap-est-18>.

[EST-COAPS] Stok、P.、Kampanakis、P.、Richardson、M。、およびS. Raza、「安全なCoAP（EST-coaps）を介したEST」、Work in Progress、インターネットドラフト、draft-ietf-ace -coap-est-18、2020年1月6日、<https://tools.ietf.org/html/draft-ietf-ace-coap-est-18>。

[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <https://www.rfc-editor.org/info/rfc2046>.

[RFC2046] Freed、N。およびN. Borenstein、「Multipurpose Internet Mail Extensions（MIME）Part Two：Media Types」、RFC 2046、DOI 10.17487 / RFC2046、1996年11月、<https://www.rfc-editor.org / info / rfc2046>。

[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>。

[RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, <https://www.rfc-editor.org/info/rfc7641>.

[RFC7641] Hartke、K。、「Observing Resources in the Constrained Application Protocol（CoAP）」、RFC 7641、DOI 10.17487 / RFC7641、2015年9月、<https://www.rfc-editor.org/info/rfc7641>。

[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、「簡潔なデータ定義言語（CDDL）：簡潔なバイナリオブジェクト表現（CBOR）およびJSONデータ構造を表現するための表記法」、RFC 8610、DOI 10.17487 / RFC8610、2019年6月、<https://www.rfc-editor.org/info/rfc8610>。

Acknowledgements

謝辞

Most of the text in this document is from earlier contributions by two of the authors, Thomas Fossati and Klaus Hartke. This earlier work was reorganized in this document based on the requirements in [EST-COAPS] and discussions with Michael Richardson, Panos Kampanis, and Peter van der Stok.

このドキュメントのテキストのほとんどは、著者のうちの2人、Thomas FossatiとKlaus Hartkeによる以前の寄稿からのものです。この初期の作業は、[EST-COAPS]の要件と、Michael Richardson、Panos Kampanis、およびPeter van der Stokとの議論に基づいて、このドキュメントで再編成されました。

Authors' Addresses

著者のアドレス

Thomas Fossati ARM

   Email: thomas.fossati@arm.com

Klaus Hartke Ericsson Torshamnsgatan 23 SE-16483 Stockholm Sweden

Klaus Hartke Ericsson Torshamnsgatan 23 SE-16483ストックホルムスウェーデン

   Email: klaus.hartke@ericsson.com

Carsten Bormann Universität Bremen TZI Postfach 330440 D-28359 Bremen Germany

カルステンボルマンブレーメン大学TZI P.O. Box 330440 D-28359ブレーメンドイツ

   Phone: +49-421-218-63921
   Email: cabo@tzi.org