16:42:00 <RRSAgent> RRSAgent has joined #wot-ap
16:42:00 <RRSAgent> logging to http://www.w3.org/2015/07/30-wot-ap-irc
16:42:40 <kaz> meeting: WoT AP-TF breakout - Day1
16:43:06 <kaz> topic: Recap by Johannes
16:43:15 <kaz> [ Discussion topics of TF-AP ]
16:43:34 <kaz> johannes: explains
16:43:48 <kaz> ... Abstract resource model
16:43:54 <kaz> ... Architecture model
16:43:58 <kaz> ... Technology landscape
16:44:07 <kaz> ... Use cases & requirements
16:45:03 <kaz> [ Protocol-agnostic resource model for web things ]
16:45:15 <kaz> johannes: Properties
16:45:58 <kaz> ... Actions
16:46:05 <kaz> ... Subscriptions/EventSources
16:47:27 <kaz> brad(?): property should always reflect the most updated state
16:48:23 <kaz> ... as the temp. changes the device (e.g., air conditioner) needs to updated the status
16:48:40 <kaz> ... action is more than just changing the value
16:49:28 <JonathanJ2> JonathanJ2 has joined #wot-ap
16:49:33 <aizu> aizu has joined #wot-ap
16:50:01 <kaz> johannes: what would be the necessary atomic approach?
16:50:31 <kaz> ... is everybody ok?
16:50:38 <kaz> ... any opinions?
16:50:58 <kaz> ... make sense to split these?
16:51:12 <kaz> ... property plus action
16:51:54 <kaz> brad(?): meta data associated to actions
16:52:38 <kaz> ... if you want to have something more than "just data"
16:52:43 <kaz> ... you need to have actions
16:53:28 <kaz> johannes: don't have clear answer at the moment
16:53:38 <kaz> ... you might need something like subscription/events
16:54:24 <kaz> s/events/eventsources
16:54:47 <kaz> brad(?): depending on use cases
16:55:16 <kaz> ... for some use case, just need property
16:55:35 <kaz> ... another use case is getting data from a sensor every 5 mins
16:56:33 <kaz> ... if you want something more than property
16:56:35 <kaz> ... you need actions
16:57:33 <kaz> @@@: polling would be painful to get data
16:57:41 <kaz> ... when the state changes, let me know
16:58:23 <kaz> johannes: for some property, you can set subscription
16:58:35 <kaz> brad: what kind of data you want to subscribe
16:58:51 <kaz> ... detect sensor data like temperature
16:59:11 <kaz> ... to get value only when the value changes
16:59:56 <kaz> s/brad(?)/vlad/g
17:00:10 <kaz> s/brad:/vlad:/
17:00:23 <kaz> s/@@@:/jay:/
17:02:09 <kaz> johannes: anybody think we should NOT have events, actions?
17:02:18 <kaz> (no objections)
17:02:31 <kaz> johannes: so we could have these depending on the need
17:02:51 <kaz> jay: anything dynamic?
17:03:33 <kaz> jay: people would make mistakes
17:03:53 <kaz> ... preventing those mistakes would be useful
17:04:34 <kaz> johannes: adds "indication to avoid subscriptions on static
17:05:05 <kaz> ... where to handle this?
17:05:15 <kaz> vlad: some properties are static
17:05:19 <kaz> ... and some are dynamic
17:07:03 <kaz> kaz: mentions the work by the automotive wg
17:07:20 <kaz> ... and suggests we identify the need for get vs. subscribe based on use cases
17:07:36 <kaz> [ Peoperties ]
17:07:47 <kaz> johannes: REad-only properties
17:07:56 <kaz> ... read-only data
17:08:09 <kaz> ... what kind of properties?
17:08:46 <kaz> ... how to handle streaming data?
17:09:00 <kaz> ... also time and data?
17:09:14 <kaz> ... opinions?
17:09:44 <kaz> jay: security considerations?
17:09:52 <kaz> ... you don't want people to change the value
17:10:04 <kaz> ... things might be highly sensible
17:10:30 <kaz> ... you want to keep properties open if possible, though
17:11:09 <kaz> vlad: some of the devices might be provided on the asis-based
17:11:14 <kaz> ... we can't change anything
17:11:28 <kaz> ... what if we define vocabulary
17:11:40 <kaz> johannes: there is difference
17:12:11 <kaz> ... something might be not changeable
17:12:26 <kaz> ... you can't change the location for example
17:12:34 <kaz> ... security is of course important
17:12:42 <kaz> ... need to model what is needed
17:13:02 <kaz> jay: we might want to revisit the first point
17:13:09 <kaz> ... permission for subscription
17:13:18 <kaz> ... permission to read
17:13:37 <kaz> johannes: need some kind of mechanism to handle permission
17:13:48 <kaz> ... might make sense to restrict the interaction
17:14:16 <kaz> ... some properties are not writable or subscribable
17:14:35 <kaz> vlad: every action has unique URL
17:14:51 <kaz> ... for what we did within EVRYTHNG
17:15:06 <kaz> ... HTTP offers the mechanism
17:15:18 <kaz> ... should be inside or outside?
17:15:26 <kaz> jay: millions of URIs?
17:15:33 <kaz> vlad: yeah
17:16:33 <kaz> ... the user would like to interact with his own devices
17:17:03 <kaz> johannes: maybe this afternoon, we can talk with the security TF guys about that
17:17:11 <kaz> ... several possible ways
17:17:33 <kaz> ... did we have agreement on suggestion about properties?
17:17:53 <kaz> ... both ways have pros and cons
17:18:22 <kaz> ... could we have discussion now?
17:18:34 <kaz> ... thinking of resources?
17:19:05 <kaz> (raise hands)
17:19:20 <kaz> johannes: let's postpone a bit
17:19:26 <kaz> ... and have more discussions
17:19:33 <kaz> [ Actions ]
17:19:58 <kaz> johannes: want to involve actions
17:20:12 <kaz> ... running executable actions
17:20:53 <kaz> ... one-time action vs. long-term action
17:21:50 <kaz> jay: you could start something
17:21:58 <kaz> ... and could choose stop at some point
17:22:07 <kaz> ... or let it continue
17:22:11 <kaz> johannes: right
17:22:41 <kaz> ... and keep the status exposed
17:22:48 <kaz> jay: how would you stop it?
17:23:03 <kaz> ... can use some ID
17:23:18 <kaz> ... to control it
17:23:36 <kaz> s/... can/johannes: can/
17:23:42 <kaz> jay: would see the worst case
17:23:56 <kaz> ... sometimes things are unmanageable
17:24:05 <kaz> ... need to shutdown it
17:24:18 <kaz> vlad: what do you mean?
17:24:37 <kaz> johannes: would keep the states of devices
17:25:08 <kaz> vlad: if you have a specific server to manage the status of devices
17:25:17 <kaz> johannes: cache to keep the status
17:25:35 <kaz> ... you can find resources
17:25:59 <kaz> jay: much smarter to have the status information at the end point
17:26:43 <kaz> johannes: should have concrete scenario on the use case
17:27:16 <kaz> ... keep status info at the end point vs. on the server side
17:27:33 <kaz> vlad: exactly same information
17:27:54 <kaz> don: robustness and security
17:28:04 <kaz> ... don't want to limit one
17:28:51 <kaz> jay: individual device can publish once and subscribers can tell
17:29:15 <kaz> don: may want to subscribe more than one devices
17:29:32 <kaz> ... at least two (may be more) for robustness
17:29:49 <kaz> ... this model should consider that kind of scalability for robustness
17:29:57 <ryuichi> ryuichi has joined #wot-ap
17:30:11 <kaz> ... and security consideration
17:30:33 <kaz> ... might need restriction for permissions
17:32:33 <kaz> jay: agree with you we should draw a big picture including scalability
17:34:48 <kaz> johannes: we'll take use cases first, and then see scalability
17:35:45 <kaz> ... we can agree on the action point?
17:36:35 <kaz> kaz: maybe we can add a note on scalability, robustness and security consideration here
17:37:04 <kaz> osamu: those points have effect to all the parts
17:37:15 <kaz> johannes: would apply to all the points
17:37:24 <kaz> [ Events ]
17:38:08 <kaz> [ Discussion ]
17:38:22 <kaz> johannes: do we have the same understanding?
17:38:49 <kaz> ... history/timeline vs. spontaneous event?
17:40:22 <kaz> jay: smartmeter raise data every min
17:41:04 <kaz> ... sometimes you may want to get data immediately
17:41:57 <kaz> Present: Johannes, Jonathan, Kaz, Ryuichi, Kazuaki, Hiroyuki, Don, Yoshiaki, Jay, Yuki, Reyries, Osamu, Vlad, Alan
17:42:43 <kaz> johannes: some kind of values like temperature fits subscription
17:43:42 <kaz> jay: should have both poll and subscription
17:44:06 <kaz> johannes: should have special resource type to manage that?
17:44:26 <kaz> ... sometimes allow polling and sometimes allow subscription
17:44:41 <kaz> vlad: if you own the server, you have lots of devices
17:45:39 <kaz> johannes: would put your points here (on the "Discussion" slide)
17:46:30 <kaz> ... resources should always be pollable
17:46:50 <kaz> ... next, relation to, e.g., CoRE interfaces
17:47:33 <kaz> ... put that part into "()"
17:47:39 <kaz> ... next, media types?
17:48:10 <kaz> ... close to what the TF-TD is doing
17:48:52 <kaz> ... any suggestions?
17:49:47 <kaz> ... data structures?
17:50:00 <kaz> [ Subscription resource]
17:50:07 <kaz> johannes: discussed during the IETF meeting
17:50:51 <kaz> [ Problem: RESTful but ...]
17:51:03 <kaz> [ Solution ...]
17:51:06 <kaz> [ Dataflow
17:51:12 <kaz> s/flow/flow ]/
17:51:21 <kaz> don: who gets the slots?
17:51:34 <kaz> Present+ Michael
17:51:40 <kaz> rrsagent, make log public
17:51:44 <kaz> rrsagent, draft minutes
17:51:44 <RRSAgent> I have made the request to generate http://www.w3.org/2015/07/30-wot-ap-minutes.html kaz
17:52:05 <kaz> johannes: the police might have priority access to the traffic information
17:52:33 <kaz> Chair: Johannes
17:52:59 <kaz> michael: subscription resource expose who is observing, etc.
17:53:11 <kaz> ... polling and subscription
17:53:26 <kaz> s/Solution .../Solution Sketch /
17:54:07 <kaz> ... subscription resource links to endpoint
17:54:17 <kaz> ... protocol-agnostic
17:54:30 <kaz> ... endpoint is protocol-specific
17:55:12 <kaz> ... already exists within CoRE interface
17:55:42 <kaz> johannes: info on who is subscribing?
17:55:53 <kaz> michael: identifier on observer resource
17:56:33 <kaz> ... in CoRE interface, that is interesting question
17:56:51 <kaz> don: who gets occupied by the slot?
17:57:04 <kaz> ... a concern was security
17:57:20 <kaz> ... is there limitation who could subscribe what?
17:57:33 <kaz> michael: interestig to have those concepts
17:57:52 <kaz> don: large number of sensors and small number of controllers
17:58:06 <kaz> ... you might want to have 3-4 controllers
17:58:22 <kaz> johannes: adds notes
17:58:45 <kaz> ... who is subscribing? (DOS prevention, resource management)
17:59:11 <kaz> ... possibly LWM2M, Oauth bearer?
18:00:09 <kaz> michael: secure paring
18:00:51 <kaz> ... with constraint devices, would think about subscription issues
18:01:19 <kaz> [ Architecture Model ]
18:01:24 <kaz> johannes: short recap
18:01:55 <kaz> ... shows the basic architecture picture on the GitHub wiki
18:02:45 <kaz> ... WoT servient interact with Web Server/Browser and Devices
18:03:03 <kaz> s/Devices/Physical Devices/
18:04:00 <kaz> ... virtual instances and real things
18:04:54 <kaz> ... can one physical device correspond with more than one virtual instances?
18:06:57 <kaz> michael: a virtual entity could be a mash-up server corresponds to more than one virtual entities
18:08:04 <kaz> kaz: Michael's comment implies that this model should allow nested structure like Russian dolls
18:08:09 <kaz> michael: right
18:08:16 <kaz> s/michael:/johannes:/
18:08:58 <kaz> johannes: behavior of WoT servient
18:09:25 <kaz> ... how to interact with legacy devices?
18:10:17 <kaz> ... get device profile on discovery, invokes a virtual instance and installs a device driver
18:10:31 <kaz> ... and then exposes APIs of virtual instance
18:10:47 <kaz> ... opinions?
18:12:42 <kaz> michael: those two (WoT servient and BT GW) are good examples
18:12:57 <kaz> johannes: these examples are two natural ways
18:13:32 <kaz> ... shows another diagram on data transfer
18:13:40 <kaz> ... HTTP can be used
18:14:11 <kaz> ... how do we create events/actions?
18:14:22 <kaz> ... right side diagram exposes APIs
18:15:04 <kaz> ... declaratively vs. programmatically
18:15:34 <kaz> michael: may be useful to have constraints
18:15:51 <kaz> ... using events/actions/properties
18:16:02 <kaz> ... changing properties using subscription
18:16:40 <kaz> ... script can't access internal resources directly
18:17:35 <kaz> johannes: left side diagram consists of thin client
18:18:06 <kaz> michael: the current constraint to restrict access to server-side resource
18:18:47 <kaz> johannes: you would only see the server-side APIs or client-side APIs
18:18:51 <kaz> michael: right
18:19:05 <kaz> ... we have a controller object
18:19:18 <kaz> ... also have a temperature object
18:19:36 <kaz> ... internally linked each other
18:19:53 <kaz> ... the sensor could internally expose the value
18:21:06 <kaz> osamu: we had several use cases during the Munich meeting
18:21:15 <kaz> ... e.g., from Panasonic
18:21:46 <kaz> ... maybe difficult to manage their proposed business model by this model
18:22:00 <kaz> ... we need both of the two models
18:22:35 <kaz> s/this/only one/
18:23:33 <kaz> ... authentication, binding, resource discovery, etc., should be provided by the server
18:23:38 <kaz> johannes: adds notes
18:23:48 <kaz> ... server-side: expose inputs and outputs as resources
18:23:59 <kaz> ... needs data binding of resources
18:24:33 <kaz> ... we need to include those points into our resource model
18:24:42 <kaz> ... any more comments?
18:24:59 <kaz> ... server-side scripts vs. client-side scripts
18:26:27 <kaz> kaz: Kajimoto-san from Panasonic also thought we need some scripts/APIs on the server-side
18:26:38 <kaz> ... he will make his presentation in the afternoon
18:27:06 <kaz> michael: URIs, hypermedia, etc., to represent resources
18:27:19 <kaz> johannes: not much discussion on APIs so far
18:28:19 <kaz> michael: client-side should also has similar model on resource management
18:28:33 <kaz> ... how to generate actions, etc.
18:28:40 <kaz> johannes: would keep this model protocol-agnostic
18:28:52 <kaz> rrsagent, draft minutes
18:28:52 <RRSAgent> I have made the request to generate http://www.w3.org/2015/07/30-wot-ap-minutes.html kaz
18:29:00 <kaz> osamu: one question
18:29:09 <kaz> ... IETF has core mapping document
18:29:32 <kaz> michael: how proxy interacts
18:29:40 <kaz> s/mapping/HTTP mapping
18:29:57 <kaz> ... we use whole different models as well
18:31:09 <kaz> johannes: on the GitHub wiki, we're discussing existing models/protocols
18:31:53 <kaz> osamu: architecture/modeling discussion is done by this TF. right?
18:32:09 <kaz> ... want to discuss the whole model for WoT here
18:32:35 <kaz> ... regarding some details on protocols, we could work with IETF
18:32:54 <kaz> michael: we've established the collaboration with IETF based on that direction
18:33:36 <kaz> johannes: we've started to have a model
18:34:04 <kaz> ... would put all the diagrams together on the wiki
18:34:40 <kaz> ... resources within "WoT Servient"
18:35:33 <kaz> [ slide 20 with three WoT Servients ]
18:36:04 <kaz> johannes: does this picture cover all our points?
18:36:18 <kaz> ... or anything missing?
18:36:51 <kaz> michael: script only can consume visible resources
18:37:04 <kaz> ... through the common resource model
18:37:13 <kaz> johannes: inside or outside?
18:37:33 <kaz> michael: legacy devices expose resources as a WoT devices
18:37:40 <kaz> s/a WoT/
18:37:54 <kaz> s/as devices/as WoT devices/
18:38:23 <kaz> johannes: legacy protocols like BT or sensor's proprietary one
18:40:07 <kaz> michael: the Adapter is a device driver for legacy devices
18:41:09 <ryuichi> ryuichi has joined #wot-ap
18:41:38 <kaz> johannes: Nimura-san, you have a similar image?
18:41:47 <kaz> nimura: fine with this
18:43:39 <kaz> kaz: there are two possible passes
18:43:58 <kaz> ... direct data exposure from the middle WoT Servient
18:44:12 <kaz> ... or via the Web service server
18:44:37 <kaz> ... and people can choose which path to use based on their own need or business model
18:44:54 <kaz> s/passes/pathes/
18:45:05 <kaz> aizu: @@@
18:45:40 <kaz> osamu: relationship between multiple servients
18:46:37 <kaz> johannes: blue line is some legacy protocol
18:46:47 <kaz> ... orange lines are web-based protocols
18:46:56 <kaz> ... not necessarily HTTP
18:47:25 <kaz> jonathan: constrained device?
18:47:50 <kaz> johannes: WoT servient could be a constrained device
18:48:18 <kaz> jonathan: this looks like heavy...
18:48:39 <kaz> s/web-based/web/
18:49:03 <kaz> johannes: can we have a servient for only one protocol as a constrained device
18:49:32 <kaz> jonathan: need to consider some light-weight model as well
18:49:43 <kaz> johannes: what would be the difference?
18:50:07 <kaz> jonathan: e.g., just support CoAP
18:50:14 <kaz> s/support/supporting/
18:50:25 <kaz> johannes: that's possible
18:51:04 <kaz> ... a GW might support multiple protocols but a specific device may support only one protocols
18:51:09 <kaz> s/protocols/protocol
18:52:09 <kaz> rrsagent, draft minutes
18:52:09 <RRSAgent> I have made the request to generate http://www.w3.org/2015/07/30-wot-ap-minutes.html kaz
18:52:25 <kaz> johannes: adds notes
18:52:33 <kaz> ... orange vs. blue
18:52:47 <kaz> ... constrained devices: one protocol
18:54:21 <kaz> michael: what is the minimum WoT Servient?
18:54:45 <kaz> johannes: web protocol can be used to talk each other
18:56:49 <kaz> johannes: adds some more edit to the notes
18:57:14 <kaz> ... orange vs. blue - when is a protocol considered as a web protocol
18:58:25 <kaz> nimura: structure model?
18:58:53 <kaz> i/structure/... add constrained device: one protocol, fixed resources, no APIs
18:59:21 <kaz> johannes: protocol between client and servient?
18:59:43 <kaz> i/structure/... what is the minimal servient?
19:00:11 <kaz> ... we didn't cover that aspect yet
19:00:53 <kaz> ... one servient corresponds to multiple devices
19:01:55 <kaz> ... good to have a new picture to capture that as well
19:02:15 <kaz> ... we already have 4-5 pictures for each case
19:02:34 <kaz> ... but would have one more abstract picture to capture all the points
19:03:37 <kaz> ... adds another note: One servient hosting structural instances
19:04:02 <kaz> s/structural/several virtual/
19:04:15 <kaz> michael: do they have permissions to talk with each other?
19:04:44 <kaz> ... talk thorough HTTP or another protocol?
19:04:59 <kaz> ... optimization and communication
19:05:33 <kaz> rrsagent, draft mintues
19:05:33 <RRSAgent> I'm logging. I don't understand 'draft mintues', kaz.  Try /msg RRSAgent help
19:05:40 <kaz> rrsagent, draft minutues
19:05:40 <RRSAgent> I'm logging. I don't understand 'draft minutues', kaz.  Try /msg RRSAgent help
19:05:44 <kaz> rrsagent, draft minutes
19:05:44 <RRSAgent> I have made the request to generate http://www.w3.org/2015/07/30-wot-ap-minutes.html kaz
19:05:54 <kaz> johannes: implication on security
19:06:16 <kaz> ... origin policies?
19:06:35 <kaz> michael: we could say servient is a security domain
19:07:06 <kaz> johannes: we could discuss this model from the security viewpoint
19:07:44 <kaz> michael: definition of virtual instances?
19:08:21 <kaz> Present+ Kazuo
19:08:33 <kaz> rrsagent, draft minutes
19:08:33 <RRSAgent> I have made the request to generate http://www.w3.org/2015/07/30-wot-ap-minutes.html kaz
19:09:33 <kaz> johannes: should we try to include these comments into this picture?
19:09:42 <kaz> ... or generate another picture?
19:10:56 <kaz> jonathan: do you have any idea about controlling compound resource?
19:11:14 <kaz> johannes: group of resources?
19:12:04 <kaz> ... two approaches
19:12:20 <kaz> ... one entity covers all the grouped resources
19:12:38 <kaz> ... another one is atomic approach
19:13:39 <kaz> jonathan: another question is regarding cloud services
19:14:25 <kaz> johannes: cloud service as a background proxy?
19:22:33 <kaz> ... adds yet another note: add services in the cloud
19:23:08 <kaz> rrsagent, draft minutes
19:23:08 <RRSAgent> I have made the request to generate http://www.w3.org/2015/07/30-wot-ap-minutes.html kaz
19:24:50 <kaz> [ Properties ]
19:25:01 <kaz> [ Actions ]
19:25:18 <kaz> i/Properties/johannes: summarizes the discussion/
19:25:41 <kaz> s/discussion/discussion during the morning session/
19:25:45 <kaz> [ Events ]
19:26:57 <kaz> [ Dataflow ]
19:28:59 <kaz> johannes: would talk about "Technology landscape" before lunch
19:29:38 <kaz> ... after lunch we'll talk about security consideration, etc.
19:29:48 <kaz> s/before lunch/
19:29:55 <kaz> s/after lunch/also/
19:30:00 <kaz> [ lunch break ]
19:30:04 <kaz> rrsagent, draft minutes
19:30:04 <RRSAgent> I have made the request to generate http://www.w3.org/2015/07/30-wot-ap-minutes.html kaz
20:41:46 <JonathanJ2> JonathanJ2 has joined #wot-ap
20:56:17 <ymatsuda> ymatsuda has joined #wot-ap
21:10:11 <kaz> topic: Security & Privacy topics for joint meeting
21:11:57 <kaz> johannes: common points to discuss between S&P and TF-AP?
21:12:12 <kaz> ... and Kajimoto-san's presentation
21:13:44 <kaz> topic: Kajimoto-san's presentation
21:13:55 <kaz> [ Treatment of Implementation ]
21:14:56 <kaz> Present+ Simon, Karen, Alan, Oliver, Yuki, Reynier
21:15:08 <ymatsuda> ymatsuda has joined #wot-ap
21:15:33 <kaz> kajimoto: Web-sentric, Smartphone-centric, Hub-centric and Cloud-centric
21:15:52 <kaz> ... implementation models and servient mapping
21:16:21 <kaz> [ Implementation Model (1) ]
21:16:57 <kaz> kajimoto: Web-centric model was shown by Mr. Komatsu from NTT
21:17:21 <kaz> ... also by Dave from W3C
21:18:04 <kaz> ... each device has a globally unique URI
21:18:17 <kaz> ... next is Smartphone-centric model
21:18:37 <kaz> ... smartphone itself has GW functionality
21:20:06 <kaz> ... the third is Hub-centric model
21:20:42 <kaz> ... the Hub has both the functionality of WoT server and GW
21:21:01 <kaz> ... there are many possible models
21:21:33 <kaz> ... however, we should/could discuss the same I/F regardless of those models
21:21:50 <kaz> [ WoT Servient Lifecycle (State Diagram) ]
21:22:17 <kaz> kajimoto: standalone is not connected status
21:22:36 <kaz> ... connected is just connected and IP reachable
21:23:26 <kaz> ... registered: URI-like address is registered and can work as a WoT servient
21:23:35 <kaz> s/connected is/connected:/
21:23:45 <kaz> s/standalone is/standalone:/
21:23:51 <jhund> jhund has joined #wot-ap
21:24:18 <kaz> ... activated: powered on the device and support full service of things as a WoT servient
21:24:47 <kaz> [ WoT Servient API classification ]
21:24:56 <jhund> jhund has joined #wot-ap
21:25:40 <kaz> kajimoto: Activate/Inactivate, Get, Put, and Notify
21:26:38 <jhund> jhund has joined #wot-ap
21:27:33 <kaz> johannes: works with our APIs :)
21:28:44 <kaz> ... any ideas on the relationship with Event/Action/Property discussion as well?
21:29:22 <kaz> kajimoto: we're thinking of the Cloud-centric model
21:29:34 <kaz> s/we're/we ourselves are/
21:31:37 <kaz> alan: the Mobile-centric model is similar to what Bryan from AT&T yesterday
21:31:56 <kaz> ... a class of APIs
21:32:15 <kaz> s/APIs/APIs defined/
21:34:13 <kaz> kaz: standalone, connected, registered, activated are states
21:34:36 <kaz> ... and activate/inactivate, get, put, notify could be defined as events which change the above states
21:34:37 <kaz> ... right?
21:34:43 <kaz> johannes: good mapping
21:36:03 <kaz> kajimoto: the scope of WoT servient API definition is registered and activated
21:36:14 <kaz> alan: how to start discovery?
21:36:22 <kaz> kajimoto: could be done by NFC, etc.
21:36:56 <kaz> alan: who would maintain the registration?
21:37:18 <kaz> ... something like BT?
21:37:33 <kaz> s/BT/BT paring/
21:37:57 <kaz> ... visibility?
21:38:59 <kaz> kaz: we should think about unregister in addition to register like activate/inactivate?
21:40:33 <kaz> alan: like this model as a simple starting point
21:40:37 <kaz> ... similar to what we're doing
21:41:06 <kaz> johannes: need some description for actions
21:41:21 <kaz> ... how could we proceed?
21:47:17 <kaz> topic: Security&Privacy
21:48:07 <kaz> oliver: atomic use cases
21:48:38 <kaz> ... canonical ways to describe security consideration
21:50:33 <kaz> ... charter to be generated by TPAC
21:51:56 <kaz> rrsagent, draft minutes
21:51:56 <RRSAgent> I have made the request to generate http://www.w3.org/2015/07/30-wot-ap-minutes.html kaz
21:55:43 <kaz> ... security&privacy requirements catalogue on the wiki
21:56:57 <kaz> -> https://www.w3.org/WoT/IG/wiki/Security%26Privacy_Requirements_Catalogue security&privacy requirements categories
21:57:07 <kaz> s/categolies/catalog/
21:59:09 <kaz> oliver: technical landscape
21:59:21 <kaz> -> https://www.w3.org/WoT/IG/wiki/Design-Time_Security%26Privacy_Means Design-Time Security&Privacy Means
22:08:38 <kaz> oliver: we should have discussion technology landscape during TPAC
22:09:25 <kaz> johannes: what is the granularity for the discussion?
22:10:23 <kaz> oliver: pick you interested atomic use cases
22:11:21 <kaz> ... should not go for binary (yes or no) method
22:13:12 <kaz> johannes: so we'll see the atomic use cases
22:13:52 <kaz> oliver: maybe the next step should be cleaning up the catalog description
22:16:45 <kaz> johannes: given the discussion so far including Kajimoto-san's talk, you already have some use cases
22:17:28 <ryuichi> ryuichi has joined #wot-ap
22:20:27 <kaz> kaz: the automotive wg is also working on security/privacy portion
22:20:36 <kaz> ... so we should collaborate with each other
22:20:50 <kaz> oliver: TPAC in Sapporo would be a good timing
22:30:25 <kaz> topic: Possible collaboration with the Autmotive WG and the MMI WG
22:30:57 <kaz> kaz: explains the security/privacy discussion by the Automotive WG
22:32:00 <kaz> -> https://www.w3.org/auto/security/wiki/Use_Cases security wiki
22:32:33 <kaz> kaz: also mentions the discovery/registration work and state transition discussion by the MMI WG
22:33:29 <kaz> -> http://www.w3.org/TR/2012/NOTE-mmi-discovery-20120705/ MMI discovery&registration draft
22:33:48 <kaz> kaz: and suggests we collaboratively work with those groups
22:34:04 <kaz> ... for example, TPAC 2015 in Sapporo would be a good opportunity
22:34:51 <kaz> johannes: Debbie Dahl, the Chair of the MMI WG joined one of the TF-AP calls and explained the MMI Architecture as the generic mechanism to handle state transition and application lifecycle
22:36:23 <kaz> [ afternoon break ]
22:36:33 <kaz> rrsagent, draft minutes
22:36:33 <RRSAgent> I have made the request to generate http://www.w3.org/2015/07/30-wot-ap-minutes.html kaz
22:53:23 <kaz> topic: Technology Landscape
22:53:35 <kaz> johannes: would talk about technology landscape
22:54:38 <kaz> ... the IG Charter mentions "Survey of Existing Practices and Standards Relevant to the Web of Things"
22:54:57 <kaz> -> http://www.w3.org/2014/12/wot-ig-charter.html#deliverables WoT IG Charter
22:55:41 <kaz> -> https://www.w3.org/WoT/IG/wiki/APIs_and_Protocols_TF#Technology_Landscape Technology Landscape wiki
22:56:35 <kaz> johannes: protocols and resource models
22:58:14 <kaz> ... after TPAC, we'll have a readable version of this landscape description
22:59:33 <kaz> alan: can I put information on GotAPI?
22:59:47 <kaz> ... more than just a protocol
22:59:53 <kaz> ... rather a design pattern
23:00:37 <kaz> ... could be applied to anything
23:01:40 <kaz> ... will send summary to Johannes
23:02:54 <kaz> johannes: if people ask about protocol X, Y or Z, we can see the landscape document
23:03:11 <kaz> [ States ]
23:03:36 <kaz> johannes: put some information on possible states together
23:03:58 <kaz> s/together/together based on Kajimoto-san's talk/
23:04:19 <kaz> [ Technology landscape of TF-AP ]
23:04:45 <kaz> johannes: review what we discussed so far
23:06:18 <kaz> s/review/reviews/
23:06:24 <kaz> rrsagent, draft minutes
23:06:24 <RRSAgent> I have made the request to generate http://www.w3.org/2015/07/30-wot-ap-minutes.html kaz
23:21:09 <kaz> topic: Joint meeting with TF-TD
23:21:20 <kaz> Present+ Dave
23:21:38 <kaz> [ Protocol-agnostic resource model for web things ]
23:21:57 <kaz> johannes: properties, actions, subscriptions/event sources
23:23:00 <kaz> [ Properties ]
23:23:12 <kaz> johannes: read-only/read-write properties
23:23:17 <kaz> ... configuration
23:23:33 <kaz> ... and dynamic properties
23:23:37 <kaz> [ Actions ]
23:23:57 <kaz> johannes: invokable actions on physical things
23:24:34 <kaz> [ Events ]
23:24:36 <kaz> [ Discussion ]
23:25:04 <kaz> johannes: link to TF-TD on media types and data structures
23:26:10 <kaz> dsr: think about services
23:26:47 <kaz> ... server provides APIs
23:27:05 <kaz> ... register a proxy
23:27:19 <kaz> ... need URI to identify the resource
23:27:55 <kaz> ... when you change the proxy, how the change would propagate?
23:28:20 <kaz> ... all the proxies need to notify
23:29:11 <kaz> johannes: the difference is that we're expected to subscribe some specific property
23:29:41 <kaz> dsr: question of granularity
23:30:05 <kaz> ... if you have a million/billion of protocols
23:30:17 <kaz> s/if/what if/
23:30:46 <kaz> johannes: maybe we don't have to subscribe all the resources
23:31:33 <kaz> ... how to model APIs?
23:31:47 <kaz> ... for example, if I want to know the temperature of this room
23:31:57 <kaz> ... how can I do that?
23:34:44 <kaz> ... not necessarily controlling things
23:41:01 <kaz> michael: properties and events need to be mapped with existing mechanism
23:46:33 <kaz> johannes: negotiation of protocols
23:48:20 <kaz> ... add note: Things can be exposed through several end points
23:49:20 <yukimatsuda_> yukimatsuda_ has joined #wot-ap
23:51:50 <kaz> don: time information?
23:52:06 <kaz> dsr: within home, there is some mechanism for time synchronization
23:53:19 <kaz> johannes: would mention proxies?
23:53:49 <kaz> don: large number of proxies
23:53:56 <kaz> dsr: depends on the use case
23:55:05 <kaz> don: proxy servers, embedded servers
23:55:18 <kaz> ... double security nightmare
23:56:14 <kaz> johannes: we also talked about security today
23:57:01 <kaz> ... who should be in and out?
23:57:09 <kaz> ... how to identify who calls whom
23:57:35 <kaz> dsr: security risk?
23:57:47 <kaz> ... what kind of security requirement?
23:59:08 <kaz> [ Discussion topics of TF-AP ]
23:59:22 <kaz> johannes: not contradictory with this kind of model?
23:59:29 <kaz> (no objection)
23:59:41 <kaz> johannes: will brush up this for tomorrow's discussion