Change:
Note about client role and reference to architecture section for details.
+1 (if the newline in the definitions () still does render correctly...
How do you like your newlines cooked?
The definitions seem to render correctly. I'll merge this.

Discussion:
A local store of response messages and the subsystem that controls storage, retrieval, and deletion of messages in it. <del> A node that sends requests to servers and receives responses. </del> <ins> A node that sends requests to servers and receives responses.  In RESTful IoT systems it's common for nodes to have more than one role (e.g., both server and client; see sec-architecture). </ins> The state kept by a client between requests.  This typically includes the currently processed representation, the set of active

behalf of the client.  This may be useful, for example, when the client lacks the capability to make the request itself or to service the response from a cache in order to reduce response <del> time, network bandwidth and energy consumption. </del> <ins> time, network bandwidth, and energy consumption. </ins> A reverse proxy that provides an interface to a non-RESTful system such as legacy systems or alternative technologies such as Bluetooth ATT/GATT.  See also "Reverse Proxy". <del> A component embedded in a representation that identifies a resource for future hypermedia interactions, such as a link or a form.  If the client engages in an interaction with the identified resource, the result may be a change to resource state and/or client state. </del> <ins> A component, such as a link or a form, embedded in a representation that identifies a resource for future hypermedia interactions.  If the client engages in an interaction with the identified resource, the result may be a change to resource state and/or client state. </ins> A method where multiple identical requests with that method lead <del> to the same visible resource state as a single such request.  For example, the PUT method replaces the state of a resource with a new state; replacing the state multiple times with the same new state still results in the same state for the resource.  However, the response from the server can be different when the same idempotent method is used multiple times.  For example when DELETE is used twice on an existing resource, the first request would remove the association and return success acknowledgement whereas the second request would likely result in error response due to non-existing resource. </del> <ins> to the same visible resource state as a single such request. </ins> A hypermedia control that enables a client to navigate between resources and thereby change the client state.

A content negotiation mechanism where the server selects a representation based on the expressed preference of the client. <del> For example, in an IoT application, a client could send a request </del> <ins> For example, an IoT application could send a request to a sensor </ins> with preferred media type "application/senml+json". A content negotiation mechanism where the client selects a

multiple machines. A method that does not result in any state change on the origin <del> server when applied to a resource.  For example, the GET method only returns a representation of the resource state but does not change the resource.  Thus, it is always safe for a client to retrieve a representation without affecting server-side state. </del> <ins> server when applied to a resource. </ins> A node that listens for requests, performs the requested operation and sends responses back to the clients.

Section 4.3 of RFC7231 defines the set of methods in HTTP; Section 5.8 of RFC7252 defines the set of methods in CoAP.  As part of the Uniform Interface constraint, each method can have certain <del> properties that give guarantees to clients: Safe methods do not cause any state change on the origin server when applied to a resource. </del> <ins> properties that give guarantees to clients. Safe methods do not cause any state change on the origin server when applied to a resource.  For example, the GET method only returns a representation of the resource state but does not change the resource.  Thus, it is always safe for a client to retrieve a representation without affecting server-side state. </ins> Idempotent methods can be applied multiple times to the same resource while causing the same visible resource state as a single such <del> request.  The following lists the most relevant methods and gives a short explanation of their semantics. </del> <ins> request.  For example, the PUT method replaces the state of a resource with a new state; replacing the state multiple times with the same new state still results in the same state for the resource. However, the response from the server can be different when the same idempotent method is used multiple times.  For example when DELETE is used twice on an existing resource, the first request would remove the association and return success acknowledgement whereas the second request would likely result in error response due to non-existing resource. The following lists the most relevant methods and gives a short explanation of their semantics. </ins> 3.5.1.