See also: IRC log
<kaz> pick a scribe
<scribe> scribe: Yingying
<kaz> scribenick: Yingying
Johannes: agenda
... 1. Keepalive for RESTful services (Claes)
... 2. Report from joint W3C WoT / IRTF T2T RG(Ari)
... 3. Goal setting for Nice Meeting
... 4. ideas for next plugfest
<inserted> Claes' slides
Claes: 10 mins of presentation.
... this is a typical example of things requiring both peers to act as
both client and server.
... next slide, CoAP as example. E2E keep alive < 30s, which means
you could not connect to the device beyond that time.
... next slide, Web Socket as example. Although the alive time is
longer, there is still problem.
... I have discussion with my colleague. For BT LE, the device wakes up
every second.
... the worst case for receiving the msg is 2s.
... to keep the NAT/firewall awake is battery consuming.
... For LTE MTC modes, devices sleep most of the time. The wake up
interval is dynamically configurable.
... Wakeup intervals could only be configured in the server side.
... keeping firewalls open depends on use cases.
... existing solution: OMA LWM2M as option one. There is other solution,
e.g. Amazon AWS IoT, that I haven't had time to study.
Carsten: problem is UDP timeout
Carsten: Most NATs have longer timeout on
TCP.
... That's one of the two reason we use CoAP+TCP.
Carsten: IPv6 Gateway solution is something we can influence.
<Johannes> Carsten points to RFC 6092
<kaz> RFC6092
Claes: 3rd area, for LTE MTC, the devices
are directly connected. No gateway.
... We have tricky part there.
... We could configure wake up time, etc; maybe we should configure
firewall.
... I can make more investigation on LTE MTC. It's something we could
look into and find a way to make it as efficient as possible.
Michael: Firewall traversal solution?
... XMPP has external server.
... channel between server and your device is something like P2P.
Johannes: WebRTC?
Ari: ICE itself is complex, somehow need to be simplified for constraint device
Johannes: one joint meeting, two breakout
sessions.
... could Ari give short wrap-up?
Ari: based on RESTful track, one is how to
design RESTful for IoT.
... 2nd one is developing and testing the hypertext driven solution.
... for application state, how do you model it in the RESTful.
... another topic, how to use links and values in RESTful.
Johannes: could somebody post the minutes to IRC?
<kaz> draft minute on the W3C side
Johannes: how plugREST is related plugfest
in Sapporo?
... we can do cross platform test on different implementation and make
preparation for joint meeting in Nice.
... could Carsten to give introduction of security related stuff?
Carsten: Oliver made a presentation.
... Authentication token
... how to express the refreshing.
... one document of security consideration of WoT was discussed.
... bootstrapping approach used by LemonBeat was discussed.
... We made official charter this morning. Ari is the co-chair.
... congrats!
Johannes: comments on the joint meeting?
... we will have another joint meeting in Nice. Welcome everyone to join
the meeting.
<inserted> Johannes' slides
Johannes: I would like to share something
with you.
... this is the slide showed in TPAC.
Johannes quickly went through the slides.
Johannes: I suggest we look into Thing.
... some API could be used to expose the thing.
... we can access some things on regular web pages.
... some APIs could be used to access the HW drivers.
... If the script is written for manufacturer A, it could also be used
for manufacturer B without modification.
... this could be one topic that we could discuss in next meeting.
... I would like to hear your comments.
Claes: We have proposals for scripting API
and for things API.
... how far should we go in the IG for these APIs?
Johannes: there are different designs of
APIs.
... there are some different ways to go to design API.
... IG is in a very good position to experiment on the APIs
... to see which ones are feasible.
... We could gather experiences during experiments.
... we could know what should be in and what should be out the scope.
Michael: we can open discussions on hypermedia driven interfaces
Kazuaki: there are some kinds of adaptor in
underlying layer.
... higher layer adaption needs to be considered.
... e.g. to access the GPIO.
... my question is how to choose the protocol in the adaptor.
Carsten: we would like to have common APIs for local and remote devices.
Johannes: this level of abstraction could
be the layer that you describe the thing.
... You could use the thing as the abstraction.
Matthias: Physical API is to
access the different HWs.
... and could also run remotely.
Johannes: I can see there are many
interesting points in the discussion.
... I wonder if we have other topics or goals to be discussed in Nice so
that we could prepare.
Daniel: Louay and I agree that we could go
beyond Javascript API,
... e.g. Web IDL that can be used for other language.
... first test could be the plugfest.
... to see whether we could use these APIs to communicate.
Johannes: we should not aim at only for
Javascript.
... is that what you want to say?
Daniel: we can focus on some specific language but we could broaden it.
Johannes: we have different people doing
the plugfest based on some rough spec posted on wiki in TPAC.
... We think it valuable to include not only theoretic discussion but
some practical implementation.
... we would like to continue in the next F2F in Nice.
... I discussed with Oliver
... whether we could do the plugfest with security concept.
... do we have any comments on the idea to carry some security
implementation in next plugfest?
Carsten: Let's focus on the structural part.
Johannes: the whole model of who can ask
for what authentication or token is a real challenge to WoT.
... not suggest to the details.
... one idea is to use the thing description, e.g.,
... does the thing need access control?
... what kind of resources are protected, what are not in the TD?
... we could go further to the discovery direction as well.
Matthias: we could post the vocabulary for the function and API that could be used on the thing.
Johannes: I would like to take an action to
make introduction of simple specification on the whole thing API.
... if someone has already had some idea, welcome to send to the mailing
list or put on GitHub.
... any other comments?
This is scribe.perl Revision: 1.144 of Date: 2015/11/17 08:39:34 Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/ Guessing input format: RRSAgent_Text_Format (score 1.00) Succeeded: i|10 mins|-> https://lists.w3.org/Archives/Public/public-wot-ig/2015Dec/att-0001/Issues_with_bi-directional_communication_for_CoAP_and_other_IoT_related_protocols.pdf Claes' slides Succeeded: s/- ideas/... 4. ideas/ Succeeded: s/JoHannes/Johannes/ Succeeded: s/rampup/wrap-up/ Succeeded: s/some body/somebody/ Succeeded: i|would like|-> http://www.w3.org/WoT/IG/wiki/images/b/b9/TF-AP_status_TPAC15.pdf Johannes' slides Succeeded: s|rrsgent, draft minutes|| Succeeded: s/under/underlying/ Succeeded: s/specifi/specific/ Succeeded: s/Meteous/Matthias/ Found Scribe: Yingying Found ScribeNick: Yingying Present: Kaz_Ashimura Claes_Nilsson Ari_Keranen Arne_Broering Carsten_Bormann Daniel_Peintner Johannes_Hund Katsuyoshi_Naka Kazuaki_Nimura Michael_Koster Takuki_Kamiya Tuan_Tran Yingying_Chen Sebastian_Kaebisch Danh_Le_Phuoc Agenda: https://lists.w3.org/Archives/Public/public-wot-ig/2015Dec/0000.html Got date from IRC log name: 02 Dec 2015 Guessing minutes URL: http://www.w3.org/2015/12/02-wot-ap-minutes.html People with action items:[End of scribe.perl diagnostic output]