Original text:
the context of RESTful design for IoT systems.  For terminology of constrained nodes and networks, see RFC7228. <del> The state kept by a client between requests.  This typically includes the "current" resource, the set of active requests, the history of requests, bookmarks (URIs stored for later retrieval) and application-specific state. </del> A local store of response messages and the subsystem that controls storage, retrieval, and deletion of messages in it. A node that sends requests to servers and receives responses.  The practice of determining the "best" representation for a client when examining the current state of a resource.  The most common forms of content negotiation are Proactive Content Negotiation and 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 <del> resource, the result may be a change resource state and/or application state. </del>  A method where multiple identical requests with that method lead to the same visible resource state as a single such request.  For non-existing resource. A hypermedia control that enables a client to navigate between <del> resources and thereby change the application state. </del>  A string such as "text/html" or "application/json" that is used to label representations so that it is known how the representation When designing a RESTful system, the state of the distributed application must be assigned to the different components.  Here, it <del> is important to distinguish between "session state" and "resource </del>  state". <del> Session state encompasses the control flow and the interactions </del>  between the components (see sec-terms).  Following the statelessness <del> constraint, the session state must be kept only on clients.  On the </del>  one hand, this makes requests a bit more verbose since every request must contain all the information necessary to process it.  On the other hand, this makes servers efficient, since they do not have to

Reviewer comments:
Addressing issue
Thanks Ari :) I will do a final pass and merge.
Originally, application state defined the state kept on the client, that is, what Web page is currently rendered and which pages were visited before. This does not make sense anymore when resource state is more than static Web pages, but parameters, physical state, etc. "Application state" logically would mean the state of the overall IoT application (state of the client and resoource state).
Related comment by Mike Amundsen:
I would add a comment in the definition, that this is called "Application State" in Fielding's thesis, but has some ambiguity in mordern (IoT) applications, where resource state is very dynamic and reflects part of the state in which the overall application is.

Revised text:
the context of RESTful design for IoT systems.  For terminology of constrained nodes and networks, see RFC7228.  A local store of response messages and the subsystem that controls storage, retrieval, and deletion of messages in it. A node that sends requests to servers and receives responses. <ins> The state kept by a client between requests.  This typically includes the "current" resource, the set of active requests, the history of requests, bookmarks (URIs stored for later retrieval) and application-specific state.  (Note that this is called "Application State" in REST, which has some ambiguity in modern (IoT) systems where the overall state of the distributed application (i.e., application state) is reflected in the union of all Client States and Resource States of all clients and servers involved.) </ins> The practice of determining the "best" representation for a client when examining the current state of a resource.  The most common forms of content negotiation are Proactive Content Negotiation and 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  <ins> 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 to the same visible resource state as a single such request.  For non-existing resource. A hypermedia control that enables a client to navigate between  <ins> resources and thereby change the client state. </ins> A string such as "text/html" or "application/json" that is used to label representations so that it is known how the representation When designing a RESTful system, the state of the distributed application must be assigned to the different components.  Here, it  <ins> is important to distinguish between "client state" and "resource </ins> state".  <ins> Client state encompasses the control flow and the interactions </ins> between the components (see sec-terms).  Following the statelessness  <ins> constraint, the client state must be kept only on clients.  On the </ins> one hand, this makes requests a bit more verbose since every request must contain all the information necessary to process it.  On the other hand, this makes servers efficient, since they do not have to