Meeting minutes
previous minutes
<kaz> Nov-6
Ege: they look fine
Ege: any comments?
Ege: minutes approved
Initial connection
<kaz> PR 2040 - Initial/Common Connection Container Proposal
<EgeKorkan> https://
Ege: I created this hackmd
… to play with the proposals
… I created two td examples
… first with Luca's idea
… seperating connections from form defaults
… the other one is mine plus some changes
… asked feedback in Siemens
… they liked the direction
… but they are not sure about optimizing too much
… my proposal is to remove commonDefinitions container
… it is quite redundant
… do we want to merge everything in one
Luca: the idea is that the security is a special case of connection configuration
… this means that if we have a container dedicated to configure a connection then security belong to that place
… low level details should be integrated in the container
Ege: yes low level details should be described in a protocol binding
Luca: one second level of common definition can be used to describe commonalities in the forms
… it is mainly useful to keep everything more tidy
… the idea of the proposal is to keep everything as compat as possible.
Ege: it would be fine
… how do we define the default connection ?
… in this proposal I am not sure what to peak as default mechanism
Kaz: This is a meta comment about how we should handle "Security for WoT". For today's discussion, we can focus on this example. But what is the basic assumption? From the view point of IoT and smart cities, etc., in general, we should focus not only at the network level but also to application and device level security
Ege: do you mean something like access control?
Kaz: yeah that part too.
Luca: about defaults in any case we have defaults
… if connection defintions is empty we have a deafault
… in practice we need both defaultForm and defaultConnection
luca explaining how to deal with defaults
Cristiano: what is the error conditions ?
Luca: current TD have already stack defaults
… it should be that complicated to implement this mechanism
… about the mistakes, current proposal is just about overrides
… it does not tackle what is a valid TD
… ofc we could deal with errors once all the defaults are applied.
Ege: there is something that overlaps between connection and form ?
… I'm interested on how to differentiate elements that goes in connection or form definitions
… with schema definitions is still as before
… about the root container
… do we want to have it or not?
Cristiano: is this finite set or dynamic?
Ege: it is finite
Cristiano: ok, plus it looks like another affordance, at least a little bit
… so I'm ok to remove it
Luca: I don't have a strong preference, but additional level is more future proof
… plus having that would allow to point to one single property and store configurations there
Ege: ok any other options?
… ok
Ege: in this proposal we are making possible to have "inline" security schemes
… which solves the problem to have to first declare security and then use it.
… most of security settings should be moved to protocol binding vocabulary
Luca: we can support inline by saying that a property could have a name or an object
… I want to have this mechanism as something consistent everywhere
Cristiano: I'm not seeing big problems, just look after weird cycles that might be created
Ege: schemas can be defined inside formDefintions
… I'll make a simple TD
… as well as complex TDs
[adjourned]