15:02:35 RRSAgent has joined #wot-td 15:02:39 logging to https://www.w3.org/2024/02/14-wot-td-irc 15:02:45 meeting: WoT-WG - TD-TF - Slot 1 15:03:25 Ege has joined #wot-td 15:03:31 present+ Kaz_Ashimura, Ege_Korkan, Ben_Francis, Daniel_Peintner 15:04:23 dape has joined #wot-td 15:05:17 present+ Cristiano_Aguzzi 15:06:11 agenda: https://www.w3.org/WoT/IG/wiki/WG_WoT_Thing_Description_WebConf#February_14_and_February_15%2C_2024 15:07:21 ktoumura has joined #wot-td 15:08:00 scribenick: Ege 15:08:17 topic: minutes review 15:08:28 -> https://www.w3.org/2024/02/07-wot-td-minutes.html Feb-7 15:09:22 ek: anything to change? I only see name issues for daniel and koster 15:09:57 topic: TD Resource Versioning 15:10:06 cris_ has joined #wot-td 15:10:10 present+ Kunihiko_Toumura 15:11:11 ek: we have met with Mahda, Luca and Klaus. We discussed tooling 15:11:26 ... we documented everything at https://github.com/w3c/wot-thing-description/pull/1969/files#diff-5a1e620a21f1c28a342f17f7b625150e976e6d75bc4bc1ba8c24dad36d9249b8R90 15:11:32 q+ 15:12:05 ... basically we can leverage npm to do a bunch of stuff 15:12:07 ack dape 15:12:20 i|we have|-> https://github.com/w3c/wot-thing-description/pull/1969 PR 1969 - WIP: Concrete Versioning Proposal| 15:12:50 Mizushima has joined #wot-td 15:13:03 q+ 15:13:06 dp: do we want to publish packages with each PR 15:14:14 ek: maybe monthly but we do not need many additional stuff 15:14:40 kaz: we should not overcomplicate it but write the requirements first 15:14:54 ack k 15:15:04 ek: yes we have identified overall problem areas 15:15:13 present+ Tomoaki_Mizushima 15:16:02 ... but we want to keep it simple 15:16:13 topic: Profile Design 15:16:53 bf: we have discussed this before but I want to show the strawman proposal 15:17:22 ... we have two mechanisms to define protocol bindings, binding templates and profiles 15:17:37 ... bindings are descriptive, profiles are prescriptive 15:17:49 ... I have a proposal for another type of approach 15:18:07 i|we have|-> https://lists.w3.org/Archives/Public/public-wot-wg/2024Feb/0000.html Ben's strawman proposal| 15:18:12 ... for profile and bindings to work better together 15:18:14 rrsagent, make log public 15:18:18 rrsagent, draft minutes 15:18:19 I have made the request to generate https://www.w3.org/2024/02/14-wot-td-minutes.html kaz 15:18:59 ... 3 specs define bindings: TD, HTTP Binding Template and HTTP Basic Profile 15:19:14 ... profiles go into more details 15:19:31 -> https://w3c.github.io/wot-profile/#http-basic-profile WoT Profile - 6. HTTP Basic Profile 15:20:05 ... I propose removing section 8.3.1 of TD spec 15:20:06 present+ Jan_Romann 15:20:32 ... and merging http binding and profile 15:20:51 q+ 15:20:52 ... profile can use the defaults of the http binding template 15:21:12 JKRhb has joined #wot-td 15:21:31 -> https://w3c.github.io/wot-thing-description/#http-binding-assertions WoT Thing Description Editor's Draft - 8.3.1 Protocol Binding based on HTTP 15:21:40 ... I have some google docs files that are meant to be thrown away, they are just discussion starters 15:22:04 -> https://docs.google.com/document/d/1msgUZSrniTrgVieU2i_V2804gqvVsHrYByTv-OET1l8/edit?usp=sharing WoT HTTP Protocol Binding 2.0 proposal 15:22:58 ... actions are tricky though 15:23:47 luca_barbato has joined #wot-td 15:23:54 ... since it is not possible to specify manageable actions in td but it is part of the TD 2.0 workitems 15:24:44 ... now let's see the HTTP 2.0 profile proposal 15:25:09 ... each category has some tables that explains each part 15:25:34 q+ 15:26:23 ... we should think about the normativeness 15:26:34 -> https://docs.google.com/document/d/1LjBWiqQZXi85gXP2NNckQni5os6dwxW6UDGrZDb3cns/edit#heading=h.71drcnjjomtn WoT HTTP Basic Profile 2.0 proposal 15:26:44 ... if profiles depend on bindings, which are not normative, they cannot be normative as well 15:27:02 present+ Luca_Barbato 15:27:20 -> https://github.com/w3c/wot-profile/issues/285 wot-profile Issue 285 - Profile Mechanism 2.0 15:27:36 ... another approach is to define subprotocols but that would give less interop by default 15:28:07 ... daniel asked what will happen to profile 1.0? I think we should publish profile 1.0 as a note 15:28:15 q+ 15:28:28 q+ 15:28:54 ... in both case profile 2.0 will be not compatible with profile 1.0 15:29:13 subtopic: Questions 15:29:44 dp: long running actions that is currently breaking "vanilla" implementations like node-wot 15:30:35 ... TD and binding should open the hooks for profiles 15:30:40 q+ 15:30:47 ... so would profiles always be a subset of the TD and binding 15:31:43 bf: Ideally yes 15:32:24 ack dape 15:32:34 ... but I am worried that some parts of the TD can not evolve enough for profiles to support that 15:33:34 bf: I want to structure what a profile can be 15:37:14 present+ Michael_Koster 15:37:55 mjk has joined #wot-td 15:39:23 q? 15:39:57 ek: I like the direction. the table of contents is a good direction 15:40:07 ... we need to agree on the context 15:40:25 s/on the context/ on the purpose 15:41:56 (Ege@@@) 15:42:04 ack ege 15:42:20 ca: sorry for not following up on the mailing list 15:42:27 ... I like the direction overall 15:43:01 ... thank you for the work. Discovery can be brought into bindings somehow? 15:43:23 ... since discovery and protocols are closely related 15:43:39 q? 15:43:44 ack c 15:44:20 ... I agree with daniel that we should not circumvenite the TD spec to add stuff to profile. If we do that, both specs fail 15:45:09 bf: as it currently stands, all discovery specs are in discovery spec. So the proposal is a subset of the mechanisms there 15:46:16 ... I would be ok to not have some defaults if it means that mechanism is not in the td spec first 15:46:38 kaz: thank you for the proposal and it is a good input. three comments 15:47:02 ... refactoring of wot specs is necessary but it is a question for the whole group 15:47:42 ... we need to clarify what we mean by this profile and profile in general. Some proposals were extensions of TD 15:47:57 ... so we need to agree on what to specify by which spec 15:48:04 ... we need more use cases about the specific features 15:48:36 ... like async or sync actions that remind of media related apis or media and text streams 15:48:54 ... we should clarify if that would be a target for this mechanism 15:49:52 bf: profile should be constraints but in some cases we went towards extensions 15:50:04 ... everything should be UC driven but this was from a use case in the beginning 15:50:12 q? 15:50:13 ack k 15:51:11 lb: in multimedia, a profile is a subset of a codec 15:51:57 ... so we can do something like where we make the TD as descriptive and expressive as possible and then profiles constrain it 15:52:09 ... we can even target cases like resource constrained devices 15:53:03 ... TD can be extended a lot via semantic annotations 15:53:23 ... so when that happens, we need to talk about what happens when a consumer doesn't understand it 15:54:00 ... in media, a codec profile cannot extend the codec 15:55:29 ... discovery is outside of TD. We can say that it is completely orthogonal to TD 15:57:35 ack lu 15:57:44 ... we have to define how profiles can be composed 15:58:22 bf: a Thing can conform to a profile but it can do more. An HTTP basic TD can also have mqtt endpoints on top 15:58:45 ... we have to make sure that two profiles do not conflict but I think profiles can be always combined 15:59:43 q+ 15:59:43 ... there are also overlaps in discovery service api and profiles 15:59:43 q? 16:00:27 q+ 16:00:30 ack c 16:00:34 ca: discovery is orthogonal but you generally use the same protocol to use the TDD API and to interact with the THing 16:00:39 q+ to whisper we're out of time 16:01:29 lb: Discovery has a larger scope. we cannot describe mdns with a TD for example 16:02:14 ... in mdns you have coap not http. It is an interesting topic to discuss 16:04:58 kaz: we need to also discuss wot specs refactoring as a wg 16:05:49 rrsagent, draft minutes 16:05:50 I have made the request to generate https://www.w3.org/2024/02/14-wot-td-minutes.html kaz 16:07:06 s/(Ege@@@)/I had some points but I like the structured approach. We did not have concrete use cases for profiles from Siemens but we are discussing this at the moment. Maybe UI profiles or browser compatbility profiles make sense. The word profile was confusing to some in Siemens. Also, why do we constrain links in an http profile? In general, we should discuss the scope 16:07:46 @kaz luca is going to edit his points now 16:09:00 s/you have coap not http/you can have both http and coap right now, it is expected that a tiny Thing implementing coap would advertise using mdns+coap or other coap-related protocols instead/ 16:09:11 s/I had/... I had/ 16:09:15 rrsagent, draft minutes 16:09:17 I have made the request to generate https://www.w3.org/2024/02/14-wot-td-minutes.html kaz 16:10:05 chair: Ege, Koster 16:10:05 chair: Ege, Koster 16:10:05 rrsagent, draft minutes 16:10:36 I have made the request to generate https://www.w3.org/2024/02/14-wot-td-minutes.html kaz 16:10:43 Just one comment on the minutes: I said that my preference is to publish Profiles 1.0 as a REC, but I think there's also an argument to publish it as a Note and move onto Profiles 2.0. 16:10:43 s/@kaz luca is going to edit his points now/[adjourned]/ 16:11:38 rrsagent, draft minutes 16:11:39 I have made the request to generate https://www.w3.org/2024/02/14-wot-td-minutes.html kaz 18:28:32 Zakim has left #wot-td