[要約] RFC 8428は、センサー測定リスト（SenML）の標準仕様であり、センサーデータの表現と転送を目的としています。SenMLは、センサーデータの効率的な取り扱いと相互運用性を提供します。
Internet Engineering Task Force (IETF) C. Jennings
Request for Comments: 8428 Cisco
Category: Standards Track Z. Shelby
ISSN: 2070-1721 ARM
J. Arkko
A. Keranen
Ericsson
C. Bormann
Universitaet Bremen TZI
August 2018
Sensor Measurement Lists (SenML)
センサー測定リスト（SenML）
Abstract
概要
This specification defines a format for representing simple sensor measurements and device parameters in Sensor Measurement Lists (SenML). Representations are defined in JavaScript Object Notation (JSON), Concise Binary Object Representation (CBOR), Extensible Markup Language (XML), and Efficient XML Interchange (EXI), which share the common SenML data model. A simple sensor, such as a temperature sensor, could use one of these media types in protocols such as HTTP or the Constrained Application Protocol (CoAP) to transport the measurements of the sensor or to be configured.
この仕様は、センサー測定リスト（SenML）で簡単なセンサー測定とデバイスパラメーターを表すための形式を定義します。表現は、JavaScriptオブジェクト表記（JSON）、簡潔なバイナリオブジェクト表現（CBOR）、拡張マークアップ言語（XML）、および効率的なXML交換（EXI）で定義され、これらは共通のSenMLデータモデルを共有します。温度センサーなどの単純なセンサーは、HTTPや制約付きアプリケーションプロトコル（CoAP）などのプロトコルでこれらのメディアタイプの1つを使用して、センサーの測定値を転送したり、構成したりできます。
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/rfc8428.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、https：//www.rfc-editor.org/info/rfc8428で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2018 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements and Design Goals . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
4. SenML Structure and Semantics . . . . . . . . . . . . . . . . 6
4.1. Base Fields . . . . . . . . . . . . . . . . . . . . . . . 7
4.2. Regular Fields . . . . . . . . . . . . . . . . . . . . . 7
4.3. SenML Labels . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Extensibility . . . . . . . . . . . . . . . . . . . . . . 9
4.5. Records and Their Fields . . . . . . . . . . . . . . . . 9
4.5.1. Names . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5.2. Units . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5.3. Time . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5.4. Values . . . . . . . . . . . . . . . . . . . . . . . 11
4.6. Resolved Records . . . . . . . . . . . . . . . . . . . . 12
4.7. Associating Metadata . . . . . . . . . . . . . . . . . . 12
4.8. Sensor Streaming Measurement Lists (SenSML) . . . . . . . 12
4.9. Configuration and Actuation Usage . . . . . . . . . . . . 13
5. JSON Representation (application/senml+json) . . . . . . . . 13
5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Single Data Point . . . . . . . . . . . . . . . . . . 14
5.1.2. Multiple Data Points . . . . . . . . . . . . . . . . 14
5.1.3. Multiple Measurements . . . . . . . . . . . . . . . . 15
5.1.4. Resolved Data . . . . . . . . . . . . . . . . . . . . 17
5.1.5. Multiple Data Types . . . . . . . . . . . . . . . . . 17
5.1.6. Collection of Resources . . . . . . . . . . . . . . . 18
5.1.7. Setting an Actuator . . . . . . . . . . . . . . . . . 18
6. CBOR Representation (application/senml+cbor) . . . . . . . . 19
7. XML Representation (application/senml+xml) . . . . . . . . . 21
8. EXI Representation (application/senml-exi) . . . . . . . . . 23
9. Fragment Identification Methods . . . . . . . . . . . . . . . 26
9.1. Fragment Identification Examples . . . . . . . . . . . . 26
9.2. Fragment Identification for XML and EXI Formats . . . . . 27
10. Usage Considerations . . . . . . . . . . . . . . . . . . . . 27
11. CDDL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
12.1. SenML Units Registry . . . . . . . . . . . . . . . . . . 30
12.2. SenML Labels Registry . . . . . . . . . . . . . . . . . 35
12.3. Media Type Registrations . . . . . . . . . . . . . . . . 36
12.3.1. senml+json Media Type Registration . . . . . . . . . 37
12.3.2. sensml+json Media Type Registration . . . . . . . . 38
12.3.3. senml+cbor Media Type Registration . . . . . . . . . 39
12.3.4. sensml+cbor Media Type Registration . . . . . . . . 41
12.3.5. senml+xml Media Type Registration . . . . . . . . . 42
12.3.6. sensml+xml Media Type Registration . . . . . . . . . 43
12.3.7. senml-exi Media Type Registration . . . . . . . . . 44
12.3.8. sensml-exi Media Type Registration . . . . . . . . . 45
12.4. XML Namespace Registration . . . . . . . . . . . . . . . 47
12.5. CoAP Content-Format Registration . . . . . . . . . . . . 47
13. Security Considerations . . . . . . . . . . . . . . . . . . . 47
14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 48
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 49
15.1. Normative References . . . . . . . . . . . . . . . . . . 49
15.2. Informative References . . . . . . . . . . . . . . . . . 51
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
Connecting sensors to the Internet is not new, and there have been many protocols designed to facilitate it. This specification defines a format and media types for carrying simple sensor information in protocols such as HTTP [RFC7230] or CoAP [RFC7252]. The SenML format is designed so that processors with very limited capabilities could easily encode a sensor measurement into the media type, while at the same time, a server parsing the data could collect a large number of sensor measurements in a relatively efficient manner. SenML can be used for a variety of data flow models, most notably data feeds pushed from a sensor to a collector, and for the web resource model where the sensor data is requested as a resource representation (e.g., "GET /sensor/temperature").
センサーをインターネットに接続することは新しいことではなく、それを容易にするために設計された多くのプロトコルがありました。この仕様は、HTTP [RFC7230]やCoAP [RFC7252]などのプロトコルで単純なセンサー情報を伝送するためのフォーマットとメディアタイプを定義しています。 SenML形式は、機能が非常に制限されたプロセッサーがセンサー測定値をメディアタイプに簡単にエンコードできるように設計されています。同時に、データを解析するサーバーは、比較的効率的な方法で多数のセンサー測定値を収集できます。 SenMLは、さまざまなデータフローモデル、特にセンサーからコレクターにプッシュされたデータフィード、およびセンサーデータがリソース表現として要求されるWebリソースモデル（たとえば、「GET / sensor / temperature」）に使用できます。 ）。
There are many types of more complex measurements and measurements that this media type would not be suitable for. SenML strikes a balance between having some information about the sensor carried with the sensor data so that the data is self-describing, but it also tries to make that a fairly minimal set of auxiliary information for efficiency reasons. Other information about the sensor can be discovered by other methods such as using the Constrained RESTful Environments (CoRE) Link Format [RFC6690].
このメディアタイプには適さない、より複雑な測定や測定には多くのタイプがあります。 SenMLは、センサーに関するいくつかの情報をセンサーデータとともに保持することでバランスをとっており、データは自己記述的ですが、効率上の理由から、その情報を最小限に抑えようとしています。センサーに関する他の情報は、Constrained RESTful Environments（CoRE）Link Format [RFC6690]を使用するなど、他の方法で発見できます。
SenML is defined by a data model for measurements and simple metadata about measurements and devices. The data is structured as a single array that contains a series of SenML Records that can each contain fields such as a unique identifier for the sensor, the time the measurement was made, the unit the measurement is in, and the current value of the sensor. Serializations for this data model are defined for JSON [RFC8259], CBOR [RFC7049], XML [W3C.REC-xml-20081126], and Efficient XML Interchange (EXI) [W3C.REC-exi-20140211].
SenMLは、測定のデータモデルと、測定およびデバイスに関する単純なメタデータによって定義されます。データは、センサーの一意の識別子、測定が行われた時間、測定の単位、センサーの現在の値などのフィールドをそれぞれ含めることができる一連のSenMLレコードを含む単一の配列として構造化されます。このデータモデルのシリアル化は、JSON [RFC8259]、CBOR [RFC7049]、XML [W3C.REC-xml-20081126]、および効率的なXML交換（EXI）[W3C.REC-exi-20140211]に対して定義されています。
For example, the following shows a measurement from a temperature gauge encoded in the JSON syntax.
たとえば、次の例は、JSON構文でエンコードされた温度ゲージからの測定を示しています。
[
{"n":"urn:dev:ow:10e2073a01080063","u":"Cel","v":23.1}
]
In the example above, the array has a single SenML Record with a measurement for a sensor named "urn:dev:ow:10e2073a01080063" with a current value of 23.1 degrees Celsius.
上記の例では、配列に「urn：dev：ow：10e2073a01080063」という名前のセンサーの測定値があり、現在の値が摂氏23.1度の単一のSenMLレコードがあります。
The design goal is to be able to send simple sensor measurements in small packets from large numbers of constrained devices. Keeping the total size of the payload small makes it easy to also use SenML in constrained networks, e.g., in an IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) [RFC4944]. It is always difficult to define what small code is, but there is a desire to be able to implement this in roughly 1 KB of flash on an 8-bit microprocessor. Experience with power meters and other large-scale deployments has indicated that the solution needs to support allowing multiple measurements to be batched into a single HTTP or CoAP request. This "batch" upload capability allows the server side to efficiently support a large number of devices. It also conveniently supports batch transfers from proxies and storage devices, even in situations where the sensor itself sends just a single data item at a time. The multiple measurements could be from multiple related sensors or from the same sensor but at different times.
設計目標は、制約された多数のデバイスからの小さなパケットで簡単なセンサー測定値を送信できるようにすることです。ペイロードの合計サイズを小さく保つことで、制約のあるネットワーク、たとえばIPv6 over Low-Power Wireless Personal Area Network（6LoWPAN）[RFC4944]でもSenMLを簡単に使用できるようになります。小さなコードが何であるかを定義することは常に困難ですが、これを8ビットのマイクロプロセッサの約1 KBのフラッシュに実装できるようにしたいという要望があります。パワーメーターやその他の大規模な展開の経験から、ソリューションでは、複数の測定値を単一のHTTPまたはCoAP要求にバッチ処理できるようにする必要があることが示されています。この「バッチ」アップロード機能により、サーバー側で多数のデバイスを効率的にサポートできます。また、センサー自体が一度に1つのデータアイテムのみを送信する場合でも、プロキシやストレージデバイスからのバッチ転送をサポートします。複数の測定値は、関連する複数のセンサーから、または同じセンサーから異なる時間に取得できます。
The basic design is an array with a series of measurements. The following example shows two measurements made at different times. The value of a measurement is given by the "v" field, the time of a measurement is in the "t" field, the "n" field has a unique sensor name, and the unit of the measurement is carried in the "u" field.
基本的な設計は、一連の測定値を持つアレイです。次の例は、異なる時間に行われた2つの測定を示しています。測定値は「v」フィールドで与えられ、測定時間は「t」フィールドにあり、「n」フィールドは一意のセンサー名を持ち、測定の単位は「u」で行われます。 "フィールド。
[
{"n":"urn:dev:ow:10e2073a01080063","u":"Cel","t":1.276020076e+09,
"v":23.5},
{"n":"urn:dev:ow:10e2073a01080063","u":"Cel","t":1.276020091e+09,
"v":23.6}
]
To keep the messages small, it does not make sense to repeat the "n" field in each SenML Record, so there is a concept of a Base Name, which is simply a string that is prepended to the Name field of all elements in that Record and any Records that follow it. So, a more compact form of the example above is the following.
メッセージを小さく保つために、各SenMLレコードの「n」フィールドを繰り返すことは意味がありません。そのため、ベース名の概念があります。これは、その中のすべての要素の名前フィールドの前に付加される単なる文字列です。レコードとそれに続くレコード。したがって、上記の例のよりコンパクトな形式は次のとおりです。
[
{"bn":"urn:dev:ow:10e2073a01080063","u":"Cel","t":1.276020076e+09,
"v":23.5},
{"u":"Cel","t":1.276020091e+09,
"v":23.6}
]
In the above example, the Base Name is in the "bn" field, and the "n" fields in each Record are empty strings, so they are omitted.
上記の例では、ベース名は「bn」フィールドにあり、各レコードの「n」フィールドは空の文字列なので、省略されます。
Some devices have accurate time while others do not, so SenML supports absolute and relative times. Time is represented in floating point as seconds. Values greater than or equal to 2**28 represent an absolute time relative to the Unix epoch. Values less than 2**28 represent time relative to the current time.
一部のデバイスは正確な時間を持っていますが、他のデバイスは正確ではありません。したがって、SenMLは絶対時間と相対時間をサポートしています。時間は浮動小数点で秒として表されます。 2 ** 28以上の値は、Unixエポックと比較した絶対時間を表します。 2 ** 28未満の値は、現在の時刻を基準にした時間を表します。
A simple sensor with no absolute wall-clock time might take a measurement every second, batch up 60 of them, and then send the batch to a server. It would include the relative time each measurement was made compared to the time the batch was sent in each SenML Record. If the server has accurate time based on, e.g., the Network Time Protocol (NTP), it may use the time it received the data and the relative offset to replace the times in the SenML with absolute times before saving the SenML information in a document database.
絶対的な時計時間のない単純なセンサーは、毎秒測定を行い、それらの60をバッチ処理して、サーバーにバッチを送信します。これには、各測定が行われた相対時間と、各SenMLレコードでバッチが送信された時間との比較が含まれます。サーバーがネットワークタイムプロトコル（NTP）などに基づく正確な時刻を持っている場合、SenML情報をドキュメントに保存する前に、データを受信した時刻と相対オフセットを使用して、SenMLの時刻を絶対時刻に置き換えることができます。データベース。
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]で説明されているように解釈されます。
This document also uses the following terms:
このドキュメントでは、次の用語も使用しています。
SenML Record: One measurement or configuration instance in time presented using the SenML data model.
SenMLレコード：SenMLデータモデルを使用して提示された、時間内の1つの測定または構成インスタンス。
SenML Pack: One or more SenML Records in an array structure.
SenML Pack：配列構造の1つ以上のSenMLレコード。
SenML Label: A short name used in SenML Records to denote different SenML fields (e.g., "v" for "value").
SenMLラベル：異なるSenMLフィールドを示すためにSenMLレコードで使用される短い名前（たとえば、「値」の「v」）。
SenML Field: A component of a record that associates a value to a SenML Label for this record.
SenMLフィールド：値をこのレコードのSenMLラベルに関連付けるレコードのコンポーネント。
SenSML: Sensor Streaming Measurement List (see Section 4.8).
SenSML：センサーストリーミング測定リスト（セクション4.8を参照）。
SenSML Stream: One or more SenML Records to be processed as a stream.
SenSMLストリーム：ストリームとして処理される1つ以上のSenMLレコード。
This document uses the terms "attribute" and "tag" where they occur with the underlying technologies (XML, CBOR [RFC7049], and the CoRE Link Format [RFC6690]); they are not used for SenML concepts, per se. However, note that "attribute" has been widely used in the past as a synonym for the SenML "field".
このドキュメントでは、基礎となるテクノロジー（XML、CBOR [RFC7049]、およびCoREリンクフォーマット[RFC6690]）で発生する「属性」および「タグ」という用語を使用します。それ自体は、SenMLの概念には使用されません。ただし、「属性」は、SenMLの「フィールド」の同義語として以前から広く使用されていることに注意してください。
All comparisons of text strings are performed byte by byte, which results in the comparisons being case sensitive.
テキスト文字列の比較はすべてバイト単位で実行されるため、比較では大文字と小文字が区別されます。
Where arithmetic is used, this specification uses the familiar notation of the programming language C, except that the operator "**" stands for exponentiation.
算術が使用される場合、この仕様では、慣習的なプログラミング言語Cの表記法を使用します。ただし、演算子「**」は指数を表します。
Each SenML Pack carries a single array that represents a set of measurements and/or parameters. This array contains a series of SenML Records with several fields described below. There are two kinds of fields: base and regular. Both the base and regular fields can be included in any SenML Record. The base fields apply to the entries in the Record and also to all Records after it up to, but not including, the next Record that has that same base field. All base fields are optional. Regular fields can be included in any SenML Record and apply only to that Record.
各SenMLパックは、測定値やパラメーターのセットを表す単一の配列を持っています。この配列には、以下に説明するいくつかのフィールドを持つ一連のSenMLレコードが含まれています。フィールドには、ベースとレギュラーの2種類があります。基本フィールドと通常フィールドの両方を任意のSenMLレコードに含めることができます。ベースフィールドは、レコード内のエントリに適用されます。また、同じベースフィールドを持つ次のレコードを除く、そのレコード以降のすべてのレコードにも適用されます。すべての基本フィールドはオプションです。通常のフィールドは任意のSenMLレコードに含めることができ、そのレコードにのみ適用されます。
Base Name: This is a string that is prepended to the names found in the entries.
ベース名：これは、エントリで見つかった名前の前に付加される文字列です。
Base Time: A base time that is added to the time found in an entry.
基準時間：エントリで見つかった時間に追加される基準時間。
Base Unit: A base unit that is assumed for all entries, unless otherwise indicated. If a record does not contain a Unit value, then the Base Unit is used. Otherwise, the value found in the Unit (if any) is used.
基本単位：特に明記されていない限り、すべてのエントリで想定される基本単位。レコードに単位値が含まれていない場合は、基本単位が使用されます。それ以外の場合は、Unitにある値（存在する場合）が使用されます。
Base Value: A base value is added to the value found in an entry, similar to Base Time.
ベース値：ベース値は、ベース時間と同様に、エントリで見つかった値に追加されます。
Base Sum: A base sum is added to the sum found in an entry, similar to Base Time.
基本合計：基本時間は、基本時間と同様に、エントリで見つかった合計に追加されます。
Base Version: Version number of the media type format. This field is an optional positive integer and defaults to 10 if not present.
基本バージョン：メディアタイプフォーマットのバージョン番号。このフィールドはオプションの正の整数であり、存在しない場合のデフォルトは10です。
Name: Name of the sensor or parameter. When appended to the Base Name field, this must result in a globally unique identifier for the resource. The name is optional, if the Base Name is present. If the name is missing, the Base Name must uniquely identify the resource. This can be used to represent a large array of measurements from the same sensor without having to repeat its identifier on every measurement.
名前：センサーまたはパラメーターの名前。 [ベース名]フィールドに追加する場合、これはリソースのグローバルに一意の識別子になる必要があります。ベース名が存在する場合、名前はオプションです。名前がない場合、ベース名はリソースを一意に識別する必要があります。これは、すべての測定で識別子を繰り返す必要なく、同じセンサーからの多数の測定値を表すために使用できます。
Unit: Unit for a measurement value. Optional.
単位：測定値の単位。オプション。
Value: Value of the entry. Optional if a Sum value is present; otherwise, it's required. Values are represented using basic data types. This specification defines floating-point numbers ("v" field for "Value"), booleans ("vb" for "Boolean Value"), strings ("vs" for "String Value"), and binary data ("vd" for "Data Value"). Exactly one Value field MUST appear unless there is a Sum field, in which case it is allowed to have no Value field.
値：エントリの値。 Sum値が存在する場合はオプションです。それ以外の場合は必須です。値は、基本的なデータ型を使用して表されます。この仕様では、浮動小数点数（「値」の「v」フィールド）、ブール値（「ブール値」の「vb」）、文字列（「文字列値」の「vs」）、およびバイナリデータ（「vd」の「vd」）を定義します。 「データ値」）。合計フィールドがない場合は、正確に1つの値フィールドを表示する必要があります。その場合、値フィールドを含めることはできません。
Sum: Integrated sum of the values over time. Optional. This field is in the unit specified in the Unit value multiplied by seconds. For historical reasons, it is named "sum" instead of "integral".
合計：時間の経過に伴う値の合計。オプション。このフィールドは、単位の値に秒を掛けた値で指定された単位になります。歴史的な理由により、「積分」ではなく「合計」と呼ばれています。
Time: Time when the value was recorded. Optional.
時間：値が記録された時間。オプション。
Update Time: Period of time in seconds that represents the maximum time before this sensor will provide an updated reading for a measurement. Optional. This can be used to detect the failure of sensors or the communications path from the sensor.
更新時間：このセンサーが更新された測定値を提供するまでの最大時間を表す秒単位の期間。オプション。これは、センサーまたはセンサーからの通信パスの障害を検出するために使用できます。
Table 1 provides an overview of all SenML fields defined by this document with their respective labels and data types.
表1は、このドキュメントで定義されているすべてのSenMLフィールドの概要と、それぞれのラベルとデータタイプを示しています。
+---------------+-------+------------+------------+------------+
| Name | Label | CBOR Label | JSON Type | XML Type |
+---------------+-------+------------+------------+------------+
| Base Name | bn | -2 | String | string |
| Base Time | bt | -3 | Number | double |
| Base Unit | bu | -4 | String | string |
| Base Value | bv | -5 | Number | double |
| Base Sum | bs | -6 | Number | double |
| Base Version | bver | -1 | Number | int |
| Name | n | 0 | String | string |
| Unit | u | 1 | String | string |
| Value | v | 2 | Number | double |
| String Value | vs | 3 | String | string |
| Boolean Value | vb | 4 | Boolean | boolean |
| Data Value | vd | 8 | String (*) | string (*) |
| Sum | s | 5 | Number | double |
| Time | t | 6 | Number | double |
| Update Time | ut | 7 | Number | double |
+---------------+-------+------------+------------+------------+
Table 1: SenML Labels
表1：SenMLラベル
(*) Data Value is a base64-encoded string with the URL-safe alphabet as defined in Section 5 of [RFC4648], with padding omitted. (In CBOR, the octets in the Data Value are encoded using a definite-length byte string, major type 2.)
（*）データ値は、[RFC4648]のセクション5で定義されているURLセーフアルファベットを使用したbase64エンコード文字列で、パディングは省略されています。 （CBORでは、データ値のオクテットは、固定長バイト文字列、メジャータイプ2を使用してエンコードされます。）
For details of the JSON representation, see Section 5; for CBOR, see Section 6; and for XML, see Section 7.
JSON表現の詳細については、セクション5を参照してください。 CBORについては、セクション6を参照してください。 XMLについては、セクション7を参照してください。
The SenML format can be extended with further custom fields. Both new base and regular fields are allowed. See Section 12.2 for details. Implementations MUST ignore fields they don't recognize unless that field has a label name that ends with the "_" character, in which case an error MUST be generated.
SenMLフォーマットは、さらにカスタムフィールドで拡張できます。新しい基本フィールドと通常フィールドの両方が許可されます。詳細については、セクション12.2を参照してください。実装は、「_」文字で終わるラベル名がない限り、認識しないフィールドを無視する必要があります。その場合、エラーが生成される必要があります。
All SenML Records in a Pack MUST have the same version number. This is typically done by adding a Base Version field to only the first Record in the Pack or by using the default value.
パック内のすべてのSenMLレコードは、同じバージョン番号を持っている必要があります。これは通常、基本バージョンフィールドをパックの最初のレコードのみに追加するか、デフォルト値を使用して行われます。
Systems reading one of the objects MUST check for the Base Version field. If this value is a version number larger than the version that the system understands, the system MUST NOT use this object. This allows the version number to indicate that the object contains structure or semantics that is different from what is defined in the present document beyond just making use of the extension points provided here. New version numbers can only be defined in an RFC that updates this specification or its successors.
オブジェクトの1つを読み取るシステムは、基本バージョンフィールドをチェックする必要があります。この値がシステムが理解するバージョンより大きいバージョン番号である場合、システムはこのオブジェクトを使用してはなりません（MUST NOT）。これにより、バージョン番号は、オブジェクトに、ここで提供される拡張ポイントを利用するだけでなく、現在のドキュメントで定義されているものとは異なる構造またはセマンティクスが含まれていることを示すことができます。新しいバージョン番号は、この仕様またはその後継を更新するRFCでのみ定義できます。
The Name value is concatenated to the Base Name value to yield the name of the sensor. The resulting concatenated name needs to uniquely identify and differentiate the sensor from all others. The concatenated name MUST consist only of characters out of the set "A" to "Z", "a" to "z", and "0" to "9", as well as "-", ":", ".", "/", and "_"; furthermore, it MUST start with a character out of the set "A" to "Z", "a" to "z", or "0" to "9". This restricted character set was chosen so that concatenated names can be used directly within various URI schemes (including segments of an HTTP path with no special encoding; note that a name that contains "/" characters maps into multiple URI path segments) and can be used directly in many databases and analytic systems. [RFC5952] contains advice on encoding an IPv6 address in a name. See Section 14 for privacy considerations that apply to the use of long-term stable unique identifiers.
Name値はBase Name値に連結され、センサーの名前を生成します。結果の連結名は、センサーを一意に識別し、他のすべてのセンサーと区別する必要があります。連結された名前は、「A」から「Z」、「a」から「z」、および「0」から「9」、および「-」、「：」、「」のセットからの文字のみで構成する必要があります。 "、" / "、および" _ ";さらに、「A」から「Z」、「a」から「z」、または「0」から「9」までのセットの文字で始まる必要があります。この制限された文字セットは、さまざまなURIスキーム（特別なエンコーディングのないHTTPパスのセグメントを含む。「/」文字を含む名前は複数のURIパスセグメントにマッピングされることに注意）内で連結名を直接使用できるように選択され、多くのデータベースおよび分析システムで直接使用されます。 [RFC5952]には、IPv6アドレスを名前にエンコードする際のアドバイスが含まれています。長期の安定した一意の識別子の使用に適用されるプライバシーの考慮事項については、セクション14を参照してください。
Although it is RECOMMENDED that concatenated names be represented as URIs [RFC3986] or URNs [RFC8141], the restricted character set specified above puts strict limits on the URI schemes and URN namespaces that can be used. As a result, implementers need to take care in choosing the naming scheme for concatenated names, because such names both need to be unique and need to conform to the restricted character set. One approach is to include a bit string that has guaranteed uniqueness (such as a 1-wire address [AN1796]). Some of the examples within this document use the device URN namespace as specified in [DEVICE-URN]. Universally Unique Identifiers (UUIDs) [RFC4122] are another way to generate a unique name. However, the restricted character set does not allow the use of many URI schemes, such as the "tag" scheme [RFC4151] and the "ni" scheme [RFC6920], in names as such. The use of URIs with characters incompatible with this set and possible mapping rules between the two are outside the scope of the present document.
連結された名前をURI [RFC3986]またはURN [RFC8141]として表すことをお勧めしますが、上記で指定された制限された文字セットは、使用できるURIスキームとURN名前空間に厳しい制限を課します。その結果、実装者は連結された名前の命名スキームを選択する際に注意する必要があります。これらの名前はどちらも一意である必要があり、制限された文字セットに準拠する必要があるためです。 1つのアプローチは、一意性が保証されているビット文字列を含めることです（1-wireアドレス[AN1796]など）。このドキュメント内のいくつかの例では、[DEVICE-URN]で指定されているデバイスURN名前空間を使用しています。 Universally Unique Identifier（UUID）[RFC4122]は、一意の名前を生成するもう1つの方法です。ただし、制限された文字セットでは、「タグ」スキーム[RFC4151]や「ni」スキーム[RFC6920]など、多くのURIスキームを名前に使用することはできません。このセットと互換性のない文字を含むURIの使用、および2つの間の可能なマッピングルールは、現在のドキュメントの範囲外です。
If the Record has no Unit, the Base Unit is used as the Unit. Having no Unit and no Base Unit is allowed; any information that may be required about units applicable to the value then needs to be provided by the application context.
レコードに単位がない場合、基本単位が単位として使用されます。ユニットもベースユニットも使用できません。値に適用可能な単位に関して必要になる可能性がある情報は、アプリケーションコンテキストによって提供される必要があります。
If either the Base Time or Time value is missing, the missing field is considered to have a value of zero. The Base Time and Time values are added together to get a value representing the time of measurement.
Base TimeまたはTimeのいずれかの値が欠落している場合、欠落しているフィールドの値はゼロであると見なされます。 Base TimeとTimeの値を加算して、測定時間を表す値を取得します。
Values less than 268,435,456 (2**28) represent time relative to the current time. That is, a time of zero indicates that the sensor does not know the absolute time and the measurement was made roughly "now". A negative value indicates seconds in the past from roughly "now". Positive values up to 2**28 indicate seconds in the future from "now". An example for employing positive values would be actuation use, when the desired change should happen in the future, but the sender or the receiver does not have accurate time available.
268,435,456（2 ** 28）未満の値は、現在の時刻を基準とした時刻を表します。つまり、ゼロの時間は、センサーが絶対時間を知らず、測定がおおよそ「今」行われたことを示します。負の値は、おおよそ「現在」から過去の秒数を示します。 2 ** 28までの正の値は、「今」から未来の秒を示します。正の値を使用する例として、将来的に必要な変更が発生するが、送信者または受信者が正確な時間を利用できない場合の作動使用があります。
Values greater than or equal to 2**28 represent an absolute time relative to the Unix epoch (1970-01-01T00:00Z in UTC time), and the time is counted the same way as the Portable Operating System Interface (POSIX) "seconds since the epoch" [TIME_T]. Therefore, the smallest absolute Time value that can be expressed (2**28) is 1978-07-04 21:24:16 UTC.
2 ** 28以上の値は、Unixエポック（UTC時間の1970-01-01T00：00Z）を基準とした絶対時間を表し、時間はポータブルオペレーティングシステムインターフェイス（POSIX）と同じ方法でカウントされます。エポックからの秒数」[TIME_T]。したがって、表現できる最小絶対時間値（2 ** 28）は1978-07-04 21:24:16 UTCです。
Because Time values up to 2**28 are used for representing time relative to "now" and Time and Base Time are added together, care must be taken to ensure that the sum does not inadvertently reach 2**28 (i.e., absolute time) when relative time was intended to be used.
2 ** 28までのTime値は「現在」を基準とした時間を表すために使用され、TimeとBase Timeが一緒に追加されるため、合計が誤って2 ** 28（絶対時間）に到達しないように注意する必要があります。 ）相対時間が使用されることが意図されていた場合。
Obviously, SenML Records referenced to "now" are only useful within a specific communication context (e.g., based on information on when the SenML Pack, or a specific Record in a SenSML Stream, was sent) or together with some other context information that can be used for deriving a meaning of "now"; the expectation for any archival use is that they will be processed into UTC-referenced records before that context would cease to be available. This specification deliberately leaves the accuracy of "now" very vague as it is determined by the overall systems that use SenML. In a system where a sensor without wall-clock time sends a SenML Record with a time referenced to "now" over a high-speed RS-485 link to an embedded system with accurate time that resolves "now" based on the time of reception, the resulting time uncertainty could be within 1 ms. At the other extreme, a deployment that sends SenML wind-speed readings over a Low-Earth Orbit (LEO) satellite link from a mountain valley might have resulting reception Time values that are easily a dozen minutes off the actual time of the sensor reading, with the time uncertainty depending on satellite locations and conditions.
明らかに、「今」を参照するSenMLレコードは、特定の通信コンテキスト（SenMLパック、またはSenSMLストリームの特定のレコードがいつ送信されたかに関する情報に基づく）内でのみ、または他のいくつかのコンテキスト情報とともに役立つ「今」の意味を導き出すために使用されます。アーカイブの使用は、コンテキストが使用できなくなる前にUTC参照のレコードに処理されることが期待されています。この仕様は、SenMLを使用するシステム全体によって決定されるため、「今」の精度を意図的にあいまいにしています。実時間のないセンサーが、高速RS-485リンクを介して、「現在」を参照する時刻を含むSenMLレコードを、受信時刻に基づいて「現在」を解決する正確な時刻を持つ組み込みシステムに送信するシステム、結果として生じる時間の不確実性は1 ms以内である可能性があります。反対に、山谷から低地球軌道（LEO）衛星リンクを介してSenML風速測定値を送信する配備では、センサー測定値の実際の時間から数十分ずれた受信時間値が生じる可能性があります。衛星の場所と条件によっては時間の不確実性があります。
If only one of the Base Sum or Sum value is present, the missing field is considered to have a value of zero. The Base Sum and Sum values are added together to get the sum of measurement. If neither the Base Sum nor the Sum is present, then the measurement does not have a Sum value.
基本合計または合計値の1つだけが存在する場合、欠落しているフィールドの値はゼロと見なされます。基本合計と合計の値が加算され、測定の合計が得られます。基本合計も合計も存在しない場合、測定値には合計値がありません。
If the Base Value or Value is not present, the missing field(s) is considered to have a value of zero. The Base Value and Value are added together to get the value of the measurement.
基本値または値が存在しない場合、欠落しているフィールドの値はゼロであると見なされます。ベース値と値を加算して、測定値を取得します。
Representing the statistical characteristics of measurements, such as accuracy, can be very complex. Future specification may add new fields to provide better information about the statistical properties of the measurement.
精度など、測定の統計的特性を表すことは非常に複雑になる可能性があります。将来の仕様では、新しいフィールドを追加して、測定の統計的特性に関するより良い情報を提供する可能性があります。
In summary, the structure of a SenML Record is laid out to support a single measurement per Record. If multiple data values are measured at the same time (e.g., air pressure and altitude), they are best kept as separate Records linked through their Time value; this is even true when one of the data values is more "meta" than others (e.g., describes a condition that influences other measurements at the same time).
要約すると、SenMLレコードの構造は、レコードごとに1つの測定をサポートするようにレイアウトされています。複数のデータ値が同時に測定された場合（たとえば、気圧と高度）、それらはそれらの時間値を介してリンクされた個別のレコードとして保持されるのが最適です。これは、データ値の1つが他のデータ値よりも「メタ」である場合にも当てはまります（たとえば、同時に他の測定に影響を与える条件を説明します）。
Sometimes it is useful to be able to refer to a defined normalized format for SenML Records. This normalized format tends to get used for big data applications and intermediate forms when converting to other formats. Also, if SenML Records are used outside of a SenML Pack, they need to be resolved first to ensure applicable base values are applied.
SenMLレコードの定義済みの正規化された形式を参照できると便利な場合があります。この正規化された形式は、他の形式に変換するときに、ビッグデータアプリケーションや中間フォームに使用される傾向があります。また、SenMLレコードをSenMLパックの外で使用する場合は、該当する基本値が適用されるように、最初に解決する必要があります。
A SenML Record is referred to as "resolved" if it does not contain any base values, i.e., labels starting with the character "b", except for Base Version fields (see below), and has no relative times. To resolve the Records, the applicable base values of the SenML Pack (if any) are applied to the Record. That is, for the base values in the Record or before the Record in the Pack, Name and Base Name are concatenated, the Base Time is added to the time of the Record, the Base Unit is applied to the Record if it did not contain a Unit, etc. In addition, the Records need to be in chronological order in the Pack. An example of this is shown in Section 5.1.4.
SenMLレコードは、ベースバージョンのフィールド（下記参照）を除き、ベース値、つまり文字「b」で始まるラベルが含まれておらず、相対時間がない場合、「解決済み」と呼ばれます。レコードを解決するために、SenMLパック（存在する場合）の該当するベース値がレコードに適用されます。つまり、レコード内のベース値の場合、またはパック内のレコード、名前、ベース名が連結される前に、ベース時間がレコードの時間に追加され、含まれていない場合、ベース単位がレコードに適用されます。ユニットなど。さらに、レコードはパック内で時系列である必要があります。この例をセクション5.1.4に示します。
The Base Version field MUST NOT be present in resolved Records if the SenML version defined in this document is used; otherwise, it MUST be present in all the resolved SenML Records.
このドキュメントで定義されているSenMLバージョンが使用される場合、Base Versionフィールドは解決済みレコードに存在してはなりません（MUST NOT）。それ以外の場合は、解決されたすべてのSenMLレコードに存在する必要があります。
A future specification that defines new base fields needs to specify how the field is resolved.
新しい基本フィールドを定義する将来の仕様では、フィールドの解決方法を指定する必要があります。
SenML is designed to carry the minimum dynamic information about measurements and, for efficiency reasons, does not carry significant static metadata about the device, object, or sensors. Instead, it is assumed that this metadata is carried out of band. For web resources using SenML Packs, this metadata can be made available using the CoRE Link Format [RFC6690]. The most obvious use of this link format is to describe that a resource is available in a SenML format in the first place. The relevant media type indicator is included in the Content-Type (ct=) link attribute (which is defined for the link format in Section 7.2.1 of [RFC7252]).
SenMLは、測定に関する最小限の動的情報を伝達するように設計されており、効率上の理由から、デバイス、オブジェクト、またはセンサーに関する重要な静的メタデータを伝達しません。代わりに、このメタデータは帯域外で実行されると想定されています。 SenMLパックを使用するWebリソースの場合、このメタデータはCoREリンクフォーマット[RFC6690]を使用して利用可能にすることができます。このリンク形式の最も明らかな使用法は、リソースが最初にSenML形式で利用可能であることを説明することです。関連するメディアタイプインジケーターは、Content-Type（ct =）リンク属性（[RFC7252]のセクション7.2.1でリンク形式に対して定義されています）に含まれています。
In some usage scenarios of SenML, the implementations store or transmit SenML in a stream-like fashion, where data is collected over time and continuously added to the object. This mode of operation is optional, but systems or protocols using SenML in this fashion MUST specify that they are doing this. SenML defines separate media types to indicate Sensor Streaming Measurement Lists (SenSML) for this usage (see Section 12.3.2). In this situation, the SenSML Stream can be sent and received in a partial fashion, i.e., a measurement entry can be read as soon as the SenML Record is received and does not have to wait for the full SenSML Stream to be complete.
SenMLのいくつかの使用シナリオでは、実装はストリームのような方法でSenMLを格納または送信します。データは時間の経過とともに収集され、オブジェクトに継続的に追加されます。この操作モードはオプションですが、この方法でSenMLを使用するシステムまたはプロトコルは、これを実行していることを指定する必要があります。 SenMLは、この用途のセンサーストリーミング測定リスト（SenSML）を示すために、個別のメディアタイプを定義します（セクション12.3.2を参照）。この状況では、SenSMLストリームを部分的に送受信できます。つまり、SenMLレコードを受信するとすぐに測定エントリを読み取ることができ、SenSMLストリーム全体が完了するのを待つ必要がありません。
If times relative to "now" (see Section 4.5.3) are used in SenML Records of a SenSML Stream, their interpretation of "now" is based on the time when the specific Record is sent in the stream.
「現在」を基準とする時間（セクション4.5.3を参照）がSenSMLストリームのSenMLレコードで使用されている場合、「現在」の解釈は、特定のレコードがストリームで送信された時間に基づいています。
SenML can also be used for configuring parameters and controlling actuators. When a SenML Pack is sent (e.g., using an HTTP/CoAP POST or PUT method) and the semantics of the target are such that SenML is interpreted as configuration/actuation, SenML Records are interpreted as a request to change the values of given (sub)resources (given as names) to given values at the given time(s). The semantics of the target resource supporting this usage can be described, e.g., using [RID-CoRE]. Examples of actuation usage are shown in Section 5.1.7.
SenMLは、パラメーターの設定とアクチュエーターの制御にも使用できます。 SenMLパックが送信され（たとえば、HTTP / CoAP POSTまたはPUTメソッドを使用して）、ターゲットのセマンティクスがSenMLが構成/操作として解釈される場合、SenMLレコードは指定された（特定の時間に特定の値にサブ）リソース（名前として指定）。この使用法をサポートするターゲットリソースのセマンティクスは、たとえば[RID-CoRE]を使用して説明できます。アクチュエーションの使用例はセクション5.1.7に示されています。
For the SenML fields shown in Table 2, the SenML Labels are used as the JSON object member names within JSON objects representing the JSON SenML Records.
表2に示すSenMLフィールドの場合、SenMLラベルは、JSON SenMLレコードを表すJSONオブジェクト内のJSONオブジェクトメンバー名として使用されます。
+---------------+-------+-----------+
| Name | Label | JSON Type |
+---------------+-------+-----------+
| Base Name | bn | String |
| Base Time | bt | Number |
| Base Unit | bu | String |
| Base Value | bv | Number |
| Base Sum | bs | Number |
| Base Version | bver | Number |
| Name | n | String |
| Unit | u | String |
| Value | v | Number |
| String Value | vs | String |
| Boolean Value | vb | Boolean |
| Data Value | vd | String |
| Sum | s | Number |
| Time | t | Number |
| Update Time | ut | Number |
+---------------+-------+-----------+
Table 2: JSON SenML Labels
表2：JSON SenMLラベル
The root JSON value consists of an array with one JSON object for each SenML Record. All the fields in the above table MAY occur in the Records with member values of the type specified in the table.
ルートJSON値は、SenMLレコードごとに1つのJSONオブジェクトを持つ配列で構成されます。上記のテーブルのすべてのフィールドは、テーブルで指定されたタイプのメンバー値を持つレコードに存在する場合があります。
Only the UTF-8 [RFC3629] form of JSON is allowed. Characters in the String Value are encoded using the escape sequences defined in [RFC8259]. Octets in the Data Value are base64 encoded with the URL-safe alphabet as defined in Section 5 of [RFC4648], with padding omitted.
JSONのUTF-8 [RFC3629]形式のみが許可されています。文字列値の文字は、[RFC8259]で定義されているエスケープシーケンスを使用してエンコードされます。データ値のオクテットは、[RFC4648]のセクション5で定義されているURLセーフアルファベットでbase64エンコードされ、パディングは省略されています。
Systems receiving measurements MUST be able to process the range of floating-point numbers that are representable as IEEE double-precision, floating-point numbers [IEEE.754]. This allows Time values to have better than microsecond precision over the next 100 years. The number of significant digits in any measurement is not relevant, so a reading of 1.1 has exactly the same semantic meaning as 1.10. If the value has an exponent, the "e" MUST be in lower case. In the interest of avoiding unnecessary verbosity and speeding up processing, the mantissa SHOULD be less than 19 characters long, and the exponent SHOULD be less than 5 characters long.
測定値を受け取るシステムは、IEEE倍精度浮動小数点数[IEEE.754]として表現できる浮動小数点数の範囲を処理できなければなりません（MUST）。これにより、次の100年間でTime値の精度がマイクロ秒よりも高くなります。どの測定でも有効桁数は関係ないため、1.1の読み取り値は1.10とまったく同じ意味を持ちます。値に指数がある場合、「e」は小文字でなければなりません。不必要な冗長性を回避し、処理を高速化するために、仮数は19文字未満である必要があり、指数は5文字未満である必要があります（SHOULD）。
The following shows a temperature reading taken approximately "now" by a 1-wire sensor device that was assigned the unique 1-wire address of 10e2073a01080063:
以下は、一意の1線アドレス10e2073a01080063が割り当てられた1線センサーデバイスによっておおよそ「今」取得された温度測定値を示しています。
[
{"n":"urn:dev:ow:10e2073a01080063","u":"Cel","v":23.1}
]
The following example shows voltage and current "now", i.e., at an unspecified time.
次の例は、「現在」の、つまり不特定の時間における電圧と電流を示しています。
[
{"bn":"urn:dev:ow:10e2073a01080063:","n":"voltage","u":"V","v":120.1},
{"n":"current","u":"A","v":1.2}
]
The next example is similar to the above one, but it shows current at Tue Jun 8 18:01:16.001 UTC 2010 and at each second for the previous 5 seconds.
次の例は上記の例と似ていますが、火曜日6月8日18：01：16.001 UTC 2010と、直前の5秒間の1秒ごとの電流を示しています。
[
{"bn":"urn:dev:ow:10e2073a0108006:","bt":1.276020076001e+09,
"bu":"A","bver":5,
"n":"voltage","u":"V","v":120.1},
{"n":"current","t":-5,"v":1.2},
{"n":"current","t":-4,"v":1.3},
{"n":"current","t":-3,"v":1.4},
{"n":"current","t":-2,"v":1.5},
{"n":"current","t":-1,"v":1.6},
{"n":"current","v":1.7}
]
As an example of SenSML, the following stream of measurements may be sent via a long-lived HTTP POST from the producer of the stream to its consumer, and each measurement object may be reported at the time it was measured:
SenSMLの例として、次の測定ストリームが、存続期間の長いHTTP POSTを介してストリームのプロデューサーからコンシューマーに送信され、各測定オブジェクトは測定時に報告されます。
[ {"bn":"urn:dev:ow:10e2073a01080063","bt":1.320067464e+09, "bu":"%RH","v":21.2}, {"t":10,"v":21.3}, {"t":20,"v":21.4}, {"t":30,"v":21.4}, {"t":40,"v":21.5}, {"t":50,"v":21.5}, {"t":60,"v":21.5}, {"t":70,"v":21.6}, {"t":80,"v":21.7}, ...
[{"bn"： "urn：dev：ow：10e2073a01080063"、 "bt"：1.320067464e + 09、 "bu"： "％RH"、 "v"：21.2}、{"t"：10、 "v "：21.3}、{" t "：20、" v "：21.4}、{" t "：30、" v "：21.4}、{" t "：40、" v "：21.5}、{" t "：50、" v "：21.5}、{" t "：60、" v "：21.5}、{" t "：70、" v "：21.6}、{" t "：80、" v "： 21.7}、...
The following example shows humidity measurements from a mobile device with a 1-wire address 10e2073a01080063, starting at Mon Oct 31 13:24:24 UTC 2011. The device also provides position data, which is provided in the same measurement or parameter array as separate entries. Note that time is used to correlate data that belongs together, e.g., a measurement and a parameter associated with it. Finally, the device also reports extra data about its battery status at a separate time.
次の例は、1ワイヤアドレスが10e2073a01080063であるモバイルデバイスからの湿度測定を示しています。開始時刻は、Mon Oct 31 13:24:24 UTC 2011です。このデバイスは、同じ測定またはパラメーター配列で個別に提供される位置データも提供しますエントリ。時間は、測定値とそれに関連付けられたパラメータなど、一緒に属するデータを関連付けるために使用されることに注意してください。最後に、デバイスは別の時間にバッテリーの状態に関する追加のデータも報告します。
[
{"bn":"urn:dev:ow:10e2073a01080063","bt":1.320067464e+09,
"bu":"%RH","v":20},
{"u":"lon","v":24.30621},
{"u":"lat","v":60.07965},
{"t":60,"v":20.3},
{"u":"lon","t":60,"v":24.30622},
{"u":"lat","t":60,"v":60.07965},
{"t":120,"v":20.7},
{"u":"lon","t":120,"v":24.30623},
{"u":"lat","t":120,"v":60.07966},
{"u":"%EL","t":150,"v":98},
{"t":180,"v":21.2},
{"u":"lon","t":180,"v":24.30628},
{"u":"lat","t":180,"v":60.07967}
]
The following table shows the size of this example in various forms, as well as the size of each of these forms compressed with gzip.
次の表は、さまざまな形式でのこの例のサイズと、gzipで圧縮されたこれらの各形式のサイズを示しています。
+----------+------+-----------------+
| Encoding | Size | Compressed Size |
+----------+------+-----------------+
| JSON | 573 | 206 |
| XML | 649 | 235 |
| CBOR | 254 | 196 |
| EXI | 161 | 184 |
+----------+------+-----------------+
Table 3: Size Comparisons
表3：サイズの比較
The following shows the example from the previous section in resolved format.
以下は、前のセクションの例を解決された形式で示しています。
[
{"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067464e+09,
"v":20},
{"n":"urn:dev:ow:10e2073a01080063","u":"lon","t":1.320067464e+09,
"v":24.30621},
{"n":"urn:dev:ow:10e2073a01080063","u":"lat","t":1.320067464e+09,
"v":60.07965},
{"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067524e+09,
"v":20.3},
{"n":"urn:dev:ow:10e2073a01080063","u":"lon","t":1.320067524e+09,
"v":24.30622},
{"n":"urn:dev:ow:10e2073a01080063","u":"lat","t":1.320067524e+09,
"v":60.07965},
{"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067584e+09,
"v":20.7},
{"n":"urn:dev:ow:10e2073a01080063","u":"lon","t":1.320067584e+09,
"v":24.30623},
{"n":"urn:dev:ow:10e2073a01080063","u":"lat","t":1.320067584e+09,
"v":60.07966},
{"n":"urn:dev:ow:10e2073a01080063","u":"%EL","t":1.320067614e+09,
"v":98},
{"n":"urn:dev:ow:10e2073a01080063","u":"%RH","t":1.320067644e+09,
"v":21.2},
{"n":"urn:dev:ow:10e2073a01080063","u":"lon","t":1.320067644e+09,
"v":24.30628},
{"n":"urn:dev:ow:10e2073a01080063","u":"lat","t":1.320067644e+09,
"v":60.07967}
]
The following example shows a sensor that returns different data types.
次の例は、さまざまなデータ型を返すセンサーを示しています。
[
{"bn":"urn:dev:ow:10e2073a01080063:","n":"temp","u":"Cel","v":23.1},
{"n":"label","vs":"Machine Room"},
{"n":"open","vb":false},
{"n":"nfc-reader","vd":"aGkgCg"}
]
The following example shows the results from a query to one device that aggregates multiple measurements from other devices. The example assumes that a client has fetched information from a device at 2001:db8::2 by performing a GET operation on http://[2001:db8::2] at Mon Oct 31 16:27:09 UTC 2011 and has gotten two separate values as a result: a temperature and humidity measurement as well as the results from another device at http://[2001:db8::1] that also had a temperature and humidity measurement. Note that the last record would use the Base Name from the 3rd record but the Base Time from the first record.
次の例は、他のデバイスからの複数の測定値を集約する1つのデバイスへのクエリの結果を示しています。この例では、クライアントが、2001年10月31日16:27:09 UTC 2011にhttp：// [2001：db8 :: 2]でGET操作を実行することにより、2001：db8 :: 2でデバイスから情報をフェッチし、結果として、2つの別々の値を取得しました。温度と湿度の測定値と、温度と湿度の測定値があったhttp：// [2001：db8 :: 1]の別のデバイスからの結果です。最後のレコードは3番目のレコードのベース名を使用しますが、最初のレコードのベース時間を使用することに注意してください。
[
{"bn":"2001:db8::2/","bt":1.320078429e+09,
"n":"temperature","u":"Cel","v":25.2},
{"n":"humidity","u":"%RH","v":30},
{"bn":"2001:db8::1/","n":"temperature","u":"Cel","v":12.3},
{"n":"humidity","u":"%RH","v":67}
]
The following example shows the SenML that could be used to set the current set point of a typical residential thermostat that has a temperature set point, a switch to turn on and off the heat, and a switch to turn on the fan override.
次の例は、温度設定点、暖房のオンとオフを切り替えるスイッチ、およびファンのオーバーライドをオンにするスイッチを備えた一般的な住宅用サーモスタットの現在の設定点を設定するために使用できるSenMLを示しています。
[
{"bn":"urn:dev:ow:10e2073a01080063:"},
{"n":"temp","u":"Cel","v":23.1},
{"n":"heat","u":"/","v":1},
{"n":"fan","u":"/","v":0}
]
In the following example, two different lights are turned on. It is assumed that the lights are on a network that can guarantee delivery of the messages to the two lights within 15 ms (e.g., a network using 802.1BA [IEEE802.1BA] and 802.1AS [IEEE802.1AS] for time synchronization). The controller has set the time of the lights to come on at 20 ms in the future from the current time. This allows both lights to receive the message, wait till that time, then apply the switch command so that both lights come on at the same time.
次の例では、2つの異なるライトがオンになっています。ライトは、15 ms以内に2つのライトへのメッセージの配信を保証できるネットワーク上にあると想定されます（たとえば、時間同期に802.1BA [IEEE802.1BA]および802.1AS [IEEE802.1AS]を使用するネットワーク）。コントローラーは、現在の時刻から20ミリ秒後にライトが点灯する時間を設定しました。これにより、両方のライトがメッセージを受信し、それまで待機してから、switchコマンドを適用して、両方のライトが同時にオンになるようにします。
[ {"bt":1.320078429e+09,"bu":"/","n":"2001:db8::3","v":1}, {"n":"2001:db8::4","v":1} ] The following shows two lights being turned off using a non-deterministic network that has high odds of delivering a message in less than 100 ms and uses NTP for time synchronization. The current time is 1320078429. The user has just turned off a light switch that is turning off two lights. Both lights are immediately dimmed to 50% brightness to give the user instant feedback that something is changing. However, given the network, the lights will probably dim at somewhat different times. Then 100 ms in the future, both lights will go off at the same time. The instant, but not synchronized, dimming gives the user the sensation of quick responses, and the timed-off 100 ms in the future gives the perception of both lights going off at the same time.
[{"bt"：1.320078429e + 09、 "bu"： "/"、 "n"： "2001：db8 :: 3"、 "v"：1}、{"n"： "2001：db8 :: 4 "、" v "：1}]以下は、100ミリ秒未満でメッセージを配信する確率が高く、時刻同期にNTPを使用する非決定的ネットワークを使用して2つのライトがオフになっていることを示しています。現在の時刻は1320078429です。ユーザーが2つのライトをオフにしているライトスイッチをオフにしたところです。どちらのライトもすぐに50％の明るさに減光され、ユーザーは何かが変化していることを即座にフィードバックします。ただし、ネットワークを考慮して、ライトはおそらく多少異なる時間に暗くなります。その後、100 ms後に両方のライトが同時に消灯します。瞬時ではあるが同期されていない調光により、ユーザーは素早い反応の感覚を得ることができ、100 msの時間制限により、両方のライトが同時に消灯するように知覚されます。
[
{"bt":1.320078429e+09,"bu":"/","n":"2001:db8::3","v":0.5},
{"n":"2001:db8::4","v":0.5},
{"n":"2001:db8::3","t":0.1,"v":0},
{"n":"2001:db8::4","t":0.1,"v":0}
]
The CBOR [RFC7049] representation is equivalent to the JSON representation, with the following changes:
CBOR [RFC7049]表現はJSON表現と同等ですが、次の変更点があります。
o For JSON Numbers, the CBOR representation can use integers, floating-point numbers, or decimal fractions (CBOR Tag 4); however, a representation SHOULD be chosen such that when the CBOR value is converted to an IEEE double-precision, floating-point value, it has exactly the same value as the original JSON Number converted to that form. For the version number, only an unsigned integer is allowed.
o JSON番号の場合、CBOR表現は整数、浮動小数点数、または小数を使用できます（CBORタグ4）。ただし、CBOR値がIEEE倍精度浮動小数点値に変換されるときに、その形式に変換された元のJSON番号とまったく同じ値になるように、表現を選択する必要があります（SHOULD）。バージョン番号には、符号なし整数のみを使用できます。
o Characters in the String Value are encoded using a text string with a definite length (major type 3). Octets in the Data Value are encoded using a byte string with a definite length (major type 2).
o 文字列値の文字は、一定の長さのテキスト文字列（主なタイプ3）を使用してエンコードされます。データ値のオクテットは、一定の長さのバイト文字列（メジャータイプ2）を使用してエンコードされます。
o For compactness, the CBOR representation uses integers for the labels, as defined in Table 4. This table is conclusive, i.e., there is no intention to define any additional integer map keys; any extensions will use string map keys. This allows translators converting between CBOR and JSON representations to also convert all future labels without needing to update implementations. Base values are given negative CBOR labels, and others are given non-negative labels.
o コンパクトにするために、CBOR表現は、表4で定義されているように、ラベルに整数を使用します。この表は決定的なものです。つまり、追加の整数マップキーを定義する意図はありません。すべての拡張機能は文字列マップキーを使用します。これにより、CBOR表現とJSON表現の間で変換を行うトランスレーターは、実装を更新する必要なく、将来のすべてのラベルも変換できます。基本値には負のCBORラベルが付けられ、その他の値には負でないラベルが付けられます。
+---------------+-------+------------+
| Name | Label | CBOR Label |
+---------------+-------+------------+
| Base Version | bver | -1 |
| Base Name | bn | -2 |
| Base Time | bt | -3 |
| Base Unit | bu | -4 |
| Base Value | bv | -5 |
| Base Sum | bs | -6 |
| Name | n | 0 |
| Unit | u | 1 |
| Value | v | 2 |
| String Value | vs | 3 |
| Boolean Value | vb | 4 |
| Sum | s | 5 |
| Time | t | 6 |
| Update Time | ut | 7 |
| Data Value | vd | 8 |
+---------------+-------+------------+
Table 4: CBOR Representation: Integers for Map Keys
表4：CBOR表現：マップキーの整数
o For streaming SenSML in CBOR representation, the array containing the records SHOULD be a CBOR array with an indefinite length; for non-streaming SenML, an array with a definite length MUST be used.
o CBOR表現でSenSMLをストリーミングする場合、レコードを含む配列は、長さが不定のCBOR配列である必要があります（SHOULD）。非ストリーミングSenMLの場合、一定の長さの配列を使用する必要があります。
The following example shows a dump of the CBOR example for the same sensor measurement as in Section 5.1.2.
次の例は、セクション5.1.2と同じセンサー測定のCBOR例のダンプを示しています。
0000 87 a7 21 78 1b 75 72 6e 3a 64 65 76 3a 6f 77 3a |..!x.urn:dev:ow:|
0010 31 30 65 32 30 37 33 61 30 31 30 38 30 30 36 3a |10e2073a0108006:|
0020 22 fb 41 d3 03 a1 5b 00 10 62 23 61 41 20 05 00 |".A...[..b#aA ..|
0030 67 76 6f 6c 74 61 67 65 01 61 56 02 fb 40 5e 06 |gvoltage.aV..@^.|
0040 66 66 66 66 66 a3 00 67 63 75 72 72 65 6e 74 06 |fffff..gcurrent.|
0050 24 02 fb 3f f3 33 33 33 33 33 33 a3 00 67 63 75 |$..?.333333..gcu|
0060 72 72 65 6e 74 06 23 02 fb 3f f4 cc cc cc cc cc |rrent.#..?......|
0070 cd a3 00 67 63 75 72 72 65 6e 74 06 22 02 fb 3f |...gcurrent."..?|
0080 f6 66 66 66 66 66 66 a3 00 67 63 75 72 72 65 6e |.ffffff..gcurren|
0090 74 06 21 02 f9 3e 00 a3 00 67 63 75 72 72 65 6e |t.!..>...gcurren|
00a0 74 06 20 02 fb 3f f9 99 99 99 99 99 9a a3 00 67 |t. ..?.........g|
00b0 63 75 72 72 65 6e 74 06 00 02 fb 3f fb 33 33 33 |current....?.333|
00c0 33 33 33 |333|
00c3
In CBOR diagnostic notation (Section 6 of [RFC7049]), this is:
CBOR診断表記法（[RFC7049]のセクション6）では、これは次のとおりです。
[{-2: "urn:dev:ow:10e2073a0108006:",
-3: 1276020076.001, -4: "A", -1: 5, 0: "voltage", 1: "V", 2: 120.1},
{0: "current", 6: -5, 2: 1.2}, {0: "current", 6: -4, 2: 1.3},
{0: "current", 6: -3, 2: 1.4}, {0: "current", 6: -2, 2: 1.5},
{0: "current", 6: -1, 2: 1.6}, {0: "current", 6: 0, 2: 1.7}]
A SenML Pack or Stream can also be represented in XML format as defined in this section.
このセクションで定義されているように、SenMLパックまたはストリームをXML形式で表すこともできます。
Only the UTF-8 form of XML is allowed. Octets in the Data Value are base64 encoded with the URL-safe alphabet as defined in Section 5 of [RFC4648], with padding omitted.
XMLのUTF-8形式のみが許可されています。データ値のオクテットは、[RFC4648]のセクション5で定義されているURLセーフアルファベットでbase64エンコードされ、パディングは省略されています。
The following shows an XML example for the same sensor measurement as in Section 5.1.2.
以下は、セクション5.1.2と同じセンサー測定のXML例を示しています。
<sensml xmlns="urn:ietf:params:xml:ns:senml">
<senml bn="urn:dev:ow:10e2073a0108006:" bt="1.276020076001e+09"
bu="A" bver="5" n="voltage" u="V" v="120.1"></senml>
<senml n="current" t="-5" v="1.2"></senml>
<senml n="current" t="-4" v="1.3"></senml>
<senml n="current" t="-3" v="1.4"></senml>
<senml n="current" t="-2" v="1.5"></senml>
<senml n="current" t="-1" v="1.6"></senml>
<senml n="current" v="1.7"></senml>
</sensml>
The SenML Stream is represented as a sensml element that contains a series of senml elements for each SenML Record. The SenML fields are represented as XML attributes. For each field defined in this document, the following table shows the SenML Labels, which are used for the XML attribute name, as well as the according restrictions on the XML attribute values ("type") as used in the XML senml elements.
SenMLストリームは、各SenMLレコードの一連のsenml要素を含むsensml要素として表されます。 SenMLフィールドはXML属性として表されます。次の表は、このドキュメントで定義されている各フィールドについて、XML属性名に使用されるSenMLラベルと、XML senml要素で使用されるXML属性値（ "type"）に応じた制限を示しています。
+---------------+-------+----------+
| Name | Label | XML Type |
+---------------+-------+----------+
| Base Name | bn | string |
| Base Time | bt | double |
| Base Unit | bu | string |
| Base Value | bv | double |
| Base Sum | bs | double |
| Base Version | bver | int |
| Name | n | string |
| Unit | u | string |
| Value | v | double |
| String Value | vs | string |
| Data Value | vd | string |
| Boolean Value | vb | boolean |
| Sum | s | double |
| Time | t | double |
| Update Time | ut | double |
+---------------+-------+----------+
Table 5: XML SenML Labels
表5：XML SenMLラベル
The RelaxNG [RNC] Schema for the XML is:
XMLのRelaxNG [RNC]スキーマは次のとおりです。
default namespace = "urn:ietf:params:xml:ns:senml"
namespace rng = "http://relaxng.org/ns/structure/1.0"
senml = element senml { attribute bn { xsd:string }?, attribute bt { xsd:double }?, attribute bv { xsd:double }?, attribute bs { xsd:double }?, attribute bu { xsd:string }?, attribute bver { xsd:int }?,
senml = element senml {attribute bn {xsd：string} ?, attribute bt {xsd：double} ?, attribute bv {xsd：double} ?, attribute bs {xsd：double} ?, attribute bu {xsd：string} ?,属性bver {xsd：int} ?,
attribute n { xsd:string }?, attribute s { xsd:double }?, attribute t { xsd:double }?, attribute u { xsd:string }?, attribute ut { xsd:double }?,
属性n {xsd：string} ?、属性s {xsd：double} ?、属性t {xsd：double} ?、属性u {xsd：string} ?、属性ut {xsd：double} ?、
attribute v { xsd:double }?,
attribute vb { xsd:boolean }?,
attribute vs { xsd:string }?,
attribute vd { xsd:string }?
}
sensml =
element sensml {
senml+
}
start = sensml
For efficient transmission of SenML over, e.g., a constrained network, EXI can be used. This encodes the XML Schema [W3C.REC-xmlschema-1-20041028] structure of SenML into binary tags and values rather than ASCII text. An EXI representation of SenML SHOULD be made using the strict schema mode of EXI. However, this mode does not allow tag extensions to the schema; therefore, any extensions will be lost in the encoding. For uses where extensions need to be preserved in EXI, the non-strict schema mode of EXI MAY be used.
制約付きネットワークなどを介したSenMLの効率的な送信には、EXIを使用できます。これにより、SenMLのXMLスキーマ[W3C.REC-xmlschema-1-20041028]構造がASCIIテキストではなくバイナリタグと値にエンコードされます。 SenMLのEXI表現は、EXIの厳密なスキーマモードを使用して作成する必要があります（SHOULD）。ただし、このモードではスキーマへのタグ拡張は許可されません。したがって、エンコーディングで拡張機能が失われます。 EXIで拡張を保持する必要がある用途では、EXIの非厳密スキーマモードを使用できます（MAY）。
The EXI header MUST include "EXI Options", as defined in [W3C.REC-exi-20140211], with a schemaId set to the value of "a", indicating the schema provided in this specification. Future revisions to the schema can change the value of the schemaId to allow for backwards compatibility. When the data will be transported over CoAP or HTTP, an EXI Cookie SHOULD NOT be used as it simply makes things larger and is redundant to information provided in the Content-Type header.
EXIヘッダーには、[W3C.REC-exi-20140211]で定義されているように、schemaIdが「a」の値に設定された「EXIオプション」を含める必要があり、この仕様で提供されるスキーマを示します。スキーマの将来の改訂により、下位互換性を可能にするためにschemaIdの値が変更される可能性があります。データがCoAPまたはHTTPを介して転送される場合は、EXI Cookieを使用しないでください。EXICookieは、単に物事を大きくし、Content-Typeヘッダーで提供される情報に対して冗長であるためです。
The following is the XSD Schema to be used for strict schema-guided EXI processing. It is generated from the RelaxNG.
以下は、スキーマに基づく厳密なEXI処理に使用されるXSDスキーマです。 RelaxNGから生成されます。
<?xml version="1.0" encoding="utf-8"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
targetNamespace="urn:ietf:params:xml:ns:senml"
xmlns:ns1="urn:ietf:params:xml:ns:senml">
<xs:element name="senml">
<xs:complexType>
<xs:attribute name="bn" type="xs:string" />
<xs:attribute name="bt" type="xs:double" />
<xs:attribute name="bv" type="xs:double" />
<xs:attribute name="bs" type="xs:double" />
<xs:attribute name="bu" type="xs:string" />
<xs:attribute name="bver" type="xs:int" />
<xs:attribute name="n" type="xs:string" />
<xs:attribute name="s" type="xs:double" />
<xs:attribute name="t" type="xs:double" />
<xs:attribute name="u" type="xs:string" />
<xs:attribute name="ut" type="xs:double" />
<xs:attribute name="v" type="xs:double" />
<xs:attribute name="vb" type="xs:boolean" />
<xs:attribute name="vs" type="xs:string" />
<xs:attribute name="vd" type="xs:string" />
</xs:complexType>
</xs:element>
<xs:element name="sensml">
<xs:complexType>
<xs:sequence>
<xs:element maxOccurs="unbounded" ref="ns1:senml" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
The following shows a hexdump of the EXI produced from encoding the following XML example. Note that this example is the same information as the first example in Section 5.1.2 but in JSON format.
以下は、以下のXMLの例をエンコードして生成されたEXIの16進ダンプを示しています。この例は、セクション5.1.2の最初の例と同じ情報ですが、JSON形式であることに注意してください。
<sensml xmlns="urn:ietf:params:xml:ns:senml"> <senml bn="urn:dev:ow:10e2073a01080063:" n="voltage" u="V" v="120.1"></senml> <senml n="current" u="A" v="1.2"></senml> </sensml> Which compresses with EXI to the following displayed in hexdump:
<sensml xmlns = "urn：ietf：params：xml：ns：senml"> <senml bn = "urn：dev：ow：10e2073a01080063：" n = "voltage" u = "V" v = "120.1"> </ senml> <senml n = "current" u = "A" v = "1.2"> </ senml> </ sensml>これは、EXIで圧縮して、hexdumpに次のように表示されます。
0000 a0 30 0d 84 80 f3 ab 93 71 d3 23 2b b1 d3 7b b9 |.0......q.#+..{.|
0010 d1 89 83 29 91 81 b9 9b 09 81 89 81 c1 81 81 b1 |...)............|
0020 99 d2 84 bb 37 b6 3a 30 b3 b2 90 1a b1 58 84 c0 |....7.:0.....X..|
0030 33 04 b1 ba b9 39 32 b7 3a 10 1a 09 06 40 38 |3....92.:....@8|
003f
The above example used the bit-packed form of EXI, but it is also possible to use a byte-packed form of EXI, which can make it easier for a simple sensor to produce valid EXI without really implementing EXI. Consider the example of a temperature sensor that produces a value in tenths of degrees Celsius over a range of 0.0 to 55.0. It would produce an XML SenML file such as:
上記の例では、ビットパック形式のEXIを使用しましたが、バイトパック形式のEXIを使用することもできます。これにより、単純なセンサーで実際にEXIを実装しなくても、簡単に有効なEXIを生成できます。 0.0から55.0の範囲で10分の1℃の値を生成する温度センサーの例を考えてみます。次のようなXML SenMLファイルが生成されます。
<sensml xmlns="urn:ietf:params:xml:ns:senml">
<senml n="urn:dev:ow:10e2073a01080063" u="Cel" v="23.1"></senml>
</sensml>
The compressed form, using the byte-alignment option of EXI, for the above XML is the following:
上記のXMLに対して、EXIのバイト配置オプションを使用した圧縮形式は次のとおりです。
0000 a0 00 48 80 6c 20 01 06 1d 75 72 6e 3a 64 65 76 |..H.l ...urn:dev|
0010 3a 6f 77 3a 31 30 65 32 30 37 33 61 30 31 30 38 |:ow:10e2073a0108|
0020 30 30 36 33 02 05 43 65 6c 01 00 e7 01 01 00 03 |0063..Cel.......|
0030 01 |.|
0031
A small temperature sensor device that only generates this one EXI file does not really need a full EXI implementation. It can simply hard code the output, replacing the 1-wire device ID starting at byte 0x14 and going to byte 0x23 with its device ID and replacing the value "0xe7 0x01" at location 0x2b and 0x2c with the current temperature. The EXI specification [W3C.REC-exi-20140211] contains the full information on how floating-point numbers are represented, but for the purpose of this sensor, the temperature can be converted to an integer in tenths of degrees (231 in this example). EXI stores 7 bits of the integer in each byte with the top bit set to one if there are further bytes. So, the first byte is set to the low 7 bits of the integer temperature in tenths of degrees plus 0x80. In this example, 231 & 0x7F + 0x80 = 0xE7. The second byte is set to the integer temperature in tenths of degrees right-shifted 7 bits. In this example, 231 >> 7 = 0x01.
この1つのEXIファイルのみを生成する小さな温度センサーデバイスは、完全なEXI実装を実際には必要としません。単純に出力をハードコーディングして、バイト0x14から始まり、バイト0x23に行く1-wireデバイスIDをデバイスIDに置き換え、位置0x2bおよび0x2cの値 "0xe7 0x01"を現在の温度に置き換えます。 EXI仕様[W3C.REC-exi-20140211]には、浮動小数点数の表現方法に関する完全な情報が含まれていますが、このセンサーの目的のために、温度を1/10度の整数に変換できます（この例では231） ）。 EXIは、各バイトに整数の7ビットを格納します。さらにバイトがある場合、最上位ビットは1に設定されます。したがって、最初のバイトは、整数の温度の10分の1度と0x80の下位7ビットに設定されます。この例では、231＆0x7F + 0x80 = 0xE7です。 2番目のバイトは、10分の1度単位で右シフトした7ビットの整数温度に設定されます。この例では、231 >> 7 = 0x01です。
A SenML Pack typically consists of multiple SenML Records, and for some applications, it may be useful to be able to refer to a single Record, or a set of Records, in a Pack with a fragment identifier. The fragment identifier is only interpreted by a client and does not impact retrieval of a representation. The SenML fragment identification is modeled after Comma-Separated Value (CSV) fragment identifiers [RFC7111].
通常、SenMLパックは複数のSenMLレコードで構成されます。一部のアプリケーションでは、フラグメント識別子を使用してパック内の単一のレコードまたはレコードのセットを参照できると便利な場合があります。フラグメント識別子はクライアントによってのみ解釈され、表現の取得には影響しません。 SenMLフラグメント識別は、カンマ区切り値（CSV）フラグメント識別子[RFC7111]をモデルにしています。
To select a single SenML Record, the "rec" scheme followed by a single number is used. For the purpose of numbering Records, the first Record is at position 1. A range of records can be selected by giving the first and the last record number separated by a "-" character. Instead of the second number, the "*" character can be used to indicate the last SenML Record in the Pack. A set of Records can also be selected using a comma-separated list of Record positions or ranges.
単一のSenMLレコードを選択するには、「rec」スキームとそれに続く単一の数値を使用します。レコードに番号を付けるために、最初のレコードは位置1にあります。「-」文字で区切られた最初と最後のレコード番号を指定することにより、レコードの範囲を選択できます。 2番目の数字の代わりに、「*」文字を使用して、パック内の最後のSenMLレコードを示すことができます。レコードのセットは、レコードの位置または範囲のコンマ区切りリストを使用して選択することもできます。
(We use the term "selecting a Record" for identifying it as part of the fragment, not in the sense of isolating it from the Pack -- the Record still needs to be interpreted as part of the Pack, e.g., using the base values defined in earlier Records.)
（「レコードを選択する」という用語は、それをパックから分離するという意味ではなく、フラグメントの一部として識別するために使用します-レコードは、たとえば、基本値を使用して、パックの一部として解釈される必要があります以前のレコードで定義されています。）
The 3rd SenML Record from the "coap://example.com/temp" resource can be selected with:
「coap：//example.com/temp」リソースからの3番目のSenMLレコードは、次のように選択できます。
coap://example.com/temp#rec=3
Records from 3rd to 6th can be selected with:
3番目から6番目までのレコードは、以下を使用して選択できます。
coap://example.com/temp#rec=3-6
Records from 19th to the last can be selected with:
19日から最後までのレコードは、次のようにして選択できます。
coap://example.com/temp#rec=19-*
The 3rd and 5th Records can be selected with:
3番目と5番目のレコードは、次の方法で選択できます。
coap://example.com/temp#rec=3,5
To select the Records from third to fifth, the 10th Record, and all Records from 19th to the last:
3番目から5番目までのレコード、10番目のレコード、および19番目から最後までのすべてのレコードを選択するには：
coap://example.com/temp#rec=3-5,10,19-*
In addition to the SenML fragment identifiers described above, with the XML and EXI SenML formats, the syntax defined in the XPointer element() Scheme [XPointerElement] of the XPointer Framework [XPointerFramework] can be used. (This is required by [RFC7303] for media types using the syntax suffix structured with "+xml". For consistency, SenML allows this for the EXI formats as well.)
上記のSenMLフラグメント識別子に加えて、XMLおよびEXI SenML形式では、XPointer Framework [XPointerFramework]のXPointer element()スキーム[XPointerElement]で定義された構文を使用できます。 （これは、[+ xml]で構造化された構文サフィックスを使用するメディアタイプの[RFC7303]で必要です。一貫性を保つために、SenMLは、EXIフォーマットでもこれを許可しています。）
Note that fragment identifiers are available to the client side only; they are not provided in transfer protocols such as CoAP or HTTP. Thus, they cannot be used by the server in deciding which media type to send. Where a server has multiple representations available for a resource identified by a URI, it might send a JSON or CBOR representation when the client was directed to use an XML/EXI fragment identifier with it. Clients can prevent running into this problem by explicitly requesting an XML or EXI media type (e.g., using the CoAP Accept option) when XML-/EXI-only fragment identifier syntax is in use in the URI.
フラグメント識別子はクライアント側でのみ使用できることに注意してください。 CoAPやHTTPなどの転送プロトコルでは提供されません。したがって、サーバーは、送信するメディアタイプを決定する際に使用できません。サーバーがURIで識別されるリソースで利用可能な複数の表現を持っている場合、クライアントがXML / EXIフラグメント識別子を使用するように指示されたときに、JSONまたはCBOR表現を送信する可能性があります。 XML- / EXI-onlyフラグメント識別子構文がURIで使用されている場合、クライアントは、明示的にXMLまたはEXIメディアタイプを要求する（たとえば、CoAP Acceptオプションを使用する）ことで、この問題の発生を防ぐことができます。
The measurements support sending both the current value of a sensor as well as an integrated sum. For many types of measurements, the sum is more useful than the current value. For historical reasons, this field is called "Sum" instead of "integral", which would more accurately describe its function. For example, an electrical meter that measures the energy a given computer uses will typically want to measure the cumulative amount of energy used. This is less prone to error than reporting the power each second and trying to have something on the server side sum together all the power measurements. If the network between the sensor and the meter goes down over some period of time, when it comes back up, the cumulative sum helps reflect what happened while the network was down. A meter like this would typically report a measurement with the unit set to watts, but it would put the sum of energy used in the "s" field of the measurement. It might optionally include the current power in the "v" field.
測定は、センサーの現在の値と統合された合計の両方の送信をサポートします。多くのタイプの測定では、合計は現在の値よりも役立ちます。歴史的な理由から、このフィールドは「積分」ではなく「和」と呼ばれ、その機能をより正確に説明します。たとえば、特定のコンピューターが使用するエネルギーを測定する電気メーターは、通常、使用されたエネルギーの累積量を測定する必要があります。これは、毎秒電力を報告し、サーバー側で何かを測定してすべての電力測定値を合計するよりもエラーが発生しにくい傾向があります。センサーとメーター間のネットワークが一定期間ダウンした場合、それが復旧すると、累積合計はネットワークがダウンしている間に何が起こったかを反映するのに役立ちます。このようなメーターは通常、単位がワットに設定された測定を報告しますが、使用されたエネルギーの合計を測定の「s」フィールドに入れます。オプションで、「v」フィールドに現在のパワーを含めることができます。
While the benefit of using the integrated sum is fairly clear for measurements like power and energy, it is less obvious for something like temperature. Reporting the sum of the temperature makes it easy to compute averages even when the individual temperature values are not reported frequently enough to compute accurate averages. Implementers are encouraged to report the cumulative sum as well as the raw value of a given sensor.
統合された合計を使用する利点は、電力やエネルギーなどの測定ではかなり明確ですが、温度などの場合はそれほど明白ではありません。温度の合計を報告すると、個々の温度値が正確な平均を計算するのに十分な頻度で報告されない場合でも、平均を簡単に計算できます。実装者は、特定のセンサーの累積値と未加工の値を報告することをお勧めします。
Applications that use the cumulative Sum values need to understand they are very loosely defined by this specification, and depending on the particular sensor implementation, they may behave in unexpected ways. Applications should be able to deal with the following issues:
累積合計値を使用するアプリケーションは、この仕様で非常に大まかに定義されていることを理解する必要があり、特定のセンサー実装によっては、予期しない方法で動作する可能性があります。アプリケーションは、次の問題を処理できる必要があります。
1. Many sensors will allow the cumulative sums to "wrap" back to zero after the value gets sufficiently large.
1. 多くのセンサーでは、値が十分に大きくなった後、累積合計をゼロに「折り返す」ことができます。
2. Some sensors will reset the cumulative sum back to zero when the device is reset, loses power, or is replaced with a different sensor.
2. 一部のセンサーは、デバイスがリセットされるか、電源が失われるか、別のセンサーと交換されると、累積合計をゼロにリセットします。
3. Applications cannot make assumptions about when the device started accumulating values into the sum.
3. アプリケーションは、デバイスがいつ合計に値を累積し始めたかについての仮定を行うことができません。
Typically, applications can make some assumptions about specific sensors that will allow them to deal with these problems. A common assumption is that for sensors whose measurement values are non-negative, the sum should never get smaller; if the sum does get smaller, the application will know that one of the situations listed above has happened.
通常、アプリケーションは、これらの問題に対処できる特定のセンサーについていくつかの仮定を行うことができます。一般的な仮定は、測定値が負でないセンサーの場合、合計が小さくなることはないということです。合計が小さくなると、アプリケーションは、上記の状況のいずれかが発生したことを認識します。
Despite the name "Sum", the Sum field is not useful for applications that maintain a running count of the number of times an event happened or that keep track of a counter such as the total number of bytes sent on an interface. Data like that can be sent directly in the Value field.
「Sum」という名前にもかかわらず、Sumフィールドは、イベントが発生した回数の実行中のカウントを維持するアプリケーション、またはインターフェイスで送信された合計バイト数などのカウンターを追跡するアプリケーションには役立ちません。そのようなデータは、「値」フィールドで直接送信できます。
As a convenient reference, the JSON and CBOR representations can be described with the common Concise Data Definition Language (CDDL) specification [CDDL-CBOR] in Figure 1 (informative).
便利なリファレンスとして、JSONおよびCBOR表現は、図1の共通の簡潔データ定義言語（CDDL）仕様[CDDL-CBOR]で記述できます（参考）。
SenML-Pack = [1* record]
record = {
? bn => tstr, ; Base Name
? bt => numeric, ; Base Time
? bu => tstr, ; Base Units
? bv => numeric, ; Base Value
? bs => numeric, ; Base Sum
? bver => uint, ; Base Version
? n => tstr, ; Name
? u => tstr, ; Units
? s => numeric, ; Sum
? t => numeric, ; Time
? ut => numeric, ; Update Time
? ( v => numeric // ; Numeric Value
vs => tstr // ; String Value
vb => bool // ; Boolean Value
vd => binary-value ) ; Data Value
* key-value-pair
}
; now define the generic versions
key-value-pair = ( label => value )
label = non-b-label / b-label
non-b-label = tstr .regexp "[A-Zac-z0-9][-_:.A-Za-z0-9]*" / uint
b-label = tstr .regexp "b[-_:.A-Za-z0-9]+" / nint
value = tstr / binary-value / numeric / bool
numeric = number / decfrac
Figure 1: Common CDDL Specification for CBOR and JSON SenML
図1：CBORおよびJSON SenMLの一般的なCDDL仕様
For JSON, we use text labels and base64url-encoded binary data (Figure 2).
JSONの場合、テキストラベルとbase64urlでエンコードされたバイナリデータを使用します（図2）。
bver = "bver" n = "n" s = "s"
bn = "bn" u = "u" t = "t"
bt = "bt" v = "v" ut = "ut"
bu = "bu" vs = "vs" vd = "vd"
bv = "bv" vb = "vb"
bs = "bs"
binary-value = tstr ; base64url encoded
バイナリ値= tstr; base64urlエンコード
Figure 2: JSON-Specific CDDL Specification for SenML
図2：SenMLのJSON固有のCDDL仕様
For CBOR, we use integer labels and native binary data (Figure 3).
CBORでは、整数ラベルとネイティブバイナリデータを使用します（図3）。
bver = -1 n = 0 s = 5
bn = -2 u = 1 t = 6
bt = -3 v = 2 ut = 7
bu = -4 vs = 3 vd = 8
bv = -5 vb = 4
bs = -6
binary-value = bstr
Figure 3: CBOR-Specific CDDL Specification for SenML
図3：SenMLのCBOR固有のCDDL仕様
IANA has created a new "Sensor Measurement Lists (SenML)" registry that contains the subregistries defined in Sections 12.1 and 12.2.
IANAは、セクション12.1および12.2で定義されたサブレジストリを含む新しい「センサー測定リスト（SenML）」レジストリを作成しました。
IANA has created a registry of SenML unit symbols called the "SenML Units" registry. The primary purpose of this registry is to make sure that symbols uniquely map to indicate a type of measurement. Definitions for many of these units can be found in other publications such as [NIST811] and [BIPM]. Units marked with an asterisk are NOT RECOMMENDED to be produced by new implementations but are in active use and SHOULD be implemented by consumers that can use the corresponding SenML units that are closer to the unscaled SI units.
IANAは、「SenMLユニット」レジストリと呼ばれるSenMLユニットシンボルのレジストリを作成しました。このレジストリの主な目的は、シンボルが一意にマッピングされ、測定のタイプを示すことを確認することです。これらの単位の多くの定義は、[NIST811]や[BIPM]などの他の出版物に記載されています。アスタリスクでマークされたユニットは、新しい実装によって生成されることはお勧めしませんが、アクティブに使用されており、スケーリングされていないSIユニットにより近い対応するSenMLユニットを使用できるコンシューマーによって実装されるべきです（SHOULD）。
+----------+------------------------------------+-------+-----------+
| Symbol | Description | Type | Reference |
+----------+------------------------------------+-------+-----------+
| m | meter | float | RFC 8428 |
| kg | kilogram | float | RFC 8428 |
| g | gram* | float | RFC 8428 |
| s | second | float | RFC 8428 |
| A | ampere | float | RFC 8428 |
| K | kelvin | float | RFC 8428 |
| cd | candela | float | RFC 8428 |
| mol | mole | float | RFC 8428 |
| Hz | hertz | float | RFC 8428 |
| rad | radian | float | RFC 8428 |
| sr | steradian | float | RFC 8428 |
| N | newton | float | RFC 8428 |
| Pa | pascal | float | RFC 8428 |
| J | joule | float | RFC 8428 |
| W | watt | float | RFC 8428 |
| C | coulomb | float | RFC 8428 |
| V | volt | float | RFC 8428 |
| F | farad | float | RFC 8428 |
| Ohm | ohm | float | RFC 8428 |
| S | siemens | float | RFC 8428 |
| Wb | weber | float | RFC 8428 |
| T | tesla | float | RFC 8428 |
| H | henry | float | RFC 8428 |
| Cel | degrees Celsius | float | RFC 8428 |
| lm | lumen | float | RFC 8428 |
| lx | lux | float | RFC 8428 |
| Bq | becquerel | float | RFC 8428 |
| Gy | gray | float | RFC 8428 |
| Sv | sievert | float | RFC 8428 |
| kat | katal | float | RFC 8428 |
| m2 | square meter (area) | float | RFC 8428 |
| m3 | cubic meter (volume) | float | RFC 8428 |
| l | liter (volume)* | float | RFC 8428 |
| m/s | meter per second (velocity) | float | RFC 8428 |
| m/s2 | meter per square second | float | RFC 8428 |
| | (acceleration) | | |
| m3/s | cubic meter per second (flow rate) | float | RFC 8428 |
| l/s | liter per second (flow rate)* | float | RFC 8428 |
| W/m2 | watt per square meter (irradiance) | float | RFC 8428 |
| cd/m2 | candela per square meter | float | RFC 8428 |
| | (luminance) | | |
| bit | bit (information content) | float | RFC 8428 |
| bit/s | bit per second (data rate) | float | RFC 8428 |
| lat | degrees latitude (Note 1) | float | RFC 8428 |
| lon | degrees longitude (Note 1) | float | RFC 8428 |
| pH | pH value (acidity; logarithmic | float | RFC 8428 |
| | quantity) | | |
| dB | decibel (logarithmic quantity) | float | RFC 8428 |
| dBW | decibel relative to 1 W (power | float | RFC 8428 |
| | level) | | |
| Bspl | bel (sound pressure level; | float | RFC 8428 |
| | logarithmic quantity)* | | |
| count | 1 (counter value) | float | RFC 8428 |
| / | 1 (ratio, e.g., value of a switch; | float | RFC 8428 |
| | Note 2) | | |
| % | 1 (ratio, e.g., value of a switch; | float | RFC 8428 |
| | Note 2)* | | |
| %RH | percentage (relative humidity) | float | RFC 8428 |
| %EL | percentage (remaining battery | float | RFC 8428 |
| | energy level) | | |
| EL | seconds (remaining battery energy | float | RFC 8428 |
| | level) | | |
| 1/s | 1 per second (event rate) | float | RFC 8428 |
| 1/min | 1 per minute (event rate, "rpm")* | float | RFC 8428 |
| beat/min | 1 per minute (heart rate in beats | float | RFC 8428 |
| | per minute)* | | |
| beats | 1 (cumulative number of heart | float | RFC 8428 |
| | beats)* | | |
| S/m | siemens per meter (conductivity) | float | RFC 8428 |
+----------+------------------------------------+-------+-----------+
Table 6: IANA Registry for SenML Units
表6：SenMLユニットのIANAレジストリ
o Note 1: Assumed to be in World Geodetic System 1984 (WGS84), unless another reference frame is known for the sensor.
o 注1：センサーの別の参照フレームが既知でない限り、World Geodetic System 1984（WGS84）にあると想定されます。
o Note 2: A value of 0.0 indicates the switch is off, 1.0 indicates on, and 0.5 indicates half on. The preferred name of this unit is "/". For historical reasons, the name "%" is also provided for the same unit, but note that while that name strongly suggests a percentage (0..100), it is NOT a percentage but the absolute ratio!
o 注2：値0.0はスイッチがオフ、1.0はオン、0.5はハーフオンを示します。このユニットの推奨名は「/」です。歴史的な理由により、「％」という名前も同じ単位に付けられていますが、その名前はパーセンテージ（0..100）を強く示唆していますが、パーセンテージではなく絶対比率です。
New entries can be added to the registration by Expert Review as defined in [RFC8126]. Experts should exercise their own good judgment but need to consider the following guidelines:
[RFC8126]で定義されているように、エキスパートレビューによって新しいエントリを登録に追加できます。専門家は独自の適切な判断を行う必要がありますが、次のガイドラインを考慮する必要があります。
1. There needs to be a real and compelling use for any new unit to be added.
1. 追加する新しいユニットには、実際の説得力のある使用方法が必要です。
2. Each unit should define the semantic information and be chosen carefully. Implementers need to remember that the same word may be used in different real-life contexts. For example, degrees when measuring latitude have no semantic relation to degrees when measuring temperature; thus, two different units are needed.
2. 各ユニットは意味情報を定義し、慎重に選択する必要があります。実装者は、同じ単語が実際のさまざまなコンテキストで使用される可能性があることを覚えておく必要があります。たとえば、緯度を測定する場合の度は、温度を測定する場合の度と意味的な関係はありません。したがって、2つの異なるユニットが必要です。
3. These measurements are produced by computers for consumption by computers. The principle is that conversion has to be easily done when both reading and writing the media type. The value of a single canonical representation outweighs the convenience of easy human representations or loss of precision in a conversion.
3. これらの測定値は、コンピューターによる消費のためにコンピューターによって生成されます。原則は、メディアタイプの読み取り時と書き込み時の両方で変換を簡単に行う必要があるということです。単一の正規表現の値は、人間による簡単な表現の便利さ、または変換の精度の低下を上回ります。
4. Use of System of Units (SI) prefixes such as "k" before the unit is not recommended. Instead, one can represent the value using scientific notation such as 1.2e3. The "kg" unit is an exception to this rule since it is an SI base unit; the "g" unit is provided for legacy compatibility.
4. 単位の前に "k"などの単位系（SI）プレフィックスを使用することはお勧めしません。代わりに、1.2e3などの科学表記法を使用して値を表すことができます。 「kg」単位はSI基本単位であるため、このルールの例外です。 「g」ユニットは、レガシー互換性のために提供されています。
5. For a given type of measurement, there will only be one unit type defined. So for length, meter is defined, and other lengths such as mile, foot, and light year are not allowed. For most cases, the SI unit is preferred.
5. 特定のタイプの測定では、1つの単位タイプのみが定義されます。したがって、長さについてはメートルが定義され、マイル、フィート、光年などの他の長さは許可されません。ほとんどの場合、SI単位が推奨されます。
(Note that some amount of judgment will be required here, as even SI itself is not entirely consistent in this respect. For instance, for temperature, [ISO-80000-5] defines a quantity, item 5-1 (thermodynamic temperature), and a corresponding unit of 5-1.a (Kelvin); [ISO-80000-5] goes on to define another quantity, item 5-2 ("Celsius temperature"), and the corresponding unit of 5-2.a (degree Celsius). The latter quantity is defined such that it gives the thermodynamic temperature as a delta from T0 = 275.15 K. ISO 80000-5 is defining both units side by side and not really expressing a preference. This level of recognition of the alternative unit degree Celsius is the reason why Celsius temperatures seem exceptionally acceptable in the SenML units list alongside Kelvin.)
（SI自体もこの点で完全に一貫しているわけではないため、ここではある程度の判断が必要になることに注意してください。たとえば、温度の場合、[ISO-80000-5]は数量、アイテム5-1（熱力学的温度）を定義します。および5-1.a（ケルビン）の対応する単位。[ISO-80000-5]は、別の数量、項目5-2（「摂氏温度」）、および5-2.aの対応する単位（後者の量は、熱力学温度をT0 = 275.15 Kからのデルタとして与えるように定義されています。ISO80000-5は、両方のユニットを並べて定義しており、実際には優先度を表していません。代替のこのレベルの認識摂氏単位度が、ケルビンと一緒にSenML単位リストで摂氏温度が非常に許容できるように見える理由です。）
6. Symbol names that could be easily confused with existing common units or units combined with prefixes should be avoided. For example, selecting a unit name of "mph" to indicate something that had nothing to do with velocity would be a bad choice, as "mph" is commonly used to mean "miles per hour".
6. 既存の一般的なユニットまたはプレフィックスと組み合わせたユニットと混同されやすいシンボル名は避けてください。たとえば、「mph」は一般的に「時速マイル」を意味するために使用されるため、「mph」という単位名を選択して速度とは何の関係もないことを示すことは悪い選択です。
7. The following should not be used because they are common SI prefixes: Y, Z, E, P, T, G, M, k, h, da, d, c, u, n, p, f, a, z, y, Ki, Mi, Gi, Ti, Pi, Ei, Zi, and Yi.
7. 次は一般的なSI接頭辞であるため使用しないでください：Y、Z、E、P、T、G、M、k、h、da、d、c、u、n、p、f、a、z、y 、Ki、Mi、Gi、Ti、Pi、Ei、Zi、およびYi。
8. The following units should not be used as they are commonly used to represent other measurements: Ky, Gal, dyn, etg, P, St, Mx, G, Oe, Gb, sb, Lmb, mph, Ci, R, RAD, REM, gal, bbl, qt, degF, Cal, BTU, HP, pH, B/s, psi, Torr, atm, at, bar, and kWh.
8. 次の単位は、他の測定を表すために一般的に使用されるため、使用しないでください。Ky、Gal、dyn、etg、P、St、Mx、G、Oe、Gb、sb、Lmb、mph、Ci、R、RAD、REM 、gal、bbl、qt、degF、Cal、BTU、HP、pH、B / s、psi、Torr、atm、at、bar、kWh。
9. The unit names are case sensitive, and the correct case needs to be used; however, symbols that differ only in case should not be allocated.
9. ユニット名は大文字と小文字が区別され、正しい大文字と小文字を使用する必要があります。ただし、大文字と小文字のみが異なるシンボルは割り当てないでください。
10. A number after a unit typically indicates the previous unit raised to that power, and "/" indicates that the units that follow are the reciprocals. A unit should have only one "/" in the name.
10. ユニットの後の数字は、通常、その累乗された前のユニットを示し、「/」は、後続のユニットが逆数であることを示します。ユニットの名前には「/」を1つだけ含める必要があります。
11. A good list of common units can be found in the Unified Code for Units of Measure [UCUM].
11. 一般的な単位の適切なリストは、測定単位の統一コード[UCUM]にあります。
IANA has created a new registry for SenML Labels called the "SenML Labels" registry. The initial contents of the registry are as follows:
IANAは、「SenMLラベル」レジストリと呼ばれるSenMLラベル用の新しいレジストリを作成しました。レジストリの初期内容は次のとおりです。
+--------------+-------+----+-----------+----------+----+-----------+
| Name | Label | CL | JSON Type | XML Type | EI | Reference |
+--------------+-------+----+-----------+----------+----+-----------+
| Base Name | bn | -2 | String | string | a | RFC 8428 |
| Base Time | bt | -3 | Number | double | a | RFC 8428 |
| Base Unit | bu | -4 | String | string | a | RFC 8428 |
| Base Value | bv | -5 | Number | double | a | RFC 8428 |
| Base Sum | bs | -6 | Number | double | a | RFC 8428 |
| Base Version | bver | -1 | Number | int | a | RFC 8428 |
| Name | n | 0 | String | string | a | RFC 8428 |
| Unit | u | 1 | String | string | a | RFC 8428 |
| Value | v | 2 | Number | double | a | RFC 8428 |
| String Value | vs | 3 | String | string | a | RFC 8428 |
| Boolean | vb | 4 | Boolean | boolean | a | RFC 8428 |
| Value | | | | | | |
| Data Value | vd | 8 | String | string | a | RFC 8428 |
| Sum | s | 5 | Number | double | a | RFC 8428 |
| Time | t | 6 | Number | double | a | RFC 8428 |
| Update Time | ut | 7 | Number | double | a | RFC 8428 |
+--------------+-------+----+-----------+----------+----+-----------+
Note that CL = CBOR Label and EI = EXI ID.
CL = CBORラベルおよびEI = EXI IDであることに注意してください。
Table 7: IANA Registry for SenML Labels
表7：SenMLラベルのIANAレジストリ
This is the same table as Table 1, with notes removed and columns added for the information that is all the same for this initial set of registrations, but it will need to be supplied with different values for new registrations.
これは表1と同じ表ですが、この最初の登録セットではすべて同じである情報のためにメモが削除され、列が追加されていますが、新しい登録には異なる値を指定する必要があります。
All new entries must define the Name, Label, and XML Type, but the CBOR labels SHOULD be left empty as CBOR will use the string encoding for any new labels. The EI column contains the EXI schemaId value of the first schema that includes this label, or it is empty if this label was not intended for use with EXI. The Reference column SHOULD contain information about where to find out more information about this label.
すべての新しいエントリは名前、ラベル、XMLタイプを定義する必要がありますが、CBORは新しいラベルに文字列エンコーディングを使用するため、CBORラベルは空のままにする必要があります。 EI列には、このラベルを含む最初のスキーマのEXI schemaId値が含まれます。このラベルがEXIでの使用を目的としていない場合は、空です。参照列には、このラベルに関する詳細情報の入手先に関する情報を含める必要があります（SHOULD）。
The JSON, CBOR, and EXI types are derived from the XML type. All XML numeric types such as double, float, integer, and int become a JSON Number. XML boolean and string become a JSON Boolean and String, respectively. CBOR represents numeric values with a CBOR type that does not lose any information from the JSON value. EXI uses the XML types.
JSON、CBOR、およびEXIタイプは、XMLタイプから派生します。 double、float、integer、intなどのすべてのXML数値型は、JSON番号になります。 XMLのブール値と文字列は、それぞれJSONのブール値と文字列になります。 CBORは、JSON値から情報を失わないCBORタイプの数値を表します。 EXIはXMLタイプを使用します。
New entries can be added to the registration by Expert Review as defined in [RFC8126]. Experts should exercise their own good judgment but need to consider that shorter labels should have more strict review. New entries should not be made that counteract the advice at the end of Section 4.5.4.
[RFC8126]で定義されているように、エキスパートレビューによって新しいエントリを登録に追加できます。専門家は独自の適切な判断を行う必要がありますが、短いラベルにはより厳密なレビューが必要であることを考慮する必要があります。セクション4.5.4の最後にあるアドバイスに反するような新しいエントリは作成しないでください。
All new SenML Labels that have "base" semantics (see Section 4.1) MUST start with the character "b". Regular labels MUST NOT start with that character. All new SenML Labels with Value semantics (see Section 4.2) MUST have "Value" in their (long-form) name.
「基本」セマンティクス（セクション4.1を参照）を持つすべての新しいSenMLラベルは、文字「b」で始める必要があります。通常のラベルは、その文字で始めることはできません。値のセマンティクスを持つ新しいすべてのSenMLラベル（セクション4.2を参照）は、その（長い形式の）名前に「値」を含める必要があります。
Extensions that add a label intended for use with XML need to create a new RelaxNG Schema that includes all the labels in the "SenML Labels" registry.
XMLでの使用を目的としたラベルを追加する拡張機能では、「SenMLラベル」レジストリ内のすべてのラベルを含む新しいRelaxNGスキーマを作成する必要があります。
Extensions that add a label that is intended for use with EXI need to create a new XSD Schema that includes all the labels in the "SenML Labels" registry and then allocate a new EXI schemaId value. Moving to the next letter in the alphabet is the suggested way to create the new value for the EXI schemaId. Any labels with previously blank ID values SHOULD be updated in the "SenML Labels" registry to have their ID set to this new schemaId value.
EXIでの使用を目的としたラベルを追加する拡張機能は、「SenMLラベル」レジストリ内のすべてのラベルを含む新しいXSDスキーマを作成し、新しいEXI schemaId値を割り当てる必要があります。アルファベットの次の文字に移動することは、EXI schemaIdの新しい値を作成するための推奨方法です。以前に空白のID値を持つラベルは、 "SenML Labels"レジストリで更新して、IDをこの新しいschemaId値に設定する必要があります。
Extensions that are mandatory to understand to correctly process the Pack MUST have a label name that ends with the "_" character.
パックを正しく処理するために理解する必要がある拡張には、「_」文字で終わるラベル名が必要です。
The registrations in the subsections below follow the procedures specified in [RFC6838] and [RFC7303]. This document registers media types for each serialization format of SenML (JSON, CBOR, XML, and EXI) and also a corresponding set of media types for streaming use (SenSML; see Section 4.8). Clipboard formats are defined for the JSON and XML forms of SenML but not for streams or non-textual formats.
以下のサブセクションの登録は、[RFC6838]および[RFC7303]で指定された手順に従います。このドキュメントでは、SenMLの各シリアル化形式（JSON、CBOR、XML、EXI）のメディアタイプと、ストリーミングで使用するための対応するメディアタイプのセット（SenSML、セクション4.8を参照）を登録します。クリップボード形式は、SenMLのJSONおよびXML形式に対して定義されていますが、ストリーム形式または非テキスト形式に対しては定義されていません。
The reason there are both SenML and the streaming SenSML formats is that they are not the same data formats, and they require separate negotiation to understand if they are supported and which one is being used. The non-streaming format is required to have some sort of end-of-pack syntax that indicates there will be no more records. Many implementations that receive SenML wait for this end-of-pack marker before processing any of the records. On the other hand, with the streaming formats, it is explicitly not required to wait for this end-of-pack marker. Many implementations that produce streaming SenSML will never send this end-of-pack marker, so implementations that receive streaming SenSML cannot wait for the end-of-pack marker before they start processing the records. Given that SenML and streaming SenML are different data formats, and considering the requirement for separate negotiation, a media type for each one is needed.
SenMLとストリーミングSenSMLの両方の形式がある理由は、それらが同じデータ形式ではなく、サポートされているかどうか、およびどちらが使用されているかを理解するために、別々のネゴシエーションが必要なためです。非ストリーミング形式には、これ以上レコードがないことを示す何らかのパックの終わりの構文が必要です。 SenMLを受信する多くの実装は、このend-of-packマーカーを待ってからレコードを処理します。一方、ストリーミング形式では、このパック終了マーカーを待つ必要はありません。ストリーミングSenSMLを生成する多くの実装は、このパック終了マーカーを送信しないため、ストリーミングSenSMLを受信する実装は、レコードの処理を開始する前にパック終了マーカーを待つことができません。 SenMLとストリーミングSenMLは異なるデータ形式であり、個別のネゴシエーションの要件を考慮すると、それぞれのメディアタイプが必要です。
Type name: application
タイプ名：アプリケーション
Subtype name: senml+json
サブタイプ名：senml + json
Required parameters: none
必須パラメーター：なし
Optional parameters: none
オプションのパラメーター：なし
Encoding considerations: Must be encoded as using a subset of the encoding allowed in [RFC8259]. See RFC 8428 for details. This simplifies implementation of a very simple system and does not impose any significant limitations as all this data is meant for machine-to-machine communications and is not meant to be human readable.
エンコーディングに関する考慮事項：[RFC8259]で許可されているエンコーディングのサブセットを使用するようにエンコードする必要があります。詳細については、RFC 8428を参照してください。これにより、非常に単純なシステムの実装が簡素化され、これらのデータはすべてマシン間通信用であり、人間が読み取れるものではないため、大きな制限はありません。
Security considerations: See Section 13 of RFC 8428.
セキュリティに関する考慮事項：RFC 8428のセクション13をご覧ください。
Interoperability considerations: Applications MUST ignore any JSON key-value pairs that they do not understand unless the key ends with the "_" character, in which case an error MUST be generated. This allows backwards-compatible extensions to this specification. The "bver" field can be used to ensure the receiver supports a minimal level of functionality needed by the creator of the JSON object.
相互運用性に関する考慮事項：アプリケーションは、キーが「_」文字で終了しない限り、理解できないJSONのキーと値のペアを無視する必要があります。この場合、エラーが生成される必要があります。これにより、この仕様に対する下位互換性のある拡張が可能になります。 「bver」フィールドを使用すると、JSONオブジェクトの作成者が必要とする最低レベルの機能をレシーバーが確実にサポートできるようになります。
Published specification: RFC 8428
公開された仕様：RFC 8428
Applications that use this media type: The type is used by systems that report, e.g., electrical power usage and environmental information such as temperature and humidity. It can be used for a wide range of sensor reporting systems.
このメディアタイプを使用するアプリケーション：このタイプは、電力使用量や温度や湿度などの環境情報などを報告するシステムで使用されます。さまざまなセンサーレポートシステムに使用できます。
Fragment identifier considerations: Fragment identification for application/senml+json is supported by using fragment identifiers as specified by RFC 8428.
フラグメント識別子の考慮事項：RFC 8428で指定されているフラグメント識別子を使用することにより、application / senml + jsonのフラグメント識別がサポートされます。
Additional information:
追加情報：
Deprecated alias names for this type: N/A
このタイプの非推奨のエイリアス名：N / A
Magic number(s): N/A
File extension(s): senml
ファイル拡張子：senml
Windows Clipboard Name: "JSON Sensor Measurement List"
Windowsクリップボード名：「JSONセンサー測定リスト」
Macintosh file type code(s): none
Macintoshファイルタイプコード：なし
Macintosh Universal Type Identifier code: org.ietf.senml-json conforms to public.text
Macintoshユニバーサルタイプ識別子コード：org.ietf.senml-jsonはpublic.textに準拠しています
Person & email address to contact for further information:
Cullen Jennings <fluffy@iii.ca>
Intended usage: COMMON
使用目的：COMMON
Restrictions on usage: None
使用上の制限：なし
Author: Cullen Jennings <fluffy@iii.ca>
Change controller: IESG
コントローラーの変更：IESG
Type name: application
タイプ名：アプリケーション
Subtype name: sensml+json
サブタイプ名：sensml + json
Required parameters: none
必須パラメーター：なし
Optional parameters: none
オプションのパラメーター：なし
Encoding considerations: Must be encoded as using a subset of the encoding allowed in [RFC8259]. See RFC 8428 for details. This simplifies implementation of a very simple system and does not impose any significant limitations as all this data is meant for machine-to-machine communications and is not meant to be human readable.
エンコーディングに関する考慮事項：[RFC8259]で許可されているエンコーディングのサブセットを使用するようにエンコードする必要があります。詳細については、RFC 8428を参照してください。これにより、非常に単純なシステムの実装が簡素化され、これらのデータはすべてマシン間通信用であり、人間が読み取れるものではないため、大きな制限はありません。
Security considerations: See Section 13 of RFC 8428.
セキュリティに関する考慮事項：RFC 8428のセクション13をご覧ください。
Interoperability considerations: Applications MUST ignore any JSON key-value pairs that they do not understand unless the key ends with the "_" character, in which case an error MUST be generated. This allows backwards-compatible extensions to this specification. The "bver" field can be used to ensure the receiver supports a minimal level of functionality needed by the creator of the JSON object.
相互運用性に関する考慮事項：アプリケーションは、キーが「_」文字で終了しない限り、理解できないJSONのキーと値のペアを無視する必要があります。この場合、エラーが生成される必要があります。これにより、この仕様に対する下位互換性のある拡張が可能になります。 「bver」フィールドを使用すると、JSONオブジェクトの作成者が必要とする最低レベルの機能をレシーバーが確実にサポートできるようになります。
Published specification: RFC 8428
公開された仕様：RFC 8428
Applications that use this media type: The type is used by systems that report, e.g., electrical power usage and environmental information such as temperature and humidity. It can be used for a wide range of sensor reporting systems.
このメディアタイプを使用するアプリケーション：このタイプは、電力使用量や温度や湿度などの環境情報などを報告するシステムで使用されます。さまざまなセンサーレポートシステムに使用できます。
Fragment identifier considerations: Fragment identification for application/sensml+json is supported by using fragment identifiers as specified by RFC 8428.
フラグメント識別子の考慮事項：RFC 8428で指定されているフラグメント識別子を使用することにより、application / sensml + jsonのフラグメント識別がサポートされます。
Additional information:
追加情報：
Deprecated alias names for this type: N/A
このタイプの非推奨のエイリアス名：N / A
Magic number(s): N/A
File extension(s): sensml
ファイル拡張子：sensml
Macintosh file type code(s): none
Macintoshファイルタイプコード：なし
Person & email address to contact for further information:
Cullen Jennings <fluffy@iii.ca>
Intended usage: COMMON
使用目的：COMMON
Restrictions on usage: None
使用上の制限：なし
Author: Cullen Jennings <fluffy@iii.ca>
Change controller: IESG
コントローラーの変更：IESG
Type name: application
タイプ名：アプリケーション
Subtype name: senml+cbor
サブタイプ名：senml + cbor
Required parameters: none
必須パラメーター：なし
Optional parameters: none
オプションのパラメーター：なし
Encoding considerations: Must be encoded as using [RFC7049]. See RFC 8428 for details.
エンコードに関する考慮事項：[RFC7049]を使用するようにエンコードする必要があります。詳細については、RFC 8428を参照してください。
Security considerations: See Section 13 of RFC 8428.
セキュリティに関する考慮事項：RFC 8428のセクション13をご覧ください。
Interoperability considerations: Applications MUST ignore any key-value pairs that they do not understand unless the key ends with the "_" character, in which case an error MUST be generated. This allows backwards-compatible extensions to this specification. The "bver" field can be used to ensure the receiver supports a minimal level of functionality needed by the creator of the CBOR object.
相互運用性に関する考慮事項：キーが「_」文字で終わっていない限り、アプリケーションは、理解できないキーと値のペアを無視する必要があります。この場合、エラーが生成される必要があります。これにより、この仕様に対する下位互換性のある拡張が可能になります。 「bver」フィールドは、レシーバーがCBORオブジェクトの作成者が必要とする最低レベルの機能をサポートするようにするために使用できます。
Published specification: RFC 8428
公開された仕様：RFC 8428
Applications that use this media type: The type is used by systems that report, e.g., electrical power usage and environmental information such as temperature and humidity. It can be used for a wide range of sensor reporting systems.
このメディアタイプを使用するアプリケーション：このタイプは、電力使用量や温度や湿度などの環境情報などを報告するシステムで使用されます。さまざまなセンサーレポートシステムに使用できます。
Fragment identifier considerations: Fragment identification for application/senml+cbor is supported by using fragment identifiers as specified by RFC 8428.
フラグメント識別子の考慮事項：RFC 8428で指定されているフラグメント識別子を使用することにより、application / senml + cborのフラグメント識別がサポートされます。
Additional information:
追加情報：
Deprecated alias names for this type: N/A
このタイプの非推奨のエイリアス名：N / A
Magic number(s): N/A
File extension(s): senmlc
ファイル拡張子：senmlc
Macintosh file type code(s): none
Macintoshファイルタイプコード：なし
Macintosh Universal Type Identifier code: org.ietf.senml-cbor conforms to public.data
Macintoshユニバーサルタイプ識別子コード：org.ietf.senml-cborはpublic.dataに準拠
Person & email address to contact for further information:
Cullen Jennings <fluffy@iii.ca>
Intended usage: COMMON
使用目的：COMMON
Restrictions on usage: None
使用上の制限：なし
Author: Cullen Jennings <fluffy@iii.ca>
Change controller: IESG
コントローラーの変更：IESG
Type name: application
タイプ名：アプリケーション
Subtype name: sensml+cbor
サブタイプ名：sensml + cbor
Required parameters: none
必須パラメーター：なし
Optional parameters: none
オプションのパラメーター：なし
Encoding considerations: Must be encoded as using [RFC7049]. See RFC 8428 for details.
エンコードに関する考慮事項：[RFC7049]を使用するようにエンコードする必要があります。詳細については、RFC 8428を参照してください。
Security considerations: See Section 13 of RFC 8428.
セキュリティに関する考慮事項：RFC 8428のセクション13をご覧ください。
Interoperability considerations: Applications MUST ignore any key-value pairs that they do not understand unless the key ends with the "_" character, in which case an error MUST be generated. This allows backwards-compatible extensions to this specification. The "bver" field can be used to ensure the receiver supports a minimal level of functionality needed by the creator of the CBOR object.
相互運用性に関する考慮事項：キーが「_」文字で終わっていない限り、アプリケーションは、理解できないキーと値のペアを無視する必要があります。この場合、エラーが生成される必要があります。これにより、この仕様に対する下位互換性のある拡張が可能になります。 「bver」フィールドは、レシーバーがCBORオブジェクトの作成者が必要とする最低レベルの機能をサポートするようにするために使用できます。
Published specification: RFC 8428
公開された仕様：RFC 8428
Applications that use this media type: The type is used by systems that report, e.g., electrical power usage and environmental information such as temperature and humidity. It can be used for a wide range of sensor reporting systems.
このメディアタイプを使用するアプリケーション：このタイプは、電力使用量や温度や湿度などの環境情報などを報告するシステムで使用されます。さまざまなセンサーレポートシステムに使用できます。
Fragment identifier considerations: Fragment identification for application/sensml+cbor is supported by using fragment identifiers as specified by RFC 8428.
フラグメント識別子の考慮事項：RFC 8428で指定されているフラグメント識別子を使用することにより、application / sensml + cborのフラグメント識別がサポートされます。
Additional information:
追加情報：
Deprecated alias names for this type: N/A
このタイプの非推奨のエイリアス名：N / A
Magic number(s): N/A
File extension(s): sensmlc
ファイル拡張子：sensmlc
Macintosh file type code(s): none
Macintoshファイルタイプコード：なし
Person & email address to contact for further information:
Cullen Jennings <fluffy@iii.ca>
Intended usage: COMMON Restrictions on usage: None
使用目的：共通使用上の制限：なし
Author: Cullen Jennings <fluffy@iii.ca>
Change controller: IESG
コントローラーの変更：IESG
Type name: application
タイプ名：アプリケーション
Subtype name: senml+xml
サブタイプ名：senml + xml
Required parameters: none
必須パラメーター：なし
Optional parameters: none
オプションのパラメーター：なし
Encoding considerations: Must be encoded as using [W3C.REC-xml-20081126]. See RFC 8428 for details.
エンコードに関する考慮事項：[W3C.REC-xml-20081126]を使用するようにエンコードする必要があります。詳細については、RFC 8428を参照してください。
Security considerations: See Section 13 of RFC 8428.
セキュリティに関する考慮事項：RFC 8428のセクション13をご覧ください。
Interoperability considerations: Applications MUST ignore any XML tags or attributes that they do not understand unless the attribute name ends with the "_" character, in which case an error MUST be generated. This allows backwards-compatible extensions to this specification. The "bver" attribute in the senml XML tag can be used to ensure the receiver supports a minimal level of functionality needed by the creator of the XML SenML Pack.
相互運用性に関する考慮事項：アプリケーションは、属性名が「_」文字で終了しない限り、理解できないXMLタグまたは属性を無視する必要があります。この場合、エラーが生成される必要があります。これにより、この仕様に対する下位互換性のある拡張が可能になります。 senml XMLタグの「bver」属性を使用して、レシーバーがXML SenMLパックの作成者が必要とする最低レベルの機能をサポートするようにすることができます。
Published specification: RFC 8428
公開された仕様：RFC 8428
Applications that use this media type: The type is used by systems that report, e.g., electrical power usage and environmental information such as temperature and humidity. It can be used for a wide range of sensor reporting systems.
このメディアタイプを使用するアプリケーション：このタイプは、電力使用量や温度や湿度などの環境情報などを報告するシステムで使用されます。さまざまなセンサーレポートシステムに使用できます。
Fragment identifier considerations: Fragment identification for application/senml+xml is supported by using fragment identifiers as specified by RFC 8428.
フラグメント識別子の考慮事項：application / senml + xmlのフラグメント識別は、RFC 8428で指定されているフラグメント識別子を使用してサポートされています。
Additional information:
追加情報：
Deprecated alias names for this type: N/A
このタイプの非推奨のエイリアス名：N / A
Magic number(s): N/A
File extension(s): senmlx Windows Clipboard Name: "XML Sensor Measurement List"
ファイル拡張子：senmlx Windows Clipboard Name： "XML Sensor Measurement List"
Macintosh file type code(s): none
Macintoshファイルタイプコード：なし
Macintosh Universal Type Identifier code: org.ietf.senml-xml conforms to public.xml
Macintoshユニバーサルタイプ識別子コード：org.ietf.senml-xmlはpublic.xmlに準拠
Person & email address to contact for further information:
Cullen Jennings <fluffy@iii.ca>
Intended usage: COMMON
使用目的：COMMON
Restrictions on usage: None
使用上の制限：なし
Author: Cullen Jennings <fluffy@iii.ca>
Change controller: IESG
コントローラーの変更：IESG
Type name: application
タイプ名：アプリケーション
Subtype name: sensml+xml
サブタイプ名：sensml + xml
Required parameters: none
必須パラメーター：なし
Optional parameters: none
オプションのパラメーター：なし
Encoding considerations: Must be encoded as using [W3C.REC-xml-20081126]. See RFC 8428 for details.
エンコードに関する考慮事項：[W3C.REC-xml-20081126]を使用するようにエンコードする必要があります。詳細については、RFC 8428を参照してください。
Security considerations: See Section 13 of RFC 8428.
セキュリティに関する考慮事項：RFC 8428のセクション13をご覧ください。
Interoperability considerations: Applications MUST ignore any XML tags or attributes that they do not understand unless the attribute name ends with the "_" character, in which case an error MUST be generated. This allows backwards-compatible extensions to this specification. The "bver" attribute in the senml XML tag can be used to ensure the receiver supports a minimal level of functionality needed by the creator of the XML SenML Pack.
相互運用性に関する考慮事項：アプリケーションは、属性名が「_」文字で終了しない限り、理解できないXMLタグまたは属性を無視する必要があります。この場合、エラーが生成される必要があります。これにより、この仕様に対する下位互換性のある拡張が可能になります。 senml XMLタグの「bver」属性を使用して、レシーバーがXML SenMLパックの作成者が必要とする最低レベルの機能をサポートするようにすることができます。
Published specification: RFC 8428
公開された仕様：RFC 8428
Applications that use this media type: The type is used by systems that report, e.g., electrical power usage and environmental information such as temperature and humidity. It can be used for a wide range of sensor reporting systems.
このメディアタイプを使用するアプリケーション：このタイプは、電力使用量や温度や湿度などの環境情報などを報告するシステムで使用されます。さまざまなセンサーレポートシステムに使用できます。
Fragment identifier considerations: Fragment identification for application/sensml+xml is supported by using fragment identifiers as specified by RFC 8428.
フラグメント識別子の考慮事項：RFC 8428で指定されているフラグメント識別子を使用することにより、application / sensml + xmlのフラグメント識別がサポートされます。
Additional information:
追加情報：
Deprecated alias names for this type: N/A
このタイプの非推奨のエイリアス名：N / A
Magic number(s): N/A
File extension(s): sensmlx
ファイル拡張子：sensmlx
Macintosh file type code(s): none
Macintoshファイルタイプコード：なし
Person & email address to contact for further information:
Cullen Jennings <fluffy@iii.ca>
Intended usage: COMMON
使用目的：COMMON
Restrictions on usage: None
使用上の制限：なし
Author: Cullen Jennings <fluffy@iii.ca>
Change controller: IESG
コントローラーの変更：IESG
Type name: application
タイプ名：アプリケーション
Subtype name: senml-exi
サブタイプ名：senml-exi
Required parameters: none
必須パラメーター：なし
Optional parameters: none
オプションのパラメーター：なし
Encoding considerations: Must be encoded as using [W3C.REC-exi-20140211]. See RFC 8428 for details.
エンコードに関する考慮事項：[W3C.REC-exi-20140211]を使用するようにエンコードする必要があります。詳細については、RFC 8428を参照してください。
Security considerations: See Section 13 of RFC 8428.
セキュリティに関する考慮事項：RFC 8428のセクション13をご覧ください。
Interoperability considerations: Applications MUST ignore any XML tags or attributes that they do not understand unless the attribute name ends with the "_" character, in which case an error MUST be generated. This allows backwards-compatible extensions to this specification. The "bver" attribute in the senml XML tag can be used to ensure the receiver supports a minimal level of functionality needed by the creator of the XML SenML Pack. Further information on using schemas to guide the EXI can be found in RFC 8428.
相互運用性に関する考慮事項：アプリケーションは、属性名が「_」文字で終了しない限り、理解できないXMLタグまたは属性を無視する必要があります。この場合、エラーが生成される必要があります。これにより、この仕様に対する下位互換性のある拡張が可能になります。 senml XMLタグの「bver」属性を使用して、レシーバーがXML SenMLパックの作成者が必要とする最低レベルの機能をサポートするようにすることができます。スキーマを使用してEXIをガイドする方法の詳細については、RFC 8428を参照してください。
Published specification: RFC 8428
公開された仕様：RFC 8428
Applications that use this media type: The type is used by systems that report, e.g., electrical power usage and environmental information such as temperature and humidity. It can be used for a wide range of sensor reporting systems.
このメディアタイプを使用するアプリケーション：このタイプは、電力使用量や温度や湿度などの環境情報などを報告するシステムで使用されます。さまざまなセンサーレポートシステムに使用できます。
Fragment identifier considerations: Fragment identification for application/senml-exi is supported by using fragment identifiers as specified by RFC 8428.
フラグメント識別子の考慮事項：application / senml-exiのフラグメント識別は、RFC 8428で指定されているフラグメント識別子を使用してサポートされています。
Additional information:
追加情報：
Deprecated alias names for this type: N/A
このタイプの非推奨のエイリアス名：N / A
Magic number(s): N/A
File extension(s): senmle
ファイル拡張子：senmle
Macintosh file type code(s): none
Macintoshファイルタイプコード：なし
Macintosh Universal Type Identifier code: org.ietf.senml-exi conforms to public.data
Macintoshユニバーサルタイプ識別子コード：org.ietf.senml-exiはpublic.dataに準拠
Person & email address to contact for further information:
Cullen Jennings <fluffy@iii.ca>
Intended usage: COMMON
使用目的：COMMON
Restrictions on usage: None
使用上の制限：なし
Author: Cullen Jennings <fluffy@iii.ca>
Change controller: IESG
コントローラーの変更：IESG
Type name: application
タイプ名：アプリケーション
Subtype name: sensml-exi
サブタイプ名：sensml-exi
Required parameters: none
必須パラメーター：なし
Optional parameters: none
オプションのパラメーター：なし
Encoding considerations: Must be encoded as using [W3C.REC-exi-20140211]. See RFC 8428 for details.
エンコードに関する考慮事項：[W3C.REC-exi-20140211]を使用するようにエンコードする必要があります。詳細については、RFC 8428を参照してください。
Security considerations: See Section 13 of RFC 8428.
セキュリティに関する考慮事項：RFC 8428のセクション13をご覧ください。
Interoperability considerations: Applications MUST ignore any XML tags or attributes that they do not understand unless the attribute name ends with the "_" character, in which case an error MUST be generated. This allows backwards-compatible extensions to this specification. The "bver" attribute in the senml XML tag can be used to ensure the receiver supports a minimal level of functionality needed by the creator of the XML SenML Pack. Further information on using schemas to guide the EXI can be found in RFC 8428.
相互運用性に関する考慮事項：アプリケーションは、属性名が「_」文字で終了しない限り、理解できないXMLタグまたは属性を無視する必要があります。この場合、エラーが生成される必要があります。これにより、この仕様に対する下位互換性のある拡張が可能になります。 senml XMLタグの「bver」属性を使用して、レシーバーがXML SenMLパックの作成者が必要とする最低レベルの機能をサポートするようにすることができます。スキーマを使用してEXIをガイドする方法の詳細については、RFC 8428を参照してください。
Published specification: RFC 8428
公開された仕様：RFC 8428
Applications that use this media type: The type is used by systems that report, e.g., electrical power usage and environmental information such as temperature and humidity. It can be used for a wide range of sensor reporting systems.
このメディアタイプを使用するアプリケーション：このタイプは、電力使用量や温度や湿度などの環境情報などを報告するシステムで使用されます。さまざまなセンサーレポートシステムに使用できます。
Fragment identifier considerations: Fragment identification for application/sensml-exi is supported by using fragment identifiers as specified by RFC 8428.
フラグメント識別子の考慮事項：application / sensml-exiのフラグメント識別は、RFC 8428で指定されているフラグメント識別子を使用することでサポートされます。
Additional information:
追加情報：
Deprecated alias names for this type: N/A
このタイプの非推奨のエイリアス名：N / A
Magic number(s): N/A
File extension(s): sensmle
ファイル拡張子：sensmle
Macintosh file type code(s): none
Macintoshファイルタイプコード：なし
Person & email address to contact for further information:
Cullen Jennings <fluffy@iii.ca>
Intended usage: COMMON
使用目的：COMMON
Restrictions on usage: None
使用上の制限：なし
Author: Cullen Jennings <fluffy@iii.ca>
Change controller: IESG
コントローラーの変更：IESG
This document registers the following XML namespace in the "IETF XML Registry" defined in [RFC3688].
このドキュメントは、[RFC3688]で定義されている「IETF XMLレジストリ」に次のXML名前空間を登録します。
URI: urn:ietf:params:xml:ns:senml
Registrant Contact: The IESG.
登録者の連絡先：IESG。
XML: N/A, the requested URIs are XML namespaces
XML：N / A、リクエストされたURIはXML名前空間です
IANA has assigned CoAP Content-Format IDs for the SenML media types in the "CoAP Content-Formats" subregistry within the "Constrained RESTful Environments (CoRE) Parameters" registry [RFC7252]. IDs for the JSON, CBOR, and EXI Content-Formats have been assigned in the 0-255 range (Expert Review), and IDs for the XML Content-Formats have been assigned in the 256-9999 range (IETF Review or IESG Approval). The assigned IDs are shown in the table below:
IANAは、「Constrained RESTful Environments（CoRE）Parameters」レジストリ[RFC7252]内の「CoAP Content-Formats」サブレジストリで、SenMLメディアタイプにCoAP Content-Format IDを割り当てました。 JSON、CBOR、およびEXIコンテンツ形式のIDは0〜255の範囲（エキスパートレビュー）で割り当てられ、XMLコンテンツ形式のIDは256〜9999の範囲（IETFレビューまたはIESG承認）で割り当てられています。割り当てられたIDを以下の表に示します。
+-------------------------+----------+-----+-----------+
| Media Type | Encoding | ID | Reference |
+-------------------------+----------+-----+-----------+
| application/senml+json | - | 110 | RFC 8428 |
| application/sensml+json | - | 111 | RFC 8428 |
| application/senml+cbor | - | 112 | RFC 8428 |
| application/sensml+cbor | - | 113 | RFC 8428 |
| application/senml-exi | - | 114 | RFC 8428 |
| application/sensml-exi | - | 115 | RFC 8428 |
| application/senml+xml | - | 310 | RFC 8428 |
| application/sensml+xml | - | 311 | RFC 8428 |
+-------------------------+----------+-----+-----------+
Table 8: CoAP Content-Format IDs
表8：CoAPコンテンツ形式ID
Sensor data presented with SenML can contain a wide array of information that ranges from very public (such as the outside temperature in a given city) to very private (such as patient health information that requires integrity and confidentiality protection). When SenML is used for configuration or actuation, it can be used to change the state of systems and also impact the physical world, e.g., by turning off a heater or opening a lock. Malicious use of SenML to change system state could have severe consequences, potentially including violation of physical security, property damage, and even loss of life.
SenMLで提示されるセンサーデータには、非常に一般的な情報（特定の都市の外気温など）から非常に個人的な情報（完全性と機密保護を必要とする患者の健康情報など）まで、さまざまな情報を含めることができます。 SenMLを構成または作動に使用すると、システムの状態を変更したり、ヒーターをオフにしたり、ロックを開いたりするなど、現実の世界に影響を与えることができます。システム状態を変更するための悪意のあるSenMLの使用は、深刻な結果をもたらす可能性があり、物理的なセキュリティの侵害、物的損害、さらには生命の損失さえも含む可能性があります。
SenML formats alone do not provide any security and instead rely on the protocol that carries them to provide security. Applications using SenML need to look at the overall context of how these formats will be used to decide if the security is adequate. In particular, for sensitive sensor data and actuation use, it is important to ensure that proper security mechanisms are used to provide, e.g., confidentiality, data integrity, and authentication as appropriate for the usage.
SenML形式だけではセキュリティは提供されず、代わりに、それらを運ぶプロトコルに依存してセキュリティが提供されます。 SenMLを使用するアプリケーションは、セキュリティが適切であるかどうかを判断するためにこれらの形式がどのように使用されるかの全体的なコンテキストを調べる必要があります。特に、機密性の高いセンサーデータと作動の使用では、適切なセキュリティメカニズムを使用して、機密性、データの整合性、および認証を使用に応じて提供することが重要です。
SenML formats defined by this specification do not contain any executable content. However, future extensions could potentially embed application-specific executable content in the data.
この仕様で定義されているSenML形式には、実行可能なコンテンツは含まれていません。ただし、将来の拡張では、アプリケーション固有の実行可能コンテンツがデータに埋め込まれる可能性があります。
SenML Records are intended to be interpreted in the context of any applicable base values. If Records become separated from the Record that establishes the base values, the data will be useless or, worse, wrong. Care needs to be taken in keeping the integrity of a Pack that contains unresolved SenML Records (see Section 4.6).
SenMLレコードは、適用可能な基本値のコンテキストで解釈されることを目的としています。レコードが基本値を確立するレコードから分離されると、データは役に立たなくなるか、さらに悪いことに、誤ったものになります。未解決のSenMLレコードを含むパックの整合性を維持するように注意する必要があります（セクション4.6を参照）。
See also Section 14.
セクション14も参照してください。
Sensor data can range from information with almost no privacy considerations, such as the current temperature in a given city, to highly sensitive medical or location data. This specification provides no security protection for the data but is meant to be used inside another container or transfer protocol such as S/MIME [RFC5751] or HTTP with TLS [RFC2818] that can provide integrity, confidentiality, and authentication information about the source of the data.
センサーデータは、特定の都市の現在の気温など、プライバシーをほとんど考慮しない情報から、機密性の高い医療データや位置データまでさまざまです。この仕様は、データのセキュリティ保護を提供しませんが、S / MIME [RFC5751]やHTTP with TLS [RFC2818]などの別のコンテナまたは転送プロトコル内で使用することを意図しており、ソースの整合性、機密性、および認証情報を提供できます。データ。
The Name fields need to uniquely identify the sources or destinations of the values in a SenML Pack. However, the use of long-term stable and unique identifiers can be problematic for privacy reasons [RFC6973], depending on the application and the potential of these identifiers to be used in correlation with other information. They should be used with care or avoided, for example, as described for IPv6 addresses in [RFC7721].
名前フィールドは、SenMLパックの値のソースまたは宛先を一意に識別する必要があります。ただし、アプリケーションや他の情報との関連でこれらの識別子が使用される可能性によっては、長期的な安定した一意の識別子の使用がプライバシー上の理由から問題となる可能性があります[RFC6973]。たとえば、[RFC7721]のIPv6アドレスで説明されているように、注意して使用するか、または使用しないでください。
[BIPM] Bureau International des Poids et Mesures, "The International System of Units (SI)", 8th Edition, 2006.
[BIPM]国際重量計量局、「国際単位系（SI）」、第8版、2006年。
[IEEE.754] IEEE, "Standard for Binary Floating-Point Arithmetic", IEEE Standard 754.
[IEEE.754] IEEE、「2進浮動小数点演算の標準」、IEEE標準754。
[NIST811] Thompson, A. and B. Taylor, "Guide for the Use of the International System of Units (SI)", NIST Special Publication 811, DOI 10.6028/NIST.SP.811e2008, March 2008.
[NIST811] Thompson、A。およびB. Taylor、「国際単位系（SI）の使用に関するガイド」、NIST Special Publication 811、DOI 10.6028 / NIST.SP.811e2008、2008年3月。
[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>。
[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>。
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, <https://www.rfc-editor.org/info/rfc3688>.
[RFC3688] Mealling、M。、「The IETF XML Registry」、BCP 81、RFC 3688、DOI 10.17487 / RFC3688、2004年1月、<https://www.rfc-editor.org/info/rfc3688>。
[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>。
[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>。
[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>。
[RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, DOI 10.17487/RFC7303, July 2014, <https://www.rfc-editor.org/info/rfc7303>.
[RFC7303] Thompson、H。およびC. Lilley、「XML Media Types」、RFC 7303、DOI 10.17487 / RFC7303、2014年7月、<https://www.rfc-editor.org/info/rfc7303>。
[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] Bray、T。、編、「JavaScript Object Notation（JSON）データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、<https://www.rfc-editor.org / info / rfc8259>。
[RNC] ISO/IEC, "Information technology -- Document Schema Definition Language (DSDL) -- Part 2: Regular-grammar-based validation -- RELAX NG", ISO/IEC 19757-2, Annex C: RELAX NG Compact syntax, December 2008.
[RNC] ISO / IEC、「情報技術-ドキュメントスキーマ定義言語（DSDL）-パート2：通常の文法ベースの検証-RELAX NG」、ISO / IEC 19757-2、付録C：RELAX NG Compact構文、2008年12月。
[TIME_T] The Open Group Base Specifications, "Open Group Standard - Vol. 1: Base Definitions, Issue 7", Section 4.16, "Seconds Since the Epoch", IEEE Standard 1003.1, 2018, <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ V1_chap04.html#tag_04_16>.
[TIME_T]オープングループの基本仕様、「オープングループ標準-第1巻：基本定義、第7版」、セクション4.16、「エポック以降の秒数」、IEEE標準1003.1、2018、<http：//pubs.opengroup。 org / onlinepubs / 9699919799 / basedefs / V1_chap04.html＃tag_04_16>。
[W3C.REC-exi-20140211] Schneider, J., Kamiya, T., Peintner, D., and R. Kyusakov, "Efficient XML Interchange (EXI) Format 1.0 (Second Edition)", W3C Recommendation REC-exi-20140211, February 2014, <http://www.w3.org/TR/2014/REC-exi-20140211>.
[W3C.REC-exi-20140211] Schneider、J.、Kamiya、T.、Peintner、D。、およびR. Kyusakov、「Efficient XML Interchange（EXI）Format 1.0（Second Edition）」、W3C Recommendation REC-exi- 20140211、2014年2月、<http://www.w3.org/TR/2014/REC-exi-20140211>。
[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", W3C Recommendation REC-xml-20081126, November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126>.
[W3C.REC-xml-20081126] Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", W3C Recommendation REC-xml-20081126, November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126>.
[W3C.REC-xmlschema-1-20041028] Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, "XML Schema Part 1: Structures Second Edition", W3C Recommendation REC-xmlschema-1-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[W3C.REC-xmlschema-1-20041028] Thompson、H.、Beech、D.、Maloney、M。、およびN. Mendelsohn、「XML Schema Part 1：Structures Second Edition」、W3C勧告REC-xmlschema-1- 20041028、2004年10月、<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>。
[XPointerElement] Grosso, P., Maler, E., Marsh, J., and N. Walsh, "XPointer element() Scheme", W3C Recommendation REC-xptr-element, March 2003, <https://www.w3.org/TR/2003/REC-xptr-element-20030325/>.
[XPointerElement] Grosso、P.、Maler、E.、Marsh、J。、およびN. Walsh、「XPointer element()スキーム」、W3C勧告REC-xptr-element、2003年3月、<https：//www.w3 .org / TR / 2003 / REC-xptr-element-20030325 />。
[XPointerFramework] Grosso, P., Maler, E., Marsh, J., and N. Walsh, "XPointer Framework", W3C Recommendation REC-XPointer-Framework, March 2003, <http://www.w3.org/TR/2003/REC-xptr-framework-20030325/>.
[XPointerFramework] Grosso、P.、Maler、E.、Marsh、J。、およびN. Walsh、「XPointer Framework」、W3C勧告REC-XPointer-Framework、2003年3月、<http://www.w3.org/ TR / 2003 / REC-xptr-framework-20030325 />。
[AN1796] Linke, B., "Overview of 1-Wire Technology and Its Use", Maxim Integrated, Tutorial 1796, June 2008, <http://pdfserv.maximintegrated.com/en/an/AN1796.pdf>.
[AN1796] Linke、B。、「1-Wireテクノロジーとその使用の概要」、Maxim Integrated、チュートリアル1796、2008年6月、<http://pdfserv.maximintegrated.com/en/an/AN1796.pdf>。
[CDDL-CBOR] Birkholz, H., Vigano, C., and C. Bormann, "Concise data definition language (CDDL): a notational convention to express CBOR and JSON data structures", Work in Progress, draft-ietf-cbor-cddl-05, August 2018.
[CDDL-CBOR] Birkholz、H.、Vigano、C。、およびC. Bormann、「簡潔なデータ定義言語（CDDL）：CBORおよびJSONデータ構造を表現するための表記規則」、Work in Progress、draft-ietf-cbor -cddl-05、2018年8月。
[DEVICE-URN] Arkko, J., Jennings, C., and Z. Shelby, "Uniform Resource Names for Device Identifiers", Work in Progress, draft-ietf-core-dev-urn-02, July 2018.
[DEVICE-URN] Arkko, J., Jennings, C., and Z. Shelby, "Uniform Resource Names for Device Identifiers", Work in Progress, draft-ietf-core-dev-urn-02, July 2018.
[IEEE802.1AS] IEEE, "IEEE Standard for Local and Metropolitan Area Networks - Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks", IEEE Standard 802.1AS.
[IEEE802.1AS] IEEE、「IEEE Standard for Local and Metropolitan Area Networks-Timing and Synchronization for Time-Sensitive Applications in Bridged Local Area Networks」、IEEE Standard 802.1AS。
[IEEE802.1BA] IEEE, "IEEE Standard for Local and metropolitan area networks--Audio Video Bridging (AVB) Systems", IEEE Standard 802.1BA.
[IEEE802.1BA] IEEE、「ローカルおよびメトロポリタンエリアネットワークのIEEE標準-オーディオビデオブリッジング（AVB）システム」、IEEE標準802.1BA。
[ISO-80000-5] ISO, "Quantities and units - Part 5: Thermodynamics", ISO 80000-5, Edition 1.0, May 2007.
[ISO-80000-5] ISO、「数量と単位-パート5：熱力学」、ISO 80000-5、エディション1.0、2007年5月。
[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>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：/ /www.rfc-editor.org/info/rfc3986>。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, <https://www.rfc-editor.org/info/rfc4122>.
[RFC4122] Leach、P.、Mealling、M。、およびR. Salz、「Universally Unique IDentifier（UUID）URN Namespace」、RFC 4122、DOI 10.17487 / RFC4122、2005年7月、<https：//www.rfc- editor.org/info/rfc4122>。
[RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme", RFC 4151, DOI 10.17487/RFC4151, October 2005, <https://www.rfc-editor.org/info/rfc4151>.
[RFC4151] Kindberg、T。およびS. Hawke、「The 'tag' URI Scheme」、RFC 4151、DOI 10.17487 / RFC4151、2005年10月、<https://www.rfc-editor.org/info/rfc4151>。
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <https://www.rfc-editor.org/info/rfc4944>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, <https://www.rfc-editor.org/info/rfc4944>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, DOI 10.17487/RFC5751, January 2010, <https://www.rfc-editor.org/info/rfc5751>.
[RFC5751] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、DOI 10.17487 / RFC5751、2010年1月、<https：//www.rfc- editor.org/info/rfc5751>。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <https://www.rfc-editor.org/info/rfc5952>.
[RFC5952] Kawamura、S. and M. Kawashima、 "A Recommendation for IPv6 Address Text Representation"、RFC 5952、DOI 10.17487 / RFC5952、August 2010、<https://www.rfc-editor.org/info/rfc5952> 。
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, <https://www.rfc-editor.org/info/rfc6690>.
[RFC6690] Shelby、Z。、「Constrained RESTful Environments（CoRE）Link Format」、RFC 6690、DOI 10.17487 / RFC6690、2012年8月、<https://www.rfc-editor.org/info/rfc6690>。
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A., and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, <https://www.rfc-editor.org/info/rfc6920>.
[RFC6920] Farrell、S.、Kutscher、D.、Dannewitz、C.、Ohlman、B.、Keranen、A。、およびP. Hallam-Baker、「Naming Things with Hashes」、RFC 6920、DOI 10.17487 / RFC6920、 2013年4月、<https://www.rfc-editor.org/info/rfc6920>。
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., Morris, J., Hansen, M., and R. Smith, "Privacy Considerations for Internet Protocols", RFC 6973, DOI 10.17487/RFC6973, July 2013, <https://www.rfc-editor.org/info/rfc6973>.
[RFC7111] Hausenblas, M., Wilde, E., and J. Tennison, "URI Fragment Identifiers for the text/csv Media Type", RFC 7111, DOI 10.17487/RFC7111, January 2014, <https://www.rfc-editor.org/info/rfc7111>.
[RFC7111] Hausenblas、M.、Wilde、E。、およびJ. Tennison、「text / csvメディアタイプのURIフラグメント識別子」、RFC 7111、DOI 10.17487 / RFC7111、2014年1月、<https：//www.rfc -editor.org/info/rfc7111>。
[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>。
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy Considerations for IPv6 Address Generation Mechanisms", RFC 7721, DOI 10.17487/RFC7721, March 2016, <https://www.rfc-editor.org/info/rfc7721>.
[RFC7721] Cooper、A.、Gont、F。、およびD. Thaler、「IPv6アドレス生成メカニズムのセキュリティとプライバシーに関する考慮事項」、RFC 7721、DOI 10.17487 / RFC7721、2016年3月、<https：//www.rfc- editor.org/info/rfc7721>。
[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, <https://www.rfc-editor.org/info/rfc8141>.
[RFC8141] Saint-Andre、P。およびJ. Klensin、「Uniform Resource Names（URNs）」、RFC 8141、DOI 10.17487 / RFC8141、2017年4月、<https://www.rfc-editor.org/info/rfc8141 >。
[RID-CoRE] Shelby, Z., Vial, M., Groves, C., Zhu, J., and B. Silverajan, Ed., "Reusable Interface Definitions for Constrained RESTful Environments", Work in Progress, draft-ietf-core-interfaces-12, June 2018.
[RID-CoRE] Shelby、Z.、Vial、M.、Groves、C.、Zhu、J。、およびB. Silverajan、編、「制約付きRESTful環境の再利用可能なインターフェース定義」、Work in Progress、draft-ietf -core-interfaces-12、2018年6月。
[UCUM] Schadow, G. and C. McDonald, "The Unified Code for Units of Measure", Version 2.1, Regenstrief Institute and the UCUM Organization, November 2017, <http://unitsofmeasure.org/ucum.html>.
[UCUM]シャドーG.およびC.マクドナルド、「測定単位の統一コード」、バージョン2.1、Regenstrief InstituteおよびUCUM組織、2017年11月、<http://unitsofmeasure.org/ucum.html>。
Acknowledgements
謝辞
We would like to thank Alexander Pelov, Alexey Melnikov, Andrew McClure, Andrew McGregor, Bjoern Hoehrmann, Christian Amsuess, Christian Groves, Daniel Peintner, Jan-Piet Mens, Jim Schaad, Joe Hildebrand, John Klensin, Karl Palsson, Lennart Duhrsen, Lisa Dusseault, Lyndsay Campbell, Martin Thomson, Michael Koster, Peter Saint-Andre, Roni Even, and Stephen Farrell, for their review comments.
Alexander Pelov、Alexey Melnikov、Andrew McClure、Andrew McGregor、Bjoern Hoehrmann、Christian Amsuess、Christian Groves、Daniel Peintner、Jan-Piet Mens、Jim Schaad、Joe Hildebrand、John Klensin、Karl Palsson、Lennart Duhrsen、Lisaに感謝しますDusseault、Lyndsay Campbell、Martin Thomson、Michael Koster、Peter Saint-Andre、Roni Even、Stephen Farrellのレビューコメント。
Authors' Addresses
著者のアドレス
Cullen Jennings Cisco 400 3rd Avenue SW Calgary, AB T2P 4H2 Canada
Cullen Jennings Cisco 400 3rd Avenue SW Calgary, AB T2P 4H2 Canada
Email: fluffy@iii.ca
Zach Shelby ARM 150 Rose Orchard San Jose 95134 United States of America
ザックシェルビーアーム150ローズオーチャードサンノゼ95134アメリカ合衆国
Phone: +1-408-203-9434
Email: zach.shelby@arm.com
Jari Arkko Ericsson Jorvas 02420 Finland
Jari Arkko Ericsson Jorvas 02420フィンランド
Email: jari.arkko@piuha.net
Ari Keranen Ericsson Jorvas 02420 Finland
Ari Keranen Ericsson Jorvas 02420 Finland
Email: ari.keranen@ericsson.com
Carsten Bormann Universitaet Bremen TZI Postfach 330440 Bremen D-28359 Germany
Carsten Bormann Universitaet Bremen TZI PO Box 330440ブレーメンD-28359ドイツ
Phone: +49-421-218-63921
Email: cabo@tzi.org