--- 1/draft-ietf-core-dynlink-09.txt 2019-07-22 14:13:46.916856523 -0700 +++ 2/draft-ietf-core-dynlink-10.txt 2019-07-22 14:13:46.972857945 -0700 @@ -1,25 +1,25 @@ CoRE Working Group Z. Shelby Internet-Draft ARM Intended status: Informational M. Koster -Expires: January 9, 2020 SmartThings +Expires: January 23, 2020 SmartThings C. Groves J. Zhu Huawei B. Silverajan, Ed. Tampere University - July 08, 2019 + July 22, 2019 Dynamic Resource Linking for Constrained RESTful Environments - draft-ietf-core-dynlink-09 + draft-ietf-core-dynlink-10 Abstract This specification defines Link Bindings, which provide dynamic linking of state updates between resources, either on an endpoint or between endpoints, for systems using CoAP (RFC7252). This specification also defines Conditional Notification Attributes that work with Link Bindings or with CoAP Observe (RFC7641). Editor note @@ -35,21 +35,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 9, 2020. + This Internet-Draft will expire on January 23, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. 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 @@ -70,39 +70,40 @@ 3.1.3. Change Step (st) . . . . . . . . . . . . . . . . . . 6 3.1.4. Greater Than (gt) . . . . . . . . . . . . . . . . . . 6 3.1.5. Less Than (lt) . . . . . . . . . . . . . . . . . . . 7 3.1.6. Notification Band (band) . . . . . . . . . . . . . . 7 3.2. Server processing of Conditional Notification Attributes 8 4. Link Bindings . . . . . . . . . . . . . . . . . . . . . . . . 9 4.1. The "bind" attribute and Binding Methods . . . . . . . . 10 4.1.1. Polling . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.2. Observe . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.3. Push . . . . . . . . . . . . . . . . . . . . . . . . 12 + 4.1.4. Execute . . . . . . . . . . . . . . . . . . . . . . . 12 4.2. Link Relation . . . . . . . . . . . . . . . . . . . . . . 12 - 5. Binding Table . . . . . . . . . . . . . . . . . . . . . . . . 12 - 6. Implementation Considerations . . . . . . . . . . . . . . . . 13 - 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 8.1. Resource Type value 'core.bnd' . . . . . . . . . . . . . 14 - 8.2. Link Relation Type . . . . . . . . . . . . . . . . . . . 14 - 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 - 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15 - 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 15 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 17 - 12.2. Informative References . . . . . . . . . . . . . . . . . 18 - Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18 - A.1. Minimum Period (pmin) example . . . . . . . . . . . . . . 18 - A.2. Maximum Period (pmax) example . . . . . . . . . . . . . . 19 - A.3. Greater Than (gt) example . . . . . . . . . . . . . . . . 20 - A.4. Greater Than (gt) and Period Max (pmax) example . . . . . 21 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 + 5. Binding Table . . . . . . . . . . . . . . . . . . . . . . . . 13 + 6. Implementation Considerations . . . . . . . . . . . . . . . . 14 + 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 8.1. Resource Type value 'core.bnd' . . . . . . . . . . . . . 15 + 8.2. Link Relation Type . . . . . . . . . . . . . . . . . . . 15 + 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 + 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 + 11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 18 + 12.2. Informative References . . . . . . . . . . . . . . . . . 19 + Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19 + A.1. Minimum Period (pmin) example . . . . . . . . . . . . . . 19 + A.2. Maximum Period (pmax) example . . . . . . . . . . . . . . 20 + A.3. Greater Than (gt) example . . . . . . . . . . . . . . . . 21 + A.4. Greater Than (gt) and Period Max (pmax) example . . . . . 22 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction IETF Standards for machine to machine communication in constrained environments describe a REST protocol [RFC7252] and a set of related information standards that may be used to represent machine data and machine metadata in REST interfaces. CoRE Link-format [RFC6690] is a standard for doing Web Linking [RFC8288] in constrained environments. This specification introduces the concept of a Link Binding, which @@ -113,22 +114,22 @@ are sent over the link to the other. CoRE Link Format representations are used to configure, inspect, and maintain Link Bindings. This specification additionally defines Conditional Notification Attributes for use with Link Bindings and with CoRE Observe [RFC7641]. 2. Terminology 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 + "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. This specification requires readers to be familiar with all the terms and concepts that are discussed in [RFC8288] and [RFC6690]. This specification makes use of the following additional terminology: Link Binding: A unidirectional logical link between a source resource and a destination resource, over which state information is synchronized. @@ -429,20 +430,22 @@ this specification. +---------+------------+-------------+---------------+ | Name | Identifier | Location | Method | +---------+------------+-------------+---------------+ | Polling | poll | Destination | GET | | | | | | | Observe | obs | Destination | GET + Observe | | | | | | | Push | push | Source | PUT | + | | | | | + | Execute | exec | Source | POST | +---------+------------+-------------+---------------+ Table 3: Binding Method Summary The description of a binding method defines the following aspects: Identifier: This is the value of the "bind" attribute used to identify the method. Location: This information indicates whether the binding entry is @@ -475,26 +478,50 @@ the content from the source resource is copied to the destination resource. The creation of the observation relationship requires the CoAP Observation mechanism [RFC7641] hence this method is only permitted when the resources are made available over CoAP. The binding entry for this method MUST be stored on the destination endpoint. The binding conditions are mapped as query parameters in the Observe request (see Section 3). 4.1.3. Push - When the Push method is assigned to a binding, the source endpoint - sends PUT requests to the destination resource when the Conditional - Notification Attributes are satisfied for the source resource. The - source endpoint SHOULD only send a notification request if any - included Conditional Notification Attributes are met. The binding - entry for this method MUST be stored on the source endpoint. + The Push method can be used to allow a source endpoint to replace an + outdated resource state at the destination with a newer + representation. When the Push method is assigned to a binding, the + source endpoint sends PUT requests to the destination resource when + the Conditional Notification Attributes are satisfied for the source + resource. The source endpoint SHOULD only send a notification + request if any included Conditional Notification Attributes are met. + The binding entry for this method MUST be stored on the source + endpoint. + +4.1.4. Execute + + An alternative means for a source endpoint to deliver change-of-state + notifications to a destination resource is to use the Execute Method. + While the Push method simply updates the state of the destination + resource with the representation of the source resource, Execute can + be used when the destination endpoint wishes to receive all state + changes from a source. This allows, for example, the existence of a + resource collection consisting of all the state changes at the + destination endpoint. When the Execute method is assigned to a + binding, the source endpoint sends POST requests to the destination + resource when the Conditional Notification Attributes are satisfied + for the source resource. The source endpoint SHOULD only send a + notification request if any included Conditional Notification + Attributes are met. The binding entry for this method MUST be stored + on the source endpoint. + + Note: Both the Push and the Execute methods are examples of Server + Push mechanisms that are being researched in the Thing-to-Thing + Research Group (T2TRG) [I-D.irtf-t2trg-rest-iot]. 4.2. Link Relation Since Binding involves the creation of a link between two resources, Web Linking and the CoRE Link-Format used to represent binding information. This involves the creation of a new relation type, "boundto". In a Web link with this relation type, the target URI contains the location of the source resource and the context URI points to the destination resource. @@ -633,34 +660,41 @@ 9. Acknowledgements Acknowledgement is given to colleagues from the SENSEI project who were critical in the initial development of the well-known REST interface concept, to members of the IPSO Alliance where further requirements for interface types have been discussed, and to Szymon Sasin, Cedric Chauvenet, Daniel Gavelle and Carsten Bormann who have provided useful discussion and input to the concepts in this specification. Christian Amsuss supplied a comprehensive review of draft -06. Hannes Tschofenig and Mert Ocak highlighted syntactical - corrections in the usage of pmax and pmin in a query. + corrections in the usage of pmax and pmin in a query. Discussions + with Ari Keraenen led to the addition of an extra binding method + supporting POST operations. 10. Contributors Matthieu Vial Schneider-Electric Grenoble France Phone: +33 (0)47657 6522 EMail: matthieu.vial@schneider-electric.com 11. Changelog + draft-ietf-core-dynlink-10 + + o Binding methods now support both POST and PUT operations for + server push. + 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 @@ -770,20 +803,25 @@ [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8288] Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, . 12.2. Informative References + [I-D.irtf-t2trg-rest-iot] + Keranen, A., Kovatsch, M., and K. Hartke, "RESTful Design + for Internet of Things Systems", draft-irtf-t2trg-rest- + iot-04 (work in progress), July 2019. + [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained Application Protocol (CoAP)", RFC 7252, DOI 10.17487/RFC7252, June 2014, . [RFC7641] Hartke, K., "Observing Resources in the Constrained Application Protocol (CoAP)", RFC 7641, DOI 10.17487/RFC7641, September 2015, .