3.1. SenML FETCH

The FETCH method can be used to select and return a subset of Records, in sequence, of one or more SenML Packs. The SenML Records are selected by giving a set of names that, when resolved, match resolved names in a Target SenML Pack. The names for a Fetch Pack are given using the SenML "name" and/or "base name" fields. The names are resolved by concatenating the base name with the name field as defined in [RFC8428].¶

A Fetch Pack MUST contain at least one Fetch Record. A Fetch Record MUST contain a name and/or base name field.¶

For example, to select the resources "5850" and "5851" from the example in Section 1, the following Fetch Pack can be used:¶

[
 {"bn":"2001:db8::2/3311/0/", "n":"5850"},
 {"n":"5851"}
]

The result of a FETCH request with the example above would be:¶

[
 {"bn":"2001:db8::2/3311/0/", "n":"5850", "vb":true},
 {"n":"5851", "v":42},
]

The SenML time and unit fields can be used in a Fetch Record to further narrow the selection of matched SenML Records. When no time or unit is given in a Fetch Record, all SenML Records with the given name are matched (i.e., unlike with SenML Records, the lack of time field in a Fetch Record does not imply a time value of zero). When time is given in the Fetch Record, a Target Record is matched only when its resolved time value and name are equal to those of the Fetch Record. Similarly, when unit is given, a Target Record is matched only when its resolved unit and name are equal to those of the Fetch Record. If both the time and unit are given in the Fetch Record, a Target Record is matched only when both are equal to those of the Fetch Record. Each Target Record MUST be included in the response at most once, even if multiple Fetch Records match with the same Target Record.¶

For example, if the resource "5850" had multiple sensor readings (SenML Records) with different time values, the following Fetch Pack can be used to retrieve the Record with time "1.276020091e+09":¶

[
 {"bn":"2001:db8::2/3311/0/", "n":"5850", "t":1.276020091e+09}
]

The resolved form of Records (Section 4.6 of [RFC8428]) is used when comparing the names, times, and units of the Target and Fetch Records to accommodate differences in the use of the base values. In the resolved form, the SenML name in the example above becomes "2001:db8::2/3311/0/5850". Since there is no base time in the Pack, the time in resolved form is equal to the time in the example.¶

If no SenML Records match, an empty SenML Pack (i.e., array with no elements) is returned as a response.¶

Fetch Records MUST NOT contain other fields than name, base name, time, base time, unit, and base unit. Implementations MUST reject and generate an error for a Fetch Pack with other fields. [RFC8132], Section 2.2 provides guidance for FETCH request error handling, e.g., using the 4.22 (Unprocessable Entity) CoAP error response code.¶

3.2. SenML (i)PATCH

The (i)PATCH method can be used to change the fields of SenML Records, to add new Records, and to remove existing Records. The names, times, and units of the Patch Records are given and matched in the same way as for the Fetch Records, except each Patch Record MUST match at most one Target Record. A Patch Record matching more than one Target Record is considered invalid (patching multiple Target Records with one Patch Record would result in multiple copies of the same Record). Patch Packs can also include new values and other SenML fields for the Records. Application of Patch Packs is idempotent; hence, the PATCH and iPATCH methods for SenML Packs are equivalent.¶

When the name in a Patch Record matches with the name in an existing Record, the resolved time values and units (if any) are compared. If the time values and units either do not exist in both Records or are equal, the Target Record is replaced with the contents of the Patch Record. All Patch Records MUST contain at least a SenML Value or Sum field.¶

If a Patch Record contains a name, or the combination of a time value, unit, and name, that does not exist in any existing Record in the Pack, the given Record, with all the fields it contains, is added to the Pack.¶

If a Patch Record has a value ("v") field with a null value, it MUST NOT be added, but the matched Record (if any) is removed from the Target Pack.¶

The Patch Records MUST be applied in the same sequence as they are in the Patch Pack. If multiple Patch Packs are being processed at the same time, the result MUST be equivalent to applying them in one sequence.¶

Implementations MUST reject and generate an error for Patch Packs with invalid Records. If a Patch Pack is rejected, the state of the Target Pack is not changed, i.e., either all or none of the Patch Records are applied. [RFC8132], Section 3.4 provides guidance for error handling with PATCH and iPATCH requests, e.g., using the 4.22 (Unprocessable Entity) and 4.09 (Conflict) CoAP error response codes.¶

For example, the following document could be given as an (i)PATCH payload to change/set the values of two SenML Records for the example in Section 1:¶

[
 {"bn":"2001:db8::2/3311/0/", "n":"5850", "vb":false},
 {"n":"5851", "v":10}
]

If the request is successful, the resulting representation of the example SenML Pack would be as follows:¶

[
 {"bn":"2001:db8::2/3311/0/", "n":"5850", "vb":false},
 {"n":"5851", "v":10},
 {"n":"5750", "vs":"Ceiling light"}
]

As another example, the following document could be given as an (i)PATCH payload to remove the two SenML Records:¶

[
 {"bn":"2001:db8::2/3311/0/", "n":"5850", "v":null},
 {"n":"5851", "v":null}
]

7.1. CoAP Content-Format Registration

IANA has assigned CoAP Content-Format IDs for the SenML PATCH and FETCH media types in the "CoAP Content-Formats" subregistry, within the "Constrained RESTful Environments (CoRE) Parameters" registry [RFC7252]. The assigned IDs are shown in Table 1.¶

7.2. senml-etch+json Media Type

Type name:

application¶

Subtype name:

senml-etch+json¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

binary¶

Security considerations:

See Section 6 of RFC 8790.¶

Interoperability considerations:

N/A¶

Published specification:

RFC 8790¶

Applications that use this media type:

Applications that use the SenML media type for resource representation.¶

Fragment identifier considerations:

Fragment identification for application/senml-etch+json is supported by using fragment identifiers as specified by Section 4 of RFC 8790.¶

Additional information:

Deprecated alias names for this type:

N/A¶

Magic number(s):

N/A¶

File extension(s):

senml-etchj¶

Windows Clipboard Name:

"SenML FETCH/PATCH format"¶

Macintosh file type code(s):

N/A¶

Macintosh Universal Type Identifier code:

org.ietf.senml-etch-json conforms to public.text¶

Person & email address to contact for further information:

Ari Keränen <ari.keranen@ericsson.com>¶

Intended usage:

COMMON¶

Restrictions on usage:

N/A¶

Author:

Ari Keränen <ari.keranen@ericsson.com>¶

Change controller:

IESG¶

7.3. senml-etch+cbor Media Type

Type name:

application¶

Subtype name:

senml-etch+cbor¶

Required parameters:

N/A¶

Optional parameters:

N/A¶

Encoding considerations:

binary¶

Security considerations:

See Section 6 of RFC 8790.¶

Interoperability considerations:

N/A¶

Published specification:

RFC 8790¶

Applications that use this media type:

Applications that use the SenML media type for resource representation.¶

Fragment identifier considerations:

Fragment identification for application/senml-etch+cbor is supported by using fragment identifiers as specified by Section 4 of RFC 8790.¶

Additional information:

Deprecated alias names for this type:

N/A¶

Magic number(s):

N/A¶

File extension(s):

senml-etchc¶

Macintosh file type code(s):

N/A¶

Macintosh Universal Type Identifier code:

org.ietf.senml-etch-cbor conforms to public.data¶

Person & email address to contact for further information:

Ari Keränen <ari.keranen@ericsson.com>¶

Intended usage:

COMMON¶

Restrictions on usage:

N/A¶

Author:

Ari Keränen <ari.keranen@ericsson.com>¶

Change controller:

IESG¶