Draft: draft-keranen-t2trg-rest-iot

Commentary: Addressing issue 
 Thanks  :) 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   : 
 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 .
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.
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 resource state and/or
application state.
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 hypermedia control that enables a client to navigate between
resources and thereby change the application state.
A hypermedia control that enables a client to navigate between
resources and thereby change the client state.
When designing a RESTful system, the state of the distributed
application must be assigned to the different components.  Here, it
is important to distinguish between "session state" and "resource
state".
Session state encompasses the control flow and the interactions
between the components (see sec-terms).  Following the statelessness
constraint, the session state must be kept only on clients.  On the
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
keep any state about their clients.  Requests can easily be
distributed over multiple worker threads or server instances.  For
the IoT systems, it lowers the memory requirements for server
implementations, which is particularly important for constrained
servers and servers serving large amount of clients.
When designing a RESTful system, the state of the distributed
application must be assigned to the different components.  Here, it
is important to distinguish between "client state" and "resource
state".
Client state encompasses the control flow and the interactions
between the components (see sec-terms).  Following the statelessness
constraint, the client state must be kept only on clients.  On the
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
keep any state about their clients.  Requests can easily be
distributed over multiple worker threads or server instances.  For
the IoT systems, it lowers the memory requirements for server
implementations, which is particularly important for constrained
servers and servers serving large amount of clients.