Meeting minutes
Minutes
<kaz> Oct-23
Ege: any objections on the minutes?
(None; Approved)
Organizational
Ege: tomorrow we will discuss the use case
Toolchain
Ege: Not really new information
… We want to showcase with mahda, compare whether the new way of doing things is easier in comparison to the current way
Initial Connection
<kaz> TD.Next Usability and Design Work Items
Ege: we need to agree on the names, we left it open last time intentionally on the PR
… is there any opinions on what the commonDefinitions and connectionDefinitions should be called? This is up to us to invent
… there should be different names otherwise semantic processing and linkability are broken
… we should avoid having the same term in two places
Luca: Naming things are hard, I don't have strong opinion on naming things, as long as it is consistent. One other item that appeared in Github and is worth discussing is, if we are going to use Form as a holder for the connection or we use another vocabulary term to include the connection setup?
Ege: I didn't understand
Luca: I try to explain the problem: my proposal was to keep the two items seperate, we have different forms and last time we decided that since we have defaults for a bunch of stuff we put a container around them so that everything is tidy. But, the part we didn't discuss was that if we want to use the Form as a connection setup or we use another connection?
… the current situation is that, we have the security definition which are a special case of connection setup, the part we didn't discuss was...
… one item is that, security goes away and is a connection
… it is nit a deal breaker, since the two ideas are separate, but would be good to see if we have consensus in that regard.
Ege: Would be good to see an example
Luca: one problem is that, we need a transport that needs a setup, currently we don't have a protocol that acts in this way
Ege: what do you mean with transport having a setup
Luca: the transport setup can be very special HTTP, and inside we say HTTP version 3, or QUIC
Ege: It would be good if you could make an example
Luca: I can do now
Ege: I realized I didn't reply to Ben Francis, and will have to do this
Ege: Luca please provide the comment and i will have look at it async
Registry
<kaz> registry-requirements.md
<EgeKorkan> w3c/
Ege: There was some refactoring on this document, each section is going to be a section in the registry document. We have the intro section which has already been decided. Then we say in terms of the content of registry definition we provide entry format, lifecycle of entries and what is the requirement for the submitted documents to contain per
lifecycle. For the entry requirements, we have no points to discuss. There is one thing to discuss.
… We agreed that an entry can contain a name, and a link, we have to document the prefixes to not do RDF processing, we need to document how it can be identified in the TD
… the reason this is still open is that whether we keep the subprotocol href or we provide other things
… once there is the entry it should have a status, this is dependent on the lifecycle discusion
… I would like to get opinions
… Regarding how things are submitted, label stuff and assign it to people it would make more sense to restrict the issues. Is there opinions on how bindings would be submitted?
… If there are no objections, I would remove my name from the mentioned points
… of course the review has to happen and the custodian makes a PR to add a binding
… there is an overall thing about versioning of an enetry, in the current entries we have analyzed it is not possible, they either allow deprecation or double
… We do not allow updates of a registry content, should not be updated randomly, but a new version can be submitted.
… would we allow two versions of a binding to stay in a registry?
… there were previously points from Cristiano and Luca
… do we have any opinions on this so far?
there is a need for an example, which has to be doone
… next point is about deletion of an entry, we either move them to another table or deprecate them
… Do we have opinions on whether entries should be deleted?
… any objections?
Luca: I agree with that. I also completed an example
<JKRhb> +1
Ege: We need to agree on the status and how it gets changed
Luca: if you want to add another option, you can add provisional, draft, and current instead of Final
Ege: I would remove Final. I also though of "stable".
Jan: I was wondering if existing implementations can also trigger change. Maybe the stable label could be applied to alternative implementations
Ege: The discussion of how we change from one label to another, I will come to
… seems that these three states seem fine
… the point from transition, this is also part of the discussion on requirements. I will just write my point and what Jan mentioned in the document
… we need to discuss the ownership part, we say that the working group is the owner
… there is another point, who is the reviewer?
… I say this because, IANA registries involve external reviewers, I think called expert reviews
… I think all the entries should make sense in the context of WoT, but if we get a protocol that is unknown to the working group, we should get an external reviewer
… do we have an opinion on this?
(none)
… I would suggest the following: if there is an expert of the binding entry's specification within the custodian entity, they can do the review on their own. If that is not the case, the custodian MUST look for an expert of that specification and a Web of Things expert
Cristiano: is this in the context of WG or in general?
… I think we should specify that WG has the power to reject the expert or suggest and expert.
Ege: it's up to the custodian
… if the WG doesn't exist, the delegated entity becomes the custodian
… Ege updates the document
Cristiano: I think it works now like that
Kaz: As I mentioned before, we need to talk with PLH about this at some point, but technically, creating a dedicated CG for maintenance might be a possibility.
Ege: you mean now or whether WG doesn't exist?
Kaz: whichever is possible
Ege: I think doing this now would give a bad message, but for future I am fine
Kaz: so we can include that possibility as well
Ege: Ege updates the text accordingly to Kaz points
Jan: who makes the final decision?
Ege: I think suggesting would not make sense, Ege updates the text accordingly.
… maybe one edge case, what if these two people are the same
Cristiano: I think thats fine
Initial Connection - revisited
<kaz> Luca's updated comments on PR 2040 - Initial/Common Connection Container Proposal
Ege: We will go back to Luca's example
Luca: assume we have connection definitions which is the main container, inside there is some protocol specific items, transport, and some other information such as tls:cyphers. Then, on our bases, we can refer to our connection Definitions. My form would be only the operations...
Ege: I think overall it makes sense to include these, but how will people differentiate where to put things, like in Modbus. Maybe we shuld have one and merge them.
Luca: As I said, we have these two options
Ege: for example an MQTT broker would go in the frst one?
Luca: All the broker information could be a connection defintion, and usually you do not want to say, in order to connect to an MQTT broker you have to connect to this broker, version, etc., that motivates why having connection definitions is a good idea. It's like security.
… you don't have to repeat
Ege: This would be really pure default mechanism
Cristiano: default for forms?
… can't we just name them form definitions?
Luca: That was just the starting point, but form definitions makes alot of sense
Ege: I think I like it
Cristiano: About the use case we discussed in the last CG meetings, do we sort of understand the protocols that the TD uses or do we still need to go through all the forms?
Luca: the partial connection definition could be a set of allowed derived schemes
Ege: this would destroy the connection using other connection
Ege: where would the base go in case of HTTP?
Luca: That would also be open, if we want to put the bases, we can put it in the connectionDefinition or ...
… so the part is, the base uri could be either something as we put default in the form or we give up using it in the links
[adjourned]