Draft: draft-keranen-t2trg-rest-iot

Commentary: 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 .
A node that sends requests to servers and receives responses.
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).
An intermediary that is selected by a client, usually via local
configuration rules, and that can be tasked to make requests on
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
time, network bandwidth and energy consumption.
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.
A method where multiple identical requests with that method lead
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.
An intermediary that is selected by a client, usually via local
configuration rules, and that can be tasked to make requests on
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
time, network bandwidth, and energy consumption.
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.
A method where multiple identical requests with that method lead
to the same visible resource state as a single such request.
A content negotiation mechanism where the server selects a
representation based on the expressed preference of the client.
For example, in an IoT application, a client could send a request
with preferred media type "application/senml+json".
A content negotiation mechanism where the server selects a
representation based on the expressed preference of the client.
For example, an IoT application could send a request to a sensor
with preferred media type "application/senml+json".
A method that does not result in 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.
A method that does not result in any state change on the origin
server when applied to a resource.
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
properties that give guarantees to clients: Safe methods do not cause
any state change on the origin server when applied to a resource.
Idempotent methods can be applied multiple times to the same resource
while causing the same visible resource state as a single such
request.  The following lists the most relevant methods and gives a
short explanation of their semantics.
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
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.
Idempotent methods can be applied multiple times to the same resource
while causing 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.
The following lists the most relevant methods and gives a short
explanation of their semantics.