< draft-ietf-core-dynlink-08.txt   draft-ietf-core-dynlink-09.txt >
CoRE Working Group Z. Shelby CoRE Working Group Z. Shelby
Internet-Draft ARM Internet-Draft ARM
Intended status: Informational M. Koster Intended status: Informational M. Koster
Expires: September 9, 2019 SmartThings Expires: January 9, 2020 SmartThings
C. Groves C. Groves
J. Zhu J. Zhu
Huawei Huawei
B. Silverajan, Ed. B. Silverajan, Ed.
Tampere University Tampere University
March 08, 2019 July 08, 2019
Dynamic Resource Linking for Constrained RESTful Environments Dynamic Resource Linking for Constrained RESTful Environments
draft-ietf-core-dynlink-08 draft-ietf-core-dynlink-09
Abstract Abstract
This specification defines Link Bindings, which provide dynamic This specification defines Link Bindings, which provide dynamic
linking of state updates between resources, either on an endpoint or linking of state updates between resources, either on an endpoint or
between endpoints, for systems using CoAP (RFC7252). This between endpoints, for systems using CoAP (RFC7252). This
specification also defines Conditional Notification Attributes that specification also defines Conditional Notification Attributes that
work with Link Bindings or with CoAP Observe (RFC7641). work with Link Bindings or with CoAP Observe (RFC7641).
Editor note Editor note
skipping to change at page 1, line 46 skipping to change at page 1, line 46
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 https://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 September 9, 2019. This Internet-Draft will expire on January 9, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
(https://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
skipping to change at page 2, line 27 skipping to change at page 2, line 27
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. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Conditional Notification Attributes . . . . . . . . . . . . . 4 3. Conditional Notification Attributes . . . . . . . . . . . . . 4
3.1. Attribute Definitions . . . . . . . . . . . . . . . . . . 4 3.1. Attribute Definitions . . . . . . . . . . . . . . . . . . 4
3.1.1. Minimum Period (pmin) . . . . . . . . . . . . . . . . 5 3.1.1. Minimum Period (pmin) . . . . . . . . . . . . . . . . 5
3.1.2. Maximum Period (pmax) . . . . . . . . . . . . . . . . 5 3.1.2. Maximum Period (pmax) . . . . . . . . . . . . . . . . 6
3.1.3. Change Step (st) . . . . . . . . . . . . . . . . . . 5 3.1.3. Change Step (st) . . . . . . . . . . . . . . . . . . 6
3.1.4. Greater Than (gt) . . . . . . . . . . . . . . . . . . 6 3.1.4. Greater Than (gt) . . . . . . . . . . . . . . . . . . 6
3.1.5. Less Than (lt) . . . . . . . . . . . . . . . . . . . 6 3.1.5. Less Than (lt) . . . . . . . . . . . . . . . . . . . 7
3.1.6. Notification Band (band) . . . . . . . . . . . . . . 7 3.1.6. Notification Band (band) . . . . . . . . . . . . . . 7
3.2. Server processing of Conditional Notification Attributes 8 3.2. Server processing of Conditional Notification Attributes 8
4. Link Bindings . . . . . . . . . . . . . . . . . . . . . . . . 8 4. Link Bindings . . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. The "bind" attribute and Binding Methods . . . . . . . . 9 4.1. The "bind" attribute and Binding Methods . . . . . . . . 10
4.1.1. Polling . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.1. Polling . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.2. Observe . . . . . . . . . . . . . . . . . . . . . . . 10 4.1.2. Observe . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.3. Push . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.3. Push . . . . . . . . . . . . . . . . . . . . . . . . 12
4.2. Link Relation . . . . . . . . . . . . . . . . . . . . . . 11 4.2. Link Relation . . . . . . . . . . . . . . . . . . . . . . 12
5. Binding Table . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Binding Table . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Implementation Considerations . . . . . . . . . . . . . . . . 12 6. Implementation Considerations . . . . . . . . . . . . . . . . 13
7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
8.1. Resource Type value 'core.bnd' . . . . . . . . . . . . . 13 8.1. Resource Type value 'core.bnd' . . . . . . . . . . . . . 14
8.2. Link Relation Type . . . . . . . . . . . . . . . . . . . 13 8.2. Link Relation Type . . . . . . . . . . . . . . . . . . . 14
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15
10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 14 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 15
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
12.1. Normative References . . . . . . . . . . . . . . . . . . 16 12.1. Normative References . . . . . . . . . . . . . . . . . . 17
12.2. Informative References . . . . . . . . . . . . . . . . . 17 12.2. Informative References . . . . . . . . . . . . . . . . . 18
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 17 Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18
A.1. Greater Than (gt) example . . . . . . . . . . . . . . . . 17 A.1. Minimum Period (pmin) example . . . . . . . . . . . . . . 18
A.2. Greater Than (gt) and Period Max (pmax) example . . . . . 18 A.2. Maximum Period (pmax) example . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 A.3. Greater Than (gt) example . . . . . . . . . . . . . . . . 20
A.4. Greater Than (gt) and Period Max (pmax) example . . . . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
IETF Standards for machine to machine communication in constrained IETF Standards for machine to machine communication in constrained
environments describe a REST protocol [RFC7252] and a set of related environments describe a REST protocol [RFC7252] and a set of related
information standards that may be used to represent machine data and information standards that may be used to represent machine data and
machine metadata in REST interfaces. CoRE Link-format [RFC6690] is a machine metadata in REST interfaces. CoRE Link-format [RFC6690] is a
standard for doing Web Linking [RFC8288] in constrained environments. standard for doing Web Linking [RFC8288] in constrained environments.
This specification introduces the concept of a Link Binding, which This specification introduces the concept of a Link Binding, which
defines a new link relation type to create a dynamic link between defines a new link relation type to create a dynamic link between
resources over which state updates are conveyed. Specifically, a resources over which state updates are conveyed. Specifically, a
Link Binding is a unidirectional link for binding the states of Link Binding is a unidirectional link for binding the states of
source and destination resources together such that updates to one source and destination resources together such that updates to one
are sent over the link to the other. CoRE Link Format are sent over the link to the other. CoRE Link Format
representations are used to configure, inspect, and maintain Link representations are used to configure, inspect, and maintain Link
Bindings. This specification additionally defines Conditional Bindings. This specification additionally defines Conditional
Notification Attributes for use with Link Bindings and with the CoRE Notification Attributes for use with Link Bindings and with CoRE
Observe [RFC7641] method. Observe [RFC7641].
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This specification requires readers to be familiar with all the terms This specification requires readers to be familiar with all the terms
skipping to change at page 4, line 34 skipping to change at page 5, line 5
The set of parameters defined here allow a client to control how The set of parameters defined here allow a client to control how
often a client is interested in receiving notifications and how much often a client is interested in receiving notifications and how much
a resource value should change for the new representation to be a resource value should change for the new representation to be
interesting. interesting.
One or more Notification Attributes MAY be included as query One or more Notification Attributes MAY be included as query
parameters in an Observe request. parameters in an Observe request.
These attributes are defined below: These attributes are defined below:
+--------------------+-----------+------------------+ +--------------------+-----------+-----------------+
| Attribute | Parameter | Value | | Attribute | Parameter | Value |
+--------------------+-----------+------------------+ +--------------------+-----------+-----------------+
| Minimum Period (s) | pmin | xsd:decimal (>0) | | Minimum Period (s) | pmin | xs:decimal (>0) |
| | | | | | | |
| Maximum Period (s) | pmax | xsd:decimal (>0) | | Maximum Period (s) | pmax | xs:decimal (>0) |
| | | | | | | |
| Change Step | st | xsd:decimal (>0) | | Change Step | st | xs:decimal (>0) |
| | | | | | | |
| Greater Than | gt | xsd:decimal | | Greater Than | gt | xs:decimal |
| | | | | | | |
| Less Than | lt | xsd:decimal | | Less Than | lt | xs:decimal |
| | | | | | | |
| Notification Band | band | xsd:boolean | | Notification Band | band | xs:boolean |
+--------------------+-----------+------------------+ +--------------------+-----------+-----------------+
Table 1: Conditional Notification Attributes Table 1: Conditional Notification Attributes
Conditional Notification Attributes SHOULD be evaluated on all Conditional Notification Attributes SHOULD be evaluated on all
potential notifications from a resource, whether resulting from an potential notifications from a resource, whether resulting from an
internal server-driven sampling process or from external update internal server-driven sampling process or from external update
requests to the server. requests to the server.
Note: In this draft, we assume that there are finite quantization Note: In this draft, we assume that there are finite quantization
effects in the internal or external updates to the value of a effects in the internal or external updates to the value of a
skipping to change at page 9, line 43 skipping to change at page 10, line 32
A binding method defines the rules to generate the network-transfer A binding method defines the rules to generate the network-transfer
exchanges that synchronize state between source and destination exchanges that synchronize state between source and destination
resources. By using REST methods content is sent from the source resources. By using REST methods content is sent from the source
resource to the destination resource. resource to the destination resource.
This specification defines a new CoRE link attribute "bind". This is This specification defines a new CoRE link attribute "bind". This is
the identifier for a binding method which defines the rules to the identifier for a binding method which defines the rules to
synchronize the destination resource. This attribute is mandatory. synchronize the destination resource. This attribute is mandatory.
+----------------+-----------+------------+ +----------------+-----------+-----------+
| Attribute | Parameter | Value | | Attribute | Parameter | Value |
+----------------+-----------+------------+ +----------------+-----------+-----------+
| Binding method | bind | xsd:string | | Binding method | bind | xs:string |
+----------------+-----------+------------+ +----------------+-----------+-----------+
Table 2: The bind attribute Table 2: The bind attribute
The following table gives a summary of the binding methods defined in The following table gives a summary of the binding methods defined in
this specification. this specification.
+---------+------------+-------------+---------------+ +---------+------------+-------------+---------------+
| Name | Identifier | Location | Method | | Name | Identifier | Location | Method |
+---------+------------+-------------+---------------+ +---------+------------+-------------+---------------+
| Polling | poll | Destination | GET | | Polling | poll | Destination | GET |
skipping to change at page 12, line 5 skipping to change at page 13, line 5
Table 4: Binding Table Description Table 4: Binding Table Description
The REST methods GET and PUT are used to manipulate a Binding Table. The REST methods GET and PUT are used to manipulate a Binding Table.
A GET request simply returns the current state of a Binding Table. A A GET request simply returns the current state of a Binding Table. A
request with a PUT method and a content format of application/link- request with a PUT method and a content format of application/link-
format is used to clear the bindings to the table or replaces its format is used to clear the bindings to the table or replaces its
entire contents. All links in the payload of a PUT rquest MUST have entire contents. All links in the payload of a PUT rquest MUST have
a relation type "boundto". a relation type "boundto".
(Editor's Note: Usage of the PATCH method for fine-grained addition
and removal of individual bindings is under study.)
The following example shows requests for discovering, retrieving and The following example shows requests for discovering, retrieving and
replacing bindings in a binding table. replacing bindings in a binding table.
Req: GET /.well-known/core?rt=core.bnd (application/link-format) Req: GET /.well-known/core?rt=core.bnd (application/link-format)
Res: 2.05 Content (application/link-format) Res: 2.05 Content (application/link-format)
</bnd/>;rt=core.bnd;ct=40 </bnd/>;rt=core.bnd;ct=40
Req: GET /bnd/ Req: GET /bnd/
Res: 2.05 Content (application/link-format) Res: 2.05 Content (application/link-format)
<coap://sensor.example.com/a/switch1/>; <coap://sensor.example.com/a/switch1/>;
rel=boundto;bind=obs;anchor=/a/fan,;bind="obs", rel=boundto;anchor=/a/fan,;bind="obs",
<coap://sensor.example.com/a/switch2/>; <coap://sensor.example.com/a/switch2/>;
rel=boundto;bind=obs;anchor=/a/light;bind="obs" rel=boundto;anchor=/a/light;bind="obs"
Req: PUT /bnd/ (Content-Format: application/link-format) Req: PUT /bnd/ (Content-Format: application/link-format)
<coap://sensor.example.com/s/light>; <coap://sensor.example.com/s/light>;
rel="boundto";anchor="/a/light";bind="obs";pmin="10";pmax="60" rel="boundto";anchor="/a/light";bind="obs";pmin=10;pmax=60
Res: 2.04 Changed Res: 2.04 Changed
Req: GET /bnd/ Req: GET /bnd/
Res: 2.05 Content (application/link-format) Res: 2.05 Content (application/link-format)
<coap://sensor.example.com/s/light>; <coap://sensor.example.com/s/light>;
rel="boundto";anchor="/a/light";bind="obs";pmin="10";pmax="60" rel="boundto";anchor="/a/light";bind="obs";pmin=10;pmax=60
Figure 2: Binding Table Example Figure 2: Binding Table Example
Additional operations on the Binding Table can be specified in future
documents. Such operations can include, for example, the usage of
the iPATCH or PATCH methods [RFC8132] for fine-grained addition and
removal of individual bindings or binding subsets.
6. Implementation Considerations 6. Implementation Considerations
When using multiple resource bindings (e.g. multiple Observations of When using multiple resource bindings (e.g. multiple Observations of
resource) with different bands, consideration should be given to the resource) with different bands, consideration should be given to the
resolution of the resource value when setting sequential bands. For resolution of the resource value when setting sequential bands. For
example: Given BandA (Abmn=10, Bbmx=20) and BandB (Bbmn=21, Bbmx=30). example: Given BandA (Abmn=10, Bbmx=20) and BandB (Bbmn=21, Bbmx=30).
If the resource value returns an integer then notifications for If the resource value returns an integer then notifications for
values between and inclusive of 10 and 30 will be triggered. Whereas values between and inclusive of 10 and 30 will be triggered. Whereas
if the resolution is to one decimal point (0.1) then notifications if the resolution is to one decimal point (0.1) then notifications
for values 20.1 to 20.9 will not be triggered. for values 20.1 to 20.9 will not be triggered.
skipping to change at page 14, line 21 skipping to change at page 15, line 23
9. Acknowledgements 9. Acknowledgements
Acknowledgement is given to colleagues from the SENSEI project who Acknowledgement is given to colleagues from the SENSEI project who
were critical in the initial development of the well-known REST were critical in the initial development of the well-known REST
interface concept, to members of the IPSO Alliance where further interface concept, to members of the IPSO Alliance where further
requirements for interface types have been discussed, and to Szymon requirements for interface types have been discussed, and to Szymon
Sasin, Cedric Chauvenet, Daniel Gavelle and Carsten Bormann who have Sasin, Cedric Chauvenet, Daniel Gavelle and Carsten Bormann who have
provided useful discussion and input to the concepts in this provided useful discussion and input to the concepts in this
specification. Christian Amsuss supplied a comprehensive review of specification. Christian Amsuss supplied a comprehensive review of
draft -06. draft -06. Hannes Tschofenig and Mert Ocak highlighted syntactical
corrections in the usage of pmax and pmin in a query.
10. Contributors 10. Contributors
Matthieu Vial Matthieu Vial
Schneider-Electric Schneider-Electric
Grenoble Grenoble
France France
Phone: +33 (0)47657 6522 Phone: +33 (0)47657 6522
EMail: matthieu.vial@schneider-electric.com EMail: matthieu.vial@schneider-electric.com
11. Changelog 11. Changelog
draft-ietf-core-dynlink-09
o Corrections in Table 1, Table 2, Figure 2.
o Clarifications for additional operations to binding table added in
section 5
o Additional examples in Appendix A
draft-ietf-core-dynlink-08 draft-ietf-core-dynlink-08
o Reorganize the draft to introduce Conditional Notification o Reorganize the draft to introduce Conditional Notification
Attributes at the beginning Attributes at the beginning
o Made pmin and pmax type xsd:decimal to accommodate fractional o Made pmin and pmax type xs:decimal to accommodate fractional
second timing second timing
o updated the attribute descriptions. lt and gt notify on all o updated the attribute descriptions. lt and gt notify on all
crossings, both directions crossings, both directions
o updated Binding Table description, removed interface description o updated Binding Table description, removed interface description
but introduced core.bnd rt attribute value but introduced core.bnd rt attribute value
draft-ietf-core-dynlink-07 draft-ietf-core-dynlink-07
o Added reference code to illustrate attribute interactions for o Added reference code to illustrate attribute interactions for
observations observations
draft-ietf-core-dynlink-06
o Document restructure and refactoring into three main sections o Document restructure and refactoring into three main sections
o Clarifications on band usage o Clarifications on band usage
o Implementation considerations introduced o Implementation considerations introduced
o Additional text on security considerations o Additional text on security considerations
draft-ietf-core-dynlink-05 draft-ietf-core-dynlink-05
skipping to change at page 17, line 17 skipping to change at page 18, line 29
[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, Application Protocol (CoAP)", RFC 7252,
DOI 10.17487/RFC7252, June 2014, DOI 10.17487/RFC7252, June 2014,
<https://www.rfc-editor.org/info/rfc7252>. <https://www.rfc-editor.org/info/rfc7252>.
[RFC7641] Hartke, K., "Observing Resources in the Constrained [RFC7641] Hartke, K., "Observing Resources in the Constrained
Application Protocol (CoAP)", RFC 7641, Application Protocol (CoAP)", RFC 7641,
DOI 10.17487/RFC7641, September 2015, DOI 10.17487/RFC7641, September 2015,
<https://www.rfc-editor.org/info/rfc7641>. <https://www.rfc-editor.org/info/rfc7641>.
[RFC8132] van der Stok, P., Bormann, C., and A. Sehgal, "PATCH and
FETCH Methods for the Constrained Application Protocol
(CoAP)", RFC 8132, DOI 10.17487/RFC8132, April 2017,
<https://www.rfc-editor.org/info/rfc8132>.
Appendix A. Examples Appendix A. Examples
This appendix provides some examples of the use of binding attribute This appendix provides some examples of the use of binding attribute
/ observe attributes. / observe attributes.
Note: For brevity the only the method or response code is shown in Note: For brevity the only the method or response code is shown in
the header field. the header field.
A.1. Greater Than (gt) example A.1. Minimum Period (pmin) example
Observed CLIENT SERVER Actual
t State | | State
____________ | | ____________
1 | |
2 unknown | | 18.5 Cel
3 +----->| Header: GET
4 | GET | Token: 0x4a
5 | | Uri-Path: temperature
6 | | Uri-Query: pmin="10"
7 | | Observe: 0 (register)
8 | |
9 ____________ |<-----+ Header: 2.05
10 | 2.05 | Token: 0x4a
11 18.5 Cel | | Observe: 9
12 | | Payload: "18.5 Cel"
13 | | ____________
14 | |
15 | | 23 Cel
16 | |
17 | |
18 | |
19 | | ____________
20 ____________ |<-----+ Header: 2.05
21 | 2.05 | 26 Cel Token: 0x4a
22 26 Cel | | Observe: 20
23 | | Payload: "26 Cel"
24 | |
25 | |
Figure 3: Client registers and receives one notification of the
current state and one of a new state state when pmin time expires.
A.2. Maximum Period (pmax) example
Observed CLIENT SERVER Actual
t State | | State
____________ | | ____________
1 | |
2 unknown | | 18.5 Cel
3 +----->| Header: GET
4 | GET | Token: 0x4a
5 | | Uri-Path: temperature
6 | | Uri-Query: pmax="20"
7 | | Observe: 0 (register)
8 | |
9 ____________ |<-----+ Header: 2.05
10 | 2.05 | Token: 0x4a
11 18.5 Cel | | Observe: 9
12 | | Payload: "18.5 Cel"
13 | |
14 | |
15 | | ____________
16 ____________ |<-----+ Header: 2.05
17 | 2.05 | 23 Cel Token: 0x4a
18 23 Cel | | Observe: 16
19 | | Payload: "23 Cel"
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
32 | |
33 | |
34 | |
35 | |
36 | | ____________
37 ____________ |<-----+ Header: 2.05
38 | 2.05 | 23 Cel Token: 0x4a
39 23 Cel | | Observe: 37
40 | | Payload: "23 Cel"
41 | |
42 | |
Figure 4: Client registers and receives one notification of the
current state, one of a new state and one of an unchanged state when
pmax time expires.
A.3. Greater Than (gt) example
Observed CLIENT SERVER Actual Observed CLIENT SERVER Actual
t State | | State t State | | State
____________ | | ____________ ____________ | | ____________
1 | | 1 | |
2 unknown | | 18.5 Cel 2 unknown | | 18.5 Cel
3 +----->| Header: GET 3 +----->| Header: GET
4 | GET | Token: 0x4a 4 | GET | Token: 0x4a
5 | | Uri-Path: temperature 5 | | Uri-Path: temperature
6 | | Uri-Query: gt="25" 6 | | Uri-Query: gt=25
7 | | Observe: 0 (register) 7 | | Observe: 0 (register)
8 | | 8 | |
9 ____________ |<-----+ Header: 2.05 9 ____________ |<-----+ Header: 2.05
10 | 2.05 | Token: 0x4a 10 | 2.05 | Token: 0x4a
11 18.5 Cel | | Observe: 9 11 18.5 Cel | | Observe: 9
12 | | Payload: "18.5 Cel" 12 | | Payload: "18.5 Cel"
13 | | 13 | |
14 | | 14 | |
15 | | ____________ 15 | | ____________
16 ____________ |<-----+ Header: 2.05 16 ____________ |<-----+ Header: 2.05
17 | 2.05 | 26 Cel Token: 0x4a 17 | 2.05 | 26 Cel Token: 0x4a
18 26 Cel | | Observe: 16 18 26 Cel | | Observe: 16
29 | | Payload: "26 Cel" 29 | | Payload: "26 Cel"
20 | | 20 | |
21 | | 21 | |
Figure 3: Client Registers and Receives one Notification of the Figure 5: Client registers and receives one notification of the
Current State and One of a New State when it passes through the current state and one of a new state when it passes through the
greather than threshold of 25. greater than threshold of 25.
A.2. Greater Than (gt) and Period Max (pmax) example A.4. Greater Than (gt) and Period Max (pmax) example
Observed CLIENT SERVER Actual Observed CLIENT SERVER Actual
t State | | State t State | | State
____________ | | ____________ ____________ | | ____________
1 | | 1 | |
2 unknown | | 18.5 Cel 2 unknown | | 18.5 Cel
3 +----->| Header: GET 3 +----->| Header: GET
4 | GET | Token: 0x4a 4 | GET | Token: 0x4a
5 | | Uri-Path: temperature 5 | | Uri-Path: temperature
6 | | Uri-Query: pmax="20";gt="25" 6 | | Uri-Query: pmax=20;gt=25
7 | | Observe: 0 (register) 7 | | Observe: 0 (register)
8 | | 8 | |
9 ____________ |<-----+ Header: 2.05 9 ____________ |<-----+ Header: 2.05
10 | 2.05 | Token: 0x4a 10 | 2.05 | Token: 0x4a
11 18.5 Cel | | Observe: 9 11 18.5 Cel | | Observe: 9
12 | | Payload: "18.5 Cel" 12 | | Payload: "18.5 Cel"
13 | | 13 | |
14 | | 14 | |
15 | | 15 | |
16 | | 16 | |
skipping to change at page 19, line 33 skipping to change at page 22, line 33
34 | | 34 | |
35 | | 35 | |
36 | | ____________ 36 | | ____________
37 ____________ |<-----+ Header: 2.05 37 ____________ |<-----+ Header: 2.05
38 | 2.05 | 26 Cel Token: 0x4a 38 | 2.05 | 26 Cel Token: 0x4a
39 26 Cel | | Observe: 37 39 26 Cel | | Observe: 37
40 | | Payload: "26 Cel" 40 | | Payload: "26 Cel"
41 | | 41 | |
42 | | 42 | |
Figure 4: Client Registers and Receives one Notification of the Figure 6: Client registers and receives one notification of the
Current State, one when pmax time expires and one of a new State when current state, one when pmax time expires and one of a new state when
it passes through the greather than threshold of 25. it passes through the greater than threshold of 25.
Authors' Addresses Authors' Addresses
Zach Shelby Zach Shelby
ARM ARM
Kidekuja 2 Kidekuja 2
Vuokatti 88600 Vuokatti 88600
FINLAND FINLAND
Phone: +358407796297 Phone: +358407796297
 End of changes. 27 change blocks. 
70 lines changed or deleted 176 lines changed or added

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