Change:
such as load balancers can be introduced without changing the client side.  The clean separation of concerns helps with simplicity. <ins> IoT systems greatly benefit from this constraint, as it allows to effectively shield constrained devices behind intermediaries and is also the basis for gateways, which are used to integrate other (IoT) ecosystems. </ins> 4.6. This principle enables origin servers to ship code to clients.

Discussion:
I extended the constraints sections (4.x) with a paragraph on the role for IoT. This does not introduce the MAY/SHOULD/MUST levels by Mike, but starts a basis for reaching such as conclusion.
From WISHI hackathon breakout: Capture that constrained networks may split data from metadata -- they are still bound together, but not always sent together.
Minimal text under 4.2 Stateless with PR
Was addressed with 41
Sections URL REST constraints URL
Many points were moved to the corresponding issue.
Let's pick the interesting discussion about the REST constraints here: I like the idea of revisiting the constraints. I am less sure of MAY, SHOULD, and MUST is the best taxonomy here. The experience from CoAP shows that it is most practical to have both roles simultaneously on a device. The division into client and server is still very useful because it declares which component had the initiative to do something, which is helpful for the visibility, but also accountability in "digital forensics"(?). When an IoT device has initiative (because there is a user, e.g., pressing a button, or it has some policy/rules/AI), it acts as a client. When a device offers a service, it is in server role. Both can happen on the same device There are not details in the mail why Mike picked SHOULD. One concern is of course efficiency and compact messages. Introducing state can help a lot here. I guess we need a proper evaluation of the desired properties enabled through statelessness and the advantages from breaking the constraint. Maybe helpful: FTP vs HTTP comparison about how filepath is conveyed. Yes, must be enabled whenever possible to protect constrained devices. This is a bit endangered through security, as transport layer security is currently predominant. Object security is quite interesting here. One should analyze how to enable caching for encrypted content that can be accessed by multiple participants. There should be guidance what trade-offs are made with respect to security, since cache-key options may not be encrypted... Caching usually only makes sense when the data is used by multiple/many participants. In the IoT, it might make sense to cache also individual data to protect constrained devices. Here the explanation of the methods would fit, and why one should respect their properties (no side effects with a GET...). CoAP is collecting more methods (FETCH, PATCH).

Explain the different philosophy compared to RPC. Not sure how to understand this. Is this related to queries and FETCH? Hmm. This simply results from the uniform interface and context-dependent meaning of methods. Should this be reinterpreted somehow? An interesting point here could be the handling of events, that is state that is pushed from the server to the client and each individual notification is important and must not be lost (which makes them different from Observe notifications). Partly, this is statelessness. The other part is not relying on implicit out-of-band information. That is, proper use of Internet Media Types (and not just labeling everything app/json). IoT often has "dead ends" in the application: a sensor or actuator that does not link any further. For discovery, HATEOAS is still very important and I see a MUST there to enable loose coupling. Might this be related to sleepy devices? Explicit delegation? We have to find examples where this would apply, in particular since code is shipped from the server to the client. For instance, form checking is irrelevant in a Thing-to-Thing context. Preprocessing of data is interesting, but that should be done on the server side, which is the origin of data (e.g., a sensor).
Let's start with having a short discussion paragraph about this under Sections 4.x
waiting to be merged. Carsten/Kovatsch: First, fine session today in the t2trg room. thanks for that. Now, I am not suggesting we NOT adopt any of Fielding's Constraints (there are ten[1] to consider). But we should keep in mind that the ten requirements (think 2119 words) he selected are based on the 16 Architectural Properties of Key Interest [2] Fielding identified in Chapter IoT might not share all those desireable properties and some IoT ones might be missing from Fielding's WWW-inspired list. As a simple exercise, we can tick down the list of ten Constraints and see what 2119 words we want to invoke in our guidance document.

here's my straw-man: Applying Fielidng's Constraints to IoT using RFC2119 Words Client-Server : MAY Stateless : SHOULD Cache : MUST Uniform Interface : MUST Identification of Resources : MUST Manipulation of Resources through Representations : MUST Self-Describing Messages : SHOULD Hypermedia as the Engine of App State : MAY Layered System : MUST Code-On-Demand : MAY Now, rather than say "is it RESTful" we can look at this list and start asking about the value of each of these ten constraints when it comes to IoT. Even more important, I suspect that there are constraints missing from this list that would be important to IoT. And we haven't even started on the list of Properties of Key Interest for IoT. BTW - naming is fun. I toss out IoTA for Internet of Things Architecture Cheers. [1] URL [2] URL mamund Mike Amundsen +1.859.757.1449 skype: mca.amundsen URL URL URL URL >
I read through the draft this week and am send along my initial comments for discussion. I like the notion of providing guidance to IoT developers and hope this document can be a cornerstone of that effort. Section 1. Introduction The intro says this document is meant as guidance for designing IoT systems that follow the principles of the REST style but those principles do not appear anywhere in this document nor are the appropriate sections in Fielding's dissertation noted. You come close with the following: "RESTful design facilitates many desirable features for a system, such as good scaling properties." This is where I'd refer to the full set of "Architectural Properties of Key Interest" from the dissertation[0]. I think it is then worthwhile to mention Fielding's requirements[1] (note these are WWW requirements, not IoT requirements) and the constraints [2] he selects to induce the properties. The remainder of the document focuses not on archtectural issues, but on protocol issues and is limited in even this area to focusing on HTTP and CoAP. I'm not sure if you want to provide protocol guidance or design guidance and will leave that up to discussion before making any other comments on this part of the doc.

Section 2 Terminology - no comment for now Section 3.,1 - no comment Section 3.2 I suggest using the words "client state" and "resource state" in section of draft-keranen-t2trg-rest-iot. This more clearly identifies who is responsible for which state elements and avoids discussions about "application" and "session" definitions. Flow control MAY be managed from either the client ("please set this valve to position 3") or the resource server ("According to my configuration data, your client certificate only allows you to do one of the following...") Rather than try to define "session state" as flow control, I think it s better the establish lines of responsibility for client state and resource state. Section 3.3 I suggest the following updated wording for the opening: "Important part of designing a system is to model is as a set of resources which represent the "state of the system." Clients MAY be allowed to modify the state of resources by passing representations to the server (using request bodies). Servers manipulate the state of clients by passing representations of resources (using response bodies)." Section 3.4 I think most of the text here can be removed and replaced with a reference to existing RFCs on URI (e.g. 3986). I think it would also be good guidance to reference RFC7320 ("URI Design and Ownership")[3]. Section 3.5 & 3.6 I think a reference to the relevant RFCs is all that is needed here. Listing methods here runs the risk of becoming outdated as the list of valid methods changes over time. Section 4 I think it's a mistake to call out RFCs here since even media types will have security considerations and we can't know which types are in use (including new types as they are created). I suggest something about "Relavent RFCs" or something here. I appreciate the oppty to comment and look forward to any follow up discussions. thanks. [0] URL [1] URL [2] URL [3] URL mamund Mike Amundsen +1.859.757.1449 skype: mca.amundsen URL URL URL URL