[T2TRG] [REST-as-we-use-it] Preparation for Prague

["Kovatsch Matthias" <[e-mail]>]

Dear all

We have been working on the milestones (https://github.com/t2trg/2015-ietf92/blob/master/slides/milestones.mkd) in a smaller group (Klaus, Carsten, and I). The current status is the following and it would be nice to get more input on the open points:


*         Origin state, ... --> let's make this "Terminology"

o   The general section of the milestones lists design patterns and we think terms would become the clearest when we work on and discuss them together. Hence, we started with a few simple patterns (which started to complicate automatically...). I am thinking about giving a "short presentation of contributions" to trigger the discussions with our world view.

o   The patterns so far include the duality of pub/sub and REST, options where to place the application logic, and possibilities to deal with normally-off nodes.

o   Kerry, you wanted to send me some terms that appeared in previous discussions and rather caused confusion than helped to explain ;)

*         Management: Andy, Mehmet, Ana, Georgios, Hannes

o   I understood that management can also provide good input on how we use REST today, and hence also design patterns, e.g., how to interact with collection resources, batches, etc. Is there any input by you guys?

o   Were there other topics you wanted to contribute?

*         Map examples to REST, a consistent state/event model

o   The first set of design patterns from above can already be mapped to easy examples that show the difference (or duality) between a state and an event model (e.g., doorbell as resource state vs doorbell emitting ring events). Usually, an event model can be transformed into a state model if a REST architecture is preferred or one transforms everything to an event model. Mixing both just increases complexity.

o   Once the simple cases are understood, we could continue to more challenging examples. Here input from industry would be helpful, to work on an actual real-world problem (i.e., we use an application that already exists and map it to each model and do not look at hypothetical use cases).

*         How are we {b,ext}ending REST?

o   Here, Klaus has a nice contribution that highlights how applications are modelled with "hypertext-driven" REST (without bending): https://tools.ietf.org/html/draft-hartke-core-apps-01

o   We can use this draft to see what is missing for some applications and which requirements would bend/extend REST.

*         In addition, the topic of QoS for the IoT was raised in Dallas

o   Together with Giacomo Tanganelli, we started a survey what people usually understand under this term and what features protocols/middlewares should provide for QoS in the context of IoT.

o   We plan a short presentation in Prague to introduce the research topic of QoS and can present you first results from the survey. We would definitely benefit from input by industrial practitioners to gain a better understanding of the quite fuzzy term "QoS."

o   Andreas, I think you raised this issue. Would you have some input on this?

Michael, you also have to honor to have an asterisk next to your name ;)
Could you please do another pass on my brain dump and add what you have been up to?

A preview of the agenda can be found here:
https://www.w3.org/WoT/IG/wiki/Joint_IRTF_T2T_RG_/_W3C_WoT_IG_meeting_18-19_July_2015_in_Prague,_Czech_Republic
Please take note of the possible breakout sessions

*         Orchestration

*         Interaction patterns (including "subscriptions")

*         Modelling

Best regards
Matthias