draft-ietf-core-senml-15.txt   draft-ietf-core-senml-16.txt 
Network Working Group C. Jennings Network Working Group C. Jennings
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Standards Track Z. Shelby Intended status: Standards Track Z. Shelby
Expires: November 8, 2018 ARM Expires: November 19, 2018 ARM
J. Arkko J. Arkko
A. Keranen A. Keranen
Ericsson Ericsson
C. Bormann C. Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
May 7, 2018 May 18, 2018
Sensor Measurement Lists (SenML) Sensor Measurement Lists (SenML)
draft-ietf-core-senml-15 draft-ietf-core-senml-16
Abstract Abstract
This specification defines a format for representing simple sensor This specification defines a format for representing simple sensor
measurements and device parameters in the Sensor Measurement Lists measurements and device parameters in the Sensor Measurement Lists
(SenML). Representations are defined in JavaScript Object Notation (SenML). Representations are defined in JavaScript Object Notation
(JSON), Concise Binary Object Representation (CBOR), Extensible (JSON), Concise Binary Object Representation (CBOR), Extensible
Markup Language (XML), and Efficient XML Interchange (EXI), which Markup Language (XML), and Efficient XML Interchange (EXI), which
share the common SenML data model. A simple sensor, such as a share the common SenML data model. A simple sensor, such as a
temperature sensor, could use one of these media types in protocols temperature sensor, could use one of these media types in protocols
skipping to change at page 1, line 37 skipping to change at page 1, line 37
to be configured. to be configured.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 8, 2018. This Internet-Draft will expire on November 19, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements and Design Goals . . . . . . . . . . . . . . . . 4 2. Requirements and Design Goals . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
4. SenML Structure and Semantics . . . . . . . . . . . . . . . . 6 4. SenML Structure and Semantics . . . . . . . . . . . . . . . . 6
4.1. Base Fields . . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Base Fields . . . . . . . . . . . . . . . . . . . . . . . 6
4.2. Regular Fields . . . . . . . . . . . . . . . . . . . . . 7 4.2. Regular Fields . . . . . . . . . . . . . . . . . . . . . 7
4.3. SenML Labels . . . . . . . . . . . . . . . . . . . . . . 7 4.3. SenML Labels . . . . . . . . . . . . . . . . . . . . . . 8
4.4. Extensibility . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Extensibility . . . . . . . . . . . . . . . . . . . . . . 8
4.5. Records and Their Fields . . . . . . . . . . . . . . . . 9 4.5. Records and Their Fields . . . . . . . . . . . . . . . . 9
4.5.1. Names . . . . . . . . . . . . . . . . . . . . . . . . 9 4.5.1. Names . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5.2. Units . . . . . . . . . . . . . . . . . . . . . . . . 9 4.5.2. Units . . . . . . . . . . . . . . . . . . . . . . . . 9
4.5.3. Time . . . . . . . . . . . . . . . . . . . . . . . . 10 4.5.3. Time . . . . . . . . . . . . . . . . . . . . . . . . 10
4.5.4. Values . . . . . . . . . . . . . . . . . . . . . . . 10 4.5.4. Values . . . . . . . . . . . . . . . . . . . . . . . 11
4.6. Resolved Records . . . . . . . . . . . . . . . . . . . . 11 4.6. Resolved Records . . . . . . . . . . . . . . . . . . . . 11
4.7. Associating Meta-data . . . . . . . . . . . . . . . . . . 11 4.7. Associating Meta-data . . . . . . . . . . . . . . . . . . 12
4.8. Sensor Streaming Measurement Lists (SensML) . . . . . . . 12 4.8. Sensor Streaming Measurement Lists (SensML) . . . . . . . 12
4.9. Configuration and Actuation usage . . . . . . . . . . . . 12 4.9. Configuration and Actuation usage . . . . . . . . . . . . 12
5. JSON Representation (application/senml+json) . . . . . . . . 12 5. JSON Representation (application/senml+json) . . . . . . . . 13
5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Examples . . . . . . . . . . . . . . . . . . . . . . . . 14
5.1.1. Single Datapoint . . . . . . . . . . . . . . . . . . 14 5.1.1. Single Datapoint . . . . . . . . . . . . . . . . . . 14
5.1.2. Multiple Datapoints . . . . . . . . . . . . . . . . . 14 5.1.2. Multiple Datapoints . . . . . . . . . . . . . . . . . 14
5.1.3. Multiple Measurements . . . . . . . . . . . . . . . . 15 5.1.3. Multiple Measurements . . . . . . . . . . . . . . . . 15
5.1.4. Resolved Data . . . . . . . . . . . . . . . . . . . . 16 5.1.4. Resolved Data . . . . . . . . . . . . . . . . . . . . 16
5.1.5. Multiple Data Types . . . . . . . . . . . . . . . . . 17 5.1.5. Multiple Data Types . . . . . . . . . . . . . . . . . 17
5.1.6. Collection of Resources . . . . . . . . . . . . . . . 17 5.1.6. Collection of Resources . . . . . . . . . . . . . . . 17
5.1.7. Setting an Actuator . . . . . . . . . . . . . . . . . 17 5.1.7. Setting an Actuator . . . . . . . . . . . . . . . . . 17
6. CBOR Representation (application/senml+cbor) . . . . . . . . 18 6. CBOR Representation (application/senml+cbor) . . . . . . . . 18
7. XML Representation (application/senml+xml) . . . . . . . . . 20 7. XML Representation (application/senml+xml) . . . . . . . . . 20
8. EXI Representation (application/senml-exi) . . . . . . . . . 22 8. EXI Representation (application/senml-exi) . . . . . . . . . 22
skipping to change at page 5, line 30 skipping to change at page 5, line 30
"v":23.5}, "v":23.5},
{"u":"Cel","t":1.276020091e+09, {"u":"Cel","t":1.276020091e+09,
"v":23.6} "v":23.6}
] ]
In the above example the Base Name is in the "bn" field and the "n" In the above example the Base Name is in the "bn" field and the "n"
fields in each Record are the empty string so they are omitted. fields in each Record are the empty string so they are omitted.
Some devices have accurate time while others do not so SenML supports Some devices have accurate time while others do not so SenML supports
absolute and relative times. Time is represented in floating point absolute and relative times. Time is represented in floating point
as seconds. Values greater than zero represent an absolute time as seconds. Values greater than or equal to 2**28 represent an
relative to the Unix epoch (1970-01-01T00:00Z in UTC time) and the absolute time relative to the Unix epoch. Values less than 2**28
time is counted same way as the Portable Operating System Interface represent time relative to the current time.
(POSIX) "seconds since the epoch" [TIME_T]. Values of 0 or less
represent a relative time in the past from the current time. A A simple sensor with no absolute wall clock time might take a
simple sensor with no absolute wall clock time might take a
measurement every second, batch up 60 of them, and then send the measurement every second, batch up 60 of them, and then send the
batch to a server. It would include the relative time each batch to a server. It would include the relative time each
measurement was made compared to the time the batch was sent in each measurement was made compared to the time the batch was sent in each
SenML Record. The server might have accurate NTP time and use the SenML Record. The server might have accurate NTP time and use the
time it received the data, and the relative offset, to replace the time it received the data, and the relative offset, to replace the
times in the SenML with absolute times before saving the SenML times in the SenML with absolute times before saving the SenML
information in a document database. information in a document database.
3. Terminology 3. Terminology
skipping to change at page 6, line 30 skipping to change at page 6, line 30
This document uses the terms "attribute" and "tag" where they occur This document uses the terms "attribute" and "tag" where they occur
with the underlying technologies (XML, CBOR [RFC7049], and Link with the underlying technologies (XML, CBOR [RFC7049], and Link
Format [RFC6690]), not for SenML concepts per se. Note that Format [RFC6690]), not for SenML concepts per se. Note that
"attribute" has been widely used previously as a synonym for SenML "attribute" has been widely used previously as a synonym for SenML
"field", though. "field", though.
All comparisons of text strings are performed byte-by-byte (and All comparisons of text strings are performed byte-by-byte (and
therefore necessarily case-sensitive). therefore necessarily case-sensitive).
Where arithmetic is used, this specification uses the notation
familiar from the programming language C, except that the operator
"**" stands for exponentiation.
4. SenML Structure and Semantics 4. SenML Structure and Semantics
Each SenML Pack carries a single array that represents a set of Each SenML Pack carries a single array that represents a set of
measurements and/or parameters. This array contains a series of measurements and/or parameters. This array contains a series of
SenML Records with several fields described below. There are two SenML Records with several fields described below. There are two
kinds of fields: base and regular. Both the base fields and the kinds of fields: base and regular. Both the base fields and the
regular fields can be included in any SenML Record. The base fields 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 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 up to, but not including, the next Record that has that same base
field. All base fields are optional. Regular fields can be included field. All base fields are optional. Regular fields can be included
skipping to change at page 10, line 9 skipping to change at page 10, line 11
If the Record has no Unit, the Base Unit is used as the Unit. Having 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 no Unit and no Base Unit is allowed; any information that may be
required about units applicable to the value then needs to be required about units applicable to the value then needs to be
provided by the application context. provided by the application context.
4.5.3. Time 4.5.3. Time
If either the Base Time or Time value is missing, the missing field 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 is considered to have a value of zero. The Base Time and Time values
are added together to get the time of measurement. A time of zero are added together to get the time of measurement.
indicates that the sensor does not know the absolute time and the
measurement was made roughly "now". A negative value is used to Values less than 268,435,456 (2**28) represent time relative to the
indicate seconds in the past from roughly "now". A positive value is current time. That is, a time of zero indicates that the sensor does
used to indicate the number of seconds, excluding leap seconds, since not know the absolute time and the measurement was made roughly
the start of the year 1970 in UTC. "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". Positive values can be used, e.g., for actuation use
when the desired change should happen in the future but the sender or
the receiver does not have accurate time available.
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 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.
Because time values up to 2**28 are used for presenting 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.
Obviously, "now"-referenced SenML records are only useful within a Obviously, "now"-referenced SenML records are only useful within a
specific communication context (e.g., based on information on when specific communication context (e.g., based on information on when
the SenML pack, or a specific record in a SensML stream, was sent) or 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 together with some other context information that can be used for
deriving a meaning of "now"; the expectation for any archival use is deriving a meaning of "now"; the expectation for any archival use is
that they will be processed into UTC-referenced records before that that they will be processed into UTC-referenced records before that
context would cease to be available. This specification deliberately context would cease to be available. This specification deliberately
leaves the accuracy of "now" very vague as it is determined by the 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 overall systems that use SenML. In a system where a sensor without
skipping to change at page 12, line 18 skipping to change at page 12, line 34
transmit SenML in a stream-like fashion, where data is collected over transmit SenML in a stream-like fashion, where data is collected over
time and continuously added to the object. This mode of operation is time and continuously added to the object. This mode of operation is
optional, but systems or protocols using SenML in this fashion MUST optional, but systems or protocols using SenML in this fashion MUST
specify that they are doing this. SenML defines separate media types specify that they are doing this. SenML defines separate media types
to indicate Sensor Streaming Measurement Lists (SensML) for this to indicate Sensor Streaming Measurement Lists (SensML) for this
usage (see Section 12.3.2). In this situation, the SensML stream can 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 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 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. to wait for the full SensML Stream to be complete.
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.9. Configuration and Actuation usage 4.9. Configuration and Actuation usage
SenML can also be used for configuring parameters and controlling SenML can also be used for configuring parameters and controlling
actuators. When a SenML Pack is sent (e.g., using a HTTP/CoAP POST actuators. When a SenML Pack is sent (e.g., using a HTTP/CoAP POST
or PUT method) and the semantics of the target are such that SenML is or PUT method) and the semantics of the target are such that SenML is
interpreted as configuration/actuation, SenML Records are interpreted interpreted as configuration/actuation, SenML Records are interpreted
as a request to change the values of given (sub)resources (given as 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 names) to given values at the given time(s). The semantics of the
target resource supporting this usage can be described, e.g., using target resource supporting this usage can be described, e.g., using
[I-D.ietf-core-interfaces]. Examples of actuation usage are shown in [I-D.ietf-core-interfaces]. Examples of actuation usage are shown in
skipping to change at page 45, line 36 skipping to change at page 45, line 36
health information. When SenML is used for configuration or health information. When SenML is used for configuration or
actuation, it can be used to change the state of systems and also 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 impact the physical world, e.g., by turning off a heater or opening a
lock. lock.
The SenML formats alone do not provide any security and instead rely The SenML formats alone do not provide any security and instead rely
on the protocol that carries them to provide security. Applications on the protocol that carries them to provide security. Applications
using SenML need to look at the overall context of how these formats 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 will be used to decide if the security is adequate. In particular
for sensitive sensor data and actuation use it is important to ensure for sensitive sensor data and actuation use it is important to ensure
that proper security mechanisms are used. that proper security mechanisms are used to provide, e.g.,
confidentiality, data integrity, and authentication as appropriate
for the usage.
The SenML formats defined by this specification do not contain any The SenML formats defined by this specification do not contain any
executable content. However, future extensions could potentially executable content. However, future extensions could potentially
embed application specific executable content in the data. embed application specific executable content in the data.
SenML Records are intended to be interpreted in the context of any SenML Records are intended to be interpreted in the context of any
applicable base values. If records become separated from the record applicable base values. If records become separated from the record
that establishes the base values, the data will be useless or, worse, 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 wrong. Care needs to be taken in keeping the integrity of a Pack
that contains unresolved SenML Records (see Section 4.6). that contains unresolved SenML Records (see Section 4.6).
skipping to change at page 46, line 43 skipping to change at page 46, line 43
16. References 16. References
16.1. Normative References 16.1. Normative References
[BIPM] Bureau International des Poids et Mesures, "The [BIPM] Bureau International des Poids et Mesures, "The
International System of Units (SI)", 8th edition, 2006. International System of Units (SI)", 8th edition, 2006.
[IEEE.754.1985] [IEEE.754.1985]
Institute of Electrical and Electronics Engineers, Institute of Electrical and Electronics Engineers,
"Standard for Binary Floating-Point Arithmetic", IEEE "Standard for Binary Floating-Point Arithmetic",
Standard 754, August 1985. IEEE Standard 754, August 1985.
[NIST811] Thompson, A. and B. Taylor, "Guide for the Use of the [NIST811] Thompson, A. and B. Taylor, "Guide for the Use of the
International System of Units (SI)", NIST Special International System of Units (SI)", NIST Special
Publication 811, 2008. Publication 811, 2008.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ Requirement Levels", BCP 14, RFC 2119,
RFC2119, March 1997, <https://www.rfc-editor.org/info/ DOI 10.17487/RFC2119, March 1997,
rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November
2003, <https://www.rfc-editor.org/info/rfc3629>. 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004, <https://www.rfc- DOI 10.17487/RFC3688, January 2004,
editor.org/info/rfc3688>. <https://www.rfc-editor.org/info/rfc3688>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<https://www.rfc-editor.org/info/rfc4648>. <https://www.rfc-editor.org/info/rfc4648>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, RFC Specifications and Registration Procedures", BCP 13,
6838, DOI 10.17487/RFC6838, January 2013, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>. <https://www.rfc-editor.org/info/rfc6838>.
[RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object [RFC7049] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049, Representation (CBOR)", RFC 7049, DOI 10.17487/RFC7049,
October 2013, <https://www.rfc-editor.org/info/rfc7049>. October 2013, <https://www.rfc-editor.org/info/rfc7049>.
[RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
Application Protocol (CoAP)", RFC 7252, DOI 10.17487/ Application Protocol (CoAP)", RFC 7252,
RFC7252, June 2014, <https://www.rfc-editor.org/info/ DOI 10.17487/RFC7252, June 2014,
rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303, [RFC7303] Thompson, H. and C. Lilley, "XML Media Types", RFC 7303,
DOI 10.17487/RFC7303, July 2014, <https://www.rfc- DOI 10.17487/RFC7303, July 2014,
editor.org/info/rfc7303>. <https://www.rfc-editor.org/info/rfc7303>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26, Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017, RFC 8126, DOI 10.17487/RFC8126, June 2017,
<https://www.rfc-editor.org/info/rfc8126>. <https://www.rfc-editor.org/info/rfc8126>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259, DOI 10.17487/ Interchange Format", STD 90, RFC 8259,
RFC8259, December 2017, <https://www.rfc-editor.org/info/ DOI 10.17487/RFC8259, December 2017,
rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
[RNC] ISO/IEC, "Information technology -- Document Schema [RNC] ISO/IEC, "Information technology -- Document Schema
Definition Language (DSDL) -- Part 2: Regular-grammar- Definition Language (DSDL) -- Part 2: Regular-grammar-
based validation -- RELAX NG", ISO/IEC 19757-2, Annex C: based validation -- RELAX NG", ISO/IEC 19757-2, Annex
RELAX NG Compact syntax, December 2008. C: RELAX NG Compact syntax, December 2008.
[TIME_T] The Open Group Base Specifications, "Vol. 1: Base [TIME_T] The Open Group Base Specifications, "Vol. 1: Base
Definitions, Issue 7", Section 4.15 'Seconds Since the Definitions, Issue 7", Section 4.15 'Seconds Since the
Epoch', IEEE Std 1003.1, 2013 Edition, 2013, Epoch', IEEE Std 1003.1, 2013 Edition, 2013,
<http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/ <http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/
V1_chap04.html#tag_04_15>. V1_chap04.html#tag_04_15>.
[W3C.REC-exi-20140211] [W3C.REC-exi-20140211]
Schneider, J., Kamiya, T., Peintner, D., and R. Kyusakov, Schneider, J., Kamiya, T., Peintner, D., and R. Kyusakov,
"Efficient XML Interchange (EXI) Format 1.0 (Second "Efficient XML Interchange (EXI) Format 1.0 (Second
skipping to change at page 48, line 40 skipping to change at page 48, line 40
[W3C.REC-xmlschema-1-20041028] [W3C.REC-xmlschema-1-20041028]
Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn, Thompson, H., Beech, D., Maloney, M., and N. Mendelsohn,
"XML Schema Part 1: Structures Second Edition", World Wide "XML Schema Part 1: Structures Second Edition", World Wide
Web Consortium Recommendation REC-xmlschema-1-20041028, Web Consortium Recommendation REC-xmlschema-1-20041028,
October 2004, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[XPointerElement] [XPointerElement]
Grosso, P., Maler, E., Marsh, J., and N. Walsh, "XPointer Grosso, P., Maler, E., Marsh, J., and N. Walsh, "XPointer
element() Scheme", W3C Recommendation REC-xptr-element, element() Scheme", W3C Recommendation REC-xptr-element,
March 2003, <https://www.w3.org/TR/2003/REC-xptr-element- March 2003,
20030325/>. <https://www.w3.org/TR/2003/REC-xptr-element-20030325/>.
[XPointerFramework] [XPointerFramework]
Grosso, P., Maler, E., Marsh, J., and N. Walsh, "XPointer Grosso, P., Maler, E., Marsh, J., and N. Walsh, "XPointer
Framework", W3C Recommendation REC-XPointer-Framework, Framework", W3C Recommendation REC-XPointer-Framework,
March 2003, March 2003,
<http://www.w3.org/TR/2003/REC-xptr-framework-20030325/>. <http://www.w3.org/TR/2003/REC-xptr-framework-20030325/>.
16.2. Informative References 16.2. Informative References
[AN1796] Linke, B., "Overview of 1-Wire Technology and Its Use", [AN1796] Linke, B., "Overview of 1-Wire Technology and Its Use",
skipping to change at page 49, line 38 skipping to change at page 49, line 38
[IEEE802.1as-2011] [IEEE802.1as-2011]
IEEE, "IEEE Standard for Local and Metropolitan Area IEEE, "IEEE Standard for Local and Metropolitan Area
Networks - Timing and Synchronization for Time-Sensitive Networks - Timing and Synchronization for Time-Sensitive
Applications in Bridged Local Area Networks", 2011. Applications in Bridged Local Area Networks", 2011.
[IEEE802.1ba-2011] [IEEE802.1ba-2011]
IEEE, "IEEE Standard for Local and metropolitan area IEEE, "IEEE Standard for Local and metropolitan area
networks--Audio Video Bridging (AVB) Systems", 2011. networks--Audio Video Bridging (AVB) Systems", 2011.
[ISO-80000-5] [ISO-80000-5]
"Quantities and units - Part 5: Thermodynamics", ISO "Quantities and units - Part 5: Thermodynamics",
80000-5, Edition 1.0, May 2007. ISO 80000-5, Edition 1.0, May 2007.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818,
RFC2818, May 2000, <https://www.rfc-editor.org/info/ DOI 10.17487/RFC2818, May 2000,
rfc2818>. <https://www.rfc-editor.org/info/rfc2818>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, RFC Resource Identifier (URI): Generic Syntax", STD 66,
3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI Unique IDentifier (UUID) URN Namespace", RFC 4122,
10.17487/RFC4122, July 2005, <https://www.rfc- DOI 10.17487/RFC4122, July 2005,
editor.org/info/rfc4122>. <https://www.rfc-editor.org/info/rfc4122>.
[RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme", RFC [RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme",
4151, DOI 10.17487/RFC4151, October 2005, RFC 4151, DOI 10.17487/RFC4151, October 2005,
<https://www.rfc-editor.org/info/rfc4151>. <https://www.rfc-editor.org/info/rfc4151>.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<https://www.rfc-editor.org/info/rfc4944>. <https://www.rfc-editor.org/info/rfc4944>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, DOI 10.17487/RFC5751, January Specification", RFC 5751, DOI 10.17487/RFC5751, January
2010, <https://www.rfc-editor.org/info/rfc5751>. 2010, <https://www.rfc-editor.org/info/rfc5751>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, DOI 10.17487/ Address Text Representation", RFC 5952,
RFC5952, August 2010, <https://www.rfc-editor.org/info/ DOI 10.17487/RFC5952, August 2010,
rfc5952>. <https://www.rfc-editor.org/info/rfc5952>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<https://www.rfc-editor.org/info/rfc6690>. <https://www.rfc-editor.org/info/rfc6690>.
[RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., [RFC6920] Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B.,
Keranen, A., and P. Hallam-Baker, "Naming Things with Keranen, A., and P. Hallam-Baker, "Naming Things with
Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013, Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013,
<https://www.rfc-editor.org/info/rfc6920>. <https://www.rfc-editor.org/info/rfc6920>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, DOI Considerations for Internet Protocols", RFC 6973,
10.17487/RFC6973, July 2013, <https://www.rfc- DOI 10.17487/RFC6973, July 2013,
editor.org/info/rfc6973>. <https://www.rfc-editor.org/info/rfc6973>.
[RFC7111] Hausenblas, M., Wilde, E., and J. Tennison, "URI Fragment [RFC7111] Hausenblas, M., Wilde, E., and J. Tennison, "URI Fragment
Identifiers for the text/csv Media Type", RFC 7111, DOI Identifiers for the text/csv Media Type", RFC 7111,
10.17487/RFC7111, January 2014, <https://www.rfc- DOI 10.17487/RFC7111, January 2014,
editor.org/info/rfc7111>. <https://www.rfc-editor.org/info/rfc7111>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
Protocol (HTTP/1.1): Message Syntax and Routing", RFC Protocol (HTTP/1.1): Message Syntax and Routing",
7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc- RFC 7230, DOI 10.17487/RFC7230, June 2014,
editor.org/info/rfc7230>. <https://www.rfc-editor.org/info/rfc7230>.
[RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy [RFC7721] Cooper, A., Gont, F., and D. Thaler, "Security and Privacy
Considerations for IPv6 Address Generation Mechanisms", Considerations for IPv6 Address Generation Mechanisms",
RFC 7721, DOI 10.17487/RFC7721, March 2016, RFC 7721, DOI 10.17487/RFC7721, March 2016,
<https://www.rfc-editor.org/info/rfc7721>. <https://www.rfc-editor.org/info/rfc7721>.
[RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names [RFC8141] Saint-Andre, P. and J. Klensin, "Uniform Resource Names
(URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017, (URNs)", RFC 8141, DOI 10.17487/RFC8141, April 2017,
<https://www.rfc-editor.org/info/rfc8141>. <https://www.rfc-editor.org/info/rfc8141>.
 End of changes. 33 change blocks. 
69 lines changed or deleted 94 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/