draft-ietf-core-dynlink-09.txt		draft-ietf-core-dynlink-10.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: January 9, 2020 SmartThings		Expires: January 23, 2020 SmartThings
	C. Groves		C. Groves
	J. Zhu		J. Zhu
	Huawei		Huawei
	B. Silverajan, Ed.		B. Silverajan, Ed.
	Tampere University		Tampere University
	July 08, 2019		July 22, 2019
	Dynamic Resource Linking for Constrained RESTful Environments		Dynamic Resource Linking for Constrained RESTful Environments
	draft-ietf-core-dynlink-09		draft-ietf-core-dynlink-10
	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 January 9, 2020.		This Internet-Draft will expire on January 23, 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 38 ¶		skipping to change at page 2, line 38 ¶
	3.1.3. Change Step (st) . . . . . . . . . . . . . . . . . . 6		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) . . . . . . . . . . . . . . . . . . . 7		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 . . . . . . . . . . . . . . . . . . . . . . . . 9		4. Link Bindings . . . . . . . . . . . . . . . . . . . . . . . . 9
	4.1. The "bind" attribute and Binding Methods . . . . . . . . 10		4.1. The "bind" attribute and Binding Methods . . . . . . . . 10
	4.1.1. Polling . . . . . . . . . . . . . . . . . . . . . . . 11		4.1.1. Polling . . . . . . . . . . . . . . . . . . . . . . . 11
	4.1.2. Observe . . . . . . . . . . . . . . . . . . . . . . . 11		4.1.2. Observe . . . . . . . . . . . . . . . . . . . . . . . 11
	4.1.3. Push . . . . . . . . . . . . . . . . . . . . . . . . 12		4.1.3. Push . . . . . . . . . . . . . . . . . . . . . . . . 12
			4.1.4. Execute . . . . . . . . . . . . . . . . . . . . . . . 12
	4.2. Link Relation . . . . . . . . . . . . . . . . . . . . . . 12		4.2. Link Relation . . . . . . . . . . . . . . . . . . . . . . 12
	5. Binding Table . . . . . . . . . . . . . . . . . . . . . . . . 12		5. Binding Table . . . . . . . . . . . . . . . . . . . . . . . . 13
	6. Implementation Considerations . . . . . . . . . . . . . . . . 13		6. Implementation Considerations . . . . . . . . . . . . . . . . 14
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 14		7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	8.1. Resource Type value 'core.bnd' . . . . . . . . . . . . . 14		8.1. Resource Type value 'core.bnd' . . . . . . . . . . . . . 15
	8.2. Link Relation Type . . . . . . . . . . . . . . . . . . . 14		8.2. Link Relation Type . . . . . . . . . . . . . . . . . . . 15
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16
	10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15		10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16
	11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 15		11. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	12. References . . . . . . . . . . . . . . . . . . . . . . . . . 17		12. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
	12.1. Normative References . . . . . . . . . . . . . . . . . . 17		12.1. Normative References . . . . . . . . . . . . . . . . . . 18
	12.2. Informative References . . . . . . . . . . . . . . . . . 18		12.2. Informative References . . . . . . . . . . . . . . . . . 19
	Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 18		Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 19
	A.1. Minimum Period (pmin) example . . . . . . . . . . . . . . 18		A.1. Minimum Period (pmin) example . . . . . . . . . . . . . . 19
	A.2. Maximum Period (pmax) example . . . . . . . . . . . . . . 19		A.2. Maximum Period (pmax) example . . . . . . . . . . . . . . 20
	A.3. Greater Than (gt) example . . . . . . . . . . . . . . . . 20		A.3. Greater Than (gt) example . . . . . . . . . . . . . . . . 21
	A.4. Greater Than (gt) and Period Max (pmax) example . . . . . 21		A.4. Greater Than (gt) and Period Max (pmax) example . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
	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
	skipping to change at page 3, line 32 ¶		skipping to change at page 3, line 33 ¶
	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 CoRE		Notification Attributes for use with Link Bindings and with CoRE
	Observe [RFC7641].		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
	14 [RFC2119] [RFC8174] when, and only when, they appear in all		BCP 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
	and concepts that are discussed in [RFC8288] and [RFC6690]. This		and concepts that are discussed in [RFC8288] and [RFC6690]. This
	specification makes use of the following additional terminology:		specification makes use of the following additional terminology:
	Link Binding: A unidirectional logical link between a source		Link Binding: A unidirectional logical link between a source
	resource and a destination resource, over which state information		resource and a destination resource, over which state information
	is synchronized.		is synchronized.
	skipping to change at page 11, line 13 ¶		skipping to change at page 11, line 13 ¶
	this specification.		this specification.
	+---------+------------+-------------+---------------+		+---------+------------+-------------+---------------+
	| Name | Identifier | Location | Method |		| Name | Identifier | Location | Method |
	+---------+------------+-------------+---------------+		+---------+------------+-------------+---------------+
	| Polling | poll | Destination | GET |		| Polling | poll | Destination | GET |
	| | | | |		| | | | |
	| Observe | obs | Destination | GET + Observe |		| Observe | obs | Destination | GET + Observe |
	| | | | |		| | | | |
	| Push | push | Source | PUT |		| Push | push | Source | PUT |
			| | | | |
			| Execute | exec | Source | POST |
	+---------+------------+-------------+---------------+		+---------+------------+-------------+---------------+
	Table 3: Binding Method Summary		Table 3: Binding Method Summary
	The description of a binding method defines the following aspects:		The description of a binding method defines the following aspects:
	Identifier: This is the value of the "bind" attribute used to		Identifier: This is the value of the "bind" attribute used to
	identify the method.		identify the method.
	Location: This information indicates whether the binding entry is		Location: This information indicates whether the binding entry is
	skipping to change at page 12, line 10 ¶		skipping to change at page 12, line 12 ¶
	the content from the source resource is copied to the destination		the content from the source resource is copied to the destination
	resource. The creation of the observation relationship requires the		resource. The creation of the observation relationship requires the
	CoAP Observation mechanism [RFC7641] hence this method is only		CoAP Observation mechanism [RFC7641] hence this method is only
	permitted when the resources are made available over CoAP. The		permitted when the resources are made available over CoAP. The
	binding entry for this method MUST be stored on the destination		binding entry for this method MUST be stored on the destination
	endpoint. The binding conditions are mapped as query parameters in		endpoint. The binding conditions are mapped as query parameters in
	the Observe request (see Section 3).		the Observe request (see Section 3).
	4.1.3. Push		4.1.3. Push
	When the Push method is assigned to a binding, the source endpoint		The Push method can be used to allow a source endpoint to replace an
	sends PUT requests to the destination resource when the Conditional		outdated resource state at the destination with a newer
	Notification Attributes are satisfied for the source resource. The		representation. When the Push method is assigned to a binding, the
	source endpoint SHOULD only send a notification request if any		source endpoint sends PUT requests to the destination resource when
	included Conditional Notification Attributes are met. The binding		the Conditional Notification Attributes are satisfied for the source
	entry for this method MUST be stored on the source endpoint.		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		4.2. Link Relation
	Since Binding involves the creation of a link between two resources,		Since Binding involves the creation of a link between two resources,
	Web Linking and the CoRE Link-Format used to represent binding		Web Linking and the CoRE Link-Format used to represent binding
	information. This involves the creation of a new relation type,		information. This involves the creation of a new relation type,
	"boundto". In a Web link with this relation type, the target URI		"boundto". In a Web link with this relation type, the target URI
	contains the location of the source resource and the context URI		contains the location of the source resource and the context URI
	points to the destination resource.		points to the destination resource.
	skipping to change at page 15, line 24 ¶		skipping to change at page 16, line 22 ¶
	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. Hannes Tschofenig and Mert Ocak highlighted syntactical		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		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-10
			o Binding methods now support both POST and PUT operations for
			server push.
	draft-ietf-core-dynlink-09		draft-ietf-core-dynlink-09
	o Corrections in Table 1, Table 2, Figure 2.		o Corrections in Table 1, Table 2, Figure 2.
	o Clarifications for additional operations to binding table added in		o Clarifications for additional operations to binding table added in
	section 5		section 5
	o Additional examples in Appendix A		o Additional examples in Appendix A
	draft-ietf-core-dynlink-08		draft-ietf-core-dynlink-08
	skipping to change at page 18, line 19 ¶		skipping to change at page 19, line 19 ¶
	[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>.
	[RFC8288] Nottingham, M., "Web Linking", RFC 8288,		[RFC8288] Nottingham, M., "Web Linking", RFC 8288,
	DOI 10.17487/RFC8288, October 2017,		DOI 10.17487/RFC8288, October 2017,
	<https://www.rfc-editor.org/info/rfc8288>.		<https://www.rfc-editor.org/info/rfc8288>.
	12.2. Informative References		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		[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>.
End of changes. 12 change blocks.
	31 lines changed or deleted		70 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/