Meeting minutes
Agenda
Ege: today will have some quick notes at the beginning and then dive deeper into the discussion about binding mechanism
Kaz: I have short updates
… in last main call we discussed profile and we should talk about next steps
Ege: ok
minutes review
<kaz> June-26
Ege: we mostly talked about plug fest
… I have follow ups
Ege: I noticed an empty section
… I don't know why
… just small fixes around the "Tooling" section
… any other mistakes?
… minutes approved
Profile discussion next week
Ege: there are open points regarding TD in the Profile task force
… but there is no much of attendance from the TD task force.
… when should we discuss this points?
… kaz or luca which are the current options?
Luca: the idea is to devote half of slot to the items that are shared between TD and profile
… we can make progress
… we should try to cover both sides of the coin: make everything correct in profile and beign able to extend TD
<kaz> Profile discussion during the WoT main call on July 3
Kaz: my original expectation was also reusing part of the TD calls for Profile-related discussion, but McCool mentioned TD agenda was already full during the main call yesterday, and I got an action to generate a doodle to see another slot right before or after TD calls
… but if you all are actually OK with reusing part of the TD call, that still can be an option
Ege: we can
… but I'd like to have a dedicated slot
… either before or after
… share td call with profile might be good for exceptional topics
… we need another slot
Ege: I would try to find this slot
… and only as a second option share td time
Kaz: ok
… that's inline with the decision during the main call yesterday, and I ca create a doodle poll. I just wanted to confirm the direction mainly with Ege since you were not there at the main call.
WoT week plugfest
<kaz> WoT Week in November
Ege: in the agenda a created points to keep an eye on for WoT week plugfest
… however I don't want to copy and paste them everytime
… where should I place them?
Cris: don't we have a dedicated place for plugfest organization?
Ege: yes we usually use the events folder in the wot-testing repository
… I'll move it there
Initial connection
<kaz> Issue 2025 - Extending the initial/reusable connection examples
Ege: I'm working on updating the marmaid schema to draw.io
… this is also useful for writing in the spec
… I won't make an example for all wot operations in every protocol
Cris: that's ok
… it's only needed for reference of the reader
Binding templates registry mechanism
<kaz> Registry analysis including draft policy
Ege: we should get rid of everything that has a todo label
… first point is the lifecycle
… I propose to use the last policy that was accepted in the WG
… it's about errata
… there is a point which mention what happens if the WG is not available
… I suggest to add that if the WG is not active anymore the W3C team takes over and can decide
Cris: +1
Kaz: probably the W3C Project Management Team should handle the registry at that time, but maybe we could think about a dedicated CG for that purpose.
… I think we should talk with Philippe about what would be the best solution at some point.
… also, that is a good topic for breakout breakout or a joint session Verifiable Credentials, etc., during TPAC.
<Ege> Proposal: If the WoT WG does not exist anymore, the W3C Team or their delegated entity becomes the custodian.
Kaz: I'd suggest to updatie the proposed resolution text above to say "We'd like to propose...", since we don't have the registry itself yet.
… with "we would like to propose"
<Ege> Proposal: For the potential binding registry, we would like to propose the requirement of "If the WoT WG does not exist anymore, the W3C Team or their delegated entity becomes the custodian."
RESOLUTION: For the potential binding registry, we would like to propose the requirement of "If the WoT WG does not exist anymore, the W3C Team or their delegated entity becomes the custodian."
Mahda: spotted a typo
Ege: next point is more technical
… the requirement is obvious -> there should not be two bindings regarding the same protocol
… but what happens when you have two ecosystems?
… for example protocol over another application protocol like coap
… still in this case there should not be two bindings competing witch each other
… we can use a layered approach
… a binding can refer another binding
mjk: this is the right direction
… it's important that if another binding that needs coap does not change what is in coap
… probably there is no such thing as a pure coap binding
… maybe they are just default
… same goes for http
Ege: pure binding can be use for testing
Cris: I guess in the end the only mechanism that works to assure no duplicates is that the reviewer is in charge of verifing common parts with other bindings.
Luca: what needs to be clear is that once you take the namespace is up to you to control it
… and nobody else can redefine
… or add keywords
… remember that if is not the registry then is not conformant
Ege: another thing to discuss is defaults
… ocf can change defaults for coap ?
Luca: it is a topic for degraded consumption
… if a consumer understand ocf then it applies its defaults
Luca: otherwise it might refuse to use the form
Ege: it depends
… with ocf you could be verbose and still be used by a generic coap
… consumer
Luca: you can duplicate forms
… one for OCF and the other for CoAP
Luca: for the future we should declare which binding the form is using.
Cris: I would not create a new binding just because it changes a bunch of default in the lower leve
<mjk> +1 to cris point
<mjk> maybe OCF, LWM2M, etc. should all be profiles and not bindings
Cris: +1 to mjk's point
<mjk> maybe bindings choose a protocol driver and profiles define API patterns
Kaz: I was also thinking about the relationship between Binding and Profile for this point. Probably it could be included in the agenda for the possible TD-Profile calls
… On the other hand, the question here is kind of similar to the issue around dialects of natural languages, e.g., American English vs British English
… I personally think we should define how to deal with both (1) the base language part like English (or CoAP) and (2) the dialects of the base language like American English and British English (or CoAP-based protocols)
… anyway, we need to discuss more concrete variations and use cases
… BTW, we can keep track all the "TODO"s within the Registry Analysis document as separate GitHub Issues for future discussion, can't we?
Ege: Good point
Ege: AOB for today?
Ege: nothing
[adjourned]