RFC 9100 - Sensor Measurement Lists (SenML) Features and Versions 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc9100.html
タイトル : RFC 9100 - センサー測定リスト（SENML）の機能とバージョン
翻訳編集 : 自動生成

[要約] RFC 9100 - Sensor Measurement Lists (SenML) Features and Versions は、センサーからの測定値を表現、交換するための標準フォーマットを定義します。この標準は、IoTデバイス間のデータ互換性を高め、効率的なデータ処理とアプリケーション統合を目的としています。利用場面には、環境モニタリング、スマートホーム、産業自動化などがあります。

Internet Engineering Task Force (IETF)                        C. Bormann
Request for Comments: 9100                        Universität Bremen TZI
Updates: 8428                                                August 2021
Category: Standards Track
ISSN: 2070-1721

Sensor Measurement Lists (SenML) Features and Versions

センサー測定リスト（SENML）の機能とバージョン

Abstract

概要

This short document updates RFC 8428, "Sensor Measurement Lists (SenML)", by specifying the use of independently selectable "SenML Features" and mapping them to SenML version numbers.

この短い文書は、独立して選択可能な「SENML機能」の使用を指定し、それらをSENMLバージョン番号にマッピングすることで、RFC 8428「センサー測定リスト（SENML）」を更新します。

Status of This Memo

本文書の位置付け

This is an Internet Standards Track document.

これはインターネット規格のトラック文書です。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9100.

この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法については、https://www.rfc-editor.org/info/rfc9100で入手できます。

著作権表示

著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。

Table of Contents

   1.  Introduction
     1.1.  Terminology
   2.  Feature Codes and the Version Number
     2.1.  Discussion
     2.2.  Updating Section 4.4 of RFC 8428
   3.  Features: Reserved0, Reserved1, Reserved2, Reserved3
   4.  Feature: Secondary Units
   5.  Security Considerations
   6.  IANA Considerations
   7.  References
     7.1.  Normative References
     7.2.  Informative References
   Acknowledgements
   Author's Address

1. Introduction

1. はじめに

The Sensor Measurement Lists (SenML) specification [RFC8428] provides a version number that is initially set to 10, without further specification on the way to make use of different version numbers.

センサ測定リスト（SENML）仕様[RFC8428]は、別のバージョン番号を使用する方法をさらに指定することなく、最初に10に設定されているバージョン番号を提供します。

The common idea of using a version number to indicate the evolution of an interchange format generally assumes an incremental progression of the version number as the format accretes additional features over time. However, in the case of SenML, it is expected that the likely evolution will be for independently selectable capability _features_ to be added to the basic specification that is indicated by version number 10. To support this model, this document repurposes the single version number accompanying a pack of SenML records so that it is interpreted as a bitmap that indicates the set of features a recipient would need to have implemented to be able to process the pack.

交換フォーマットの進化を示すためにバージョン番号を使用するという共通の考えは、一般的に、フォーマットが追加の機能を頻繁に追加の機能であるため、バージョン番号の増分進行を想定しています。ただし、SENMLの場合は、バージョン番号10で示される基本仕様に追加される可能性のある能力_FEATURES_FEATURES_FEATURES_FEATURES_FEATURES_FEATURES_FEATURES_FEATURES_FEATURES_FEATURES_FEATURES_FEATURES_FEATURES_FEATURES_FEATURES_FEATURES_FEATURES_FEATURES_FEATURES_FEATURES_FEATURES_FEATURES_FEATICATESが必要です。この文書は単一のバージョン番号を再利用します。SENMLレコードのパックは、受信者がパックを処理できるようにするために実装する必要がある機能のセットを示すビットマップとして解釈されるように記録します。

This short document specifies the use of SenML Features and maps them to SenML version number space, updating [RFC8428].

この短い文書はSENML機能の使用を指定し、それらをSENMLバージョン番号スペースにマッピングし、[RFC8428]を更新します。

1.1. Terminology

1.1. 用語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。

Where bit arithmetic is explained, this document uses the notation familiar from the programming language C [C], including the "0b" prefix for binary numbers defined in Section 5.13.2 of the C++ language standard [CPLUSPLUS], except that superscript notation (example for two to the power of 64: 2^64) denotes exponentiation; in the plain text version of this document, superscript notation is rendered in paragraph text by C-incompatible surrogate notation as seen in this example, and in display math by a crude plain text representation, as is the sum (Sigma) sign.

ビット演算が説明される場合、この文書は、SuperScriptの表記を除いて、C言語標準[CPlusplus]のセクション5.13.2で定義されているバイナリ番号の「0b」プレフィックスを含む、プログラミング言語C [C]から馴染みのある表記を使用しています。2つの電力64：2 ^ 64）の例は、指数を表します。この文書のプレーンテキストバージョンでは、SuperScript表記は、この例で見られるように、C-互換性のないサロゲート表記によって段落テキストでレンダリングされ、Sum（Sigma）の符号なしで原油テキスト表現によって数学を表示します。

2. Feature Codes and the Version Number

2. フィーチャーコードとバージョン番号

The present specification defines "SenML Features", each identified by a "feature name" (a text string) and a "feature code" (an unsigned integer less than 53).

本明細書は、それぞれ「フィーチャー名」（テキスト文字列）と「機能コード」（53未満の符号なし整数）で識別される「SENML機能」を定義しています。

The specific version of a SenML pack is composed of a set of features. The SenML version number ("bver" field) is then a bitmap of these features represented as an unsigned integer, specifically the sum of, for each feature present, two taken to the power of the feature code of that feature (Figure 1).

SENMLパックの特定のバージョンは、一連の機能で構成されています。SENMLバージョン番号（「BVER」フィールド）は、符号なし整数として表されるこれらの機能のビットマップ、具体的には、存在する各機能について、その機能のフィーチャコードの機能コードの電源に照合されます（図1）。

              __ 52                     fc
   version = \           present(fc) ⋅ 2
             /__ fc = 0

Figure 1: Feature Bitmap as a Sum (Sigma Symbol) of Feature Bits

図1：フィーチャビットの合計（シグマシンボル）としての機能ビットマップ

where present(fc) is 1 if the feature with the feature code "fc" is present, 0 otherwise. (The expression 2^fc can be implemented as "1 << fc" in C and related languages.)

特徴コード「FC」を持つ特徴が存在する場合、存在する場合は1（FC）は1です。（式2 ^ FCは、Cおよび関連言語で「1 << FC」として実装できます。）

2.1. Discussion

2.1. 考察

Representing features as a bitmap within a number is quite efficient as long as feature codes are sparingly allocated (see also Section 6).

機能コードが控えめに割り当てられている限り、数値内のビットマップとしての機能を表すことは非常に効率的です（セクション6も参照）。

Compatibility with the existing SenML version number, 10 decimal (0b1010), requires reserving four of the least significant bit positions for the base version as described in Section 3. There is an upper limit to the range of the integer numbers that can be represented in all SenML representations: practical JSON limits this to 2^53-1 [RFC7493]. This means the feature codes 4 to 52 are available, one of which is taken by the feature defined in Section 4, leaving 48 for allocation. (The current version 10 (with all other feature codes unset) can be visualized as "0b00000000000000000000000000000000000000000000000001010".) For a lifetime of this scheme of several decades, approximately two feature codes per year or fewer should be allocated. Note that less generally applicable features can always be communicated via fields labeled with names that end with the "_" character ("must-understand fields"). See Section 4.4 of [RFC8428] for details.

既存のSENMLバージョン番号10（0B1010）との互換性は、セクション3に記載されている基本バージョンに対して4つの最下位ビット位置を予約する必要があります。内に表すことができる整数番号の範囲に上限があります。すべてのSENML表現：実用的なJSONこれを2 ^ 53-1 [RFC7493]に制限します。これは、特徴コード4~52が利用可能であり、そのうちの1つはセクション4で定義された特徴によって取られ、割り当てのために48を残す。（（）未設定の他のすべての機能コードと現在のバージョン10が「0b00000000000000000000000000000000000000000000000001010」として視覚化することができます。）数十年のこの方式の有効期間については、約一年または少ないごとに2つの機能コードが割り当てられるべきです。一般的に適用可能な機能は、「_」文字（「必須フィールド」）で終わる名前でラベル付けされたフィールドを介して常に通信できます。詳細については、[RFC8428]のセクション4.4を参照してください。

Most representations visible to engineers working with SenML will use decimal numbers. For instance, 26 (0b11010, 0x1a) denotes a version that adds the "Secondary Units" feature (Section 4). This is slightly unwieldy but will be quickly memorized in practice.

SENMLを使用して作業するエンジニアに表示されるほとんどの表現は10進数を使用します。たとえば、26（0b11010,0x1a）は、「セカンダリユニット」機能を追加するバージョンを表します（セクション4）。これはわずかに扱いにくいですが、実際には素早く記憶されます。

As a general observation, ending up over time with dozens of individually selectable optional extensions may lead to too many variants of what is supported by different implementations, reducing interoperability. So, in practice, it is still desirable to batch up extensions that are expected to be supported together into a single feature bit, leading to a sort of hybrid between completely independent extensions and a linear version scheme. This is also another reason why a space of 48 remaining feature codes should suffice for a while.

一般的な観察として、何十もの個別に選択可能なオプションの延長が時間の経過とともに終了すると、異なる実装によってサポートされているものの多すぎ、相互運用性が低下する可能性があります。したがって、実際には、単一のフィーチャービットにサポートされると予想される拡張機能をバッチアップすることが依然として望ましいので、完全に独立した拡張と線形バージョン方式の間の一種のハイブリッドがあります。これはまた48残りの特徴コードの空間がしばらくの間で十分であるべきである他の理由である。

2.2. Updating Section 4.4 of RFC 8428

2.2. RFC 8428の更新セクション4.4

The last paragraph of Section 4.4 of [RFC8428] may be read to give the impression that SenML version numbers are totally ordered, i.e., that an implementation that understands version n also always understands all versions k < n. If this ever was true for SenML versions before 10, it certainly is no longer true with this specification.

[RFC8428]のセクション4.4の最後の段落は、SENMLバージョン番号が完全に順序付けられているという印象を与えることができます。すなわち、バージョンNを理解している実装も常にすべてのバージョンK <Nを理解することを理解することができます。これが10の前のSENMLバージョンに当てはまる場合、それは確かにこの仕様にはもはや真実ではありません。

Any SenML pack that sets feature bits beyond the first four will lead to a version number that actually is greater than 10, so the requirement in Section 4.4 of [RFC8428] will prevent false interoperability with version 10 implementations.

最初の4つを超えて機能ビットを設定するSenML Packは、実際には10を超えるバージョン番号につながっているため、[RFC8428]のセクション4.4の要件はバージョン10の実装との誤った相互運用性を防ぎます。

Implementations that do implement feature bits beyond the first four, i.e., versions greater than 10, will instead need to perform a bitwise comparison of the feature bitmap as described in this specification and ensure that all features indicated are understood before using the pack. For example, an implementation that implements basic SenML (version number 10) plus only a future feature code 5 will accept version number 42, but it would not be able to work with a pack indicating version number 26 (base specification plus feature code 4). (If the implementation _requires_ feature code 5 without being backwards compatible, it will accept 42, but not 10.)

最初の4つを超える、すなわち10より大きいバージョンを超えて特徴ビットを実装する実装は、代わりに、この仕様で説明されているように特徴ビットマップのビットごとの比較を実行する必要があり、示されたすべての機能がパックを使用する前に理解されることを保証する。たとえば、基本的なSENMLを実装する実装（バージョン番号10）と将来のフィーチャーコード5のみがバージョン番号42を受け入れますが、バージョン番号26を示すパックで動作することはできません（基本仕様と機能コード4）。。（実装_Requires_機能を互換性がある場合は、コード5が互換性がある場合は42を受け入れますが、10は10。）

3. Features: Reserved0, Reserved1, Reserved2, Reserved3

3. 特徴：Reserved0、Reserved1、Reserved2、Reserved3

For SenML version 10 as described in [RFC8428], the feature codes 0 to 3 are already in use. Reserved1 (1) and Reserved3 (3) are always present, and the features Reserved0 (0) and Reserved2 (2) are always absent, i.e., the four least significant bits set to 0b1010 indicate a version number of 10 if no other feature is in use. These four reserved feature codes are not to be used with any more specific semantics except in a specification that updates the present specification. (Note that Reserved0 and Reserved2 could be used in such a specification in a way similar to that of feature codes 4 to 52 in the present specification.)

[RFC8428]に記載されているSENMLバージョン10の場合、フィーチャコード0~3はすでに使用されています。Reserved1（1）とReserved3（3）は常に存在し、特徴が常に存在しない、すなわち、0B1010に設定された4つの最下位ビットは、他の機能がない場合は10のバージョン番号10を示す。使用中で。これら4つの予約機能コードは、本明細書を更新する仕様を除いて、それ以上具体的な意味論と共に使用されるべきではない。（本明細書において特徴コード4~52のような方法で、予約0および予約2をそのような仕様で使用することができることに注意してください。）

4. Feature: Secondary Units

4. 特徴：二次ユニット

The feature "Secondary Units" (code number 4) indicates that secondary unit names [RFC8798] MAY be used in the "u" field of SenML records in addition to the primary unit names already allowed by [RFC8428].

特徴「二次単位」（コード番号4）は、[RFC8428]で既に許可されている主要なユニット名に加えて、SENMLレコードの「U」フィールドで2次ユニット名[RFC8798]を使用できることを示しています。

Note that the most basic use of this feature simply sets the SenML version number to 26 (10 + 2^4).

この機能の最も基本的な使用は、SENMLバージョン番号を26（10 2 ^ 4）に設定するだけです。

5. Security Considerations

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

The security considerations of [RFC8428] apply. This specification provides structure to the interpretation of the SenML version number, which poses no additional security considerations except for some potential for surprise that version numbers do not simply increase linearly.

[RFC8428]のセキュリティ上の考慮事項が適用されます。この仕様はSENMLバージョン番号の解釈に構造を提供します。これは、バージョン番号が単に直線的に増加しないという驚きを除いて、追加のセキュリティ上の考慮事項はありません。

6. IANA Considerations

6. IANAの考慮事項

IANA has created a new "SenML Features" subregistry within the "Sensor Measurement Lists (SenML)" registry [IANA.SENML] with the registration policy "Specification Required" [RFC8126] and the columns:

IANAは、「センサ測定リスト（SENME測定リスト（SENMME測定リスト（SenML）」レジストリ[IANA.SENML]内の新しい「SENML機能」を作成しました[RFC8126]と列：

* Feature Code (an unsigned integer less than 53)

* 機能コード（53未満の符号なし整数）

* Feature Name (text)

* 機能名（テキスト）

* Reference

* リファレンス

To facilitate the use of feature names in programs, the designated expert is requested to ensure that feature names are usable as identifiers in most programming languages, after lowercasing the feature name in the registry entry and replacing blank space with underscores or hyphens, and that they also are distinct in this form.

プログラム内の機能名の使用を容易にするために、指定されたエキスパートは、レジストリエントリ内のフィーチャネームを縮小し、空白スペースをアンダースコアまたはハイフンまたはハイフンで置き換えた後、特徴名がほとんどのプログラミング言語で識別子として使用可能であることを要求されます。この形でも異なります。

The initial content of this registry is as follows:

このレジストリの初期コンテンツは次のとおりです。

         +==============+=================+=====================+
         | Feature Code | Feature Name    | Reference           |
         +==============+=================+=====================+
         | 0            | Reserved0       | [RFC9100]           |
         +--------------+-----------------+---------------------+
         | 1            | Reserved1       | [RFC9100]           |
         +--------------+-----------------+---------------------+
         | 2            | Reserved2       | [RFC9100]           |
         +--------------+-----------------+---------------------+
         | 3            | Reserved3       | [RFC9100]           |
         +--------------+-----------------+---------------------+
         | 4            | Secondary Units | [RFC9100] [RFC8798] |
         +--------------+-----------------+---------------------+

Table 1: Features Defined for SenML at the Time of Writing

表1：執筆時点でSENML用に定義された機能

As the number of features that can be registered has a hard limit (48 codes left at the time of writing), the designated expert is specifically instructed to maintain a frugal regime of code point allocation, keeping code points available for SenML Features that are likely to be useful for non-trivial subsets of the SenML ecosystem. Quantitatively, the expert could, for instance, steer the allocation to a target of not allocating more than 10% of the remaining set per year.

登録できる機能の数が難しさ（書き込み時に残された48符号）は、指定されたエキスパートが特にコードポイント割り当ての維持管理のために特に指示されており、これは、Code Pointsが可能性が高いSENML生態系の些細なサブセットに役立つこと。定量的に、エキスパートは、例えば、年間の残りのセットの10％を超えないように割り当てられていないターゲットへの割り当てを操作することができます。

Where the specification of the feature code is provided in a document that is separate from the specification of the feature itself (as with feature code 4 above), both specifications should be listed.

特徴コードの仕様は、特徴自体の仕様とは別の文書に記載されている場合（上記の特徴コード4のように）、両方の仕様をリストする必要がある。

7. References

7. 参考文献

7.1. Normative References

7.1. 引用文献

[C] International Organization for Standardization, "Information technology - Programming languages - C", ISO/ IEC 9899:2018, Fourth Edition, June 2018, <https://www.iso.org/standard/74528.html>.

[C]国際標準化、「情報技術 - プログラミング言語 - C」、ISO / IEC 9899：2018、第4版、2018年6月、<https://www.iso.org/standard/74528.html>。

[CPLUSPLUS] International Organization for Standardization, "Programming languages - C++", ISO/IEC 14882:2020, Sixth Edition, December 2020, <https://www.iso.org/standard/79358.html>.

[Cplusplus]国際標準化、「プログラミング言語 - C」、ISO / IEC 14882：2020、第6版、2020年12月、<https://www.iso.org/standard/79358.html>。

[IANA.SENML] IANA, "Sensor Measurement Lists (SenML)", <https://www.iana.org/assignments/senml>.

[IANA.SENML] IANA、「センサー測定リスト（SENML）」、<https://www.iana.org/assignments/senml>。

[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、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。

[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.、Leiba、B.およびT.Narten、「RFCSの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>。

[RFC8428] Jennings, C., Shelby, Z., Arkko, J., Keranen, A., and C. Bormann, "Sensor Measurement Lists (SenML)", RFC 8428, DOI 10.17487/RFC8428, August 2018, <https://www.rfc-editor.org/info/rfc8428>.

[RFC8428]ジェニングニング、C、Shelby、Z.、Arkko、J.、Keranen、A.、C. Bormann、C. Bormann、「センサ測定リスト（SenML）」、RFC 8428、DOI 10.17487 / RFC8428、2018年8月、<HTTPS///www.rfc-editor.org/info/rfc8428>。

[RFC8798] Bormann, C., "Additional Units for Sensor Measurement Lists (SenML)", RFC 8798, DOI 10.17487/RFC8798, June 2020, <https://www.rfc-editor.org/info/rfc8798>.

[RFC8798] Bormann、C。、「センサ測定リストの追加単位（SenML）」、RFC 8798、DOI 10.17487 / RFC8798、2020年6月、<https://www.rfc-editor.org/info/rfc8798>。

7.2. Informative References

7.2. 参考引用

[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, <https://www.rfc-editor.org/info/rfc7493>.

[RFC7493] Bray、T.、Ed。、「I-JSONメッセージフォーマット」、RFC 7493、DOI 10.17487 / RFC7493、2015年3月、<https：//www.rfc-editor.org/info/rfc7493>。

Acknowledgements

謝辞

Ari Keränen proposed to use the version number as a bitmap and provided further input on this specification. Jaime Jiménez helped clarify the document by providing a review and acted as Document Shepherd. Elwyn Davies provided a detailed GENART review with directly implementable text suggestions that now form part of this specification. Rob Wilton supplied comments, one of which became the last paragraph of Section 2.1; Éric Vyncke helped with Section 2. Additional thanks go to the other IESG reviewers.

AriKeränenは、バージョン番号をビットマップとして使用し、この仕様にさらに入力を提供することを提案しました。JaimeJiménezは、レビューを提供し、ドキュメント羊飼いとして行動することによって文書を明確にしました。Elwyn Daviesは、この仕様の一部を形成する直接実装可能なテキスト提案を用いて詳細なGenartレビューを提供しました。Rob Wiltonはコメントを提供し、そのうちの1つはセクション2.1の最後の段落になりました。éricVynckeはセクション2を手伝った。他のIESGレビューアにありがとうございます。

Author's Address

著者の住所

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

Bremen Tzi Postfach 330440 D-28359ブレーメンドイツ

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